Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Ads
Discussion Groups
Discussion Groups | FPGA-CPU | xr16 ISA reimplementation
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).
6502 compile time and area - Author Unknown - Mar 9 14:39:00 2001
|
1.) I compiled the free-ip 6502 in a couple of minutes on a Celeron 600. 2.) If you estimated the size of your cpu succesfully, could you pease add the results to: http://www.prowokulta.org:80/phpwiki/index.php?SoftCPUs Your competitors achieved 700, 1100 and 1800 XC4K LUTs respectively. 3.) The free-ip webpage has not been updated since june 2000. I sent email to the creator of the Free-6502 and got no response. The reason for my email was a small test: I took one of the microcode ROMs (ALU-Control) and substitutes don't cares for NOP whenever the ALU result was not used. This reduced the size of the ROM from 52 LUTs to 20 LUTs. Since most of the area of the design is ROM, a considerable area improvement should be possible. If there continues to be now response, I might do this work myself on e day :-) CU, Kolja Sulimma |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 6502 compile time and area - David Kessner - Mar 9 15:07:00 2001
|
wrote: > 3.) > The free-ip webpage has not been updated since june 2000. > I sent email to the creator of the Free-6502 and got no > response. > The reason for my email was a small test: I took one of the > microcode ROMs (ALU-Control) and substitutes don't cares for > NOP whenever the ALU result was not used. This reduced the > size of the ROM from 52 LUTs to 20 LUTs. > > Since most of the area of the design is ROM, a considerable > area improvement should be possible. > > If there continues to be now response, I might do this work > myself on e day :-) Damn, I would have swore that I wrote a response! But I checked my old emails (I do keep them all), and sure enough, I missed that one. I do remember giving it considerable thought. Basically, you're right. Having a lot of don't cares in unused ROM entries would make it smaller. One possible side effect, and the only one that I can see, is increased power consumption because registers that don't need to be flipping might (I'm thinking of beyond just the ALU control here). But it would be smaller. I didn't do that in the Free-6502 core for several reasons. #1 was that I'm not convinced that all synthesis programs out there will handle that correctly. And #2 was that it would make the source code much less readable. As far as I know, I would not be able to use an enumerated data type _and_ have a don't care. Without enumerated data types, the entire core would become one wild mess! For the Free-IP cores, I place a priority on portability and readability over speed and size. On the other hand, if someone can show me how to do an enum with don't cares then it should be very easy to convert. Probably a 2 hour job. Ben Franchuk <> said: > PS. I have read somewhere on the net that the 6502 is very nasty > cpu to synthesize for a FPGA because some FPGA's handle random logic very > poorly and the early CPU's had a large a amount that. Nobody wants to > do a 6800 in a FPGA for some reason. Many CPU's, not just early CPU's, have a lot of random logic. What makes early CPU's difficult is that they were not pipelined, had large microcode ROM's, and had lots of internal tri-state busses. These makes it difficult to do in an FPGA. Another thing to remember is that these early CPU's were often designed at a very low level-- at the gate and sometimes the transistor level. There are lots of tricks that you can do at the low level that is difficult to effectively reproduce in something that is higher level. It's a bit like comparing assembly language with C++. I actually considered doing a 6800 core, and the Free-6502 core was a type of "conceptual proving ground" for that. The reason why I didn't go ahead with the 6800 core was two fold. First there were the legal issues (no one is going to sue over a 6502), but Motorola has lots of investment into the 6800 that they will defend. But the larger issue is the size of the 6800's microcode ROM. That ROM is huge and not something that is effective to put into an FPGA. There are some simple 32-bit RISC processors out there (like the MIPS R3000) that would actually be smaller in an FPGA than the 6800. David Kessner |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 6502 compile time and area - Author Unknown - Mar 9 15:32:00 2001
|
--- In fpga-cpu@y..., David Kessner <davidk@f...> wrote: > Damn, I would have swore that I wrote a response! But I > checked my old emails (I do keep them all), and sure enough, I > missed that one. I do remember giving it considerable thought. Hi! It's good to see that I am not the only one who forgets to answer his mail :-) When you did not respond I thought the free-6503 would be a dead project --- isn't :-) > Basically, you're right. Having a lot of don't cares in unused ROM > entries would make it smaller. One possible side effect, and the > only one that I can see, is increased power consumption because > registers that don't need to be flipping might If the area savings are as large for the other ROMs as for the alu control, you will gain rather large power savings from less switching interconnect (That's where the largest capacitances are). It is hard to tell what the net gain will be. Another argument that I read on this topic, is that signal with don't care values on them complicate verification, because the behaviour of these signals might change from sythesis run to synthesis run. Formal verification becomes impossible. But: Nobody can afford these tools anyway. > I didn't do that in the Free-6502 core for several reasons. #1 was > that I'm not convinced that all synthesis programs out there will > handle that correctly. It is part of the IEEE-Standard. They better should. > And #2 was that it would make the source > code much less readable. As far as I know, I would not be able to > use an enumerated data type _and_ have a don't care. Without > enumerated data types, the entire core would become one wild > mess! I believe you can use enumeration types with don't cares, but you must explicitly specify the state encoding. First I thought that this would hurt the synthesis result, because I expected the tools to do state encoding optimization, but then I read that FPGA-express just numbers the state in the order that you list them. > For the Free-IP cores, I place a priority on portability and > readability over speed and size. And you are allready smaller and faster than most commercial ones. > On the other hand, if someone can show me how to do an > enum with don't cares then it should be very easy to convert. > Probably a 2 hour job. Let me tell you that I really, really like your excel micro code approach! CU, Kolja |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
ISA copyright - Author Unknown - Mar 9 15:40:00 2001
|
> The reason why I didn't go ahead with the 6800 core was two fold. > First there were the legal issues (no one is going to sue over a > 6502), but Motorola has lots of investment into the 6800 that they > will defend. IANAL, but AFAIK it is very hard to legally protect an ISA. It is for sure impossible in germany, and my impression from verious texts that I read, the protection in the US is very weak. The usual approach is to patent some architechture detail that you believe is absolutely necessary to implement your ISA. That way a competitor can only be 99% compatible. (Examples for this are the pentium burst order, some special cases of skip instruction, etc.) This approach is not very succesfull, and for the 6800 all the patents should have run out by now. Motorola gets there money for silicon, not for ISA licenses so they should not be to grumpy. But you should not mess with the people who make there whole revenue from IP money, like MIPS or ARM. In this context I have a question to Jan Gray: Jan, do you consider the xr16 ISA as protected your license or just your HDL source code and documentation? CU, Kolja |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: 6502 compile time and area - David Kessner - Mar 9 16:00:00 2001
|
wrote: > > I didn't do that in the Free-6502 core for several reasons. #1 was > > that I'm not convinced that all synthesis programs out there will > > handle that correctly. > It is part of the IEEE-Standard. They better should. These tool makers have a long history of not completely adhering to the standard. For example, some tools used to not accept this: process begin... (simplified version) if clk'event and clk='1' and clk_enable='1' then ... Yet they would accept this: process begin... if clk'event and clk='1' then if clk_enable='1' then ... These are, of course, identical from a VHDL standard perspective but the synthesis tool wouldn't accept it. I forgot which one this was, it might have been FPGA Express, Cypress Warp, or whatever it was that Quicklogic used. Hopefully it's fixed now, but I would not be suprised if other tools have similar type of limitations. > > And #2 was that it would make the source > > code much less readable. As far as I know, I would not be able to > > use an enumerated data type _and_ have a don't care. Without > > enumerated data types, the entire core would become one wild > > mess! > I believe you can use enumeration types with don't cares, but you > must explicitly specify the state encoding. First I thought that this > would hurt the synthesis result, because I expected the tools to do > state encoding optimization, but then I read that FPGA-express just > numbers the state in the order that you list them. So something like this? type this_list is (APPLES="00", ORANGES="01", DONT_CARE="XX"); That would be relatively trivial to do. First, modify the mcgen.c program to explicitly list the encodings and add a don't care at the end. Then change the microcode.xls so that the default value is don't care (second or third line). You would probably have to do some manual checks to make sure that a default of don't care is a reasonable thing (it wouldn't be, for example, for the DONE flag). That's it. > > For the Free-IP cores, I place a priority on portability and > > readability over speed and size. > And you are allready smaller and faster than most commercial ones. I think that most commercial cores try to execute all the opcodes in the same number of clocks as the original 6502, and they try to perfectly emulate the 6502's bus. I think that both of these are bogus goals. While it's true that some code will be broken by the clocks/instruction thing, this code would also break when you run it faster than 1 MHz anyway-- so who cares? Ok, so then the core doesn't fit into a couple of very small applications. That's a price I'm willing to pay. By twiddling with the clocks/instruction, I could optimize and pipeline some things and crank the clock speed way up. In most cases the clocks/instruction goes up by 10-20%, but the clock speed more than doubles. I designed several circuits with the original 6502-- and I hated it. The bus timing was simple, but inefficient. It also doesn't interface well with modern peripherals and FPGA-implemented logic that really likes synchronous busses. With a modern core that fit well into FPGA's and low cost ASIC's, it made sense to ditch the old bus and design something that was slightly more modern. This, combined with the clocks/instruction thing, has the side effect of boosting speeds and reducing size. On the other hand, the Free-6502 is fairly large when compared to the original 6502. The original 6502 had less ALU-like blocks than the Free-6502. The original 6502 used the main ALU for addressing mode type calculations and other misc things while the Free-6502 tends to have several more dedicated ALU's. > Let me tell you that I really, really like your excel micro code > approach! Thanks! I think that entering the microcode is the most error prone part of designing this type of CPU. You can see from the microcode.vhd file that the data for one opcode is spread out over a large source file-- and there is no way to make it more readable without sacrificing portability. So the Excel file really made things easier to modify _AND_ less error prone. It's also nice to have it automatically generate the VHDL and Verilog versions, so we don't have to worry about fixing things twice. David Kessner |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 6502 compile time and area - Ben Franchuk - Mar 9 18:31:00 2001
|
David Kessner wrote: > For the Free-IP cores, I place a priority on portability and > readability over speed and size. Good Point. One problem with emulating a CPU is often knowing what BUGS to put back in,or how unused opcodes are processed. > Many CPU's, not just early CPU's, have a lot of random logic. What makes > early > CPU's difficult is that they were not pipelined, had large microcode ROM's, > and had > lots of internal tri-state busses. These makes it difficult to do in an > FPGA. What is with all this pipeling stuff? What makes not having a pipeline harder to fit than having a pipeline? Microcode rom may not be a difficult problem as many FPGA's have loadable RAM nowadays that can be used as rom. Tristate logic is still a problem how ever. > Another thing to remember is that these early CPU's were often designed at a > very > low level-- at the gate and sometimes the transistor level. There are lots > of tricks that > you can do at the low level that is difficult to effectively reproduce in > something > that is higher level. It's a bit like comparing assembly language with C++. I consider C++ to be bloated,and don't like modern hardware languages cause you can't write things like "a+b,carry -> sum,carry out,overflow" > I actually considered doing a 6800 core, and the Free-6502 core was a type of > "conceptual proving ground" for that. The reason why I didn't go ahead with > the> 6800 core was two fold. First there were the legal issues (no one is going > to sue> over a 6502), but Motorola has lots of investment into the 6800 that they > will defend. But the larger issue is the size of the 6800's microcode ROM. That > ROM is huge and not something that is effective to put into an FPGA. There > are some simple 32-bit RISC processors out there (like the MIPS R3000) > that would actually be smaller in an FPGA than the 6800. > I did not think the 6800 micro code was so huge. You are right about the legal bit. Ben. BTW what is a good speed to aim for a FPGA cpu.I am guessing a memory cycle of 125ns to 200 ns for the older CPU's so one can use slow low cost chips. -- "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 |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 6502 compile time and area - Ben Franchuk - Mar 9 19:22:00 2001
|
If you estimated the size of your cpu succesfully, could you > pease add the results to: > http://www.prowokulta.org:80/phpwiki/index.php?SoftCPUs > Your competitors achieved 700, 1100 and 1800 XC4K LUTs > respectively. There is a definite lack of 24 bit processors there and other FPGA brands. A 12/24 bit cpu - random logic,no pipeline, no tri-state buffers,untested, is 430 logic cells out of 480, in a Quicklogic ql2007-X 84 PLCC FPGA. CPU cycle time of 9 MHZ. No fast carry or RAM in this FPGA. -- "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 |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
xr16 ISA reimplementation - Jan Gray - Apr 6 10:04:00 2001
|
> In this context I have a question to Jan Gray: > > Jan, > do you consider the xr16 ISA as protected your license or just your > HDL source code and documentation? > > CU, > Kolja To clarify my company's position on these things, we welcome the "from scratch" "clean room" reimplementation of the xr16, xr32, and gr00x0 instruction set architectures. For example, this is what Mike Butts has done. I have looked over his implementation, and I am satisfied it is not derived from the xr16 implementation in the XSOC Kit. So, create your own implementation from a blank sheet of paper, perhaps referring to the xr16 ISA specification and the xr16 test suite (xsoc/tests/xr16), and then dispose of your own work (share it, sell it, whatever) as you will. You can point your users to the XSOC/xr16 Kit for compiler, tools, specs, etc. but their use will be bound by the licensing agreement too. Conversely, a translation of our xr16 implementation from Verilog to Verilog, or Verilog to VHDL, or any other work that uses, or is based upon, any part of our implementation, are plainly derivative works, and as such are bound by the terms of the license agreeement. Distribution, commercial use, etc. of such derivative works is not permitted. The license agreement also does not permit distribution of subsets of the Kit, so you may distribute the whole kit verbatim, but may not extract the compiler and specs and package that up. If you have a derivative work (such as a VHDL translation) that you would like to share, I would need to treat that as a 'contribution' that would then be released in a future XSOC kit refresh, under the XSOC License Agreement, copyright you (if you like), and copyright Gray Research LLC too. For at least six months I have been meaning to cleanly delineate architecture and implementation, by splitting the XSOC/xr16 Kit into two, one part the ISA specs, tools, and test suite, the second part, the hardware implementation, and relicense the first part under something more liberal than the XSOC License Agreement. When/if that day finally comes, this informal statement of position will have a more solid legal basis. Until then, the current license applies, and this license says (in effect) that nothing I write here supercedes the license... (Parenthetical remark: It was my hope in starting on this fpga-cpu endeavor to help to establish a community of developers who are empowered with knowledge, experience, and confidence, to design and build NEW instruction set architectures, quickly, whenever they like. If they have a specific problem, like fast message passing, or fully concurrent garbage collection, they should not hesitate to experiment with hardware implementations of instruction set support for the problem domain. So it is necessary to remove the barriers-to-entry, to lower the activation energy if you will, of defining new ISAs, by showing how it's done. The two most daunting obstacles are designing a hardware implementation of the ISA, and producing a C compiler port. I sense there is growing confidence in the hardware design side of the coin. But the interest in reimplementing xr16 may be indicative of a community that is less confident about defining new instruction sets and hence compiler tools chains. That's not so hard, if you know what to do. I guess we have some work ahead of us to gain more confidence on the tools porting side.) Jan Gray, Gray Research LLC p.s. .-2 s/assymetry/asymmetry/ |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )