HN Theater @HNTheaterMonth

⬐ lnsru

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.

⬐ moring

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.

⬐ blacksqr

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

⬐ anfilt

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.

⬐ lnsru

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

⬐ anfilt

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.

⬐ egg_head12

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.

⬐ black_puppydog

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.

⬐ pjc50

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.

⬐ pjmlp

Well, I kind of prefer VHDL.

⬐ anfilt

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.

⬐ anfilt

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.

⬐ lvoudour

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

⬐ anfilt

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

⬐ user20180120

In an ASIC flow, they use C++/SystemC that feeds into High Level Synthesis tools to generate an intermediate auto-machine generated RTL HDL Verilog. This then flows into a digital logic synthesis tool to be converted to a Verilog gate-level netlist. The industry uses a Verilog netlist as a defacto standard that is then put through an implementation flow for place and route, where the aim is to convert the Verilog netlist description of logic gates/D-flops into a physical representation of the final chip in silicon, in the form of a GDSII [GDS2 file] for taping out which in turn is then sent on to a foundry to be manufactured.

The manually written HDL RTL either in VHDL or Verilog takes too long to write in terms of human hours by large teams of HDL RTL coding engineers. The aim of using High Level Synthesis is to reduce the time to market for generating a Verilog netlist.

When RTL HDL languages first came out in conjunction with digital synthesis tools, many engineers were not believing in the technology, in which they used to do things manually by hand laying out the gates/transistors.

Youtube video link from 1977 [watch from at time from 07:52 time mark, manual work done from 9:36 time mark onwards]

BBC Horizon: 1977-1978 Now The Chips Are Down [https://youtu.be/HW5Fvk8FNOQ?t=472]

⬐ adwn

> 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.

⬐ anfilt

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.

⬐ adwn

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.

⬐ moring

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.

⬐ ChickeNES

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

⬐ moring

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.)

⬐ andars

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.

⬐ gruez

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

⬐ duskwuff

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. :)

⬐ ysleepy

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

⬐ andars

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.

⬐ tails4e

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.

⬐ meuk

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.

⬐ lvoudour

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

⬐ Shikadi

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

⬐ black_puppydog

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

⬐ planteen

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.

⬐ vinchuco

What tool is he using to show the circuit layout?

⬐ pankajdoharey

Really quite impressive work.

⬐ katastic

There's an incredible number of armchair experts and bias toward their voting in this thread for HN--downvoting actual experts and upvoting laymen.

I guess when it's not CS related, HN doesn't produce much better results than Reddit.

If you want quality, professional opinions about FPGAs, I'd suggest:

https://www.edaboard.com/

You'll learn from droves of proven experts who aren't subjected to silly flagging and downvotes.

⬐ callesgg

He kind of looks like Christopher Walken.

⬐ userbinator

It seems every few years someone does this publicly, and then either gets DMCA'd or forgotten. Nonetheless, the extremely regular structure of FPGAs, along with the availability of official documentation (which basically explains everything but stops short of mentioning which bits control what) mean that it's not all that difficult of a problem to "connect the dots".

As I've mentioned before, the bitstream formats are one of the worst-kept secrets in the industry. The only reason they aren't revealed more often is for legal, not technical reasons. I'd almost bet that a considerable number of those who work with FPGAs have figured out at least part of the structure and kept it to themselves.

⬐ moring

That makes me wonder whether it would be more DMCA-safe / lawsuit-safe to not reveal the format itself but rather the exact process to discover it (avoiding endless hours of dead-end experiments because of a wrong assumption about the format)...

⬐ adwn

I'm replying here to a different comment of yours, which has been flagged for some reason.

> Do you have any good source of what these problems are?

A quick list:

* Bad verification support. Serious verification takes at least as much effort as the implementation. Improving that is a hard problem, and you won't know if you've improved it unless you have experience with real-world designs.

* Bad support for sequential code. Contrary to what is taught at college, there is a lot of sequentialism in non-trivial designs (except if you design a CPU, but hardly anybody does that). Basically every protocol is sequential. Even most of the smaller external devices, like ADCs or DACs, typically have a sequential interface. VHDL and Verilog require you to explicitly code a state machine, which is needlessly verbose and error-prone.

* Lack of transparency. If the route tool can't meet timing, you have to be able to map the tool's report of the critical path to your high-level design, or you'll have a big problem at the most inconvenient time.

* Lack of a convenient VHDL/Verilog interface. If you can't easily instantiate VHDL/Verilog IP cores, your language will be an academic exercise, at most.

⬐ loup-vaillant

> The only reason [bitstream formats] aren't revealed more often is for legal, not technical reasons

Any idea what these reasons might be? I mean, it's the vendor's format, why couldn't they reveal it?

⬐ monocasa

I think he's saying that the vendors will sue you.

All of that being said, what bits are what mux and what LUT in the bitstream is only a small piece. All of the information needed for timing is the hard part.

⬐ navaati

Sorry to be offtopic but I think the sibling comment by @moring should be unflagged, don't know why it is…

⬐ datenwolf

> It seems every few years someone does this publicly, and then either gets DMCA'd or forgotten.

Luckily the guys who do this do not live or work in the USA, but in Austria, so Austrian and European Law applies:

http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=143505754...

"(…) It has therefore to be considered that, in these limited circumstances only, performance of the acts of reproduction and translation by or on behalf of a person having a right to use a copy of the program is legitimate and compatible with fair practice and must therefore be deemed not to require the authorisation of the rightholder. An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so that they can work together. (…)"

Essentially this means, that reverse engineering with the intent of creating a cleanroom implementation of a compatibility layer or independent toolchain is perfectly legal.

Please don't link to Youtube for CCC talks. They built their own mediasharing platform that provides downloads, has no ads and does not track you in any way:

https://media.ccc.de/v/34c3-9237-reverse_engineering_fpgas