I worked in EDA for several years, late 80's/early 90's. Its tough. Yes, the current tools are miserable. But the market isn't huge, so there are only so many development dollars to go around. And the interfaces between tools are information-lossy kludges held together with duct tape and string.

Open source is hard, because without access to the data, it is hard to do a good tool like a timing analyzer. Heck, when you do have access to the data and you can talk to the physical chemist that designed the process because his desk is 5 rows over it is still hard to get it better than "close enough".

I've thought many times about doing an open source event-driven logic simulator. At one point, I was a top guru of that technology. The thing is, I doubt if a sufficient number of people would care, and it is basically worthless without all the tools that feed it and drive it.

I would be happy if all my bullet points applied only to cycle accurate sims.

I think the market would create itself with the right ingredients present. I think a high level language, a well defined intermediate representation with an eye toward synthesis but initially just targeting simulation, and a cycle accurate high performance simulator for said intermediate language would be explosive.

(bonus points for writing the sim in WASM, heh)

WASM? Well, if I'm going to tilt at windmills, I'll use the project to learn Rust while I'm at it.

Explosive? I remain unconvinced. There just aren't enough people doing that kind of work.

I am excited to see progress in open source FPGA fitters. I've always felt those would be hard to do because without access to the performance model, it is hard to do a good job of auto-placement. So that is cool, even though the current open source tool (I forget the name...) only does a few FPGAs.

If an open source tool exists, people will end up playing with it. That's categorically not the same of closed source tools - as social creatures we want to share what we're doing, so if we can't share that we stumbled on a cool closed-source tool leaked on the internet, what's the point of playing with it?

So there's that.

I would very much like to hear about your progress on this, FWIW.

Also, I'm not sure, but just in case the following things I was reminded of are directly/indirectly useful/helpful (for ideas or parts, or maybe some of the engineers may be interesting to talk to..?)...

- MARSSx86 - a cycle-accurate x86 emulator built on top of QEMU: http://www.marss86.org/~marss86/index.php/Home

- Cling - a C++ interpreter built on top of LLVM's JIT: https://root.cern.ch/cling

There are several cycle-accurate emulators out there, MARSSx86 is the first I discovered. I'm not sure if it's useful.

I'm not entirely sure why I'm mentioning Cling. It used to be based on a custom runtime (and called CINT) that was absolutely massive and was basically its own C++ implementation. Cling is effectively a very small patch/driver on top of LLVM's C++ implementation and its JIT runtime.

Why do you think an high level language would be a positive thing? The ones that are currently available generate worse designs than hand written Verilog.

Verilog is still used for a very good reason, it is not because the EDA industry is stuck in time.

Email me (email in profile) please, would love to connect.

Working on it...

https://www.fbo.gov/spg/ODA/DARPA/CMO/HR001117S0054/listing....

I don't see how this will ever work. The needs of the defense sector are just fundamentally at odds with the needs of the commercial sector. On the hardware side you get things like Intel and AMD trying to hide "chips within chips", and on the software side you get things like foreign governments demanding to inspect proprietary software before they'll allow it to be imported.

The past and present are mired in "national interests"; but the real obstacle seems to be the idea that you can prevent other people from having what you have (an idea, a weapon, a key, etc.).

EDIT: I was responding to this quote from your link: "The goal of the ERI is to more constructively enmesh the technology needs and capabilities of the defense enterprise with the commercial and manufacturing realities of the electronics industry." I didn't mean to imply that what your company is working on won't work. Unless, of course, that is what your company is working on.

I especially like your focus on physical design, as it (along with verification) is usually the bottleneck in modern cutting edge node chip development. Any plans to update the public about progress?

Having spent about a decade in a chip design software startup that was eventually bought by Cadence, I'll say:

- you're absolutely right that the tools are horrible to use, and Verilog's time is up

- existing chip design companies are extremely conservative and hate adopting anything new even from their own preferred vendor, because risk

- a lot of the key knowledge is spread by apprenticeship and oral culture; analog IC engineers are another culture altogether

I spent over a decade doing circuit design and I can corroborate your points. Chip design is maddening! One of the most interesting differences between software and hardware engineering is how many blogs and writing on the web you can find about software. You can almost self teach a masters in CS through online blogs and various postings! The only writing you find online about hardware is either patent's or IEEE white-papers.

