Newsletter Archives

Oct 10th 2006 Open Graphics Project Newsletter

• Oct 10th 2006 Open Graphics Project Newsletter
• Announcements
  • First Prototypes have arrived
  • Testing the new prototypes
  • Beta Release of Memory Controller
• Progress and developments
  • The State of Linux graphics and writing Drivers
  • Alternatives to gtkWave
  • OGD Developments
  • Utah Spinner
  • OGP and Traversal
    • Northbridge Licensing
    • Licensing OGA and the GPL
    • Traversal, Digital Rights and Codecs
• Hardware Selection and Revision
  • Hardware Clarifications
• Open Hardware Foundation
  • Progress and Developments
  • Defining what is open
    • Open Hardware, Copyright and the GPL
  • Mini FAQ for the Open Graphics Mailing list.

Over 113 Posts covered in this Newsletter

Announcements

First Prototypes have arrived

Timothy confirmed that the first prototypes have arrived. Once we are finished with the prototypes we move on to selling ODG1:

Testing the new prototypes

Timothy:

I want to put together a test suite for video. (...) This is more of a "does the hardware work" test. We're quite far from having anything that can have any kind of normal display. Here, I'm talking about writing Verilog code that does nothing but generate sync signals. Just a little bit of logic for the FPGA that just has a few counters. The objective is to ensure that the PCB (of which we already have a nearly-populated prototype) is wired correctly, in that the right FPGA pins are connected to the right pins on the DACs and DVI transmitters, etc. Most likely, the problems we would find are related to signal integrity issues, rather than something being logically miswired, but we want to check that too. Using the video controller Patrick and I worked on would add too many variables and too many things to debug. What we need here is the simplest possible logic that will put meaningful signals out video.

(He gave some examples and invited others to suggest more):

There's no memory involved. Just video signals. So, to begin with, how about someone give me the raw timing numbers for, say, 800x600@60. Shortly, I'll provide a module header for the video pins on the two interfaces.

S. Person provided the timing numbers and a template for hardware testing was released. Timothy:

here's a template for head zero. This is the one that connects to the 330MHz triple-DAC and to the first pair of DVI transmitters.

Beta Release of Memory Controller

Timothy:

You can find the latest version of the memory controller logic here: https://svn.suug.ch/repos/opengraphics/main/trunk/rtl/mem_ctl/tims/

(...)Look at the "makeit" script to see which files are being used. The "runsim" script automates simulation with Icarus and signal view with GTKWave. You can see a history of versions of the fsm part of the memory controller. fsm2 is a redesign of fsm, and fsm3 is a redesign of fsm2. fsm4 is just a speed optimization of fsm3, so fsm3 is checked in as documentation.

The memory controller is broken up into the following stages:

[buf] Disconnects the internal state machine busy signal from outside logic.

[rh] Two stages that constitute primarily row-hit detect logic

[fsm] Two stages that constitute the primary state machine that manages commands to the memory chip, timing delays, reads, and writes.

There is some additional pipelining that brings latency for writes to 5 cycles and latency for reads to somewhere around 12 cycles (depending on CAS latency and phase differences between command clock and read clock). However, the delays are often much longer due to the need to open and close memory rows before read and write commands can be submitted.

In Xilinx Spartan 3 FPGAs, I have found this design to run at 200MHz or better when it's synthesized in isolation. Also, the fifos have been optimized for performance:

https://svn.suug.ch/repos/opengraphics/main/trunk/rtl/fifos/

Things we could use help with:

- Augment the test environment, adding more stressful tests

- Add a model of a DDR memory (write a simple one or get a commercial model to simulate with Icarus).

- Document the design, as well as add in meaningful comments.

Any takers? Don't be intimidated by the fact that this is in Verilog. There is stuff there for you to work from, so it's more like tweaking than new coding.

Progress and developments

The State of Linux graphics and writing Drivers

Jon

Mesa is a complete software implementation of OpenGL. To hardware accelerate Mesa you write DRI drivers. A DRI driver updates the dispatch table in Mesa to call your accelerated replacement function in the DRI driver instead of the software implementation. DRI drivers should be able to run without being root, so they rely on corresponding DRM kernel drivers. There is no standardized interface between DRI and DRM drivers, each pair can do whatever it wants. That model is named exokernel.To port Mesa look at the source for the various DRI drivers in the Mesa tree. The source of the DRM drivers is in the kernel tree. If you want the kernel to run 2D without using VGA mode you need to write a framebuffer driver. There is a skeleton for doing this in the kernel tree. This driver implements mode setting in the kernel. 2D X needs yet another driver, either XAA or EXA. This driver reimplements mode setting in user space. Needless to say this is a mess, but the various groups won't cooperate to clean it up.

