Hacker News new | ask | show | jobs
by artisanspam 836 days ago
I am a DV engineer, and I'm going to give some candid feedback: CI tooling is not what I spend most of my non-coding or verification-planning time on, so I wouldn't find much use out of this tool. Now that wasn't always true – I used to work somewhere that had horrible CI tooling. But that's just because the company didn't invest in someone to maintain that infrastructure. Given that, I don't think they'd pay an external vendor for a tool and require someone to maintain that tool as well.

However, I do have some problems that you may want to consider pivoting to or adding in the future:

1. A wrapper that works with all of the tools that EDA vendors offer as a back-end. Basically, CMake for SystemVerilog where I can just run `make` and compile, elab, and sim run in order. Every company I've worked for has made their own wrapper program which essentially re-creates this process and I've had to relearn it several times. If you had this wrapper, then you could easily just use other CI/CD pipeline which calls this tool. Bonus points if you can integrate it with VUnit or SVUnit unit testing frameworks.

2. SystemVerilog code generation. Something smarter than just "I wrote a Python script that prints SystemVerilog code to a file based on some config file and then you run your build with the file the Python just printed."

I'm sure there are others that I am not thinking of. But overall, I don't find a lack of CI to be the problem. It's the lack of tools that a CI pipe uses that's the problem.

ETA: Also, was it intentional to launch right on the tail of DVCon? If so, clever planning.
1 comments
pkkim 836 days ago
CI is a core component of our product, but it's also a building block that we're building lots of DV-specific features on top of. In fact, one of those features is a build wrapper sort of like Make/Bazel for compiling stimuli, feeding them into simulators, and doing post-processing. Essentially what you describe in point 1 but for verification. We'll likely open-source this so other CI platforms can use it too.

For the other problems you mentioned: we're currently just handling the verification piece of the puzzle for right now, we want to do one thing really well first. We feel your pain on the SystemVerilog code generation front, we've had to interact with similarly primitive code generation mechanisms. You can only go so far with the preprocessor and what gets generated during elaboration.

link