Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Lack of Open Tooling for FPGAs

curtis.io

Post reply on HN
Print view View original

81–90 of 125 posts

Re: The Lack of Open Tooling for FPGAs

#81

Post by makomk »

kornholi wrote: post #9
astrodust wrote: post #5

The tools for FPGAs are horribly clunky and extremely difficult to script since most are Windows GUI based. Glad to see people working to rectify this.

Not just FPGA tools, pretty much the whole EE industry. Few days ago I had trouble saving results from a semiconductor analyzer. The problem? Path had spaces in it. If you have the time to display a warning that it doesn't support spaces (on windows!), you should be able to fix the issue. Just imagine how bloated their codebase that you can't fix issues like this easily. Recently I was trying to use ModelSim (HDL sim…

ModelSim isn't even the most clunky FPGA-related tool I've used. That honour has to got to Xilinx's FPGA Editor, which has been ported to Linux using some ancient, proprietary Motif-based Windows API compatibility layer with a whole bunch of interesting issues running on anything other than the approved RHEL version.

Re: The Lack of Open Tooling for FPGAs

#82

Post by phkahler »

ChuckMcM wrote: post #22

This does a good job of capturing the first part of the problem. Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. The critical thing to understand, is that FPGA users (the big ones, not the casual ones) don't want them to be open. They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass prod…

>> They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass produced to under cut them.

So how does having a closed tool chain achieve that? Aren't the FPGAs programmed either on the line, or from ROM at power up? Either way, board producers should be able to replicate the product. How does being closed help?

Re: The Lack of Open Tooling for FPGAs

#83

Post by gluggymug »

diamondman wrote: post #24
kornholi wrote: post #9

Earlier quoted context omitted.

Not just FPGA tools, pretty much the whole EE industry. Few days ago I had trouble saving results from a semiconductor analyzer. The problem? Path had spaces in it. If you have the time to display a warning that it doesn't support spaces (on windows!), you should be able to fix the issue. Just imagine how bloated their codebase that you can't fix issues like this easily. Recently I was trying to use ModelSim (HDL sim…

I am OP astrodust: That is exactly the problem :). Turns out ISE (Xilinx's tool) has several command line tools that are run by the GUI in order, but the arguments are not documented. I was able to make a Makefile that did the ISE compilation so I could edit in emacs, but that was way too much crap to be real. The new generation of Xilinx's tools, vivado, is written in Java and does not output any temporary files so…

Lol. I used to work in HW.

You are kind of insulting but it's true: we take what we can get. I am not sure what you are suggesting HW engineers do.

Who has time to build a better tool? That's a massive task. When you are on a project, you work on delivering it.

Projects fork out several thousand dollars for tools licenses because revenue for the finished product is in the millions of dollars.

The Xilinx tools are crap. But you just work around them. 95% of HW engineering is fixing the actual design. It doesn't matter that much how good the tools are.

It's like asking a truck driver to build their own truck. They're paid for getting stuff from A to B on time.

Re: The Lack of Open Tooling for FPGAs

#84

Post by mekarpeles »

About @diamondman's Adapt Framework (github.com/diamondman/adapt)

Adapt is an open, modular framework which offers a streamlined approach for JTAG controllers to speak to target devices (currently CPLDs and soon fpgas).

Adapt is built to be extensible and currently includes open/reversed drivers for the following Controllers and target devices:

- Digilent & Xilinx PC1 (JTag Controllers) & XC2C-256 (CPLD)*

*Note: Map files are required for CPLDs to avoid legal recourse

FEATURE ROADMAP:

1. Support for Controllers: Currently Adapt only supports JTag but @diamondman intends to support dbw & spi. Patches for other serial protocols are welcome.

2. Support for Target Devices: The next milestone is to support Spartan3 & Spartan6 fpgas

3. Extending Adapt / Contributing Drivers: Adapt can be extended to additional controllers and target devices -- @diamondman will write a tutorial on how this is done + what the limitations are, if there is enough interest.

Please express interest in driver support by replying to this comment thread.

Re: The Lack of Open Tooling for FPGAs

#85

Post by kevin_thibedeau »

goodcanadian wrote: post #8

I'll offer a guess as to why the FPGA manufacturers are hostile to open tools. Open tools reveal the internal details of their FPGA hardware which is their bread and butter. I think it is probably the wrong approach, but that sort of thinking is common around intellectual "property."

They also invest a lot of money into the software tools and frankly what you can accomplish with the free ones is light years beyond what the full paid tools of 15 years ago could do. Having to compete against an alternate free toolset diminishes their value derived from that investment.

Re: The Lack of Open Tooling for FPGAs

#86

Post by fpgaminer »

phkahler wrote: post #82
ChuckMcM wrote: post #22

This does a good job of capturing the first part of the problem. Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. The critical thing to understand, is that FPGA users (the big ones, not the casual ones) don't want them to be open. They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass prod…

>> They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass produced to under cut them. So how does having a closed tool chain achieve that? Aren't the FPGAs programmed either on the line, or from ROM at power up? Either way, board producers should be able to replicate the product. How does being closed help?

> So how does having a closed tool chain achieve that?

It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though yes, cruddy in various ways).

And to be honest, this conversation about the FPGA (and ASIC) toolchains being closed sources crops up again and again. They're closed source not because Altera/Xilinx/Microsemi need to keep secrets. They already know eachother's "secrets", and the FPGAs themselves are rather trivial devices. They're closed source not because users want them to be; again they couldn't care less. They're closed source because the userbase is absolutely tiny. A small userbase means we will only ever see tools that are sufficient. There is no benefit to Altera/Xilinx/Microsemi to put in extra time and effort open sourcing their work. And honestly, I wouldn't want them to. I'd rather their time and resources go into continuing to drive the price down and features up (as does every other company).

Not that I don't think opensource toolchains/devices wouldn't be great. I follow the MiGen/Milkymist mailing list where some open source FPGA tools are being developed. But in the commercial space, open sourcing FPGAs and their tools isn't the highest priority.

Going back to protecting designs, that's what bitstream encryption is for, which all modern FPGAs possess. Though Altera was quite late to the ballgame on that front with their Cyclone series...

Re: The Lack of Open Tooling for FPGAs

#87

Post by ChuckMcM »

MichaelGG wrote: post #70
ChuckMcM wrote: post #22

This does a good job of capturing the first part of the problem. Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. The critical thing to understand, is that FPGA users (the big ones, not the casual ones) don't want them to be open. They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass prod…

If there's so much value there, how are these companies stopping internal espionage? If a company wanted to see what their competitors were doing to gain a large advantage, they could certainly field a candidate to work as an agent for their competitor. It sounds like how Nikon doesn't document the NEF format and pretends their binaries are the only way to decode such files. Except obviously the secrets these hardwar…

From what I've read of internal leaks, the leakers get caught and charged and dealt with, which discourages other leakers perhaps. But there isn't anything stopping an employee from selling or stealing company secrets. That hasn't changed.

But during the 70's and 80's a lot of manufacturers stopped printing schematics in response to clones appearing which used a circuit that was close (but not exactly like) theirs and sold at a deep discount[1].

Early computer board manufacturers used programmable logic to create special "nodes" within the system which obscured the functioning of things such that to clone them you would have to hire an engineer to understand the design and re-design it. Generally that was more effort than most of the cloner companies were willing to go through. (apparently if they had their own engineers that could understand the circuit they didn't need to clone, they could design their own)

FPGAs get you at least two layers of obfuscation, both the bit stream is encrypted and "decompiling" from the place and route configuration bits is not straight forward at all. Folks who have gone down the path of trying to figure this stuff out (as the OP is possibly doing) discover that changing a routing bit way in the front changes a bunch of other bits later but in very subtle ways. And routing in an FPGA is a great way of screwing up function, when you do timing analysis if you have to run at 200Mhz you have to make sure your setup and hold times are accurate to within a few nanoseconds across temperature and voltage differences. FPGA vendors tout this as a 'design security' feature some times.

Decoding this data is a lot more challenging than reverse engineering an image format.

[1] And yes you can argue this is just business, and it is, and this is just "business defense."

Re: The Lack of Open Tooling for FPGAs

#88

Post by elwin »

diamondman wrote: post #24
kornholi wrote: post #9

Earlier quoted context omitted.

Not just FPGA tools, pretty much the whole EE industry. Few days ago I had trouble saving results from a semiconductor analyzer. The problem? Path had spaces in it. If you have the time to display a warning that it doesn't support spaces (on windows!), you should be able to fix the issue. Just imagine how bloated their codebase that you can't fix issues like this easily. Recently I was trying to use ModelSim (HDL sim…

I am OP astrodust: That is exactly the problem :). Turns out ISE (Xilinx's tool) has several command line tools that are run by the GUI in order, but the arguments are not documented. I was able to make a Makefile that did the ISE compilation so I could edit in emacs, but that was way too much crap to be real. The new generation of Xilinx's tools, vivado, is written in Java and does not output any temporary files so…

> a C to fpga compiler which you would suspect could do some crazy things and took thousands of engineering hours to make work. But instead it just implements a CPU in the FPGA

Is that seriously how Vivado HLS works? Now I'm glad I decided not to buy it.

Re: The Lack of Open Tooling for FPGAs

#89

Post by snops »

diamondman wrote: post #73
snops wrote: post #46

Earlier quoted context omitted.

In the microcontroller world, expensive debug dongles are essentially hardware keys for the software included. Lauterbach's[1] Trace32 for instance don't even have software keys, the license for their very extensive debugging software is stored in the dongle itself. Another piece of software that isn't often mentioned in these discussions is the driver for the embedded flash memory inside parts. USB has quite poor la…

Very well written. I had no idea some companies went so far as directly making their debugger the software key. That is intense but makes a lot of sense. In the case of the Xilinx Platform Cable I wrote firmware to, they have a CPLD that does the JTAG writing of data, and a Cypress FX2LP handling the USB information. They use a quad buffered USB endpoint to let the PC load as much crap as possible into USB and in my…

>Are you talking about the flash driver for loading external SPI flash?

I was slipping into talking about ARM microcontrollers there, which have internal flash. Reads from it are memory mapped, but writes generally require feeding peripheral registers with commands, hence the latency sensitive read-modify-write. Some ARM microcontrollers do have more direct methods though, some of Freescale's Kinetis range have a feature called EzPort, where you hold a pin low on boot and it pretends to be SPI flash instead, and tiny 8 bit micros like the AVR all have something similar as full JTAG would be too big for them.

>If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip.

Yeah, this is what I meant by having code run on the "target", this being the microcontroller you are programming. You are right in thinking this means the JTAG dongle no longer needs to know how to program flash itself, but it still needs to code to load in and instructions on how to do it (setting up clocks etc), which are also very platform specific. You could do the same for external flash, but its often easier just to connect to it directly and bypass the microcontroller.

Feel free to PM me if you have any more questions.

Re: The Lack of Open Tooling for FPGAs

#90

Post by UncleOxidant »

jjoonathan wrote: post #67
UncleOxidant wrote: post #48

Earlier quoted context omitted.

How about using VHDL and records? I think these are synthesizeable outside of ports. VHDL is a much better language from a software engineering standpoint than Verilog.

I know nothing about VHDL -- I vaguely remember hearing someone say it suffered from the same issue so I didn't pursue it. Thanks for the tip!

VHDL is more strongly typed than Verilog (I consider this a good thing). Sure, it's a bit more verbose, but the language is more expressive than Verilog - allows overloading operators, for example. A nice example of the advantage of VHDL over verilog is that there's a FixedPoint type in VHDL (as of VHDL 2008, I think) whereas in Verilog you're on your own to line up the binary points - very annoying.
Post reply on HN