This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
|
Hello, It seems that at least two other people in thsi list are interested in a port of the xsoc project to burched spartan II board using VHDL. I was wondering if someaone has really started doing something on this or no. Actually I might start considering porting the project to vhdl but since it represents at lot of work, i would like to know if someone 'real' work was actually done so that I wouldn't start form scratch. Thanks Steven |
|
|
|
Hi Steven >It seems that at least two other people in thsi list are interested >in a port of the xsoc project to burched spartan II board using VHDL. Yes, I am interessted in porting xsoc to the burched board. Personally I prefer VHDL as well. >I was wondering if someaone has really started doing something on >this or no. Actually I might start considering porting the project to >vhdl but since it represents at lot of work, i would like to know if >someone 'real' work was actually done so that I wouldn't start form >scratch. Nope. I havent really started working on it, I was simply too busy and concerned with other things.. But I would appreciate collaboration very much. As the Verilog sources for xsoc (gr00041) are quite small, it should be quite esay to port these to VHDL. As the burched board allows to connect the extension boards (RAM,LED,CPU-IO module) to virtually any of its connectors, we could agree on some kind of standard configuration to facilitate code exchange. Regards, Christian |
|
|
|
--- In fpga-cpu@y..., Christian Plessl <cplessl@e...> wrote: > Hi Steven > > > It seems that at least two other people in thsi list are interested > > in a port of the xsoc project to burched spartan II board using > > VHDL. > > Yes, I am interessted in porting xsoc to the burched board. > Personally I prefer VHDL as well. > > I was wondering if someaone has really started doing something on > > this or no. Actually I might start considering porting the project > > to vhdl but since it represents at lot of work, i would like to > > >know if someone 'real' work was actually done so that I wouldn't > > start form > >scratch. > > Nope. I havent really started working on it, I was simply too busy > and concerned with other things.. But I would appreciate > > collaboration very much. As the Verilog sources for xsoc (gr00041) > > are quite small, it should > be quite esay to port these to VHDL. Actually i was considering the port of the xr16 core (the verilog version actually synthesizes and pars perfectly on a Spartan II), since there is an C compiler available for it (this is not the case for gr0041) For the moment i'm more concern with RTL level simulation than real implementation and since I don't have a verilog simulator, I therefor need a VHDL version. (I have tried to generate some post synthesis vhdl netlist, but this is not very handy, and too slow for my purpose) > As the burched board allows to connect the extension boards > (RAM,LED,CPU-IO module) to virtually any of its connectors, we could > agree on some kind of standard configuration to facilitate code > exchange. Sure. > Regards, > Christian |
|
|
|
Veronica Merryfield wrote: > Porting gcc would be much more work than lcc. I would put it at a magnitute. > There is a lot more to gcc than lcc. However, if you want features of gcc > and have the software skills, then it is possible but be prepared for the > time required. I thought the code generation for GCC was table driven, change the tables and off you go with a new CPU. I have seen files that will have gcc compile for the 6089, but they are several years old.Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk Updated - Now with schematics. |
|
|
|
>Actually i was considering the port of the xr16 core (the verilog >version actually synthesizes and pars perfectly on a Spartan II), >since there is an C compiler available for it (this is not the case >for gr0041) Well your right. Having a C compiler is essential for using the SoC later on, but personally I would perfer gr004x. A gr004x compiler could be derrived be retargetting lcc for instance looking at the implementation of the xr16 compiler, or by porting gcc, but I dont know, whether this is a major effort or not. gcc seems much more complex than lcc. xr16 is a Verilog specifiaction of the xr16 CPU, which initially has been designed using schematic entry. This results in quite low-level verilog code, operating on very detailed RTL level. This results in a very small and fast implementation of course. But consequently, it lacks a little bit of abstraction. The gr0040 series was designed in a HDL from the beginning, resulting in more readable and understandable Verilog code, which I consider more usefull. Verilog or VHDL is not a very critical question for me. I'm used to VHDL, but I appreciate the conciseness of Verilog, compared to VHDL, which is a rather chatty language, resulting in many lines of code. Regards, Christian -------------------------------------------------------------- Christian Plessl phone: +41-1-6327029 Gloriastr. 35, ETZ G-81, fax : +41-1-6321035 CH-8092 Zurich, Switzerland email: Computer Engineering and Communication Networks Lab (TIK) Swiss Federal Institute of Technology (ETH) Zuerich -------------------------------------------------------------- |
|
>on, but personally I would perfer gr004x. A gr004x compiler could be >derrived be retargetting lcc for instance looking at the implementation of >the xr16 compiler, or by porting gcc, but I dont know, whether this is a >major effort or not. gcc seems much more complex than lcc. Porting gcc would be much more work than lcc. I would put it at a magnitute. There is a lot more to gcc than lcc. However, if you want features of gcc and have the software skills, then it is possible but be prepared for the time required. I have a suspision that the newer versions of gcc are designed assuming 32 bit. Veronica |
|
project home page http://gcc.gnu.org howto setup gcc as a cross compiler http://www.objsw.com/CrossGCC/ and most importantly modifying the backend to support your instruction set http://gcc.gnu.org/onlinedocs/gcc_19.html and from here it seems that it "likes" a 32 bit register and a bunch of them at that. http://gcc.gnu.org/onlinedocs/gcc_15.html#SEC170 another avenue would be using SDCC, but really only targets 8051 and Z80 (pic in the works) http://sdcc.sourceforge.net/ I guess the major impetus for getting gcc to work on your target device is to compile megs and megs of gnu software. But if you only have a 16 bit register this is going to require a rewrite. IMHO not worth it. I would only port gcc to platform that had int >= 32 bits. Or else you could write a software emulation layer for 32 bit ints like what people do on the PIC chips. Am I on crack? Sean. On Tue, 22 May 2001, Ben Franchuk wrote: > Veronica Merryfield wrote: > > > Porting gcc would be much more work than lcc. I would put it at a magnitute. > > There is a lot more to gcc than lcc. However, if you want features of gcc > > and have the software skills, then it is possible but be prepared for the > > time required. > > I thought the code generation for GCC was table driven, > change the tables and off you go with a new CPU. I have seen > files that will have gcc compile for the 6089, but they > are several years old.Ben. > -- > "We do not inherit our time on this planet from our parents... > We borrow it from our children." > "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk > Updated - Now with schematics. > > To Post a message, send it to: > To Unsubscribe, send a blank message to: |
|
Yes, it is driven by tables. Or, well, it was in versions 1.x I think DJGPP (1) port had the tables for the 386, and I remember there were some docs on that topic. By the way. I've seen lcc generating ASM code, not binary code. Is it necessary to use an external assembler? Bye! > I thought the code generation for GCC was table driven, > change the tables and off you go with a new CPU. I have seen > files that will have gcc compile for the 6089, but they > are several years old.Ben. |