On 5/30/05, Eric Smith <[EMAIL PROTECTED]> wrote: > I wrote: > > It's hard to believe that it's not worthwhile to use a traditional > > RISC 3-state pipeline. It's not hard to do. > > Timothy replied: > > It's impossible to do if you can't do arbitrary combinations of memory > > accesses. We can access two registers at a time, and the program file > > is unified with the register file. > > Must it be? Unless there's some particularly good reason for it, > I wouldn't do that. If it's an attempt to save space, it's not going > to work; you'll burn more logic and interconnect mashing them together > than you'll save space on the RAM.
For the architecture we're fiddling with, it is necessary. 512x36 bits of memory in random logic is HUGE. We're using a block RAM. > > Why not use a BRAM for the program file, and distributed RAM for the > register file. This is always a possibility. > If you need 32 32-bit registers with two read ports > and one write port, that takes 128 LEs, which is only 16 CLBs (out > of 3238 in the 3S1500, or 6912 in the 3S4000). It actually takes > half of each of 32 CLBs, but the other half of each can be used for > logic. All this does is allow us to access the register file and the program file simultaneously. Ok, so we'd be able have more overlap in the pipeline, but not THAT much. I wish I could draw a diagram here, but if you fully pipeline the processor, then you end up having to be able to make potentially 8 reads and 2 writes to the register file all at the same time. > > This lets you do a traditional three-regiser pipelined RISC, and > is very fast. I want to see more of this. Mind educating me? One challenge that I have had with processor designs is the restriction that I could do one read and one read or write per cycle with a dual-ported RAM. > > The key point here > > is that the design needs to be very small, so putting in a > > general-purpose CPU core is not going to do. What we are designing > > right now is probably over-sized already. > > I don't know exactly what you've got now, but it doesn't sound to > me like it's much smaller than an aeMB. If you decide there are > things in an aeMB you don't need, you can always pare it down. I want to see this. :) > > This isn't a bad idea, although I need to know more about how it > > expects to access memory and where it stores its program file. > > It's synthesizable Verilog. You put the memory whereever you want, > but usually in a BlockRAM. It uses distributed memory for the > register file, as described above. > > It's also possible to use two BlockRAMs together as a triple-ported > register file (two read ports, one write port), provided that you > can live with the fact that they are synchronous. Depending on how > your processor core is designed, that might or might not involve > an extra pipeline stage. > > I haven't used aeMB too much. I spent (wasted?) some time converting > it from Verilog to VHDL, so I know a little bit about its structure. Well, it's certainly an option for us. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
