504 Gateway Time-out

Archive for April, 2010

22 April, 2010

Noted EDA analyst and guru Gary Smith delivered keynote address: “ESL: Where We Are and Where We’re Going”

OSCI sponsored the first annual SystemC Day at DVCon 2010.  The presentations were video recorded and are available for free for those who missed DVCon or who may wish to see them again.  Gary Smith’s presentation (registration required) and OSCI chair, Eric Lish’s OSCI Update lead the video set from SystemC Day.

The 12th North American SystemC Users Group (NASCUG) meeting was part of SystemC Day at DVCon and featured technical presentations on architectural modeling, verification, and analog/mixed-signal design using SystemC.

OSCI ON YOUTUBE: More videos of users and their perspectives on SystemC events and activities can be found via the OSCI channel on YouTube: http://www.youtube.com/officialsystemc

Click here for completing listing of the following technical presentations.

The Metaport: A Technique for Managing Code Complexity
Jack Donovan, HighIP Design, Texas, USA

The metaport is a coding style that can effectively manage code complexity for complex ESL models, especially models that are intended for high-level synthesis. This presentation will give an overview of the metaport concept and dive into the details of a possible implementation.

OCP Socket Modeling with TLM-2.0
Hervé Alexanian, Sonics Inc., California, USA

This presentation discusses work performed by the OCP-IP Committee, specifically modeling that OCP built upon the TLM-2.0 standard.

ADL Synthesis using ArchC
Samuel Goto, Master student at UNICAMP

The design and implementation of processors is a complex task. Architecture Description Languages (ADLs) were created to extend existing HDLs, to ease the process of developing and prototyping an architecture by providing a set of tools and algorithms to optimize and automate some of the tedious parts. While much has been done on the specification and business levels of ADLs, there is a huge gap between ADL specifications/simulators and real life processors written in RTL. This project addresses the issues of bringing an ADL description to the RTL level, and reports the development of an extension of ArchC to support this level.

Look Ma, No Clocks! Improving Model Performance
David Black, XtremeEDA, Texas, USA

This tutorial-style presentation illustrates some techniques to avoid the inclusion of clocks in SystemC simulations and provide results of simple experiments showing the simulation performance benefits. Concepts discussed include synchronization, clock-free timers, and the effects of clocks on performance. A proposal is made for a simple SystemC class that can simplify coding when clocks are thought to be needed.

TLM-driven Design and Verification Methodology
Brian Bailey, independent consultant

SystemC is well on the road to adoption in a number of areas within the Electronic System Level (ESL) space, but many of those are separated islands today. Virtual Prototyping has seen a huge leap forward with the standardization of TLM 2.0. SystemC is also being used successfully for high-level synthesis at the module level, but to make SystemC pervasive, there must be a link between the applications. In addition, to reap the maximum productivity gains from a migration to a higher-level of abstraction, the verification methodology must also change in significant ways. In this presentation we will explore a new TLM-driven design and verification methodology that is being developed within Cadence, critiqued by their customers and documented in a book, which will be released over a number of months as pieces of it mature.

, , , , , ,

16 April, 2010

Last year, the Accellera VIP-TSC spent quite a lot of time (I know, because I was there) defining a standard library to establish interoperability between OVM and VMM. All in all, I think this was a useful exercise, although it did highlight some of the shortcomings of treating a standards committee like a software development team. At the end, users were left with a nice standard that enables OVM users to include legacy VMM components in their environment and vice versa.

Beginning late last year, the TSC decided to move forward with the long-term goal of developing a single “universal” verification methodology (deemed “UVM”) ostensibly to eliminate the “methodology war” between OVM and VMM that some thought might have actually been solved with the Interoperability kit. The TSC voted back in December to use OVM2.0.3 as the starting point for the UVM, a clear indication that not only was the methodology war over, but that OVM had won. Here’s where the questions start.

