Developing open-source FPGA tools | Hacker News Reader

Developing open-source FPGA tools

twitter.com

277 pointsmr_golyadkin78 comments

For those who are not familiar with silicon vendors' toolchain, it really is very poor quality especially when they started pushing for GUI based Graphical/System development.

Vendors make money selling silicon, they see the toolchain as a necessary evil.

There are 2018 tools that are still unable to fully support VHDL-2008 standard. Many bugs reported years again remain open. And often the GUI centric approach means you are left manually changing ad nauseam several GUI fields and ticking boxes, until you eventually determine what is the tcl 'equivalent' to at least try to ease your pain (tcl scripting often is another pain all together but arguably a lesser evil).

Also specifically with Xilinx they seem to have zero consideration for basic version control and create/duplicate/modify an explosion of files and cached versions of files.

Projects like GHDL and this are a breath of fresh are.

Psst…I think you mean "silicon".

Haha indeed! I will leave it for traceability.

I had to apply some bathroom silicone sealant over the weekend so I just go ahead and blame it on that.

And we use silicone thermal paste on top of a piece of silicon ;-)

Nothing but the finest pulverized silver for me, thanks ;)

I removed those sticky e's from your fine comment above. I hope that's ok. It makes the discussion less distracting.

No problem at all, it is a relevant discussion but in a way I now feel I moved attention away from the intent of the OP which was to raise awareness and support for Symbiflow.

I've edited obvious typos in some comments. I can't seem to help it.

Psst...I think you mean "silicium" :P

