On 9/6/07, Petter Urkedal <[EMAIL PROTECTED]> wrote: > > I'm just worried about the race conditions. In fact, I know they'll > > be a problem. We really don't want to give the nanocontroller a > > separate pipe to memory. So if we have pending reads, then data will > > come back out of order. > > I though we could solve that by encoding the thread number in the > request and reply. An attempt to read a data which the thread does not > own, would cause a context switch.
I'm trying to imagine this, and I can't see a solution that wouldn't be more complicated than what I'm proposing. Could you go into some detail about assumptions you're making about the memory system? How is it to know if a read word was requested by one thread or the other? And does this mean that thread switching is completely automatic? What other conditions would cause a thread switch? > Anyway, as you point out below in your post, DMA mode runs a single > process (and I assume there are command-dependencies which prevent > splitting up the work), so agree we can go for thread- and > interrupt-free nanocontroller. For that matter, we may be challenged to make the nanocontroller really keep up with the PCI data. It can only execute 3 instructions in the time of one PCI data word (at 33MHz). What with having to manage request queues and such, we might actually run a bit slow. (Still far faster than doing it all PIO for sure.) > Given these conclusions, we are close to the desired nanocontroller: > First, lets `ifdef out the multiplier logic. Then, maybe we turn IO > access into registers. If not, a minor practical-aesthetic point is > that I'd suggest negative addresses for IO-ports because it lets us > expand the scratch memory without changing the IO base address. Then, > we can try to synthesise it again. Minor nit-pick. I'd suggest choosing a high address bit (but something within the range of our immediates) to specify the bottom of I/O port space. 16384, I guess, from 15-bit unsigned immediates. The reason I don't like negative addresses is that it introduces additional math that I don't want to deal with, even if that doesn't translate into any real hardware. Note that if the immediate gets sign extended, it doesn't make any difference. We just ignore the upper bits anyhow, and we treat -16384 as the offset for I/O ports. So we use bit 15 as the "is it scratch or I/O" flag. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
