On 5/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-05-31 at 16:31 +0200, [EMAIL PROTECTED] wrote: > >> > I assume he's referring to a classic 5-stage design with a MEM stage: > >> > -fetch > >> > -decode > >> > -execute > >> > -memory access > >> > -register writeback > >> > > >> > >> Do you really need 5 stages ? 3 is not enought ? If data could enter in > >> few register you don't need a load&store unit. > > > > I see no inherent reason it would have to be a 5-stage processor. I was > > just relating back to Hennessy & Patterson and MIPS as it seems to be > > the "classic" pipelining example. Timothy, however, seems to say we need > > 4+ stages to get clock rate up. I can't say I have much experience in > > timing/speed issues though, so I'll defer to him. > > > > With regards to your 3-stage processor: Is this a closed product? Don't > > we risk becoming encumbered by this? > > > > I can't have access to the code. But you could easly reused the idea > behind it. very simple design, no stack (or defined number of call > supported), delay slot, no dection of pipline hasard. By programing it by > hand, simplify a lot of thing, that are very hard to make it understood by > a compiler. > > If you use the idea to have a 64 register bank, 32 is true memory word > inside a block ram, the other part, is just config bit. I imagine that > you could interract with the DRAM controler using this "config" bit. So > you don't need any wait management in the pipeline. Juste a kind of > special "wait" instruction that bloc on a register value (a kind of "jump > pc -4 if reg[i] == 0").
I was thinking about that too... instead of having the memory read instruction wait on the fifo, you loop over a status bit, and then dequeue when the data is available. We'd have to do the same for writes, making sure there is space before writing. Even better would be the ability to check for a certain NUMBER of entries available. This way, you can check for, say, 8 results, and when all 8 have arrived, you can process them more efficiently. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
