Newsletter Archives

Jan 10th 2007 Open Graphics Project Newsletter

• Jan 10th 2007 Open Graphics Project Newsletter
• ANNOUNCEMENTS
• Progress and developments
  • How close are we to OGD1 release? Days, weeks, months or years?
  • Cards and Codes
  • PCI
  • Donations
  • Alternative Projects:
• Software Tools for OGP
  • Programming the OGD1 card
    • Xilinx ISE
  • Latex and Timing Diagrams
  • Bølge
• Looking at the future with PCIe
• OGP and Traversal
  • Traversal on the Web
  • Future developments
• OGD Architecture
• Open Hardware Foundation
  • Hardware Documentation
  • Mini FAQ for the Open Graphics News Group.

Over 346 Posts covered in this Newsletter

ANNOUNCEMENTS

Patrick McNamara, President of OHF, The Open Hardware Foundation reported:

The Open Hardware Foundation, Inc. is formally a Texas non-profit corporation. On January 8th, 2007 the Secretary of State of the State of Texas issues a certificate of filing for The Open Hardware Foundation, Inc. certifying that Articles of Formation had been received and accepted. The Board of Directors for the OHF will hold their first meeting on January 27th, 2007. The main agenda items for the initial board meeting will be the election of corporate officers and other administrative items necessary to begin formal operations. Current and future news items will be available on the Foundation web site: http://www.openhardwarefoundation.org

Progress and developments

How close are we to OGD1 release? Days, weeks, months or years?

Timothy:

For testing, (...) One of the concerns was, if we had a large, complex design in there, would we end up running out of some resource (like routing resources or whatever) that could be alleviated by moving external pins around. This is something we've encountered before a few times.

We could have started selling OGD1 boards back in November, but we'd be taking the risk of selling boards that would come back because they were faulty, and we just could not handle the cost of that kind of mistake. Every little decision we make comes with a complement of risks. When we're trying to do something expensive based on our own personal money, that we have to get exactly right the first time, we may find ourselves being overly conservative.

(...) To some extent, we have been bringing data out to user I/O pins, but with PCI working and a rudimentary register interface, it's not hard to make internal signals available by reading over PCI. (...)

We know for certain that the PCI bus is wired correctly. We're able to perform isolated transactions (with someone else's PCI controller that has been used in other designs), although we haven't beaten it to death yet. The trace lengths are in spec, so we don't really expect a problem there. The bridge between the XP10 and the 3S4000 is logically wired right, but the sampling phase window on the signals at 200MHz (100MHz DDR) is tighter than we had expected, and we're trying to make sure we don't need a re-layout to tighten up the variation in lengths of the different traces. Memory and video have had signals on them, but not nearly enough testing has been done to certify them, so to speak.

Testing is on-going and by the time you read this they will be much further along.

For Media interested in reproducing a picture of our board we now have some higher definition pictures prepared by Lourens and hosted by Traversal Technology: http://www.traversaltech.com/ogd1_press/

Cards and Codes

Lourens brought up that we needed to clarify the names we are using. There was agreement on this and the website was checked for consistency

Timothy:

*OGA are specifications for GPU architectures, which include things like register interfaces, although in general some of those things can be left unspecified.

*OGD are the developer boards.

*TRV10 is the ASIC implementation of OGA1.

*OGC are graphics cards based on TRV chips.

The Wiki was updated to reflect recent refinements in the part number structure. See
http://wiki.duskglow.com/tiki-index.php?page=OpenGraphics+videocard+naming

PCI

Timothy reported a working PCI target to test:

This one is highly simplified from what I was trying to do before. It's a complete rewrite that strives for logical correctness, not performance. Once we know it's functionally correct, optimizing for performance will be a straightforward process. It's also got a lot of stubs in it that'll be hooked up right later. There are a few things that need to be done:

# Since this is a replacement for the old design, I'd like to set the old one aside. I don't want to delete it or take it offline, because there's more copy/paste to be done as the new design evolves. What would be the most sensible way to handle this in SVN? I was thinking that perhaps a new directory would be good, (...). Suggestions?

# Once it's in SVN, I'd like to get some help testing it. I have a working simulation environment that should therefore be easy to hack. I was hoping I could get those of you who have a PCI spec or Shanley's book could help me beef up the tests and expand their scope.

# Going with the spirit of being an educational project, not to mention good engineering practices, I think we should document this in fine detail. It should be documented to the point that people with no experience in hardware design can follow along and make sense of it, and those with hardware design experience could code a new one in a week. We can start with more comments, but diagrams, ODF documents (and PDFs of those), and sort-of tutorials would be good to have.

The PCI block of this design is a critical component. Everything goes in and out of the PCI block, so it it's wrong, nothing else works.

A few days later he then reported:

I've just checked in a simulation model of a PCI master. In some ways, it resembles how I want our real (synthesizable) master to work, but this one is just designed as a test harness for the our PCI target. However, it will be used as a template for the real master.

After a few days of testing he noted:

There are limits to how creative I can be in testing this thing, but I believe I have completed and debugged a PCI target that I can start converting to a synthesizable form for OGD1. In the process of testing the target, I've also written a master that is 90% of the way there to being a reference design for the master we'll use in OGD1. (...) There are also other tests to be written. If I could get some help with those, I'd appreciate that very much too. I've tested both the target and master in some rather unusual circumstances, some of which shouldn't happen, but which we should be prepared for. Now it's time to simulate something a bit more real-world with more typical latencies and throughputs.

And all of this has to be done before we hit silicon, because it's going to be much easier to debug a simulation model than a highly optimized synthesizable one. That is, unless someone out there has a mobo that's tweaked to run PCI at like 1MHz.

Atilla:

First fix the directory hierarchy so that every subdirectory makes sense. Either by fixing the PCI directory or changing the current hierarchy.

Timothy agreed and made changes.

it's now under trunk/rtl/pci

One person volunteered to try to assist documenting PCI and this is an area where someone else could help. As Timothy explained: we need to recruit some of the list members to take charge of documentation. They would spend their time asking the developers questions, basically, and writing about what the developers explained. Anyone? :) We need it to be somewhat stand-alone so others can incorporate it into their projects.

Donations

We have been preparing the Open Hardware Foundation to accept donations for OGP. This way we have a third party to manage the funds. This allows us to concentrate on our job of making a Graphics card, and OHF can look after the monetary side.

Joseph asked when OHF will accept donations and Patrick mentions that this is very soon.
Patrick

At the time of incorporation, we will be a legal entity to which you could, if you so desire donate money. We, the Foundation, will have to work out how to accept, track, and disperse it, but you could give us money. (...). Until (...) we get 501(c)(3) status (which may take up to two years), any donations given to the Foundation are not tax deductible. Now for the bit of good news. Once we receive 501(c)(3) status, all donations given prior to our reception of 501(c)(3) status become retroactively tax deductible. So anybody who had already given us money gets to deduct it from their taxes once we achieve IRS non-profit status.

Alternative Projects:

Eric:

Intel has good open-source support for their integrated graphics, including their new GMA X3000. The performance doesn't match the top end ATI and NVidia chips, but it's a reasonable midrange solution. Of course, as an integrated solution, it doesn't help those of us that want to use a motherboard a different chipset, or that want multiple cards. (The Intel chips support two monitors each, provided that you don't want them to act as a PCIe x16 bridge, but some people actually want more than two monitors.) After looking at the data sheet on the G965 chip (which contains the GMA X3000), it occurred to me that it might be possible to put the G965 on a card with an FPGA (probably Spartan 3) to act as a PCIe-to-FSB bridge. ... it's not my intention to distract anyone from the OGP development, but if anyone thinks this might be a worthwhile thing to build, I'd be interested in discussing it.

Timothy Miller wrote:

How difficult would it be to get the appropriate documentation on all of this?

Eric:

As far as I can tell, the datasheet/manual on the G965 (available on the Intel web site) includes the necessary documentation to build and test such a card. http://www.intel.com/design/chipsets/g965/documentation.htm

The documentation does NOT contain the details of programming the GMA X3000 graphics engine. This is not because the information is secret; they have shared it with the X.org developers. As I understand it, the full documentation may be made publicly available at some future date, as the current issue is merely cleaning it up to meet Intel's public documentation standards.

Software Tools for OGP

Programming the OGD1 card

Some worried that programming the card would require windows but Andy reassured that this should not be so:

Once the PCI controller (which is on the Lattice fpga) is there. We can programming the main FPGA prom anywhere we want. The Xilinx tools uses a JTAG cable to program it. We might be able to reprogram the lattice prom too but if anything goes wrong, then you need a JTAG cable and proper software to reprogram it.

Koen pointed to a Xilinx article regarding using Linux:

To gain access to the Xilinx cables using iMPACT or any other Xilinx software with Linux 2.6, the cable drivers must be compiled. http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=22648

Xilinx ISE

Timothy reported a problem with installing the software under Wine..

At the point when I'm typing in the registration code, I get four four-character fields into which to type in the 16-digit key. Unfortunately, there is a problem with CrossOver? that lets me type only 3 characters into each field.

Further information became available:

Apparently, the edit field is being limited not by the number of characters but by the width (in pixels) of the edit field. This is, of course, totally absurd. If the text is too wide, the text should scroll to the left as you type. But the short-term fix is to figure out how to use a smaller font.

He then reported:

I got the ISE install to work. The solution was to copy c:\winnt\fonts\*.* from a Win2K machine to ~/.wine/whatever/windows/fonts. Then everything worked great.

Some report being able to install whereas others have difficulties. Wine has made great strides recently and you may be able to install and compile projects. You may need to use other software to load a project on an FPGA.

Latex and Timing Diagrams

Timothy:

What I wanted to do was type timing diagrams into Latex documents and be able to add the diagrams as characters into text or tables or whatever.

Daniel wondered

Cant you just embed .SVG into TeX ? Then you can do the vector graphics by some translation software from a more semantic description of your diagram (and/ore from an simulation output)

But Timothy explained

It's a pain in the neck to use two programs to do one thing. I just want to type it all into one document.

A commit was made in SVN which enables drawing timing diagrams in Latex.