James

I don't see the DRI/DRM issue as a mess but there are issues. These are just two pieces of the same driver. The only advantage that could be gained is if there was a standard DRI driver which any DRM driver could use. This doesn't seem to require cooperation — somebody just needs to write a standard DRI driver which is able to do everything. The advantage of using it vs. writing your own should be obvious.

Jon

The DRM drivers provide an IOCTL for processing command blocks to the card. DRI drivers build the command blocks and submit them. Since all of the cards use different command blocks all of the DRI drivers are different. Some of the ancient 3D hardware doesn't even use command blocks. Check out the DRM IOCTL interface. There are about 10 common IOCTLS and the rest are board specific. GGI/KGI tried to make a uniform interface for graphics hardware in the kernel. That attempt failed a couple of years ago. To make a uniform KGI interface you have to push too much of OpenGL into the kernel. You don't want to end up with a 4.5MB device driver like Nvidia has.

A poster asked about Xgl
James

Xgl would still services the standard X calls. It would have to for backwards compatibility. It just uses the GL drivers rather than the existing 2D X drivers to do drawing functions. Naturally, 2D apps can also call GL directly and I think that some of them already do since when building some 2D apps, the configure script looks for Mesa. Naturally there is less overhead using GL directly for actual 2D drawing than going through X — don't know how much difference this makes.

Jon

XGL is from David Reveman at Novell. (...) XGL and EXA are going in two different directions.

Alternatives to gtkWave

Peter:

I finally got fed up with gtkwave. It'll probably take a day or two more before v0.1 is out. I expect it will be useful even though it won't have feature parity from the start. Especially since the usability is my first priority. The version in the repository doesn't handle scrolling and the drawing isn't complete but it should be good enough for at least a smoketest. If anybody has a VCD file it won't parse or if they can't compile it or if it crashes, I'd really like to know... http://vax64.dk/bølge/

