-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
I noticed there are some GitHub Repos active on enabling UVM on Verilator:
https://github.com/MikeCovrado/GettingVerilatorStartedWithUV...
It would be an amazing leap to enable UVM fully on Verilator. Looking forward to it.
I noticed there are some GitHub Repos active on enabling UVM on Verilator:
https://github.com/MikeCovrado/GettingVerilatorStartedWithUV...
It would be an amazing leap to enable UVM fully on Verilator. Looking forward to it.
This is my feeling too, it's pretty trivial to do this stuff in git CI.
At NYU we have this entire process built into very trivial CMake and Github Actions stuff.
Here's an example: https://github.com/NYU-Processor-Design/PurdNyUart
You can see we have 100% test coverage, illustrated by CodeCov, and our CI runs the test suite on each PR. This is very normal in the software world and I guess I don't understand why the hardware world would need a specialized provider just to run Verilator for you.
It's not in gitlab's CI infrastructure, but I have continuous integration set up in a private server for https://gitlab.com/specbranch/r5lite and also for my company's proprietary hardware.
The functionality on offer here is equivalent to about 30 lines of Github Actions YAML to install verilator, run the tests, and upload the coverage information. [1]
Generating waveforms is free, Verilator already does that if you pass it the appropriate argument, either --trace or --trace-fst. We usually control that with a single CMake option.
Complex workflows can get nutty, but what's illustrated here is not a complex workflow.
[1]: https://github.com/NYU-Processor-Design/component-template/b...
Thank you for tackling this critical problem for logic designiners. I think the tools available are much too old for fast paced workflows.
From my experience attempting to get a similar workflow down for my company:
I tried to use verilator a while back but ultimately I couldn't because it didn't have same constraints in the verilog language features that I was going to use in production. It doesn't even matter who was missing a feature, verilator or the proprietary tool, it was just about getting them to be same that caused the cognitive dissonance that I didn't want to deal with.
I ultimately decided to move away from verilator and use the clunky proprietary tools since it was what would be used in production. Getting "verilator compatibility" seemed like a "nice to have".
Second, the a winning local-first framework of verilator wasn't really established. You show in your example running a test from the yaml file using what looks like a bash script. Even as an experienced programmer who knows bash and sh well, I still find it very hard to write complex thoughts in it. The last high level attempt I found to bridge this gap is likely https://www.myhdl.org/ I don't know them personally, but it seemed like they had some very good thoughts on what makes writing good hardware level tests good. I think it would be worth reaching out to them if you haven't already.
The one thing that even more critical was a way to run our tests locally. The 10-20 seconds it takes to start a docker image (best case) in the cloud is really frustrating when you are "so close to finding a bug" and you "just want to see if this one line change is going to fix it". Once we got our whole pipeline going, it would take 1-6 minutes to "start a run" since it often had to rebuild previous steps that cache large parts of the design.
So I think you will want to see how you can help bring people's "local's first" workflows slowly into the cloud. Some tools (or just tutorials) that help you take a failing test, and run it locally and on the cloud will be really good especially as you get people to transition!