Hacker News Reader

Comment by lnsru | Hacker News Reader

Reverse engineering FPGAs is like stealing a train. It might be fun, but the overall benefit is rather limited.

Vidado isn't most comfortable tool, it does the job and handles all the primitives (memory controllers, clocking, transceivers, etc) very well. I wish somebody could design comfortable IP version control system.

View on HN

Yes vendor tools are free and pretty good at their job, but it doesn't mean there shouldn't be another (or better) way.

Imagine being stuck with Intel issued compilers and 2 programming languages max when dealing with x86 processors.

>I wish somebody could design comfortable IP version control system.

That's true, vivado generates a ton of intermediate files and binary blobs which make source control a frustrating. Another reason to have a nice clean toolchain

I am amazed that apparently, a lot of bigger project formats are not VCS friendly, even in domains where everyone should (?) know how to use git. For electronics, I liked this talk, also from 34C3:

https://media.ccc.de/v/34c3-8818-designing_pcbs_with_code

When I used Vivado a couple years ago on the Zynq, I was shocked by this. It was supposed to replace ISE, but was equally bad at version control. Absolutely ridiculous.

If you export everything as tcl scripts, it actually plays very nice with vcs. Just a bit hard to set up initially, but you can even use make files to generate projects and such

To add why an open-source toolchain would be useful:

It lowers the barrier to entry for FPGA development significantly. The Papilio project, for example, tries to build an "Arduino for FPGA" and runs into the problem that a full ISE or Vivado installation and corresponding license is needed. This aggravates the primary problem that the Arduino has solved for microcontrollers, easy entry.

Also: Incremental builds, partial reconfiguration, porting to macOS. I'm not sure which of these Vivado has solved. With an open-source toolchain, those interested in these features at least have a chance of building them themselves.

The site http://opencircuitdesign.com is ancient, but it appears the tools are still getting updated. For example:

Qflow 1.1: An Open-Source Digital Synthesis Flow

http://opencircuitdesign.com/qflow/

last release: Oct. 28, 2017

IPs can be nice when working with FPGAs, but when it comes to ASICs unless its very detailed piece IP block also works with your fabs process/cell library. You either design your own IP for the fab or find a suitable replacement.

Or are you talking about managing blocks that you or team have designed? That's annoying especially when you have all these blocks with certain performance characteristics such as power use, propagation delay, area ect... So you spend time simulating a design with each of these blocks till you get the one that meets the specs for the larger design, but saves the most space so you can put more things else where. It's nice though that some of this stuff is getting automated, but it's still a pain with analog designs.

These are blocks designed by us. I put now basic configuration of the block as separate Vivado project to git. That’s the pain...

Not sure how much you have looked into it, but the tcl scripts can be quite handy for some things. You can also drive quite a few things from the command line. So depending on what your doing you could just have some text files instead of a whole project being pushed to a git repository.

You do realize an open source tool chain was made off this guys work of reverse engineering the ICE series of FPGAs. Also what about real time alteration or reconfiguration of an FPGA? Pretty hard to do without some documentation. Although, that's kinda like self modifying code kinda hard to design something useful with, but not impossible.

that's nothing like self-modifying code. It would probably be much more like CUDA kernels being uploaded to the GPU. More complex than "single cpu with global memory" but hardly "mr president, the virus is a self-mutating hydra" level.

The fact that digital logic design is constrained to one of two ancient languages by the proprietary toolsets is a serious problem.

There are ways round this by compiling to Verilog (eg Chisel) but it's an uncomfortable halfway house.

There is SystemC, and that's not exactly ancient. It's handy when working at the architectural level.

Also what's wrong with old languages? Looks at C for instance which is much older than VHDL or Verilog.

SystemC and every other high level synthesis language, has to be translated to VHDL/verilog first. That's a big difference with software land.

HDLs are not bad, but not having the option to explore better options is bad

Not entirely true. You can generate netlists without going to VHDL/Verilog.

> The fact that digital logic design is constrained to one of two ancient languages by the proprietary toolsets is a serious problem.

