Verification - open source - what is what? Part 3/x.

Open source in hardware is difficult but we see there are things moving here and there. Especially in verification, a lot of initiatives are already out there. For me open source verification stand for ReUse of existing generators, monitors and IP that was developed and successfully used in the past.

Albert Einstein : “Insanity is doing the same thing over and over again and expecting different results.”

This quote inspired me to reuse things that worked over and over again and expecting the same results. I myself have a collection of handy VHDL and verilog code collected over the years to I reuse but also:

• My shell setup, aliases, env vars and PATH defs.
• My gvimrc file with my text editor setup.
• Shell and Python scripts for regression and file changes.

But I never considered open sourcing them they are just snippets that are useful to me. They are just a few pieces of a personal puzzle.

Essentially, the entry into another person's system requires time. With snippets nobody is going to take the time to understand what it is all about. That is different with open source frameworks. There is a potential big benefit in return for the time you invest into learning how it works.

For me, the task has an extra time factor. I want to understand how the framework works. But on top of that, what are the core beliefs behind the framework. And more important, how do they translate into directory structure, tool dependencies, version control, makefiles, ... In digital circuit design, many tools want to make access easier for less experienced engineers. But in the movie "Karate Kid", mr Miyagi, makes the kid wash cars all day. And the kid doesn't understand what the point of that is? Cleaning cars? The point is that there is no neat shortcut for experience. To master a skill, you have to put in the hours. Do the dirty work yourself and find out how everything links together and what the upsides and downsides are for different approaches. Reading a lot of articles and answers regarding verification on Linkedin and on Quora points exactly to this lack of front-end design knowledge. Especially in verification-only resources. They were raised into the SV/UVM realm and their boundaries are what they were taught. When I do verification on the unit level, let's say an interrupt controller with parameters (no of interrupts, no of levels, ...), I need to be able to take out the interrupt controller directory. That directory will have all the unit files, dependency only on common files and verification, synthesis and STA that goes with it. The technology specific parameters need to be separated. But in essence, I want to be able to verify the same IP for timing, synthesis and in simulation. I want it version controlled and I don't want any compiled file or tool dumplog in the version control.

In FPGA design, again, all source files are in the same directory, the project setup and the pin definitions file is there as well. The output reports are there as well. And, in some system generators with Influencers and Upvoters (master-slave terminology has been cancelled recently), the source code is copied into the system directory so you now have two copies and you need to keep them in sync. Like the thousands of warnings in FPGA tools, that is a cesspool of accidents just waiting to happen. Everyone likes GUIs (click-click) until they go command line when they finally grow up. Documentation for open source is much better than commercial documentation for IP and frameworks. Still, sometimes changes didn't make it into the documentation yet. And the things under the hood, the things I want to know, aren't always documented. But my reasons are related to what I described above.

Via the comments on the previous article (2/x), I found out about two other open source projects:

• Open source IDE for FPGA
• FPGA development platform

One of the major issues with open source is that I regularly try to find and follow FPGA and ASIC open source related things, but I haven't heard of those two. And I haven't evaluated them but I guess they are like Vivado (Xilinx) and Quartus (Intel, formerly Altera).

For verification for my 3D printer FPGA, I'm using Vivado and the Arty S7 board. To show the difference between a project in Vivado and the open source world. Hence, the IDE's (I hate that word, like programming an FPGA, it all frames FPGA as software design) above are interesting but not for verification of the 3D printer FPGA.

Software co-simulation

For open source, the 3D printer FPGA is based on HDL source code. Like I said before, toplevel verification (not unit) spans the period from design to silicon. It is system verification. System, modeling and silicon validation are more software than hardware HDL related categories. Having the RTL in HDL and the verification not in HDL is very important for big Systems-on-Chip. Whenever there is a significant software factor (one or more embedded and complex processors), it is worthwhile to use software. SystemC was around 2005 in pole position to actually become the language of choice for co-simulation. And C/C++ is still the firmware/embedded software language today. Unfortunately SystemC never made it and SystemVerilog is now basically the verification standard.

The whole software environment including open source debuggers isn't used by silicon validation. Instead we use the EDA simulator and SystemVerilog. Dino's and some people that truly understand chip design and a bit about software know this choice was bad. And related to a business model we should never talk about. Plus, in the FPGA world, we know FPGA designers are not good ASIC designers. Even though they both write HDL code. ASIC designers can do FPGA design by default. Of course, they need to get up to speed with some very specific things related to clocks, resets and memories. But the methodology in ASIC is paranoia with respect to bugs (laughable if you know what really goes on, but for argument's sake) and in FPGA, we know they are far more relaxed. Let's put it like that.

Now, I want to teach a little bit about important tools and concepts in my 3D printing FPGA community. Directory structure (not all in one directory), command line scripts, ReUse and automation. I start from the GUI windows easy peasy relaxed stuff and then explain how the grown ups do things. ?? Due to personal circumstances, I have worked remote and did some great chips in the past (Movidius was exceptional as experience). But semiconductor companies do not trust their own employees (ticking anyone?) and certainly not contractors, so the changing reality makes me unemployable (advisory hourly consulting usually remains, hedge funds and the likes). As I have posted, TopTal and similar websites do not even offer real hardware design (FPGA profiles are embedded software or HLS people). FANGMAN offers much better rates (US only, H1B and stuff) than anyone in the semiconductor industry, software companies are quickly morphing into remote communities, so HDL design in semiconductor companies is not going to change. Project leaders with ten years experience interviewing people with 20 or 30 years experience is always a bit of an issue. So, I don't need to hold back anymore so much these days. I have shifted more to other sectors for income let's say. The 3D pinter community is truly something I do out of interest that hopefully leads to a startup I have somewhere in the back of my mind. Where the red roses grow ??.

Thus, COCOTB as co-sim with VUnit looks the path forward. I will take the link in the comments (previous article) from Lars Aplund and will dive into COOCTB and Python to find out how to do the 3DP FPGA verification. I believe that a strict and well chosen methodology that adheres to the KISS principle kicks any semi giants butt any day in TTM, cost and reduced risk. Hear, hear! So shall it be written, so shall it be done! And, keep an eye out on the Spanish inquisition! You never know ...

#verilog #systemverilog #VHDL #verification #UVM #opensource #asicdesign #fpgadesign

First article: Open source Verification, what is what Part 1 of x.

Second article: Open source Verification, what is what Part 2 of x.