( http://vax64.dk/b%c3%b8lge/ )

Timothy quickly added a few feature requests:

May I please make some feature suggestions?

- Make the signal viewer able to run the synthesizer... that is although you wouldn't want ivi to be embedded into your viewer, make the viewer able to run various simulators in a way that appears seamlessly integrated to the user.

- Allow the user to "rerun" the simulation without changing the signal view. Say I'm looking through the results of the simulation and find a subtle bug. What I'd really like to do is edit the RTL and rerun it, putting me right back where I was so I can continue looking for other bugs.

There are certain things that, for instance, ModelSim? does that I wouldn't ask for. Actually, I hate ModelSim?. But one thing it can do is allow you to simulate for some period, and that appears in the wave viewer. Then you can simulate some more, etc. Don't bother trying to do that. If the second suggestion requires a complete rerun of the simulation, fine... just give me the same signals, zoom ratio, view offset, and selection.

Peter replied that many of these were already in progress. Thank you for working on a better viewer, Peter.

OGD Developments

Utah Spinner

John released his latest graphics design using the Xilinx Spartan XC2S200E FPGA:

This release most importantly adds a Z-buffered polygon scanline routine to the TVC. The MCU has been improved to allow unaligned access to the framebuffer and a real scheduler has built into it to fairly share the framebuffer between memory users and yet give the display priority access to pixel data. A simple C++ 3d engine (included) drives the TVC and spins a flat shaded Utah teapot about its y axis in one degree increments. The driver software now only flushes epp data registers that have changed to the TVC. A block set memory user has been added to speed clearing the front and z buffer. The rp_writer memory user has been removed partly for logic space constraints. The development hardware is unchanged from Release #1.

OGP and Traversal

Northbridge Licensing

One poster asked about the planned Traversal chip:

TRV10 will be a graphic chip targetting the embedded market, could it be integrated in a northbridge?

Timothy

Yes. Someone will be able to license the RTL in such a way that it could be integrated with another chip.

Licensing OGA and the GPL

Timothy described his thought regarding licenses, OGP and Traversal.

OGA is an architecture that is comprised of pieces that themselves are under GPL license. Should any one of those pieces be incorporated into another CHIP, I would want the design of that CHIP to be covered by GPL. This applies to OGA as a whole. In my opinion, putting OGA and another design onto the same physical piece of silicon is not mere aggregation. Someone might argue that putting it together with a RAID controller IS mere aggregation, but I'm not going to worry about that just yet.

OGA can, itself, span multiple pieces of silicon. For instance, on OGD1, the PCI controller is split off. This physical separation does not, to me, constitute a semantic separation. OGA is still one design, just as an application is one design, even if different components of it are distributed over multiple computers. On the other hand, this does not spread to things that are not part of the design, like DVI transmitter, RAM chips, and the host computer. For one thing, we can get those chips from multiple suppliers. How crutial to the whole product they are is arguable, but I do not consider them to be part of the design.

If a TRV10 chip were placed on a board with other components that are not defined as part of OGA, they should not be affected by the GPL. That is mere aggregation.

Hamish asked is this could be similar to the equivalent therefore of runtime linking of shared object libraries?

Timothy:

Yes, but only in the sense of having that linking being of an optional plugin rather than a required component. Perhaps it's an application/platform division, with TRV10 being the platform. TRV10 is somewhat useless without memory chips, but you can choose any conformant memory chips.

The OGC1 PCB is a design that is copyrightable. But that copyright does not spread to the components on it. If someone were to fabricate OGC1 or OGD1 or whatever PCB and release any mods they made, that would be legal, as long as they conform to the license. This is irrespective of what they put on the board. If they copy TRV10, that's okay too, as long as the licensing is respected.

Hamish

The equivalent in the HW world for static linking therefore (Which AIUI requires GPL releasing) would be to take the OGA, TRV10 etc definition & create a new chip or chipset that extends it's functionality, and is unable to be separated out from it by an end-user... (Even if the end-user has a soldering iron & wire cutters).

Terry

Yes, and I think that this much can be achieved with the existing GPLv3 (draft 2), and appropriate use of Section 7 to define and permit a release of copyleft requirements across specifically-defined boundaries. This means you actually create multiple specific licenses(...) This way you can be completely explicit about the "system boundaries". If these licenses were mutually incompatible, that would be a real problem, but in fact, if I read things right, they're all GPLv3 compatible licenses, so "license-proliferation" isn't really a problem (strictly speaking, the complaint about the "proliferation" of open source licenses is only really applicable to the proliferation of *incompatible* open source licenses). The stickier part of using GPLv3 is that you must also define the terms "convey" and "propagate" as used in the license. This probably means you need a more explanatory "license grant statement" (this is the text in the design documents that tells the recipient what the license is). I'm going to have to look into this and ask some questions.

Timothy:

There's something I'd like to prevent, (...)I don't want someone leaving the PCI controller on the XP10 intact, reprogramming the S34000, and then selling it as proprietary product. In that case, I want them to release the source to their design or pay a licensing fee for the use of that PCI controller. (...) I want to declare the two FPGAs as being effectively one device and that whatever's in one is license-bound by what's in the other. Or in other words, what is in one chip is not merely aggregated with what's in the other chip, simply by virtue of the licensing of the PCI controller and the rest of OGA.

Lourens

The GPL declares any compile- and link-time interfaces to be "tight" in the sense that the GPL propagates across such an interface. The LGPL declares run-time (late) link interfaces "loose". The MIT licence declares all interfaces "loose". Authors can make "loose" couplings "tight": you can relicence a work derived from one published under the LGPL under the GPL. But you can't make a "tight" coupling "loose" (you can't relicence a work under the GPL under the MIT licence). So maybe we could declare certain interfaces "loose", just like you can publish a programme under the GPL with a special exception to allow linking to some proprietary library you use.

Terry:

You need a "Chipset" license in the GPLv3+Section7 model I described above. That makes it clear: all of the chips are together considered part of a copylefted "system". The idea is that the GPLv3 is starting from the position that the whole device is automatically under copyleft, and it's our refinements that increase the range of possible non-copyleft use (so they are "additional permissions", which is pretty much unlimited under Section 7, whereas "additional requirements" are limited to just a few possibilities). FWIW, I think you can actually do this with GPLv2, but the design of GPLv3 makes it easier.

Timothy

There are three licenses I see providing with _certain_ OGA components (video, memory, PCI, SPI, etc.):

- Via GPL — you can use it on your own design, as long as you conform to GPL

- Single-use commercial — when you buy N OGA boards, you get N individual commercial licenses to use those IP blocks however you want, regardless of the GPL.

