Phrasing!

Reading this whole thread, I'm reminded of a gripe I have about the FPGA manufacturers, or at least Xilinx and Altera.

If they -- or just any one of them -- would PUBLISH the details of how their bitfiles map to the workings of their FPGAs, then all of a sudden that company's stuff would be the subject of all the intensive university research on FPGA optimization that you might desire, and possibly even see an open-source tools ecology grow around its parts.

It wouldn't immediately lead to nirvana, but it may at least lead to more and better optimization, and lots of people experimenting with different optimization approaches.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com 

I'm looking for work -- see my website!

Let's say I am Xilinx... I have a bazillion dollars of investment into my products and the support software. I sell to large companies who want reliable, consistent products. I open up my chip design and a bunch of university idealists start creating tools for my devices. The tools work to varying degrees and are used for a number of different designs by a wide variety of groups.

So what happens when some of these groups report problems "with the chips"? Are these problems really with the chips or with the tools? If any of these groups ask us to deal with these problems, how do we begin?

In other words, how do we keep these tools from causing problems with our reputation?

--

Rick C

"You have reached the Xilinx automated help line. To ask about problems using our chips with unapproved tools, please hang up now..."

But yes, I see your point.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com 

I'm looking for work -- see my website!

Many people have suggested that advantage.

I presume the information will never be released because the information is

- not part of an "API" that is guaranteed over time

- highly proprietary,

- highly device specific,

- possibly varies and is corrected over time (Xilinx is good at suite updates)

- only available in a form that is directly relevant to their design tools, i.e. tightly coupled) and hence is

- difficult for someone else to interpret and process correctly

- opens all sorts of cans of worms if a third party gets it wrong

Analogy: Intel guarantee the "machine code API" of their processors, but the detailed internal structure is closely and varies significantly across processor generations.

The big issue is that much of the information that would be included in such a publication is information classified by the companies has highly competition sensitive. While companies document quite well the basic structure of the fundamental Logic Elements and I/O Blocks (and other special computational blocks), what is normally not well described, except in very general terms, is the routing. In many ways the routing is the secret sauce that will make or break a product line. If the routing is too weak, users will find they can't use a lot of the logic in the device (what they think they are paying for), too much routing and the chips get slower and too expensive (since building the routing IS a significant part of the cost of a device).

To 'Open Source' the bitfiles, you be necessity need to explain and document how you configured your sparse routing matrix, which may well help your competitors next generation of products, at the cost of your future products.

I can totally understand why Xilinx wouldn't want to mess with this. It's a support nightmare and customers would definitely associate poor open-sour ce software with the chips. I'm not even convinced that open-source tools would be any better.

At least, in the worst case, I can instantiate primitives, but I wish the t ools gave me a little more ability to override bad decisions without doing that. There are a lot of case in which I can do a better job but if I put in KEEPs, the tools ignore them, leaving me little choice but to instantiat e primitives. Another thing they could do is to have more synthesis direct ives. There are lots of good structures in the hardware, such as F7-F9 mux es, that the synthesizer almost refuses to use, and I can only make use of by using primitives. Perhaps a directive would allow me to infer a mux but to force (*USE_F7*).

And the built-in FIFOs: why can't I infer them? Preferably using the push /pop keywords from SystemVerilog. That is the kind of "high-level synthesi s" I am looking for: to not have to write structural HDL. These kinds of incremental changes to their tools would be far more useful than their HLS or AccelDSP or whatever.

I wish, after working on this since 1984, they had more solid synthesis. T here is supposed to be an intermediate layer between language-parsing and s ynthesis to primitives. When I write the same logic in two slightly differ ent ways and get totally different primitives, I know that something is klu dged. When I have to DeMorganize by hand to get better synthesis something is wrong. I am being paid to work out complex problems in Galois arithmet ic, not to do freshman-level Boolean logic.

There is indeed work going on into FPGA 'virtualisation' - creating vendor-neutral intermediate structures that open tools can compile down to, that either vendor tools can pick up and compile or will map to some pre-synthesised FPGA-on-FPGA.

I'm not sure if there's anything near mainstream, but I can see it's going to become increasingly relevant - if Microsoft have a datacentre containing a mix of Virtex 6, Virtex 7, Ultrascale, Stratix V, Stratix 10, ... FPGAs, based on whatever models were cheap when they bought that batch of servers, the number of images that needs to be supported will start multiplying and so an 'ISA' for FPGAs would help the heterogeneity problem.

Theo

There is an IEEE standard for synthesizable VHDL.

But is *is* like writing C per-ANSI, when every compiler had its own variant.

There's a IEEE standard for the synthesizeable subset of Verilog-2001 too: (IEEE 1364.1 - 2002) I know it well, as I contributed to it. It's a shame they never did one for SystemVerilog. It was suggested, but some internal politicking on the working group struck it down.

It's left us with a hit-and-miss method of finding the least common ground between toolsets. We're actively struggling with this now.