(before any of you start typing your answers: that's the joke)

I always wonder why "silicium" is disused in favor of silicon, given that "-ium" is used liberally today, and you made me to look it up. Apparently, "-ium" is a suffix for metal only. But when naming new/hypothetical elements that have no standard name yet, IUPAC's Systematic Element Name rules overrides it and use "-ium" for all elements, but when the name is given, the usual rules apply.

Can't agree more. We literally have a version controlled Windows image with Vivada just to be able to quickly restore it when it breaks.

We switched nearly all of our PCs to Linux, and it's ironic that it is our engineers' computers that still have to be on Windows because of Solidworks, MCU toolchains, Virtuoso and other semi tooling

The non-software engineering world is laughably behind the times when it comes to computer technology and software. SolidWorks is one of the defacto industry standard CAD packages, and their version control software essentially just creates copies of the files and increments the versions. There's no real concept of change management on the content level.

OpenSCAD is a nice example of how this kinda stuff can work. It's nowhere near viable as a general purpose CAD program, but the concept could easily scaled up to the level of SolidWorks.

Its file format works very well with version control systems, is human readable to an extent and can be opened with any text editor (so your data isn't 100% gone if one bit gets accidentally flipped).

It's worth pointing out that OpenSCAD was started by Clifford Wolf, who went on to develop Yosys, the synthesis tool used in these open FPGA workflows.

TIL!

Check out CadQuery. It's miles better then OpenSCAD.

Onshape (the complete CAD runs in a web browser) has built-in document management (version control, review, approval, sharing, ..).

I’ve used to do mechanical design with Pro/Engineer for several years. Now I occasionally do some mechanical design stuff in Onshape and all I can say is that this is a tool designed by elite mechanical engineers and developed by elite software engineers.

Regarding document management it is like going from assembly to some high level programming language.

The only downside could be that it cannot run on premise. Everything is in the cloud.

So I would not agree that non-software engineering is behind the times:-)

(I’m not affiliated with onshape)

update: Onshape was bought by PTC (the developer of Pro/Engineer). I hope they won’t screw it up:-|

Seems like every GUI based programming language I've worked with doesn't work well with version control. I get a dozen emails a day about someone locking/unlocking a file - if two people modify the file at the same time there is a merge conflict and no way to resolve the difference. Until git can merge two conflicting files in a sane way ("git mergetool" launching a custom merge GUI would be fine if it worked - I'm not locked into must be able to us vi to merge)

You can write a script (in Bash, Python, Go, whatever) that accepts the arguments passed by git (filenames for $BASE, $LOCAL, $REMOTE, and $MERGED)[1] and launches whatever diff tool you'd like to use. You can then tell git to use it by setting the merge.tool and merge.tool.cmd configuration variables.

If you want to invoke different tools for different types of files, you can either handle this in your script, or you can explicitly pass the --tool flag in cases where you want to use a non-default tool.

Writing the wrapper script is generally pretty straightforward - the only "gotchas" are making sure the file patterns can be handled by your merge tool, and making sure you write the result to $MERGED. Sometimes you need to have a "clean-up" step in your script that copies the merge tool output to $MERGED and maybe deletes tmp files that were created.

[1] https://git-scm.com/docs/git-mergetool

That doesn't help when the file is a binary and nobody has written a tool to merge it. How do you merge a picture?

You're not replying to me, but I imagine you'd decode both images to an uncompressed format and diff them visually, optionally with a way to highlight pixels that differ between the two.

Binary file types that you can't view in some way would be challenging.

JPEG doesn't really have pixels though, and with some modern formats it gets even worse. For netlists it's hopeless.

Unity3D works reasonably well with VCS when using Text format files, as an example of a GUI development environment.

Xilinx's toolchain is the worst piece of software I've ever had to work with.

There are two things that amaze me:

1. That the dumpster fire is actually capable at all to synthesize hardware without exploding

2. That their head of software still has a job.

Try inaccel.com

I'm so happy to read ratings of Xilinx here. I'm a novice to the world of FPGA, and I've spent so much time fighting the tools.

My very favorite issue is with their IDE. The version I'm using has a broken search and replace... if the two strings have different lengths, the editor loses its place after the first replacement -- they compute the location of matches and then just smash the replacement strings in... failing to maintain an offset as character offsets change. Makes me scream.

I'm using Vivado after having previously attempted Quartus and I can't actually say it's any worse. I was able to eventually find my way around it and in some ways it was more intuitive than Quartus.

I see the pile of ideas they're trying to glue together. But it really just does get in the way more than anything else.

Now my process is: Verilator + CMake + CLion + SystemVerilog plugin for CLion (excellent but $$$); then when it runs well in verilator I bring it over to Vivado, fix any warnings it gripes about and try it on hardware.

And I've just discovered fusesoc and this is 50x better...

What amazes me is this, from Wikipedia:

"Replacing the 15 year old ISE with Vivado Design Suite took 1000 person-years and cost US $200 million.[12]"

> Also specifically with Xilinx they seem to have zero consideration for basic version control and create/duplicate/modify an explosion of files and cached versions of files.

There is an ugly feedback loop here. HDL tools interact poorly with version control -> it is difficult to collaborate using those tools -> HDL engineers would rather silo up than fight the tools -> no pressure to improve tools' support for version control.

Perhaps there is some truth in your assessment but I think the lack of pressure on tool support is more related to the lack of industry-grade alternatives, more so than HDL teams clinging on to a desire of developing like it's 1989. The reality is that nowadays HDL teams are composed of a lot of people with CS and CE background, who are obviously aware of sane development processes and practices. You will find that a lot of people simply use their text editor of choice and then just use the vendor's tool whenever absolutely necessary with a 7 foot pole (from a script or CLI if possible).

The problem again (in my very speculative opinion) is that you have a very limited set of vendors who have a complete lock down on their hardware.

Imagine a world without gcc or llvm and only Intel or AMD could provide you with a compiler. Imagine also that they would provide you with this compiler for free, such that their business model was entirely based on them selling their CPU's. How much pressure would they have in providing a high quality toolchain?

It's not like their customers are gonna run away to a non existent competition they still need to buy CPU's and they would be stuck with their 'barely works' toolchain.

You can see the difference if you compare FPGA vendor software with HDL simulation software. Simulators are in the business of selling you software so they have pressure to actually deliver quality software. FPGA vendors are in the business of selling _silicon_ (@saagarjha) so they pretty much see the toolchain as an operational cost.

The toolchain for ASIC/EDA in general is very poor. In 2019 I'm amazed that an open-source HDL simulator is not the de-facto industry standard. The big 3 EDA vendors charge astronomically high prices for simulator licenses, yet Verilog/VHDL along with simulator APIs (DPI/PLI) have been standardized for decades.

Verilator is gaining traction as the de-facto open-source simulator for industry and hobbyists. VCS is still the sign-off simulator, but at least there’s mounting pressure to support both.

In my day job as an FPGA developer I am using totally open source tools for simulation and verification (the only tool we pay for is Vivado but you have to pay for that in order to build for the FPGA). The simulator is icarus verilog and does the job pretty well. I use cocotb for simulation.

If you're using Intel's Quartus tool (Altera), pretty much every option is exposed through a Tcl API. You can accomplish everything without ever opening the GUI. The biggest problem is that those Tcl APIs are usually not documented very well...even for us internal developers (I used to develop Quartus)

The situation for Vivado (Xilinx) is more or less the same, Tcl for everything but terrible documentation.

Same for Lattice Diamond. Was nice for CI, but didn't help much with collaboration and merges for the reasons others have stated here.

Amen. I've been dabbling in the world of FPGA & hardware lately and I don't understand why hardware engineers tolerate the state of their toolsets.

Schematic design tools that make common tasks like drawing/connecting buses an obnoxious hassle involving futzing with the mouse making sure lines and nets line up when one should just be able to describe the whole thing in a DSL and have the tool build up an initial drawing for you.

FPGA "IDEs" with no auto indentation, refactoring/rename, no support for version control, arcane project structures that don't move easily between directory structures, non-modular tools that don't work well or at all outside of the IDE, critical settings buried in dialogs, 'drag and drop' authoring that takes you about 50% of the way to your solution and then falls over in a hot mess.

Demand better

I'm surprised no one has mentioned Icarus Verilog [0]. I used this extensively when I was in college around 2002. Open source, used to only support FreeBSD (my first BSD exposure), but is cross platform. It saved my ass, as I didnt have to compete for limited lab time on the few Solaris boxes with the proprietary tools we used in my VLSI class while studying EE.

I was sitting on my living room floor with my FreeBSD laptop punching out my project while others were waiting in line at 2am for lab time.

Fun times.

Wrote all of the components for a basic 8-bit ALU while watching with Mothman Propechies and sipping some Bourbon. Wrote a C++ program in that time, too, to generate exhaustive tests for all components. Icarus was fucking awesome for all this. As a commuter student my last 2 years, not having to hang out waiting for time was awesome. I got a lot more sleep, and a lot more done.

I've not kept up with its development, but its apparently now cross platform and still under active development. Any amateur interested in Verilog should definitely give it a look.

[0] http://iverilog.icarus.com

We used Icarus Verilog for a class at SDSU specifically so we weren't saddled with crappy vendor tools.

It even worked on Windows.

And, come on, how can you argue with a coding team who will make you an honorary "Steve"? (Inside joke: for a while it seemed like everyone who worked on Icarus Verilog was named "Steve" or some variant--so we started joking that anyone not named Steve needed to get rechristened with a new honorary first name.)

Back when I used Icarus, I dont think it worked on Windows. I'm pretty sure it was the reason I got a cheap laptop off eBay to install FreeBSD on. This would have been around 2002-2003. Regardless, it is an awesome tool and certainly saved me a ton of time. I wish I could comment on its current state, but I just havent used it since college.

Tangential, working on FreeBSD with Icarus is what caused me to learn/love/prefer Vim. It was there. It worked, and I learned (some) of it's quirks.

This has been the most exciting software work I've seen in the last year. David is doing fantastic work. If you haven't seen anything about the development of these tools his talk at FOSDEM in February was quite good.

https://archive.fosdem.org/2019/schedule/event/trellis_and_n...

And you can become his patreon to support his fantastic work : https://www.patreon.com/fpga_dave

Dave is a hero for the work that he is doing here. I'm really pleased to see that his Patreon is growing and reaching a non-trivial ("rent") level of monthly funding. Great job everybody who is supporting him!

Yeah it's a big job to tackle (open source software for fpga)

But the tools are improving quickly! Because of Dave and the general community. It's really great to watch (and use!).

And the repositories[1] themselves. You can also help them with the code - see the bunch of ideas[2] for the project.

[1] https://github.com/SymbiFlow

[2] https://github.com/SymbiFlow/ideas/issues

I think the best way to support this kind of effort is to have more people know what FPGA is and what they can do with it ... So they can use the tools and tinker with this stuff. So if you're into this space just write more content : articles, how-to's, videos, tutorials etc.

A colleague and I bought TinyFPGA boards to learn FPGA. So far I can do everything I need with a microcontroller, but would like to get ahead of the game. I got "LED Blink" working, which is the embedded version of Hello World.

It's a great product.

There's definitely a quality gradient from mainstream OS development tools down to FPGAs.

Also, more SW programmers should be getting into this field, as by working in SW first you realize all the things that need improvement in the FPGA world (which the FPGA people didn't recognize, not knowing how SW is done in the modern world, or got used to).

What are people doing with FPGAs? I'd be really interested in understanding or seeing some cool projects!

Driving a lot of LEDs: https://mobile.twitter.com/GregDavill/status/119251563062629...

Processing video (especially if you have weird requirements like 14 bit greyscale input): https://gregdavill.com/blog/2018/9/9/boson-camera-project-pa...

Experimenting with non-mainstream CPUs: https://www.thanassis.space/myowncpu.html

https://github.com/cliffordwolf/picorv32

it's also used in high frequency trading (market data processing, order passing, light strategies)

That's probably only one of many applications. Just search for DFE (data flow engine). Maxeler is one of the manufacturers.

Example: https://www.microsoft.com/en-us/research/project/project-cat... (bing search etc)

Motor control for a pretty high number of motors.

There's rumors that a couple of the big cloud vendors use them on network cards for SDN.

Integration with non standard peripherals like ku band radios on a satellite.

>There's rumors that a couple of the big cloud vendors use them on network cards for SDN.

No rumours needed, the papers are out there in the open.

I said rumors due to saying "a couple". I know that azure is pretty public about it, but I didn't think AWS and Google were.

For network cards specifically it seem surprising that it wouldn't be more economical for the big three to roll out custom silicon instead of FPGA.

IIRC, the configurable logic took the place of the CAMs in the routing table mainly. There's cool niches where FPGAs make sense due to their on the fly reconfigurability even more than a purpose designed asic would.

Do they really alter the images "on the fly" when traffic is flowing? Or do they have some situation where it's OK to stop traffic on their network interface for a short while?

Yeah, they do. They might drop a few packets during a partial reconfiguration if a stream is still in progress, but that's bound to happen anyway on routing changes.

Originally FPGA evolved from programmable logic devices. An EPROM is probably the most widely used example of a PLD. Partially because of this there are a lot of projects in SDRAM designs out there.

Usually if you need extremely fast i/o in the nanosecond order of magnitude then FPGA designs are a common design choice. An example of this are GPON network switches.

As mentioned in another comment video processing or any signal processing where the algorithms benefit from high parallelization is also an application where an FPGA would be a good fit.

The caveat though is that often FPGA/ASIC development is expensive and slow so a recent trend is to have a System-On-Chip with an FPGA area and multicore Microcontrollers. The idea with this is a hybrid design so that you can have an RTOS dealing with functionality where speed is not as critical. And have a custom design on an FPGA that is responsible for whatever bespoke application you need and have some memory interface between the two.

> An EPROM is probably the most widely used example of a PLD.

Upvote for this. When I used to think about PROM, I think it as a medium of data storage, or sometimes think it's a lookup table. But it's actually simplest form of programmable logic device - a device that can transform x-bit of arbitrary input signals to y-bit of arbitrary output signals, so you can build any digital system that uses combinational logic in PROM (and RAM for sequential logic), including a CPU. And since it's a PROM, you can reprogram it to implement another different logic device, simply by burning a new truth table.

After I realized this, the existence of reprogrammable hardware like FPGAs no longer sounds like magic to me anymore. From this, you can also see that computers with finite RAM and ROM is not a Turing machine, but a Finite State Machine.

I try to use FPGAs for pretty much all my hobby projects, even if using an RPi or any other microcontroller would make more sense.

Because writing RTL is much more fun.

And if I happen to need a little CPU for some generic control operations, I just add a soft core to my design.

Building a multiband GNSS receiver on-orbit, in order to observe the weather.

https://www.ecmwf.int/sites/default/files/gpsro_lecture_2015... is an overview.

Somewhat unexpectedly, many FPGA's industrial applications involve implementing a simple CPU (a "programmable state machine", PSM) and then having the domain logic coded in its machine language (using a cross-assembler).

I can't speak to what I'm actually doing with FPGAs but lately I've been enthralled by systolic arrays [1] to achieve massive parallelization of certain algorithms. It can be a trick to rearrange cache, computation and communication to be local, but if your amortization game is strong, O(n) becomes O(1) and it's extremely satisfying work.

[1] https://en.m.wikipedia.org/wiki/Systolic_array

Building an improved Amiga accelerator and a new standalone byte-compatible Motorola 68K Amiga

http://www.apollo-core.com/

Preserving old CPU architectures and building fun retro arcade machines of them:

http://www.racketboy.com/retro/mister-fpga-the-future-of-ret...

FPGA's are an essential part of high speed trading these days.

Few applications I have worked on lately involving FPGAs: - RF and microwave, direct digital synthesis. - Data acquisition and analysis (fast, very fast) - Time of Flight imaging/video - Timing critical process control

Analogue Nt's consoles all rely on FGPAs to emulate the original systems on a hardware level.

https://www.analogue.co/nt-mini/

https://www.analogue.co/pocket/

My previous project was an UWB indoor tracking system for VR. FPGAs did all the signal transmission, reception, and digital signal processing: https://www.youtube.com/watch?v=mYyFUQbWC1E

My current project is AR glasses. An FPGA is decoding a displayport signal and driving the display.

We build 3D scanners for dentists https://www.youtube.com/watch?v=C5jKnxEyrbU

More info on the patreon page: https://www.patreon.com/fpga_dave

I wish there was an open source FPGA silicon design.

Open source silicon design itself is at its infancy. You may be interested in this project: https://libresilicon.com/ . It has a very interesting history. I really hope that someday, this will grow into a room sized fab - like how 3D printing is progressing today.

Reply on news.ycombinator.com