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. -- 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)
