[stephenmm]

I have some of the same concerns and would like to see someone from industry who has actually done it before I spend much more time on it. My additional question is then how did the academics do it? There are some tools that negate some/most of the need for gate sims but at my company we still do not ship without SOME gate sims.

[gluggymug]

how did the academics do it?

Tape out using these tools?

My guess is they skipped gate level and other stuff that I consider good quality (BISTs, DFT logic, power estimation etc). You either skip it or rewrite your tests in Verilog/VHDL/etc.

Static Timing Analysis etc. can only do a little of what's needed. You have to check your constraints are correct.

Academics don't know what they are doing. They probably never had to do a design flow for a real product or even touched a commercial tool. It's too expensive. That's why they make these other tools. And that's why these tools kinda suck at getting to a finished product.

[trsohmers]

@gluggymug

You do realize you can do all of that simulation after you generate your verilog and put it through your RTL compiler?

[trsohmers]

@gluggymug (2nd... don't know why the 'reply' button doesn't appear below your comment)

Yep. Check out this https://github.com/ucb-bar/rocket-chip ... there are plenty of testing options you can do, including waveform vcd testing.

EDIT: Also, relevant paper: http://www-inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab3-... ... check out the part regarding test harness

[gluggymug]

(Yeah you can't reply straight away)

Looking at a lot of stuff you referenced.

I think my definition of tests is a lot more generic than yours. Taking a look at your links it seems tests are written in RISC-V machine code? The code will execute some functionality of the CPU and check for an expected response then possibly through a logging IO from the chip send a pass/fail message to the test harness or update a status register that is polled.

They run Verilog simulation on RTL and gate-level using Synopsys VCS. (At least they didn't skip it! Which is good!)

This is a very specific way of doing stuff that really only applies to this particular core with very little I/O.

We don't do it this way in industry. (This is where a throw a drink in the face of whichever Berkley academic that put this crap together.) The last time I saw something like this was maybe 1999-2000. It is terrible. Usually testing is done at the interfaces.

A real-world design has lots of I/O. For me, a test generically should stimulate the inputs to the design as well as have code for the CPU if it exists. Checkers check the outputs of the design for correct behavior. These stimuli and checkers are written in the verification language of your choosing. This is the standard approach. More checkers peek into signals inside the design itself usually.

If that stuff is written in Chisel so it can be simulated by the C++, then you are screwed for the RTL and gate-level. This is what I am saying.

The RISC-V test harness pretty much only has a clock and reset for inputs, Some sort of host bus. That's it! And the tests are assembly code or whatever.

If your design is not a CPU, what would your test be? say it's a HW cryptography encoder thing, no code to load into a memory.

[gluggymug]

How do I get my test stimulus into my simulator? And where is my checking?

Hypothetically I wrote my tests and checkers in Chisel. I now want to run a gate level simulation of my tests. I asked the same thing to the Clash guys. Can it do that?

[stephenmm]

It seems like you would need some sort of formal equivalence checking if that is the flow. Is there such a thing for Chisel?