do you guys know why company use C++/C to do HWverification?

Could anybody having used C/C++ to do ASIC verification talk about your tools and verification flow that you use?

Re: do you guys know why company use C++/C to do HWverificat

Normally, we have some testbench in C. Using PLI, we connect modelsim and c routing together. You know, some algorithm are very complex, like arithmetic coding. It is very hard to write testbench in HDL. So, C + PLI + verilog is most methology in our design flow.

Hi
sweesw!
I think maybe it's easy and cheap to use c.E is a good choice except it's price.

zhpy

Re: do you guys know why company use C++/C to do HWverificat

hi,

In verification, we should not pay our attention to the timing, only function. We build the behavior models only for fitting the DUT interface timing.
So we may write code with the high-level programming language, such as C/C++, SystemC etc.

Re: do you guys know why company use C++/C to do HWverificat

Simply put, those companies can't affort specialty verification tool like specman. So C/C++ becomes "poor" man's HVL. C/C++ works, but user may have to write a lot more code while in specman many features are built into the language.

Re: do you guys know why company use C++/C to do HWverificat

C/C++ are more algorithmic than HDL,
all these SystemC , E are basically subsets of C/C++ .

Re: do you guys know why company use C++/C to do HWverificat

We do full verification in C/C++. With systemc, you are allowed to do co-simulation with ISS and HDL models. However, the HDL model usually does not exactly reflects the timing. We may have to change systemc model to adapt to it.

By the way, I dont agree verification only forcus on functionality. We do have timing concern as well.

Re: do you guys know why company use C++/C to do HWverificat

Currently, my company is using SystemC now. Originally, some engineers in my company using E as verification language, but now it seems E is impossible to be a standard language.

I use Cadence Incisive for SystemC and HDL mix-language simulation. Cadence supports SystemC well in most cases. The only thing I am not used to is when sth is wrong, ncsim reports signal error and ask me to call Cadence for support, there is no more debug information. In order to debug, you need static compilation your bench and design. Cadence seems to provide a better debug environment in its 5.3 version.

SystemC has a lot of features, such as transaction record, very good random generation scheme, assertions, etc. Also Debussy is providing an interface to record SystemC signal directly to FSDB format, but you need to specify signals one by one. Their AE told me the next version of Debussy will provide an interface same as in Verilog.

My feeling is that SystemC is more convenient than PLI because the interface between two languages is hidden from you, you don't need to take care of it.