Let me start off by saying that I still think you're all doing a
fantastic job, and that my comments where (and are) meant to be
constructive, not offensive. If it sounded otherwise, I apologise in
advance.[1]
On 5 Nov 2007, at 19:38, Timothy Normand Miller wrote:
On 11/1/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote:
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).
Gotcha.
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.
I probably went out of line there, but in my defence it felt like you
were saying that the only way out of this loop would be some
community members jumping in and closing the gap (which I personally
feel is there), while I think that it might be wiser that you would
temporarily stop pushing for the PCB, help us catch up with
documenting, and then continue.
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.)
That's exactly why I started firing off a dozen questions about the
bridge.
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 like the idea, but my agenda exploded last week so I'll have to pass.
Someone needs to please put this on the wiki:
I believe this would fit nicely on the VGARoadmap page, I'll add a
written out version to it this weekend hopefully (unless somebody
beats me to it).
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.
This is exactly the kind of stuff I wanted to hear. I had no idea it
was DDR. I just want to recap in my own words to make sure I
understood everything. So we'll end up with a more-or-less PCI
controller on the FPGA, which has C/BE[3:0] and AD[0:31] lines. I
also figure we end up with IRDY/TRDY/FRAME and an interrupt line.
DEVSEL, IDSEL and STOP can probably be left out, as well as PERR and
SERR, although some sort of recovery must be available.
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.
I assume this 'scratchpad' memory is in the XP10 and only a few
(hundred, tops) bytes big. The HQ translates it, and then does a 'pci
write' to a framebuffer on the FPGA. Finally, there's a separate
(which isn't part of HQ or the VGA controller) module on the FPGA
constantly reading that framebuffer and passing it on to the DAC.
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.
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!
Yep, pretty much. I assume that the specific VGA registers are
intercepted by the HQ and never moved in any way to the FPGA,
correct? I also assume that the address of the framebuffer on the
FPGA, as well as the settings for the video rasterscan controller
(mode etc) are done in registers, but we haven't defined yet which
registers (might as well start at 0x01? How big is this register
space going to be?) are going to be what option.
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
Mike
www.wacco.mveas.com - Project VGA
[1] If I don't pay attention, I tend to behave like a 'Dutch uncle',
and not just because I'm Dutch ;)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