Not really. You can compile any high-level language to a netlist and use that as input for place&route. Even if the proprietary toolchain didn't support EDIF netlists, you could still compile to a purely structural VHDL/Verilog file with the instantiated FPGA logic primitives (LUTs, nets, etc.), which is basically

The main (but not the only) reason why VHDL and Verilog have not been replaced yet, is that nearly all supposedly "better" alternatives fail to address the actual pain points in FPGA design. The most likely cause for this is that the overlap between professional FPGA designers and people capable and willing of designing and implementing a language is very, very small. The result is that you get a lot of languages designed by people who have never programmed larger FPGAs in a professional setting and consequently don't have a good understanding of the problems involved.

Do you have any good source of what these problems are? The reason I am asking is because I too am designing my home-grown HDL at the moment because I grew tired of both Verilog and VHDL. Since I never programmed FPGAs professionally -- the whole thing is a pet project only -- I'm likely to repeat those mistakes because I don't even know about them.

Note that I don't expect problems in the basics of language design and building tools, but rather specific mistakes in the context of FPGAs.

I'm curious to know more about your HDL, as I'm also working on an HDL of my own.

The code is at https://github.com/MartinGeisse/mahdl-plugin

Feel free to open an issue on GitHub to start a discussion. (I'm hesitant to post my private email address here -- old habits.)

It's actually kinda funny you mentioned designed without understanding FPGA development. VHDL predates FPGAs. Further, there are a lot of features that exist that are un-synthesizable. Some belong to the analog world. Some can't even be really even be used to build a real device.

Don't get me wrong – VHDL is a terrible language for design and verification (just like Verilog). Some of those new high-level languages are actually better than VHDL and Verilog, but not sufficiently better to overcome the momentum of the old languages.

> VHDL predates FPGAs

I was using "FPGA design" as a placeholder for digital logic design in general, given that by far the most VHDL and Verilog is written for FPGAs today.

Well, I kind of prefer VHDL.

Same. My main reason is Verilog does not make a distinction between variables and other objects. Verilog treats almost everything as if it were an assignment type. Furthermore, variables in verilog are shared by default. VHDL shows how it should be done. There is a clear distinction between signals and variables. Additionally, variables are local by default.

My opinion of course. Although VHDL can be bit more wordy. However, that's least of my worries (wordiness) when designing something. I would rather have clear semantics for me and other people on what the heck is going on.

Xilinx has a pretty clear disincentive to optimizing Vivado for minimum area. If it does a bad job optimizing, the user is forced to switch to a larger FPGA -> more $ for Xilinx.

How does that even make sense? It's like saying intel cripples their processors so they can sell more.

Intel a disincentive to be more advanced than a sufficient margin over the current competition. You saw the stagnation after Haswell.

No, it's like saying the only compiler for x86 is created by Intel (paid for by the sale of processors) and they therefore don't have an incentive to make the compiler particularly good at optimizing. If it does a better job at optimizing, people can get away with cheaper processors.

I'm not saying there is any intentional area bloating going on, just that there is little incentive to make Vivado better at optimizing.

Read https://www.bunniestudios.com/blog/?p=5018 to see where I'm coming from.

EDIT: It makes a lot of sense in my head, but perhaps I'm overlooking something important. I'd be interested to read in more detail why it doesn't make sense to you.

Quite a few groups of lower-end Xilinx FPGAs (e.g, XC7S6/15, or XC7A15T/35T/50T) are all physically the same silicon, but are sold under multiple SKUs with different chip IDs, with the synthesis software forced to leave some percentage of the area unused. Open-source synthesis tools would probably break this part of their business model. :)

That's definitely not true. There is strong market competition, so the tools are highly optimized. In fact if you have written logic that vivado detemines is impossible to reach it removes it, and everything connected to it, and so on. I've seen it do really amazing optimizations this way and it's all to save area. So while being inefficient it may seem like a sensible thing to do in a monopoly situation, there is a healthy duopoly, the tools squeeze every last bit of performance out of the device. Tool performance is a selling point.

Reverse engineering the format is necessary to make an open source toolchain, so I disagree. But you are right that an open source toolchain probably won't handle the primitives very well, so we're stuck with the vendor-specific tools, at least for now.

Reply on news.ycombinator.com