Introduction to SystemC TLM Verification

[kuncikehidupan]

Hi all,

 

 

After developing a virtual platform using SystemC with TLM, and also several peripherals (IP) model in high-level (LT), I realised that if in RTL design there is a UVM to say that the design is "okay".

 

How about in high-level? Is there any methodology that we could adopt?
If there is none, may I ask for your suggestion on how to verify our own SystemC TLM (LT) design?
 

The SystemC Verification subforum seems to be obsolete, so I posted it here.

Really appreciate any kind of advice and solution.

 

Thank you.

Regards,

Arya.

 

[Dineshkumar]

Hi,

 

You can use SystemC Verification 2.0 standard for LT model verification.

 

Regards,

Dinesh

[kuncikehidupan]

Hi Dinesh,

 

But SCV does not have the functional coverage?

 

Thank you.

Arya.

[ruchir.bharti]

Hello Arya,

 

Well UVM is just not limited to RTL design verification, it have various flavors as per requirements. So which means you can have various options :

 

1) TEST Sequence (UVM) -> UVM_BFM(signal interface) -> RTL.

2) TEST Sequence (UVM) -> UVM_TLM_BFM -> SystemC/TLM(LT) Model.

 

EDA vendor provides adapter layer to connect UVM_TLM <-> SystemC_TLM like ML-UVM from Cadence, UVM Connect from Mentor and TLI from Synopsys. 

 

This is just the brief, i can put it here. If you any specific Doubts please post.

 

Regards

Ruchir

(Please ignore any typo)

[apfitch]

Hi Arya,

  the verification forum is alive - it's just very new. So I would recommend also asking your question there.

 

You might want to look at UVM-SC (SC implementation of UVM) which is the draft phase. There's a presentation about it on the Accellera website by Martin Barnasconi.

 

People have also attempted to do formal equivalence checking between high level and low level - Calypto Design Systems had a tool called SLEC from memory.

 

I guess at the moment the most popular route is to verify RTL re-using the TLM SystemC as a reference model - but of course that could result in bugs being found in the TLM model as well as in the RTL,

 

regards

Alan

[kuncikehidupan]

Hi Ruchir,

 

UVM stands for Universal Verification Methodology, but it is not really "universal". As pointed clearly by Mr. Martin Barnasconi in http://accellera.org/images/news/newsletter/Using-UVM-in-SystemC-DVConUS-2014.pdf

I am aware of Mentor's UVM connect since long time ago, but personally I am not sure whether or not it is suitable. There are differences between block and system level verification.

Have you ever tried any of those EDA adapter layer?

May I ask for your advice about the big picture of it?
For example if I already have the systemverilog uvm testbench, can it be used directly using the adapter layer without any modification.

 

 

Hi Alan,

 

Yes. The UVM-SC sounds promising, but it seems like it is still under development. Especially for the assertions and coverage part.

In case I do not get this very clear, is this UVM-SC currently available to use? Where to download?

Accellera already got SCV, so this UVM-SC is intended to replace that SCV?

 

Thank you.

Regards,

Arya.

[ruchir.bharti]

Hello Alan,

 

Thanks for sharing your thoughts,

 

Let me this opportunity to ask few more question :

 

"You might want to look at UVM-SC (SC implementation of UVM) which is the draft phase. There's a presentation about it on the Accellera website by Martin Barnasconi."

This i agree that its new dimension of SC to verification domain which gives standard methodology to verification user. and im sure this will definitely grow across industry but still will take some time to get maturity level. Such as to my understanding few powerful feature are still missing/under developed in UVM-SC like register adapter layer, callback, coverage and constraints etc.. And last but not the least IT`s FREE!!! So do you think UVM-SC will move ahead from UVM-SV???

 

"I guess at the moment the most popular route is to verify RTL re-using the TLM SystemC as a reference model - but of course that could result in bugs being found in the TLM model as well as in the RTL, "

I still like to understand your valuable thoughts on : when TLM-SC is used as reference model of RTL, will still have chance to leave functional holes OR Bugs in RTL!! To my understanding and my past experience as a verification engg, if coverage is properly define or stated then there is very very minimal chances to skip holes. On the lighter note i believe in Murphy`s law.

 

thanks!!

 

----------------------------

Hello Arya,

 

Yes i have used EDA adopter layer from Mentor and Cadence both, and if you have SystemVerilog testbench and SystemC model, it hardly take a day job to integrated in env.

Let me share my thoughts:

1) when systemC as functional accurate model is used as reference model then testbench scoreboard will only be used as apple to apple compactor.

1.1) in case during start of the RTL design delivery get delayed and functional model implemented early then Verification engg. can start build test sequence and start running on reference model instead of RTL( which is missing). This control-ability should be in Testbench to route stimulus to functional model not signal driver. This exercise will stable initial hurdle during test stimulus generation. And after RTL release same stable sequence can be re-run. 

1.2) After closure of verification this functionally proven model can directly be used for virtual Soc(system Level model) for device driver development.

 

2) Adapter layer provide analysis/TLM-1/TLM2 port compatibility, so user can connect two worlds as per requirement. But just one thing to make sure weight of each packet on both world should be same, other wise there is possibility if corruption is data.

 

3) in case user have verified RTL and need to developed functional model, then this layer is used with reusable test scenarios.

 

 

