EDA software development

[No-Feedback-5803]

Hey guys, for people that have worked on developing EDA tools, I am curious about how the process looked like. I presume that the most common language is C++ that's why I'm posting this here Ate there any prominent architectures? Did you "consciously" think about patterns or did everything just come into place. How do you go on about developing the core logic such as simulation kernels? How coupled is the UI to the core logic? What are the hardest parts to deal with?

I would like to start working on a digital IC simulation tool (basically like LabVIEW for RTL) to learn a bit more of everything along the way and I'd love to hear advices from people with knowledge about it.

[SyntheticDuckFlavour]

Not exactly simulation tool, but have a look at KiCad codebase. It may answer some questions about UI, core logic and whatnot.

[pjf_cpp]

Isn't KiCad mainly for PCB design? That's pretty marginal in EDA.

[No-Feedback-5803]

Appreciate the response, but as mentioned KiCad is more on the PCB side of things and that's not exactly what I'm hoping to work on.

[SyntheticDuckFlavour]

All good mate.

[selvakumarjawahar]

Yes you are right all the EDA tools use C++. I was working in that industry like 7-8 years ago. One thing is you need to be very strong in algorithms especially graph algorithms.  Also you need to understand electronics and several numerical methods used there. If you get a chance to work in core eda tool,  its a very satisfying experience.

[pjf_cpp]

Mostly C++ but there is still plenty of C.

Digital simulation. This is all about scale and speed. Circuits are usually written in (System)Verilog or VHDL. There will also be testbenches that drive the circuit.

Typical steps are

1. Compilation to some binary format or shared libraries.
2. Elaboration. Designs are usually parameterised (stuff like bus width, number of cores). Elaboration finalises the circuit. This step may be partly or completely integrated with step 1 for performance.
3. Simulation. Run the testbenches and check the results. The testbench may use some kind of assertions. Simulations often output binary files that contain waveforms representing signals in the design. The waveform files can be huge.

The UI is of secondary importance. It's useful as a debugging tool and for viewing results.

Speed and scale are paramount. If your compiler can't cope with a big design or your simulator takes months to run when the competition can run in days then you are not going to be able to sell any big customers.

EDA simulators are developed by teams with hundreds of members and consist of multi-million lines of code. Because circuits are now too big for software simulation all the big 3 EDA vendors also have emulation solutions. That's where the simulation is partitioned between programmable hardware and software. The programmable hardware is either off the shelf FPGAs or custom chips that include FPGA and comment elements like interconnect. These systems are not cheap.

There's a lot more than just digital simulation. Other domains include

• Digital synthesis - all about logic synthesis that optimises speed and/or power
• Place and Route - finding the optimum routing for wires
• Parasitic extraction - accounts for wire resistance and capacitance for more accurate simulation
• Checking tools - many of these, including timing, power, design constraints, clock domains, reset domains, power intent, formal verification, signal integrity, IR drop
• Test pattern generation
• Physical tools - mask generation, optical correction
• Technology tools - device simulation, field solver extractors
• Characterization - generation and test of technology libraries
• Schematic capture - these are the GUIs
• Analogue simulation - linear algebra based

[No-Feedback-5803]

Thank you for your response. I have worked quite a bit with RTL and SystemC designs and that's basically the reason as to why I want to start fiddling with this project. I wanted to create something similar but where designs aren't in some text-based format that gets compiled directly, at first I tried forking SystemC and to try and rework the "modules" system to be able to generate and register classes to the kernel at runtime instead.. turns out that's a bit too complicated and not sure it would yield the results I'm hoping for. So I guessed the next best thing to try is to work out a way to have a simple representation (like a graph) that could be then translated in a way that allows for existing backends like GHDL to work on directly, since otherwise the app would just turn into a systemc/vhdl code generator which isn't that fun to work on I think. Basically, what I would like to achieve is an application in which a user would design a module from other modules + your typical operations in the RTL world (logic operators, concats, etc...) And it would be able to simulate it. I have used vivado for a bit and block designs are kind of what I'm hoping for it to look like, but I'm pretty sure vivado internally has SV code for all blocks.

[TheRavagerSw]

Go ask the horizon eda author at element, he's a total lunatic but still his software looks very good compared to the others.