Shortly after the vote, and before any substantive work had been done in the TSC other than some abstract requirements discussions, Mentor and Cadence released OVM2.1 which included some bug fixes from OVM2.0.3 and provided two new features, callbacks and objections, which just happened to surface in subsequent discussions as two of the more significant requirements for UVM. Since nothing much had been done yet, and 2.1 was already available, I made the suggestion that, instead of locking ourselves into OVM2.0.3, that was already outdated, the TSC should instead use OVM2.1 as the starting point for UVM. I was immediately shouted down for having made an outrageously inappropriate motion. I was told that the TSC had voted on 2.0.3 and that was that. Once callbacks and objections were approved as official requirements, I again suggested that OVM2.1 should be used and was not even allowed to make an official motion to that effect.

Fast-forward to last week (4/7/2010) when the TSC approved using OVM2.1.1 as the starting point for UVM. I’m still waiting for an adequate explanation of why this went from being completely inappropriate to passing overwhelmingly in just a couple of months. Could it be that the initial objections were other than technical? If so, I wonder if the motivation behind them are still there, and it’s just that moving to 2.1.1 was such an obviously good idea that those who objected initially realized that they could no longer shout it down.

For the health of the TSC, and my own sanity, I think I’ll give my colleagues on the committee the benefit of the doubt.

14 April, 2010

Accellera and The SPIRIT Consortium Merger is Complete

An open SystemVerilog requirements gathering meeting sponsored by the IEEE Design Automation Standards Committee’s (DASC) SystemVerilog Study Group was hosted at Mentor Graphics after DVCon 2010. While the meeting room was packed with many of the world’s SystemVerilog cognoscenti – as well as many from around the world on the phone.


MGC-Victory-Room-Web Dave Rich posted his blog on the meeting and shared a link that allowed everyone to see the top-3 items Users and Producers sought from the next version of SystemVerilog.  But while Cliff was making his presentation on “Design Connectivity Features,” a few people slipped out of the room into the “Victory” room next door.

What can now be disclosed was the Accellera and The SPRIRIT Consortium representatives were signing final documents to ensure the merger of the two organizations, announced at DAC 2009, would become final.

Shrenik-Stan-Web Shrenik Mehta, for Accellera and Stan Krolikoski, for The Spirit Consortium could be seen taking pen to paper as the final signatures were done to cement the merger.  With final legal and governmental reviews complete, the merger became official and was announced today.  The press release crossed the wires this morning.  The merged organization will retain the Accellera name and have 8 active standards projects.  It has also recommitted that is is aligned to create formal standards through the IEEE Standards Association.

Congratulations to the merger teams and staff that worked hard to make it a smooth merger process.  Mentor Graphics looks forward to the benefits of the electronics industry when electronic design language-based standards are brought together with Intellectual Property (IP) standards.

, , , , ,

12 April, 2010

UVM Logo Web I shared information in my last blog that Mentor’s OVM-EA starter kit could be downloaded and used by those who need to plan a possible move to, or use of UVM.  I pointed out that we uploaded to OVM World two contributions: (1) Mentor’s UVM-EA Starter Kit and (2) UVM-EA OVM Compatibility Overlay Kit.

While many have started to take a look at the kits, one use scheme I did not expect to come out of this was to convert their OVM code and run it with native UVM.  I had expected all experiments to use the OVM UVM-EA compatibility overlay instead.

But that raises the question: Should an OVM user go native or rely on compatibility?

Since Mentor Graphics continues to recommend that production design verification be done with OVM 2.1.1, we believe the OVM Compatibility Overlay kit will be crucial for UVM adoption by the OVM community if they wish to move to it in the future.  But our recommendations aside, there are examples of using the conversation script in the UVM-EA Starter Kit to translated OVM into native UVM.

The first I got wind of this was a tweet from @bakshia on how nice the sed script was to convert OVM to UVM.

Baskshia Tweet

