[Open-graphics] Check-in conflicts and top-levels

[Timothy Normand Miller]

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