On 1 Nov 2007, at 04:18, Timothy Normand Miller wrote:

[snip]

I don't disagree with anything you said.  The problem is that since
Andy, Howard and I are the "most qualified" to document this stuff,
people leave it up to us to do it.  But we're overextended, so we
don't have time to do it.  So it doesn't get done.

I can understand everybody has a day job, but this project has been crawling forward for over 3 years now (since the first lkml email) and we (the community) still don't know how to start writing verilog for something like a controller for the FPGA<->CPLD bus.

Soon enough, we'll publish things like padrings for the FPGAs that
will give names to the pins, and that'll explain the connections.  But
in the mean time, although I'm weak with schematics, I'd be happy to
try to help someone document this for the wiki, based on the
schematic.

It's very easy to focus on the example I gave, but here goes anyway. I'm not particularly interested in the exact pins of the connection, it's that this connection (after I had a look at the schematic) has 32 AD lines, 16 control lines and a clock. This probably (and here starts the speculation, it isn't in the schematic nor on the wiki) means that the bus is multiplexed. But what function is assigned to each control line? What's the projected clock speed of the bus? Are there asynchronous lines? Why did we end up with a multiplexed bus? Is it because PCI is multiplexed? I think not, because the CPLD will have things like the VGA and DMA controller, which means this bus will be used quite a bit for non-PCI like commands. Is it a space constraint then? Maybe, but I don't see a note saying that anywhere. Will it become a bottleneck if the VGA controller needs to access main memory and simultaneously output data to the DAC, which are both connected to the FPGA? Also, the bus has been in use during the demonstration, but where's the code controlling it? I can't actually find it in the svn.

And that's just of the top of my head. And that's also why I've got numb details like these in my project jotted down just to give other people an idea /why/ the schematic looks like that.

(Note that for Howard, the documention IS the schematic.  He wrote it
and is used to thinking about boards this way.  It's like reading
German for someone who lives in Berlin.)


Surely he gave some of the points I mentioned earlier some thought, and has some dirty details. It doesn't have to be a complete story, just some stuff that other people can make some coherent documentation out of. Or a controller in verilog. Or a schematic as in how the VGA controller is supposed to get it's data out to the DAC.

Mike
www.wacco.mveas.com - Project VGA

_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to