But this doesn't change Kevin's observations much. Defining what the tool should accept, still gives the tool a LOT of leeway on HOW to build it - as Kevin's shown with this example. After all, all implementions shown in this example are "correct". Some are just more optimal than others (and like always the definition of "optimal" isn't concrete...)

Regards,

Mark

pre-ANSI

The churn in language revisions isn't helping either

This is a point, although a weak one. The same should also happen to the microcontroller industry... but does not. They are quite happy selling chips that are being programmed by the open-sourced gcc toolchain.

Pere

Also consider that on the gcc side of things that they have a lot of people who know how to write software that are writing and developing the gcc sof tware. There aren't nearly as many people who know how to write software w orking on software stuff for hardware like FPGAs. Witness that we don't ha ve much of anything other than GHDL as a basic simulator. Development on t hat is up to the whims of one person who chooses to work on it (or not in w hich case everything stops...as it has of late).

It wouldn't surprise me if FPGA companies probably consider that the open s ource community would take forever to develop anything.

Kevin

I think this is apples and oranges. It is easy to look at the output of a compiler and see what it is doing. The details of the configuration file for an FPGA is not so easy to analyze. Also, the configuration bit stream isn't just a matter of telling the chip what to do, it can set up internal conflicts that can damage the chip.

Even if the FPGA vendors release their technical info on the configuration bit stream, it is a very complex thing to deal with.

--

Rick C

An ISA is an API. A lot of work goes on implementing the microarchitecture which implements the API, either in hardware or software (microcode). Another lot of work goes on proving that the implementation matches the API and is bug-free (and 'halt and catch fire' is definitely a bug).

FPGA silicon doesn't have an API, you just have the raw transistors to control. The main safeguards to prevent them generating flame-inducing configurations (or more prosaically customer returns) are in the tools.

You can put an API on top of an FPGA (eg as the 'FPGA virtualisation' folks do) but the performance and flexibility impact is substantial. As far as I'm aware of the current state of FPGA virtualisation (admittedly not that much), there's nothing there that would be usable in a product anytime soon.

Theo

I kind of doubt that would happen. I don't think there are enough hardware knowledgeable folks who can write good software. If there were, we would all be simulating with some open source VHDL+Verilog simulator that puts Mo delsim and Aldec to shame [1]. But instead most people I think are using M odelsim/Aldec or some lame simulator that comes bundled with the tools.

Since there apparently aren't many folks diving in to develop something tha t would benefit many with a decent simulator, why would you think there wou ld be enough to dive in and help develop something that benefits a subset o f that market?

Open source developers tend to use their tools in their day to day work as well. Those developers 'only' need to be good at developing software in or der to develop open source stuff. When you talk about open source tools to be used for hardware development, you would want to have someone good at d eveloping hardware and software so that the tools they develop they would t hen use day to day. If nothing else, there are fewer of those folks that h ave both skills and, based on the lack of developers for open source simula tors, I think there just isn't the critical mass.

Manufacturers keeping their details secret could be seen as nothing more th an their seeing that there aren't enough people out there who could even de velop what is needed in an open source scenario. So they pay people to dev elop what they need.

I know you're not holding your breath waiting for that nirvana...but I'd wa ger that you will have taken your last breath long before such nirvana was reached.

Kevin Jennings

[1] Yes I know about GHDL and it is and appears to have always been a one m an band. The original band member left the band and years later someone el se picked it up. Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015, nothing new in about 12 months and counting. It is still not up to release 1.0 and there will be another revision to the VHDL standard i n 2017. One person can only do so much...in addition to doing something th at puts food on the table.

Tristan moved the development to GitHub:

-Brian

That's good to hear, now you need to let Google in on the secret. I do see there is mention of the move to Github on the summary page on SourceForge page, but maybe you should consider pulling all the old stuff down from Sou rceForge and put some more redirection links to the new home.

Kevin Jennings

re knowledgeable folks who can write good software. If there were, we woul d all be simulating with some open source VHDL+Verilog simulator that puts Modelsim and Aldec to shame [1]. But instead most people I think are using Modelsim/Aldec or some lame simulator that comes bundled with the tools.

I agree. It doesn't seem likely that there would be a lot of people versed in low-level silicon design and high-level software and who would also be willing to put in a lot of time for free.

I don't suppose there is anything stopping somebody from making a synthesiz er--you can just convert RTL into structural HDL containing primitives--but I don't see a lot of free synthesizers around.

The MyHDL community is vibrant [1], and this fast[2] simulator exports Verilog and VHDL for synthesis.

I'm using open source tools [3]. As for community, there are many users, not sure about developers, maybe clues here [4].

Clifford did/does warn about frying chips, but the value of the project far exceeds the cost of a few sacrificial ICs.

Jan Coombs

--
[1] http://myhdl.org/ 
[2] http://myhdl.org/docs/performance.html 
[3] http://www.clifford.at/icestorm/ 
[4] https://www.reddit.com/r/yosys/comments/4ocilz/icestorm_adding_support_for_new_devices_part_1/