WP_Term Object
(
    [term_id] => 14325
    [name] => Accellera
    [slug] => accellera
    [term_group] => 0
    [term_taxonomy_id] => 14325
    [taxonomy] => category
    [description] => 
    [parent] => 386
    [count] => 21
    [filter] => raw
    [cat_ID] => 14325
    [category_count] => 21
    [category_description] => 
    [cat_name] => Accellera
    [category_nicename] => accellera
    [category_parent] => 386
)
            
accellera semiwiki header
WP_Term Object
(
    [term_id] => 14325
    [name] => Accellera
    [slug] => accellera
    [term_group] => 0
    [term_taxonomy_id] => 14325
    [taxonomy] => category
    [description] => 
    [parent] => 386
    [count] => 21
    [filter] => raw
    [cat_ID] => 14325
    [category_count] => 21
    [category_description] => 
    [cat_name] => Accellera
    [category_nicename] => accellera
    [category_parent] => 386
)

Accellera Update: CDC, Safety and AMS

Accellera Update: CDC, Safety and AMS
by Bernard Murphy on 07-06-2022 at 6:00 am

I recently had an update from Lu Dai, Chairman of Accellera, also Sr. Director of Engineering at Qualcomm. He’s always a pleasure to talk to, in this instance giving me a capsule summary of status in 3 areas that interested me: CDC, Functional Safety and AMS. I will start with CDC, a new proposed working group in Accellera. To manage hierarchical CDC analysis back in my Atrenta days, you would first analyze a block, then use that analysis to define pseudo constraints on ports of the block, and so on up through the hierarchy. These pseudo constraints might capture things like internal input or output synchronization with related clock info. Sort of a CDC-centric abstraction of the block.

Accellera Update

We should have guessed that other tool providers would do something similar, with their own constraint extensions. Which creates a problem when using IP from multiple vendors, each of whom use their own tools for CDC. Maybe you would have to re-do the analysis from scratch for a block? Which may not be possible for encrypted RTL. This is an obvious candidate for standardization – defining abstractions in a common language. SDC-based, no doubt, since these constraints must intermingle with the usual input, output and clock constraints. A worthy effort in support of CDC verification teams.

Functional Safety

It might seem that ISO 26262 is the final word in defining functional safety (FuSa) requirements for electronic design for vehicles. In fact, like most ISO standards ISO 26262 is more about process than detailed guidelines. As tools, IPs and Systems development have advanced to comply with FuSa needs it has become obvious that we need more rigor in those expectations. Take a simple example. What columns should appear in an FMEDA table, in what order and with what headings? Or could this information be scripted instead? None of this is nailed down by ISO 26262. Formats/scripting approaches are completely unconstrained, creating a potential nightmare for integrators.

More generally, there is a need to ensure standardized interoperability in creating and exchanging FuSa information between suppliers and integrators. Which should in turn encourage more automation. So when I claim my IP meets some safety goal, you don’t just have to take my word for it. You can run your own independent checks. On a related note, the methodology should support traceability (a favorite topic of mine). Allowing for validation across the development lifecycle, from IPs to cars. Incidentally there is a nice intro to Accellera work in this area from DAC 2021.

Lu mentioned a related effort in IEEE. I believe this is IEEE P2851, looking at some fairly closely related topics. Lu tells me the Accellera and IEEE groups have had a number of discussions to ensure they won’t trip over each other. His quick and dirty summary is that Accellera is handling the low-level tool and format details while IEEE is aiming somewhat higher. I’m sure that eventually the two efforts will be merged in some manner.

UVM-AMS

The stated objective of this working group is to standardize a method to drive and monitor analog/mixed-signal nets within UVM. Also to define a framework for the creation of analog/mixed-signal verification components by introducing extensions to digital-centric verification IP.

In talking with Lu, the initial objective is to align with existing AMS efforts, in Verilog, SystemVerilog and SystemC. There’s a nice background to the complexities of AMS modeling in simulation HERE for those of us who might have thought this should be easy to solve. Even the basics of real number modeling are still not frozen. Analog signals are not just continuous variants of digital signals; think of the complex number representations common in RF. So there’s history and learning which the standard should leverage yet not disrupt unnecessarily.

AMS teams want the benefits of UVM methodologies, but they don’t want to start from scratch. Aligning those benefits with existing AMS requirements is the current focus. Lu says that many of these requirements aren’t language specific. The working group is figuring out the semantics of the methodology first, then will look more closely at syntax issues.

Accellera will be presenting more on this topic at DAC 2022 so you’ll have an opportunity to learn more there.

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.