Semiwiki 400x100 1 final
WP_Term Object
(
    [term_id] => 157
    [name] => EDA
    [slug] => eda
    [term_group] => 0
    [term_taxonomy_id] => 157
    [taxonomy] => category
    [description] => Electronic Design Automation
    [parent] => 0
    [count] => 4047
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 4047
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0
)
EDA
Posted on by Daniel Payne

Making IP Reuse and SoC Integration Easier

Making IP Reuse and SoC Integration Easier
by Daniel Payne on 07-31-2014 at 2:00 pm
Categories: EDA

The last graphics chip that I worked on at Intel was functionally simulated with only a tiny display size of 16×16 pixels, because that size allowed a complete regression test to be simulated overnight. Our team designed three major IP blocks: Display Processor, Graphics Processor and Bus Interface Unit. We wanted to also integrate an 80186 core, but our IP team in Japan couldn’t meet the schedule, so we had to be less ambitious and rely upon an external CPU. Needless to say, when silicon came back the only display size that worked properly was 16×16 pixels.

Today we have SoCs that contain hundreds of IP blocks and cores that can come from other departments, other divisions or even bought as commercial IP. So the challenge still remains the same – how do I know that I’ve done enough functional verification, integrated all the IP properly, and uncovered enough corner-case bugs?

Assertions are one technology that promise to meet those challenges, and an assertion is a logic statement that defines the intended behavior of signals in a design. You can either write an assertion manually based upon your own understanding, or have a tool automate the creation of some assertions to assist your verification efforts. Atrentahas an EDA tool called BugScope that can automatically create assertions for an RTL design by reading in your functional stimulus and RTL source:

Methodology for Assertion Reuse in SoC – MARS

Users of BugScope can run a few different apps that provide assertion synthesis.


BugScope Assertion Synthesis Applications

One app has the acronym MARS – Methodology for Assertion Reuse in SoC. With MARS an engineer can verify that integrating each new IP block at the SoC level is correct by:

[LIST=1]

  • Verifying that the IP is configured properly at the SoC level
  • Any design issues are flagged at the SoC level
  • Measuring coverage that may have been missed at the IP level

    So assertion synthesis complements the traditional functional simulation practice in the goal to verify that an SoC is both functionally correct and ready for tape out. With assertion synthesis you can actually measure the progress towards your verification goals. Your digital design flow with assertion synthesis added looks like:


    Assertion Synthesis Flow

    Design engineers create RTL source code and then add test stimulus as inputs to the assertion synthesis tool.

    In MARS, once the properties are generated, they represent the known good state space of the design. BugScope then synthesizes assertions which create an executable specification for use in SoC integration. Note that no property classification was required at all. In fact, the entire MARS flow is fully automated.

    During IP development, output from assertion synthesis are properties that will always be true for that stimulus. If you see lots of new coverage properties when you scan through them, it may mean that your existing stimulus has some holes that verification runs have not covered. Some of these properties may also indicate that you’ve found a new design bug.

    IP designers review the properties for obvious bugs and coverage holes – not full blown classification since that’s difficult to do and time consuming. They would do this in combination with the Progressive App, which provides continuous, instant verification status.

    Once the IP team is ready to hand RTL to the SoC team, they generate assertions. You then bind these assertions to your favorite HDL simulator, emulator or even a formal verification tool. In simulation and emulation, these act like an executable specification. Once again, when you simulate or emulate and an assertion is triggered, you have just found either a specification error, an IP-level coverage hole, or a new bug to fix.

    With all of this feedback a verification engineer can then write new stimulus to fill any coverage holes, provide debug info to hardware and software engineers to fix specification errors, and ultimately debug info to fix corner-case bugs.

    Live Webinar

    Learn more about automated assertion-based verification methodologies for IP-SoC integration at the next live webinar on Thursday, August 7th where Larry Vivolo will be presenting. There’s a brief registration process, and during the one hour webinar you can ask questions at the end to see how this methodology might help out on the verification quality of your present or next IC design.

    Share this post via:

    • Comments

    There are no comments yet.

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