- Full commercial — You pay a license fee and can use those blocks anywhere in any design, without concern for the GPL.

This kinda nullifies my original statement: Given these term, we're explicitly permitting someone to reprogram only the 4000, leaving the PCI controller intact and reselling it commercially... because effectively, they're reselling OGD1 boards as another product and conforming to the single-use commercial license for the IP that comes with it. Note that some of this ("Logic Core") won't come with OGD1 right away. But it doesn't matter where you get the code from (as long as it's Traversal's version); you can use it with OGD1 without restriction.

Traversal, Digital Rights and Codecs

Timothy asked

Regarding GPLv3 and DRM, is there going to be a problem wrt codecs we might want to include in a design?

The discussion mostly concluded with Timothy again:

Technically, since Traversal will own the copyright for OGA and TRV10, we can license it however we want, so we can recombine things however we want. What'll suck, just from a purely idiological standpoint, is having to combine a closed or counter-GPL algorithm on our own otherwise completely open chip. (...) we'll make sure that any DRM logic we implement does not in any way "enable" people to break the DRM in ways that might violate the DMCA or copyright law. (...) for the most part, we'll try to rely on off-the-shelf external chips to implement things like HDCP en/de-coding. I don't want any things like that in our chips if I can help it. But I'm not going to steadfastly refuse to provide a legal mechanism that users demand just because someone has applied the label "DRM" to it. These things will have to be carefully considered on a case-by-case basis.

Hardware Selection and Revision

Hardware Clarifications

Open Hardware Foundation

Progress and Developments

Patrick has been hard at work behind the scenes as his post showed:

I have (been) contacting all the people who have been nominated for positions on the Open Hardware Foundation board of directors to gage their levels of interest and to answer any questions they might have. Once I have spoken with everyone and have a the complete list, we will have some internal discussion to do regarding the organization of the Foundation, who will be filling what roles, and such things. Once that has been completed, I will make a formal announcement to the list.

Defining what is open

Lourens raised the question for the Open Graphic Developers what did they mean when they spoke of Open Hardware.

Rob:

"OPEN" means open.

If it is possible to hide unwanted functionality inside the box, then it is not open. The only way to prevent that is to make it completely transparent and therefore auditable. I do not believe such hardware exists today. Much of it phones home without authorization from the consumer, some of it is hackable through back doors as are some voting machines. (...) An uncompromised Open Hardware Community (few organizations are uncompromised) would find anything other than complete transparency unacceptable.

Hamish

Personally open-hardware to me means open specifications. And a license to use the hardware to it's best ability without prejudice. As a couple of examples? The 6502 would be open. Because it's well documented at the register level & connectivity. You can (could?) download specs & put it into your own designs without signing non-disclosures & were free to create programs to run on a design based around the 6502 without paying license costs to anyone. Specs good enough to simulate in sofware & build your own, even of HDL not available for it. At the other end of the spectrum is chips like the ATI x1400 (R5xx family IIRC). You can't do (anything) a non-disclosure from ATI. No register level docs etc. (...) Maybe we do need several levels of openness... With the lowest being complete register level...

Lourens:

If the interface is fully documented then it could be called Standards Compliant Hardware, or perhaps Generally Useable Hardware. I agree that this is a useful distinction to make. And I like the term "generally useable". It probably also depends on your point of view. A software developer probably only cares about having the interface data available, so that a free driver can be written. A hardware developer isn't going to have much to work with if she only has the interface description. To a hardware hacker hardware with closed HDL but a documented interface isn't very open at all.

Jonathan:

Perhaps the aim shouldn't be so much to "DEFINE" what Open Hardware is, but "DEFINE" the "GOALS" or "INTENT" of the Open Hardware Foundation. Clearing set forth what OHF is ABOUT fostering, and what their INTENT is.Not so much setting up rules about what methods or levels of "Openness" are OKAY, but more about what OHF is about and where they are headed..

(An) "open standard" or an "open specification" or "open interface" provides a platform for free software (and other software of course) with a "level playing field". (with) "hardware hacking" or "community based peer production" of hardware (...) I personally call this "free-licensed hardware design" or "free hardware". It is of course, *also* "open hardware", since the spec is easily providable if you have the complete design.

