On 11/1/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > > 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.
Part of the problem is that we have no funding. Andy, Howard, and I (and our wives who aren't hardware enthusiasts) have been paying for the hardware ourselves. So our day jobs are critical for this in more ways than one. If dozens of people swooped down on us and offered us funding like they to do with the EFF, we wouldn't be crawling like this. Instead, we have to crawl until OGD1 is done, then hope it sells, and then hope that we earn enough revenue. Even there, money doesn't translate linearly into productivity. For us to be REALLY productive, we have to make enough money to be able to do this as our day jobs. Let's say we decide Andy, Howard, and I need $50k/year to live on, so we need a guaranteed profit of $150k/year (what a single ASIC designer would make on his own). Let's say we average $300 profit per OGD1 board (very optimistic!). That means we need to sell 500 OGD1 boards per year just so we can EAT (and do nothing else). Note that the OHF is in no better position. Our hope is to funnel some of our profit into our own internal R&D, but also to hand a fair amount over to the OHF so they can fund things and so that we can all reward OGP contributors by giving them free tools and even paying them to do certain projects. The thing you have to understand is that the OGP is BY DEFINITION a community project. What the community puts into it is what comes out. So when you complain that we lack certain kinds of documention online and that it's bad that we have dragged for 3 years, who are you complaining to? If you're complaining to the community as a whole, then you should include yourself, because by your very act of joining us on this list and saying something intelligent, you have made yourself into an important member of the community. Next, the important information you need IS available online. It's just encoded in an unfamiliar way. The best way for the community to help themselves would be for some of its members to become familiar with reading schematics. You won't learn it any less quickly than we did. So, say you're reading it and you can't make sense of, say, 90% of it because you've never seen one before. Post to the list something you figured out about the 10% that you do understand, and ask some questions about something you just barely understand. Work out from there. Hard? Yes, but so is any kind of engineering stuff when you first encounter it! (Learning to do this stuff is a marketable skill, BTW.) BTW, I would he happy to spend some time on the phone with some people. If you're in the US, I can call you. Otherwise, you can call me. Or we can use skype or some other medium or just gtalk, although chat is often less efficient for some things. Here's an idea! Can someone who kinda gets the schematic do a phone interview with me where we walk through it page-by-page? Maybe you can put the recording online or transcript it. Note that I don't know this nearly as well as Howard, but I know enough to get people started. I can't say if Howard is more overloaded than me. He has one job that takes 70 hours/week, and I have, you might say, 3 that take 70 hours/week. But I'm willing to cut out some time to talk to people about this. > > 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. Someone needs to please put this on the wiki: It sounds like you're talking about the bridge. This is a bus between the small FPGA and the large one. The 32 bits are for address and data. The control lines indicate things about what is being carried on the data lines. The data is sent at 200MHz (100 DDR). This serves as a simplification of the PCI protocol. When writes are streaming, we send an address once followed by multiple data for writes. For reads, we send an address and a count. Some of the control lines indicate which PCI BAR we're dealing with. The important ones are graphics memory and the engine register address space. All that goes across this bus are read and write requests for those address spaces. If you want to write a word to memory, it goes through the XP10, across the bridge, and into the Spartan, where other logic sends it to the right place. For VGA, HQ (the nanocontroller) intercepts all PCI transactions and runs algorithms to service those requests. (The latency is terrible but not really much of a practical problem in this case.) At the high level, all the VGA controller does translate host requests into a representation that can be scanned out by our video controller. For instance, in 80x25 text mode, when a write to the text buffer comes in, we just dump it unmodified straight into a section of graphics memory we have reserved. Then in the background, we read that buffer (and the font) and translate it into 32-bit color pixels and write those into ANOTHER framebuffer. We point our video controller at that second framebuffer. So the VGA controller is not actually involved in the video rasterscan. > 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. Oh, and one other thing: The bridge data/control lines are kinda arbitrary. They're enough for how we've used it. In fact, slightly more. We connected up what we thought was practical in general, with some CYA. > > (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. Some pieces are out there, some aren't. Can you make sense of VGA from what I've described above? If not, ask more questions! -- 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)
