Posts

SystemC is heating up in India – raise to the occasion and be part of this ecosystem

In the midst of a cold winter across India, there is some good news for those SystemC enthusiasts. While some in the industry thought the SystemC is being slow in adoption, there has been a constant need for moving up in abstraction in designing electronic systems. Over the past several years several ESL experiments have been carried out by local semiconductor/system companies in India. Incase you are deeply involved in this silent storm, here is your opportunity to broadcast your work as part of The Indian SystemC User’s Group (ISCUG). Abstracts are due by mid-Feb. See details at: www.iscug.in and you may download the CFP (Call For Papers from: http://www.cvcblr.com/downloads/iscug_CallForContribution.pdf See you at ISCUG!

UVM and callbacks – a pragmatic application

Many users find the factory feature in UVM as quite satisfying and easy to use and believe callbacks are not needed in UVM. However callback is a popular design pattern in software domain (see: http://stackoverflow.com/questions/946834/is-there-a-design-pattern-that-deals-with-callback-mechanism ). It is infact one of the very nice things that came from VMM to UVM. Though it is not that often used in UVM as in VMM, there are some pertinent use cases that makes the callbacks very handy in UVM as well. For instance consider a recent customer requirement that we handled: How to terminate Testcase on Max Error Count Reached? Of-course UVM has this support, but little “hidden” (see http://www.cvcblr.com/blog/?p=203 for similar stuff on VMM). You use the function: set_report_max_quit_count(2); // Quit after 2 errors However in the context of “phasing” this “terminates/interrupts” the phasing rather “abruptly”. While the UVM developers believe this is fine as default behavi...

Sledgehammer to crack a nut? – Use right tools for right class of design errors/bugs

Image
I am sure you have heard this phrase before – “A sledgehammer to crack a nut”; the below picture describes it all! Would you use a HUGE hammer to crack a small, tiny nut? (If you are further interested in this phrase read: http://www.phrases.org.uk/meanings/sledgehammer-to-crack-a-nut.html ). I recently had a small design error introduced in a piece of  RTL as below: It is an interrupt masking logic, code snippet as below: Note the use of “ANDing” logic – simply, AND- mask with data to produce result .The subtlety in Verilog/System Verilog is that you have 2 seemingly similar operators for doing AND operation; The logical AND: && The bitwise AND: & Given the “loose” data type checking, assignment rules etc. one can get away by using either one of the above many-a-times. In the above case the user used: result = data && mask; With result being a vector the above is a “logical/design error” but usually a Verilog compiler would let this go through (as it is not a...

UVM with VMM – first trial of true inter-operability

Image
  As noted in our recent blog article http://www.cvcblr.com/blog/?p=362 UVM is the first genuine step in the industry towards verification inter-operability. But it has a long way to go before all the VIPs get migrated to UVM – if they do. So there is a strong need to leverage on existing code base such as VMM, OVM & UVM. Below is a code snippet that shows how we can use both VMM & UVM messaging schemes in same env/code base. As such the code is not magic, is it? But do watch below for the real MAGIC..   If not for the inter-op kit, the above code would spit the messages from 2 different schemes and make it very hard for end user to keep track, customize etc. With UVM & VMM loggers being separate and not “inter-operating” the following user issues may arise: 1. Different formatted messages coming at different lines, making it hard, ugly to read, analyze 2. Complicating data-mining of log files as there are 2 different formats now in same log file ...

Verification inter-operability beyond UVM

As industry gets ready for adopting UVM with SystemVerilog, there are several practical combinations that come to the fore. One of the important concerns is about the existing code base/VIPs that can be “reused as-is”, yet benefit from various UVM features. For instance consider a VMM based VIP being plugged into a new UVM based env. Several user requirements/expectations arise: 1. Can the UVM & VMM co-exist in same simulation? 2. Can we leverage on single messaging scheme – instead of both `uvm_error & `vmm_error counting on their own, how do we unify them? 3. Can UVM phasing control/synchronize the vmm_xacotr::start/stop_xactor? 4. How does the UVM-Objection work with VMM-Consensus? 5. How do we talk from VMM-channel to UVM components and vice-versa? 6.How does the UVM ACTIVE/PASSIVE mechanism control VMM xactors underneath? 7. Does UVM config mechanism affect the VMM, if yes, how, if not then what do we do? I am sure there are more. But just enough to get you...

Rejuvenation of IEEE 1647-E language in functional verification

  Many articles, discussions have, in the last few years declared the most powerful verification language, IEEE-1647, the E-language as “dead” in favor of SystemVerilog. While it is very clear “SystemVerilog” is step-up from Verilog and hence is an easier next step for Verilog/HDL based verification folks, it is far from replacing well established, and still growing capabilities of E – arguably the most powerful language to do verification of HDL designs. With recent surge in Specman based jobs especially in India we were curious to see what’s happening. Here is what we found: New Project starts with Specman To give first hand information, we at CVC ( www.cvcblr.com ) have recently started a customer verification project, from scratch using Specman to verify a new RTL design block. We also heard from Singapore that they have interns starting their projects in Specman. From industry/ecosystem point of view, internship is generally for future projects especially if th...

Want to contribute/drive IEEE standards from India? Join this free Webinar to learn how!

Join IEEE-DASC webinar for free at: https://www1.gotomeeting.com/register/450027193   It is often a dream for many engineers in India to be part of IEEE committees, groups & associations and most of us feel proud about it. Here is your opportunity to take this to next step – you could well be developing, participating in next generation standards with special focus on India specific requirements too. Learn all about what it takes to participate in these activities in this hour long webinar for free @ https://www1.gotomeeting.com/register/450027193 Title: IEEE Design Automation Standards in India Date: Tuesday, September 27, 2011 Time: 8:00 PM - 9:00 PM IST For instance in the VLSI/EDA field there are several active standards such as: •IEEE 1800 – SystemVerilog •SV-AC assertions •SV-EC – enhancements/TB •Accellera VIP TSC – UVM •IEEE 1647 – E language •IEEE 1800 – PSL •IEEE 1076 – VHDL •IEEE 1801 UPF/Low Power •IEEE 1666 SystemC