IMHO, *both* are important, and an Open Hardware Foundation should support both and provide resources for both. I think, though, that the latter kind of "free and open" hardware should be the focus, because it's the most in need of support. Supporting "open spec" is more of an industry lobbying effort, and less of a grass-roots production effort. Still, going back to the "platform layers" issue, "open specs" make more "free-licensed hardware" feasible.

James provided some clarity:

I see Open (Source) Hardware as hardware for which the source code is published in a hardware logic language (including adaptions of 'C'). Yes, this can by CopyLefted?. If the current GPL needs some modification to be totally applicable to hardware, they we need to work it and issue the GPL for Hardware — the HGPL. Perhaps we might also need an LHGPL. Or, the Open Hardware could be licensed under the modified BSD license: You can do anything with this that you want except you can't claim you wrote it. But, you are not required to say who did write it.

Then there is proprietary hardware that has full documentation. This should include what every bit and every register and instruction (except those reserved for testing) does. If the hardware executes code, this should have the same level of documentation as the instruction set of a MPU. As chips become more complex, it appears that additional information is needed on exactly how to use the chip for its intended purpose — a programmer's guide is needed. What should we call this? Open Documented Hardware.

There are some companies that seem to fall a little or a lot below the Open Documented Hardware standard but still provide documentation. So, there is a gray area between this and the next. So, there is hardware which has some documentation but which is not fully documented.

Then there is closed hardware. I think that we all know what this is — hardware without documentation.

Patrick:

This fits my definition of Open Source Hardware. Everything you need to produce a working chip is available to you. You may still have to figure out how you are going to come up with the millions of dollars necessary to turn what you have into a physical device, but that is an entirely separate problem. (...) while the OHF should support Open Hardware projects, if we are lucky enough to gain any influence, it should also lobby regular companies to produce Open Documented Hardware as JRT calls it. You could also call this Open Design Hardware. The implementation may not be open, but all the details necessary to produce a compatible replacement are, assuming you have the skills and resources to do so. This obviously also means that all the detail necessary to make full use of the device are available too. In my mind, for a device to fall into this category, the documentation must come with no strings attached with regards to use of the documentation to fully implement the functions of the device. I'm not speaking about a manufacturer excluding warranty for use of a device outside its intended purpose, but of agreements that forbid the release of drivers for example. (For hardware which has some documentation but which is not fully documented...)

I'm not sure what to call these either. Perhaps these fall into that category of "deal with it when the problem presents itself".

Terry

I like calling it "Open Specification" hardware. Please, let's not use "Open Design" to mean this, because to me it sounds like you mean the design of the hardware is open (i.e. the other kind of "open"). (...) the "specifications" for the implementation: essentially it's a description of the interfaces it must provide.

Open Hardware, Copyright and the GPL

Some wondered whether the Open Graphic chip designs could be protected using copyright. Terry:

Copyrighted copies *are* goods too, and copyright certainly does apply to them. The thing that makes the copyright law applicable is that these goods convey information. A printed book — a material good composed of paper, cardboard, and ink — is considered to "distribute" its information content. Printing and binding is considered to be part of a reproduction process for that information. Likewise, O/S software burned into a ROM is considered to be software distribution (courts have upheld this interpretation in multiple jurisdictions). (...) The ASIC mask is "reproduced" onto the chip, just as a litho plate is "reproduced" onto a printed page. That is, it is a copying process which does not produce a "new work" for the purposes of copyright. Litho plates for a book are under the same copyright as the pages they print, as is the typesetting document and the original text file: they're all copies of a single "work". (...) When you print PCB boards or ASICs, you are engaging in the same kind of copying activity, and you are subject to the license terms because you are employing the license which gives you the right to make these copies. An end-user who receives the product, of course, does NOT have an obligation to include the source if he merely GIVES his open hardware product to someone (including sales). In fact, there is no copyright obligation involved there at all (in the US, this is called the "first sale doctrine", which is why, for example you can sell used books without paying any royalties to the authors). He only gets that requirement placed on him if he decides to COPY the work. And should he decide to do that, he can always get the plans to include with his copies, because the person who COPIED the work to sell it to him had to agree to provide him with those plans on demand.

Later he posted:

I think the language in the GPL is not clear on how it should be interpreted for hardware.One way to solve that is to say explicitly what you mean in a "license grant", where you say something like: "For the purposes of this license, 'compilation' will be interpreted to mean fabrication of components mastered from the source documents" or some such wording.

Mini FAQ for the Open Graphics Mailing list.

Where is the list?
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, the list is moderated

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