Re: [oc] Volunteer for GPL'd CAD tool

["Tantos Andras" <andras_tantos@yahoo.com>]

Hi!

> I feel really frustrated of the fact that it is impossible to do
> the whole design of a core under my favorite development
> platform, namely GNU/Linux :) There are some GPL'd VHDL
> simulation tools (Savant, which seems almost usable, and
> FreeHDL which is under heavy development). However it is
> impossible to actually produce a netlist, do the placement and
> routing phase, and generate the configuration bitstream of my
> target FPGA. The only solution to do so is to buy proprietary
> CAD software and to run it on Microsoft's proprietary OS.

Well, I disagree in some points:

First of all, (although I would also be very happy if FPGA manufacturers
actually release the detailed programming spec. for there chips so
third-party place-and-route tools could be created) you still have to go for
a non-GPL-ed thing as soon as you try to make the real thing: the FPGA
itself. It's only another step in the chain that not only the chip but some
of it's development chain is proprietary.

Second, many of the tools are available for free (as beer). Xilinx, Altera
and probably others give you free development tools though with limited
functionality.

Third: though I haven't seen any native Linux tools from any manufacturer
there seems to be some movement in that direction: Xilinxes latest ISE can
be executed under Wine (that's one of the main changes of that version). A
side-note: I haven't tried it out but I will. And the main reason for me not
to switch to Linux as a development platform is the lack of usable CAD
(Schematic, PCB) tools, not the lack of FPGA development tools...

> The main raison for this situation is the fact that FPGA
> manufacturers do not provide full technical information
> about their chips (let me know if I'm wrong, maybe I'm
> missing something). For example, Xilinx provide a
> "Virtex Series Configuration Architecture User Guide" for
> their Virtex chips, which explains parts of the
> configuration bitstream for logical units, but there is
> no information about how to actually configure routing
 > between CLBs and IOBs.

I think the main reason for that is that one of the most precious secrets of
an FPGA company is the exact hows and whys of the routing. And they are not
afraid of us, little guys, but from the competition: Xilinx from Altera and
vice versa.

> Of course, not providing these information is a deliberate choice;
> designers wanting to use FPGAs have no other solution than buying
 > the proprietary CAD software of the chip manufacturer.

Or choose a chip from the provider for which there is free development
support...
And one more thing: companies share their costs over the price of the chip
and the price of the development tool. If they can't sell any more
development tools they'd ask more for the chips. At least I suppose...

> And in the same state of mind, manufacturers do not provide
> any Linux support because it doesn't seem worth;
> it is a well known fact that Linux is a closed environment
 > only used by hackers and mad students :)
 >
 > Apart from the fact that designers must set up a Windows box, there
 > are some other negative consequences of this situation. For
> example, I worked with computer science researchers who developed
> a new HDL (it is called Jazz, available on
> http://www.cma.ensmp.fr/jazz/). It can describe synchronous digital
> circuits, and has some very interesting features not
 > found in other HDLs. But to actually run a design in a FPGA with
 > this HDL, we had to do ugly hacks, create our own tools to convert
> the netlist produced by jazz to the input format of the xilinx
> tools. The tool chain becomes far bigger and more complex than
> it should be; moreover, the different tools run on different
> hardware platforms, which is very annoying.

Isn't EDIF a generic and well-documented inter-tool communication format? I
guess even if you have all the detailed spec. to implement a PAR for some of
the FPGAs you would do it as a separate module and use some intermediate
(EDIF) format to pass info from the front-end...

> Proprietary CAD tools have the usual inconvenience of proprietary
> software. They are impossible to debug for the end user, the
> interfaces and file formats are not unified, each manufacturer
> redesigns its own place and route algorithms... It is obviously a
> stupid waste of time and intellectual effort.

That's probably true. However all C/C++ compiler team implements the same
optimization algorithms. That's also a 'stupid waste of time and
intellectual effort'. Even when GCC is there for more than a decade... I
don't think you could change that.

> So why not try to change this situation ? I suggest that the
> opencores project (and maybe other open hardware projects)
> officially publishes an open letter intended for FPGAs
> manufacturer (or individually mails them), asking them for
> donating complete specifications of their chip's
> configuration bitstream. In return, opencores.org would start a
> project of developping a GPL'd CAD tool which would target the
> chips of the manufacturer(s) answering this call.

Yeah! GCC of the FPGAs! Great!!! I'd opt for the open letter. The more
publicity you gain the better, I think...

> As it would have a modular design, such a tool could have different
> frontends, the most important probably being for the AIRE IIR or
> FIR format (for integration with Savant and FreeHDL). One could
> add a frontend for the Jazz language netlist. Several backends
> for the different supported FPGA architectures would be
> implemented. Of course, if we obtained sponsoring from a
> FPGA manufacturer, I would volunteer for this project.

Hmmm... I would say, the idea is great. But! I would give everyone the
opportunity to implement their own back-end without joining the open effort.
I mean: Xilinx would probably still maintain it's own PAR (back-end in your
words) but if it would be compatible with your front-end the world would be
much nicer already. So I'dd suggest creating an open and detailed
specification of the interface between the front-end and the back-end, and
leave the choice open to use any front-end with any back-end. And once
again: isn't EDIF something like that already?

> But one could wonder why FPGA manufacturers would accept this deal.
> Maybe am I only dreaming... However the recent decisions of hardware
> manufacturers (such as Creative Labs donating GPL'd driver for
> their SB Live) can give us some hope, though it is not exactly
> the same context.
> The Open Hardware movement is just at its beginning, but one could
> imagine (and it is probably the hope of everyone on this list)
> that it may become as important as the Open Software movement
> from an economical viewpoint. It could then look very attractive
> for a FPGA manufacturer to be the "official" sponsor of this
> movement, by giving complete specifications of their chips,
> and being the main target for cores designed by this community.

I'm affraid FPGA manufacturers more concered with each other than the
open-source community...

Don't misunderstand me! I think the idea is great, I'm only a bit skeptic
about it's success as it is. To be constructive, here's what I would suggest
as an action plan:

1. Study existing solutions (EDIF, again), in an effort of not reinventing
the wheel...
3. Detailed and exact specification of the intermediate format.
2. Open-letter to the manufacturer, as you've described.
4. Front-ends for HDL->int. format.
5. *Wrappers* for third-party tools that would do the int.
format ->proprietary input format translation along with a (more-or-less)
standardized command-line.
6. Start replacing wrappers with native back-ends as manufacturers join the
effort

With this, until action item 6. you won't need any support from FPGA
manufacturers other than that already there. And you will actually have
something useful at point 5.

And, unfortunately keep supporting Windows for quite some time. I would
suggest to develop multi-platform tools anyways. It couldn't be that hard,
we're talking about command-line tools...

Andras Tantos


--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml