I won't have much to do during my break either (December 19-jan 13).
Actually i won't have much to do after december 11 i think.
Most things verilog are fine with me. Maybe you can give a rough idea
about the complexity of each task (which are the trivial ones and which
are more substantial)?
Timothy Normand Miller wrote:
Final exam week is over on December 7, and the next quarter doesn't
start up again until January 7. I still periodically communicate with
people from the companies who had contacted me about our VGA
implementation, and they're still showing interest. The VGA
implementation is a superset of what we really should be providing
with OGD1 boards. Sounds like a good opportunity here. The problem
is that I'm going to need some help!
Oh, BTW, OGD1's artwork (physical board layout) is finished, and we're
waiting on quotes from two board houses. Another reason to get on the
stick. The winning fab will have to review the design and get
prepared to push the GO button when we hand over
$part_and_fab_cost*100, and Andy isn't quite ready with the online
ordering. When those are ready, we'll start taking orders.
I've mentioned before that we have friends that have been kind in
lending us some of their logic which we have bodged together with our
own stuff to make a prototype. Some effort will have to go into
separating those things back out, and some of the changes have to be
merged with what's in SVN. The demo at OSCON was on a real OGD1
board, but chunks of the FPGA logic don't belong to us.
Here are the things we have:
- A PCI controller synthesizable for Xilinx
- A working memory controller
- A working video controller
- Pad rings that need to be cleaned up
- A synthesizable nanocontroller (HQ)
I'm going to make up some ad hoc phases that we would work in to get
it all together. If I can get enough help, pieces of different (or
the same) phases can be going on in parallel with each other.
Phase 1: Getting back to the demo with all Free HDL code
- Modify the PCI controller so that it synthesizes for the Lattice chip
- Build the two halves of the bridge logic to carry memory/reg
accesses to the Xilinx
- Glue PCI to the bridge and the SPI PROM controller
- Design logic for the Xilinx to process "engine" register accesses
(so we can configure the memory controller, video controller, etc.)
- Design an arbiter that manages competing memory accesses between PCI
(bridge) and video.
- Design top levels modules for both FPGAs and wrap with pad rings.
Phase 2: Installing HQ
- Design I/O interfaces for HQ that it would use to get access to the
bridge and intercept PCI transactions.
- Insert HQ into the XP10
- Develop test code for HQ and run it both in simulation and in a real device
Phase 3: BIOS ROM
- Get basic BIOS code together. This mostly involves finding out the
format and putting together a skeleton. Without HQ, we can have it do
something simple like program memory and video controllers.
- Get started on VGA BIOS code
Phase 4: VGA
- Complete the nanocode for HQ that emulates at least CGA 80x25 text mode.
- Complete the VGA BIOS code that sets it up.
Some of what I said is going to be confusing, so first we need to
discuss this to make sure that those who volunteer understand what's
going on. We also need to agree on the pieces and steps involved. We
should Gantt chart it. Most importantly, we should have preliminary
decisions completed before Dec 7. This way, I can hit the ground
running and do little more than write Verilog code from a checklist of
things to do.
Now, we can break this up into jobs. One person can be responsible
for more than one thing, but we can assign tasks so that a person
knows what the focus on. Here are the roles/pieces to be responsible
for:
- Porting PCI
- Writing x86 BIOS code
- Merging video controller
- Merging memory controller
- Pad ring and top level module for the XP10
- Pad ring and top level module for the Spartan
- The bridge
- "engine" register glue logic
- Memory arbiter
- HQ and it's I/O interface
- Writing HQ nanocode
Each person would be responsible for documenting the interfaces
offered by their modules. In fact, you should figure out who you're
going to connect to and discuss with them individually your common
interfaces. Note that many of them are trivial, and I can just tell
you what they should be like.
Here's a clumsy diagram:
http://www.cse.ohio-state.edu/~millerti/ogd1_vga_diagram.pdf
Who's in? This is really important, so I hope I can get some of the
more hesitant people involved.
Don't be afraid to take something on if you don't know Verilog coding
very well. If you can't do it well, you can at least provide context
for someone else to complete the job. You can help keep things
organized and track progress. And don't be afraid to pitch in on
something that already has a maintainer, because they may be too busy.
If more than one person volunteers for a given job, you can just
collaborate. Also, finally, I expect to do a heck of a lot of coding
myself, so what I need as much as anything is people to just help me
think and keep track of stuff.
Oh, there's one more job. This one is of more general import. We
have document in SVN that explains this so-called "fifo interface."
We need another document that extends that notion to processing
pipelines. This is one of those things that I want to automate with
HIDE, but we can start by describing a technique that you can just use
as a template.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