More news on the conversion script came from Willamette HDL from a comment posted about my last blog.  They used the conversion script @bakshia mentioned to convert their OVM code to be UVM just as Mentor did to covert OVM to generate the UVM-EA.  WHDL ran the script on their training examples and labs and then tested them with the UVM-EA library.  “Everything worked perfectly.  Good Job!!” said Willamette’s Kurt Schwarz  If you visit the Willamette HDL website now, you will see they offer both Introductory and Advanced level UVM training.

If you are an OVM user, will you use a compatibility overlay scheme or would you prefer to go native?

, , , ,

8 April, 2010

Companion UVM-EA OVM Compatibility Overlay Kit Available for Download

uvm-logo-web1Mentor Graphics has made available its UVM-EA starter kit to promote OVM users’ feedback on UVM. As I wrote in an earlier blog, Accellera has defined specific modifications to OVM 2.1.1 to create UVM-EA.  The Mentor Graphics version of the UVM-EA can be downloaded here.  The UVM-EA starter kits passes all our Questa 6.6 regression tests.

The UVM-EA OVM Compatibility Overlay kit is also available at OVMWorld.org. The UVM-EA OVM Compatibility Overlay kit allows OVM users to continue with their unmodified OVM environments and use the UVM-EA library.  The UVM-EA OVM Compatibility Overlay kit has been fully tested with Questa 6.6 using native OVM.  Details on the tests can be found in the README file.  We welcome feedback from consumers who use it with other verification platforms. It is written in standard SystemVerilog and should work for all platforms that support IEEE 1800™.  It can be downloaded here.

What is the difference between OVM 2.1.1 and UVM-EA? The VIP-TSC has mandated that all file names that contain OVM be changed to UVM and all code that uses “ovm” be changed to “uvm.” The Mentor Graphics UVM-EA represents a faithful representation of VIP-TSC requirements. Please note: These are not the only changes contemplated by Accellera. The Accellera VIP-TSC has indicated a desire to review the “end-of-test” and “callback” services within the UVM-EA and add “message catching.” This code is for early adopter review, not for production use as VIP-TSC changes are likely.

We will share updates on UVM developments with you as it merits and as me make updates to these early adopter UVM kits as needed. If you would like follow or participate directly in the Accellera VIP-TSC standardization effort, please visit http://www.accellera.org/activities/vip/ for more information.

, , , , , , , , ,

8 April, 2010


Requirements set for Accellera UVM-EA (Early Adopter) Release

This was a productive week for Accellera. After months of discussions, the Accellera Verification IP Technical Subcommittee (VIP-TSC) voted to adopt OVM 2.1.1 as the base of its verification methodology. Accellera’s OVM version will be called UVM.

In adopting OVM 2.1.1, Accellera signaled it will make further changes. The VIP-TSC has approved changes to (1) modify file names that have OVM in them to UVM, (2) modify any function calls and element names from “ovm” to “uvm,” (3) make possible changes to the “end-of-test” and “callback” code found in OVM 2.1.1, and (4) add a “message catching” feature.

This is good news for Accellera and great news for those who have adopted OVM and use OVM today. I believe OVM users will find it easier to interoperate with this third methodology. As a strong supporter of Accellera standards, we will keep you updated on Accellera UVM as developments merit. Users should expect solid industry support in all their popular tools as the Big-3 EDA suppliers have all voiced public support for this standards project.

You can follow Accellera VIP-TSC developments directly at http://www.accellera.org/activities/vip/.

, , , , , ,

@dennisbrophy tweets

Follow dennisbrophy

@dave_59 tweets

Follow dave_59

@jhupcey tweets

  • #ARM now hiring formal verification engineers in Austin: exciting tech challenge + Ram is a great guy to work with.…https://t.co/uwIXLHWqvg
  • Attention all SF Bay Area formal practitioners: next week Wednesday 7/26 on Mentor's Fremont campus the Verificatio…https://t.co/9Y0iFXJdYi
  • This is a very hands-on, creative role for a verification expert -- join us! https://t.co/jXWFGxGrpn

Follow jhupcey