
Edalize: An abstraction library for interfacing EDA tools - osivertsson
https://github.com/olofk/edalize
======
DoingIsLearning
A welcome solution to a problem space in need of some serious simplification
and standardization.

To all the FPGA vendors out there, I want/need/have to use your chips, I
genuinely do not care about all the 20 thousand GUI-based idiosyncrasies you
decide to add to your tooling every 3 months, in order to 'make my life
easier'. Expose it through an API and document it fully (not partially).

VHDL-2008 standard was published in Jan 2009, more than _eleven_ years ago,
still to this day, it is not fully supported on most tools. How can you look
at customers with a straight face and reasonably think that you should
continue to add more GUI-based abstraction layers (looking at Xilinx Vitis),
instead of focusing on the basics first.

I sincerely hope that projects like Yosys, Symbiflow, GHDL, etc. continue to
mature and grow. Equally important, I hope that vendors that support these
projects (like Lattice) actually see a rise in market share because of opening
up their hardware to open-source community toolchain.

edit: corrected publication date of VHDL-2008

~~~
amelius
> To all the FPGA vendors out there

I wonder how many of them read HN. Perhaps it would be better to send them a
letter?

And perhaps these companies are making the "wrong" product simply because
nobody ever tells them what they want.

~~~
alxlaz
Technical reasons aside (some of these vendors are on 20+, even 30+ year-old
codebases by now), the other big reason why they are making the "wrong"
product is that the "right" product avoids some vendor lock-in and makes some
of the consulting market redundant. As far as the product managers are
concerned (or, more accurately, as far as the metrics based on which they're
evaluated are concerned), the "wrong" product isn't wrong at all.

End users have been complaining about all these "20 thousand GUI-based
idiosyncrasies " forever, but they've nonetheless put up with them because at
the end of the day you have to ship the damn thing.

There's been no shortage of outside players attempting to "disrupt" this
market. However, most of these attempts have been comical failures. Instead of
addressing problems that FPGA/hardware engineers have, lots of these attempts
were focused on addressing the sort of problems that software engineers have
when they try to do FPGA development. Not necessarily (but, in some cases,
also) due to sheer superficiality, but also because they are problems that are
a lot more accessible when coming from outside the field, without a foothold
in the FPGA manufacturing/development space (i.e. when you're not building
tools for FPGAs that you design, manufacture and sell).

So lots of these problems are very much WONTFIX: users have no meaningful
alternatives, and fixing some of these things might actually even make it
easier for alternatives to spring up (or at least for users to build various
in-house tools that aren't so vendor-specific). Why would any FPGA vendor
waste money on _that_?

~~~
gsmecher
Neither Xilinx nor Intel are in the business of making simulators (and in both
cases, it shows). If there is an opportunity to graft the LLVM model into the
FPGA world, IMO it's the simulators.

Unfortunately it requires some creativity to support encrypted RTL in an open-
source simulator, and both vendors require a way to supply simulation models
without exposing source code. Doubly unfortunately, the open-source simulators
are all language-specific and any attempts to bridge the gap have been only
limited experiments. A brand-new simulator architecture seems necessary but
has its oxygen starved by the rest of the ecosystem, open-source and
commercial.

I am watching [https://github.com/llvm/circt](https://github.com/llvm/circt)
with interest but I don't think this is quite focused on simulators the way I
think is necessary.

------
jeffreyrogers
I'm an FPGA engineer. This is cool, but seems unlikely to be used much in
practice, mostly because the tools are so crufty that the industry has silo'd
itself into separate hardware ecosystems. For example, most places will use
all Altera or all Xilinx chips, and their designs will rely on features that
are only provided by the Altera or Xilinx tools/chips, making switching tools
expensive and time-consuming.

------
nickysielicki
I can't imagine this doing well in a design where I instantiate xilinx
primitives and want to port the design to altera. Unfortunately, there are
plenty of times where instantiating vendor primitives is completely necessary.

The tools suck and I'm glad people are trying to make them suck less... but
nothing is going to change substantially until the community demands that the
vendors do their part or force their hands.

------
gsmecher
Tooling tends to stack vertically in software: you can put together Jython-on-
JVM-in-Docker-on-Linux-in-EC2 if you want to, without every layer diminishing
the ones above and below it.

In EDA, tooling stacks horizontally. At minimum, I need a simulator and a
synthesizer, and both need to support the same features for those features to
be useful. Every tool or layer I add to my EDA stack erodes the feature set I
am able to use for all of them. Encrypted IP? VHDL-2008? SystemVerilog? Only
with a commercial simulator. Now you have to start squabbling over licenses,
which is the same problem except you've traded technical limitations for
economic ones. (edit: and paid 6 figures for the privilege.)

All of this is a huge drag on productivity. It benefits only the big EDA
incumbents (not even the FPGA manufacturers). If EDA tooling is going to
improve, we need to change this dynamic. Until we do, adding layers to the
tooling is a net loss except for a small sliver of the user community.
(Typically the people who wrote it.)

~~~
R0b0t1
There are projects attempting to reverse engineer bistream formats. They are
having some success but it is slow going. The last I looked some Lattice parts
were mostly broken open.

VHDL manipulation is quite advanced, see SpinalHDL. But they are limited to
spitting out a blob of VHDL you can put into your toolchain for your device.

------
maweki
The project readme seems to be lacking a good description of how powerful it
is or which software and which workflows are supported (maybe with a list).

I remember pyEDA
([https://pyeda.readthedocs.io/](https://pyeda.readthedocs.io/)) interfacing
with SAT solvers and BDD libraries, as well as some logic minimizers. The
(EDA) field is large and pyEDA was good for general logic constraint solving,
though I never tried to verify hardware.

With the HDL-Focus it seems "hardware" is a specific target here. This is not
very well explained. But maybe for someone who works with HDL on the regular,
this is not a problem.

~~~
doix
From what I can tell, the goal here is to create an abstraction for
interfacing with the different tools from different EDA vendors. All these
tools have their own arcane CLI arg names for essentially the same stuff, this
is trying to abstract that and create a python way of describing all of that.

Where I work, we just use a bunch of Makefiles. We mostly just stick to a
single vendor though.

~~~
kingosticks
> We mostly just stick to a single vendor though.

This. The tools are expensive so we license one simulation tool and we build
our world around it. At least where I work, there's no situation where we pay
for multiple tools that do the same thing, it would be considered a waste of
money to license multiple and I think I agree with that.

The same goes for the synthesis and backend tools. Driving these tools is
difficult to get right so we stick with just one. There would have be a
really, really really compelling reason to switch and it's yet to manifest.
Sure, the tools have bugs but we report them and they do get fixed. It would
have to be something quite special to make a switch interesting, even more
special than synthesiable VHDL 2008!

------
lallysingh
I'm sure it could be very useful to some projects. Now: why are 'edam' and
'files' pure dicts instead of constructed with some basic API that can catch
errors?

It's really annoying to debug silent errors in stuff like that.

------
social_quotient
EDA = Exploratory Data Analysis

~~~
balsam
From the look of it, seems to be more like Electronic Design Automation

[https://en.m.wikipedia.org/wiki/Electronic_design_automation](https://en.m.wikipedia.org/wiki/Electronic_design_automation)