I hope this might help!!

 

 

Regards

Ruchir

[kuncikehidupan]

Hi Ruchir,

 

I find it helpful. 

 

In my case, I got verified RTL and now developing functional model, so the adapter layer (I will choose to use UVM Connect from Mentor) is used with reusable test scenarios from the SystemVerilog testbench. Correct? 
One day job sounds good enough, If the above statement is correct then I can directly use the SystemVerilog testbench with the adapter to test the functional model. Yes?

 

Since you mentioned about UVM-SC and UVM-SV in your post, may I ask you where to download these materials?
Can you give a brief summary of the advantages and disadvantages of using UVM-SV vs UVM-SC vs SCV vs UVM Connect (or any other adapter layer)?

 

Thank you.

Regards,

Arya.

[ruchir.bharti]

Hello Arya,

 

Yes if you have verified RTL and need to reuse test sequence from UVM-SV testbench, you directly use adapter layer to interact with both worlds.

for Eg of UCM Connect :

 

in UVM-SV( connect Phase ):

// Here SV agent is my TLM2.0 compliant  intiator socket  ie "tlm2_bsocket"
// "bus_stimulus" -> is tag thru which uvm connect will bind with
        uvmc_tlm #()::connect(tlm2_bsocket, "bus_stimulus"); 

in TLM-SC Module Constructor :

// here SC module is my TLM2.0 compliant target socket ie "tlm_target_socket"
// "bus_stimulus" -> is tag thru which uvm connect will bind with
    uvmc_connect(tlm_target_socket,"bus_stimulus");

But please make sure that packet weight should be match between the 2 worlds. packet weight means size of each data variable should be matched. OR best recommendation i could give is if you could use TLM-GP between UVM-SV and TLM-SC which increase interoperability.

 

To best of my knowledge, UVM-SC is under development phase, document draft is ready and SystemC verification group is available for everyone contribution. But no public release yet. 

UVM-SV : is provided by all vendors and documentation is available in there installed area. So if you still required please let me know.

 

So now there is trade off between UVM-SC vs UVM-SV ie Open source vs EDA controlled. Both have advantage and disadvantage in use, in support and in future enhancement. Currently i cant put much comments, but I wish UVM-SC is fully adopted by industry

 

SCV : SystemC verification Library is good, but personally i didn't try much over it. Still i feel SV have more powerful over constraint and coverage.

 

UVM Connect is open source you can compile and link to any simulator. On my last usage of UVM Connect there are some memory leakage issues i faced, which is correct it on my local copy.

 

 

Please note : above are purely my thoughts and experiences, nothing to do with discouraging use of different tools and methodology. Please feel free to use as per need.

 

Thanks

Ruchir

[kuncikehidupan]

Hi Ruchir,

 

Thank you for the complete detail answer, really helpful.

I just realised it that SV in UVM-SV stands for SystemVerilog, so without doubt this one is obvious.

If you still remember the workaround to fix the memory leakage issue, kindly post it here so me and everyone else could fix it in our local copy.

 

Regards,

Arya.

[ruchir.bharti]

Hello Arya,

 

Well unfortunately i don't have code handy with me right now. As this issues faced more than a year back and i changes my organisation in between, so don't have updates/code with me now.

 

Thanks for understanding!!

 

Regards

Ruchir

[karandeep963]

Interesting discussion. I appreciate !!

 

One thing I found most interesting from DVCON 2014 "Advancing system-level verification using UVM in SystemC" - Martin Barnasconi

 

 

This makes me feel that at least we need to converge some where !!

[Dineshkumar]

HI Arya,

 

Thanks for starting this topic.

 

Hi Ruchir,

 

Your posts provided a lot of info about using UVM for SC verification. Thanks.I have few questions here.

 

1) You mentioned UVM connect is open source, does it mean I can just download and use in gcc/MSVC environment. Or it require any EDA tools support?

 

2) Can I get access to UVM-SC draft version?

 

 

Regards,

Dinesh.

[apfitch]

Hi Arya,

  I missed your questions above - according to the paper by Martin, the UVM-SC reference implementation should be available "later in 2015". So expect it by 23:59 on 31st December :-)

I don't think UVM-SC is meant to replace SCV - but you could ask in the Verification Forum, or join the VWG as an observing member and ask.

 

To Dinesh - UVM-Connect is open source - but of course you need a SystemVerilog simulator with class/randomization/DPI support to use it, for which you'll have to pay. So you need EDA tool support for the SV part of UVM connect.

 

Regarding UVM-SC, the reference implementation is due "later in 2015"

 

To Ruchir - regarding functional coverage, yes if you specify functional coverage properly, you should not have coverage holes at RTL or at TLM level. But functional coverage models are written by engineers, so if you write a functional coverage model which doesn't correctly cover all specification points of your design, you can have a problem. (Compare that to code coverage where you can easily measure how much you have coverage you have achieved).

 

However I was probably thinking more about the issue that the designer and the verification engineer both independently interpret the specification to build the DUT and the reference model independently - so when they are brought together to verify the RTL, it is conceivable that either the designer or the verification engineer or both could find bugs because they have both interpreted the spec independently,

 

 

regards

Alan

[kuncikehidupan]

Thanks Alan and everyone.

Appreciate all your thoughts.