We had an unusual and happy situation on Sunday where four people were
working on OGA1 at the same time. They were all working on things
that would affect the top-level modules, so I sent emails around to
make sure that people didn't conflict.
Now, it turns out that the way I had architected the top-level modules
was not, in Howard's experience, the preferred way to do it. In
particular, I was including interconnecting fifos in the top level.
It made sense to me at the time. But the effect will be much greater
clutter at the top-level and greater potential for conflict. [Note
that in the past, I've always left top-levels up to Howard, which is
probably why they always went well. :) ]
So the way we're going to do this is to put an additional module
wrapper around each major functional block. If a fifo is used as an
interconnect between two high-level blocks, then that fifo gets
included in the wrapper around the block it most logically goes with.
Here's an ad hoc breakdown of some of the parts that I can think of
off the top of my head:
- s3_top_level
- video wrapper (two instances)
- request fifo
- four request counters
- four data return fifos (one from each arbiter)
- video controller
- hardware cursor overlay (later)
- video output for top head (connects to pins)
- video output for bot head
- memory wrapper (four instances)
- arbiter
- memory controller (itself a wrapper)
- bridge wrapper
- bridge
- command/write fifo to arbiters
- four read return data fifos (one from each arbiter)
You get the idea, and the XP10 will break down similarly. SPI
controllers will get their own fifos, HQ will get a module that
contains everything, etc.
--
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)