Bølge

(this is a teaser as this new tool will be covered in the next newsletter)

Looking at the future with PCIe

Timothy:

PCIe has independent read and write paths for each channel. Does that mean we could actually be doing a DMA upload and a DMA download at the same time? If so, under what circumstances might it be useful to us to be doing transfers in both directions at the same time? Recall that we would prefer to shadow textures in host memory, so we never have to download images unless the GPU has drawn to something. I can think of a few non-graphics situations where this would be useful.

Lourens:

When you're recording a gameplay or desktop usage movie clip (i.e. for demonstration or instruction purposes) using e.g. FRAPS (http://www.fraps.com), you want to read back the rendered frames. On many cards this makes the system unusably slow. Reading back one frame while the next is being rendered and data for the one after that is being uploaded could help there.

nick:

If you are trying to offload anything that requires much math to the FPGA, it is simply not possible to wait for the "glacially slow" PCI bus. PCIe (is different) on a PCIe 32x slot, 16GB/s should be enough for most applications... Until that is implemented, however, we should try to find other uses that are not involved with sending lots of discrete packets. If you offload entire designs to the FPGA, it is worth the wait (especially with DMA), but if every time you need to compute an FFT with SETI@home you send across the PCI bus, it is just too slow. With the physics processor, if you upload an entire scene (which I assume you are doing) than it is far faster than the CPU. There are bound to be lots of other uses which require a whole bunch of (mathematics) but don't require a constant data stream...

Since DVI is just a really high speed LVDS link, you can probably use the same circuitry on the board and instead of sending video to a monitor, send e.g. distributed computing data to a network (a bit far-fetched, I know...). It might be useful for the host computer to know what the FPGA is actually processing without interrupting the flow of information from host to PCIe card. Another thing that would be cool would be to have one DVI transmitter and one DVI receiver on a board, then stick one of these in each of two different computers. Suddenly you have a full duplex 7.4Gbit/s point-to-point link :-) (yeah, I know gigabit and infiniband are faster, but they usually don't have an on-board 256MB buffer...) As for a less crazy idea, it would be useful for a DAQ system for the FPGA. That way you can send DAC data without interrupting the flow of ADC data coming in. This could use the FPGA has a noise/ digital signal filter/FFT/whatever you want, and have a constant stream of data with enough bandwidth to probably send the converted and original data. ...

OGP and Traversal

Traversal on the Web

Traversal has been very busy working on our development board but finally they took some time with the help of the list to prepare a web page. This will eventually be where our graphics development board OGD1 will be purchased from after we finish verification. http://www.traversaltech.com/

Many from the list gave suggestions and comments which improved the site and Andy mentioned his appreciation for the assistance.

Future developments

A question was raised about Traversal allowing the OGD1 development Card to be used in proprietary designs:

Jack

From a strategic viewpoint, anybody who buys open-design hardware parts for any reason helps build up volume and bring down piece parts costs, and that helps all of us. Anything that increases the popularity of an open-design part helps our general credibility — so we want the world to know where the part is used.

Timothy

My primary concern, making this an open source project, is being able to sell to people hardware they can use with free software. If (...) some big company orders a million of them and makes us sign an NDA that prohibits us from telling anyone who bought them, and they use the chips in some completely closed-up way, I'll be a very happy person. That deal has no negative effect on your ability to use this product.

OGD Architecture

TV Out and DVI
in reply to a question of whether it will be possible to run tvout and DVI, Timothy replied:

*Head 0 gives you a choice between DVI and analog.

*Head 1 gives you a choice between DVI and TV.

*Heads 0 and 1 are independent of each other.

So, the answer is yes: Use head 0 for the DVI and head 1 for the TV, and you're all set.

(Effectively) head 0 is DVI-I and head 1 is DVI-D.

Dieter then mentioned

I was under the impression that both heads were DVI-I, with one having higher performance.

Timothy agreed:

Yes, but that's a special option.

Open Hardware Foundation

Hardware Documentation

Joseph noticed regarding one site with Hardware Level VGA and SVGA Video Programming documentation:

The FreeVGA project mirrors are dead. the original page is still active (but for how long?), and no feedback form left working.

He states regarding copyright:

# The documentation may not be <snip>[mirrored] in part<snip> unless specific permission is granted by the author.

# The FreeVGA Project documentation may be distributed in non-electronic form to <snip> members of a programming team subject to the condition that it be provided free of charge. <snip>

With the Author no longer able to be contacted this documentation was becoming neither Open nor Free (as in freedom). Preserving this type of Hardware documentation might be more the field of The Open Hardware Foundation.

Mini FAQ for the Open Graphics News Group.

Where is the group?
Gmane.comp.graphics.opengraphics
How can I get it?
Using your favourite newsreader point it toward news.gmane.org and subscribe to comp.graphics.opengraphics
Which newsreader can I use?
There are many. Specialist software such as Pan (Linux & Windows) or Gravity (Windows) are well known, but there are many others, and often your favourite email software can mostly function as a newsreader.
Can anyone post?
Yes, but the list is moderated

Suggestions for this newsletter are welcome and are made through the mailing lists.