Sunday, February 21, 2010

Signs of maturity in EDA tool built-in examples

During a recent look at ActiveDesign product from Jasper (http://www.jasper-da.com/products/ActiveDesign.htm), I was pleasantly surprised to see a high quality design being used as the case study. Usually such early product demos contain tightly canned examples, showing only the relevant tool features and much less on the actual design. Here is a refresher – we get a very representative real life design – AHB-lite to AXI bridge with 4 AHB-lite masters, a refreshing change in EDA space.

See below for a screenshot of the demo design:

AHB-lite-to-AXI

Tool demos are not on dummy designs, becoming more and more realistic indeed!

On a similar note, Breker’s Trek (www.brekersystems.com) has $TREK_HOME/examples that are complete SoC level test synthesis – not just “Hello World”, “foo-bar” anymore! Other interesting designs include a Cache controller model, CPU etc.

Similar is the SoC kit initiative from Cadence (www.cadence.com/products/fv/iv_kit) – this one tops the list of all EDA demos I’ve seen in years on Verification – they started back in late 2007 and have been growing in strength over years. During CDNLive 09 @ Bangalore, CDN showed their roadmap for these kits and clear indications are that these will be extended to ESL platforms too.

Sure all vendors ship more and more examples with their tools nowadays, this also means they employ/engage with real verification engineers besides R&D, support engineers, good for the job market, hopefully :-)

Sunday, February 7, 2010

Debug SystemVerilog macros with VCS-DVE

Srinivasan Venkataramanan, CVC Pvt. Ltd.

Rashmi Talanki, Sasken

John Paul Hirudayasamy, Synopsys

An extract from a little lengthier post @ http://www.vmmcentral.org/vmartialarts/?p=922 – focus here only on Debug side on this post:

One of the powerful features of SystemVerilog is the ability to create TEXT macros (those `define s) with arguments – they can create fairly complex code in jiffy. Take a look at VMM source code if you need examples.

In a recent customer engagement, we had to dig deep into VMM atomic Generator code that gets created by the one liner macros!

During the coding work, the customer opened up vmm.sv and got trapped in the multitude of `define vmm_atomic_gen_* macros with all those nice looking “ \ “ at the end – thanks to SV’s style of creating macros with arguments. Though powerful, it is not the easiest one to read and decipher – again for a first time SV/VMM user.

Now comes the rescue in terms of well proven DVE – the VCS’s robust GUI front end. Its macro expansion feature that works as cleanly as it can get is at times hard to locate. But with our toolsmiths ready for assistance at CVC, it took hardly a few clicks to reveal the magic behind the `vmm_atomic_gen(icu_xfer). Here is a first look at the atomic gen code inside DVE.

clip_image002

Once the desired text macro is selected, DVE has a “CSM – Context Sensitive Menu” to expand the macro with arguments. It is “Show à Macro”, as seen below in the screenshot.

clip_image004

With a quick bang go on DVE – the Macros expander popped up revealing the nicely expanded, with all class name argument substituted source code for the actual atomic_generator that gets created by the one liner macro. Along with clearly visible were the facade class name and the actual callback task with clear argument list (something that’s not obvious by looking at standard vmm.sv).

clip_image006

Now, what’s more – in DVE, you can bind such “nice feature” to a convenient hot-key if you like (say if you intend to use this feature often). Here is the trick:

Add the following to your $HOME/.synopsys_dve_usersetup.tcl

gui_set_hotkey -menu "Scope->Show->Macro" -hot_key "F6"

Now when you select a macro and type “F6” – the macro expands, no rocket science, but a cool convenient feature indeed!

The DVE’s macro expansion feature that makes debugging a real fun!

Wednesday, January 20, 2010

Renewed interest/investment in code linting! Good for the industry

As some of us have seen over last decade, approximately 5 years ago industry was upbeat about code/RTL linting with almost every EDA vendor offering products in this space. Some of them were start-ups acquired by big vendors (like LEDA.fr to Synopsys). At the end the Linting market proved too small for the 3 biggies and their focus on that technology got sidelined. In all, one company survived this wave well and that’s Atrenta – its SpyGlass product increased leaps and bounds both in its capabilities and installed base. Today SpyGlass is an undisputed leader in Linting and has enjoyed monopoly for more than 5 years, well done Atrenta!

Come recession, silently few smaller EDA vendors started investing on this niche segment and now we have ALINT from Aldec and Ascent from RealIntent. I’m personally thrilled to see more players on this technology – though the $$ may not be too high, the potential user base is large and investment is not all that HIGH as in a SystemVerilog simulator for instance.

From a user view though, Linting is a must have step in flow as recognized by experts like Adam Kronlik in a book: Functional Verification of Electronic Systems, Chapter 8 HDL Lint: http://www.iec.org/pubs/pub.asp?pid=13&bsi=3&cat=cont 

(BTW, I have a chapter on the same book, Chapter 14).

Few notes on 2 modern linters here:

Ascent from RealIntent: (http://www.realintent.com/real-intent-products/ascent).

One of the traditional challenges of a Linter has been the “heavy noise” it creates. Recent Linters *claim* to do better there – especially Ascent.

Other interesting features in this linter are:

  • Opportunities to improve simulation performance
  • Operations with hidden or expensive implementation costs

True, your mileage may vary, but good thoughts indeed!

As we read more on the Datasheet of Ascent one gets a feeling that it combines a traditional Modelchecker inside it as well – as their PBV & ABV features talk about. I’m not sure if that’s a good thing from a pricing standpoint as the linters are usually far cheaper than model checkers. But a good try by RealIntent indeed!

 

ALINT from Aldec (www.aldec.com)

Fairly young in the market (~2 years??), it has solid STARC policy inside it. What really interests me in this is their full blown API for user defined checks – yes every other vendor claims/has it in some manner, but I have not seen this level of detailed support and even better – their flexibility and response time in enhancing the API as needed.

It will be interesting to see how they survive over say next 5 years! Maybe it signals some impact to the erstwhile King of Linting – SpyGlass!

Sunday, January 17, 2010

SystemVerilog Interfaces – learn more about it for free! Register Now for this Webinar

CVC is pleased to announce online Webinar on "SystemVerilog Interfaces" along with Aldec as our partner. With ever growing interest in the true power of SystemVerilog here is your opportunity to get started with SystemVerilog in good style with no additional cost - it is a FREE Webinar and is scheduled in 3 different times to suit various timezones across the globe - ASIA, Europe & USA.Register online NOW to book your seat!

ASIA - India 9.30-10.30 AM,China: 12.00 to 13.00

Europe - 15.00 to 16.00 CET

USA - 9.00 - 10.00 AM, PST

Click here for an abstract of the Webinar. It will be presented by Srinivasan Venkataramanan from CVC and Jaroslaw K, from Aldec.

Sunday, November 8, 2009

SV: implication constraint and its implication/effect

SystemVerilog has a nice implication constraint feature to guard constraint expressions on their applicability. Last week during our SystemVerilog + methodology workshop one of the attendees faced an interesting issue. She was creating a min-VIP for APB as part of our SystemVerilog 10-day workshop (See details at: http://www.cvcblr.com/trng_profiles/CVC_VSV_WK_profile.pdf ).

She wrote a APB scenario code that was intended to create a sequence of transactions with varying address, kind etc. Here is a code snippet:

constraint cst_xactn_kind{
       if(this.scenario_kind == this.sc_id)
       this.length == 10;
       foreach (items[i])
        {
          (i==0) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b01; items[i].wdata == 'd11;


               (i==1) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b11; items[i].wdata == 'd12;
                       }
     }

Spot anything wrong in the above code? Perhaps not for the unsuspecting, bare eyes. Code intention: Keep the:

0th transaction KIND == WRITE, address == 01, data == 11;

1st transaction KIND == WRITE, address == 3, data == 12;

Read again the code – it seems to imply just that, isn’t it? Let’s run it.

Here is what Questa says:

###########################################################################                    
#                     WELCOME !!!
#                      APB PROJECT USING VMM
#                     DONE BY PRIYA @ CVC
#                     DATE:21stOctober2009
############################################################################
# Normal[NOTE] on APB_PROGRAM(0) at                    0:
#     APB PROJECT:       Start of APB Random test!    
# ****************************************************************************
# Normal[NOTE] on APB_ENV(0) at              0.00 ns:
#     APB PROJECT: Sim shall run for 10 number of transactions
# Normal[NOTE] on APB_ENV(0) at              0.00 ns:
#                     Reset!!!!!!!!!               
# Normal[NOTE] on APB_ENV(0) at            230.00 ns:
#                    Reset Release!
# ****************************************************************************
# *FATAL*[FAILURE] on APB Generator Scenario Generator(APB_GENERATOR) at            730.00 ns:
#     Cannot randomize scenario descriptor #0

Puzzled? What is wrong? Review by the code author herself few times didn’t reveal anything wrong (bias towards own code?).

Seek expert assistance.. Questa has a simple flag to bring up solver debugger as: vsim –solvefaildebug Let’s try that now..

 

# ../tb_src_scenario/apb_scenario_gen.sv(1): randomize() failed due to conflicts between the following constraints:
#     ../tb_src_scenario/apb_scenario_gen.sv(25): the_scenario.cst_xactn_kind { (the_scenario.items[0].addr == 32'h00000001); }
#     ../tb_src_scenario/apb_scenario_gen.sv(1): the_scenario.repetition { (the_scenario.repeated == 32'h00000000); }
#     ../tb_src_scenario/apb_scenario_gen.sv(25): the_scenario.cst_xactn_kind { (the_scenario.items[0].apb_op_kind == APB_WR); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[0].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[0].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[1].apb_op_kind == APB_WR); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[1].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[1].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[2].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[2].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[3].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[3].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[4].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[4].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[5].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[5].wdata == 32'h0000000c); }

Smell something wrong? Why is the constraint on addr, data getting applied across scenario items 2,3,4,5 etc.? Beyond the 0, 1 that the “implication” supposed to guard it? Relook at constraint code:

          (i==0) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b01; items[i].wdata == 'd11;

Found it? Not yet? The devil lies in details – here in that SEMICOLON “ ; “. A semicolon in Verilog/SV denotes END of a statement and begin of the next one. Hence the effect of “implication” is ENDED with the variable “kind” alone here – thereby it doesn’t affect the addr, data – hence the implication is invisible to them. At line 25, the addr == 1; At line 26, addr == 3; Hence the contradiction!

The fix will be to use && to imply that the guard is applicable to all the 3 variables – kind && addr && data.

  Instead of:

(i==0) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b01; items[i].wdata == 'd11;

Use:

   (i==0) –> (items[i].apb_op_kind == APB_WR) && (items[i].addr == 'b01) && (items[i].wdata == 'd11);

Morale of the debug session is: you need to be careful while using implication constraints for more than single variable :-)

Tuesday, July 7, 2009

Certificate course on SystemVerilog Assertions …Language + Lab + Mini-project

Certificate course on SystemVerilog Assertions

…Language + Lab + Mini-project

CVC is announcing a new session of its popular 2-day certificate course on SsystemVerilog Assertions (ABV_SVA) covering SystemVerilog Assertions in depth. Broadly it covers the following topics:

  • ABV Introduction
  • SystemVerilog Assertions (SVA)
  • Project – develop a real life Protocol IP (PIP) with SVA

Course contents: http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf

Duration

Here is a detailed breakdown of the course with duration. Note that we have a “mini project” tightly embedded in the course that helps in mastering topics learned so far in the course. This is on top of the regular labs that are part of the training.

Topic

Duration

Start

End

SystemVerilog Assertions

1.5 days

July 13

July 14

Mini Project II

0.5 day

July 14

July 14

Schedule:

July 13, 14 at Bangalore

To attend this class, confirm your registration by sending an email to training @ cvcblr.com

Ph: +91-9916176014, +91-80-42134156

Please include the following details in your email:

Name:

Company Name:

Contact Email ID:

Contact Number:

Sunday, June 14, 2009

Multi-threaded Verification MtV - taxonomy challenge

This evening I was speaking to a friend of mine on how to effectively utilize the 2-box, 4-core each machines he has at work for functional verification. He is exploring to add additional simulator licenses (did I forget which vendor :-) ) and was curious if he needs to add more machines or can he better utilize the existing ones.

During the discussion it became apparent that we have differences in various terms and their meanings. After the phone call I was casually browing edn.com and found a seemingly relevant article:

http://www.edn.com/article/CA6662624.html?industryid=47037

But a quick read didn't look like what I initially thought it would address. IMHO, while Multi-threaded Verification (MtV) is becoming mainstream (albiet slowly), it is a good time to agree upon the taxonomy for this new paradigm.

More on this later..