There is still something magical when a new chip design comes back from the fab and boots up!

On the languages front, there is Chisel, which looks promising. I'm not a hardware guy, but Chisel looks a lot more reasonable to work with than VHDL/Verilog, and it's good enough for doing real work on RISC-V. As someone who has thought about dabbling in this space, I'm curious about the thoughts of anyone who has worked with it: https://chisel.eecs.berkeley.edu/

For the rest; yeah, it looks like it's pretty eye-bleeding and hacked together from decades worth of odd little one-off tools: http://opencircuitdesign.com/qflow/, https://opencores.org/howto/eda, https://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.p...

I would stick with VHDL and SystemC. Any tools that could actual synthesize your designs are going to handle VHDL and Verilog.

I do prefer VHDL to verilog. 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.

However, Verilog is just as capable.

Chisel compiles to Verilog, so you can use that to bridge to other tools for actually synthesizing your designs.

But it brings with it the full flexibility of a general purpose programming language which makes it a lot easier to make parameterizable designs which can be more easily reused.

SystemVerilog is much more capable than either verilog or VHDL, and has brought many of the VHDL safety features to make design with it safer by construction, plus more, without the wordiness. Yes you can still write bad code, but any decent hardware flow, or synthesis step will catch basic things like mis-sharing of variables etc. I agree it's a language weakness it's not an issue in practical hardware design. In addition to The design enhancements, the fact it's got pretty powerful verification features makes it my language of choice today, at least among the low level HDLs.

Have you ever tried Bluespec SystemVerilog? I've never done hardware design, but from what I've read, it seems like an improvement over VHDL and Verilog. I'm curious to hear the opinion of someone who's actually done hardware design.

It's better than Verilog. It extends the types system, and makes user defined types easier to use. This helps with a lot with a big design with a lot modules acting as a layer of abstraction. The type system is stronger than verilog to some degree, but still is weakly typed to retain backward compatibility. VHDL still has much stronger type checking.

It also supports direct programming interfaces. For instance you have a chip your designing that needs to run software. Your test bench can call that C function to also test some software at the same time. You can also use it to speed up simulations by just modeling the input and output in C for a module. However, I prefer SystemC for this. It's great for behavior level simulation, and also runs quickly. It also is much easier to interface with any software you want to test with the design.

So I prefer SystemC for behavior models, and VHDL for gate level implementation. However, you can't really ignore verilog. Although, that depends where you are working and who you are working with. System Verilog is kinda of in between SystemC and VHDL.

https://preview.ibb.co/hRz8qc/Screen_Shot_2018_02_07_at_9_21...

I'm not sure open source EDA will happen and be as competitive as open source software has been in general. Many of the tools are extremely complex. For your example of just a simulator and systemverilog: the spec for SV is more than 10 years old, yet the best oss can do today is compatability with a small subset of it, and orders of magnitude slower than a commercial simulator. The reason? The skill set to write one of these not only needs very solid programming skills and knowledge of advanced algorithms for performance, but also some domain knowledge to understand how the tool should work from the user side and he side. This last point is the reason most oss EDA today is written by hw engineers who know some programming, rather than true software developers. Of course you will get some cases where a single engineer knows both areas well and produces some nice/interesting tools like vloghammer, icarus, ventilator, etc. However these folks are rare, and for oss EDA to be truly competitive it needs many contributors with this skillset. Thats why a language as big as SystemVerilog has not once been fully implemented in open source yet. So hard to see the other, arguably harder, challenges like Place and route, STA (on smaller nodes), analog simulation, parasitic extraction, etc being taken on in oss EDA for anything but older technologies, or with very limited capabilities. Open source IP on the other hand could take off.

I read all that as an indictment of SystemVerilog rather than of simulators.

I agree with the assessment of hw engineers doing software.

So why has it not happened in your opinion for SV, or spice or place and route despite there being references for each of these available for in some cases decades? There are free implementations of these but in each case they don't come close to a commercial offering.

Heh, #1 and #2 we are developing internally. Bonus points is that it supports analog/mixed signal as well through the chosen abstraction (SPICE level black box), models leakage, power consumption and thermals as well. Email me (on profile) if you want to connect.

For a public example, our simulator is very similar to Level 2 of the PARADISE flow being developed at LBNL.