[Open-graphics] Sample VGA translation code, for nanocontroller
Timothy Normand Miller
theosib at gmail.com
Thu Sep 6 17:25:03 EDT 2007
On 9/6/07, Petter Urkedal <urkedal at nbi.dk> 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
Open Graphics Project
More information about the Open-graphics