800x100 static WP 3
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] => 3886
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 3886
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0
)

DAC: Calypto Insight Presentation

DAC: Calypto Insight Presentation
by Paul McLellan on 05-01-2013 at 5:39 pm

 DAC has several “Insight Presentations” on Wednesday June 5th. Bryan Bowyer from Calypto will be presenting from 2-4pm that day (don’t know where, the DAC website doesn’t have a room number specified yet). The topic is Reducing Design and Debug Time with Synthesizable TLM. TLM, of course, stands for Transactional Level Model.

For teams designing hardware accelerators (that is, hand-crafted RTL blocks implementing a function in hardware as opposed to software) on an SoC, debugging and integrating the new block is often the most difficult task. For new standards, such as H.265 and Ultra HD TV, companies have moved to synthesizable, transaction-level SystemC to reduce design and debug time.

This Insight Presentation describes an approach to reduce design and debug time of hardware accelerators by 50%.

The presentation starts with information about designing synthesizable TLMs in SystemC (not all SystemC is synthesizable). Of course, before synthesizing the SystemC it needs to be verified and assertions are one way to meet functional coverage goals. Debugging transactions versus RTL (which is much lower level) requires a different approach, which is the next topic covered.

So now you have your design in synthesizable TLMs in SystemC. So the next step is to actually synthesize this using high-level synthesis (HLS). The output from this process is RTL, which can then subsequently be input to traditional RTL synthesis to get to a netlist and so on down the usual RTL to GDSII pipe.

But is the RTL correct? Sequential Logical Equivalence Checking (SLEC) is the tool to use to prove that the RTL matches the original TLM input, in just the same way as (non-sequential) equivalence checking can be used to verify that the RTL and a netlist match during regular RTL synthesis.


This is thus a complete methodology for creating a design using TLM in System-C, verifying it, synthesizing it and formally checking the synthesis is correct. In most ways it is like writing a design in synthesizable RTL, verifying it, synthesizing it and formally verifying it. Except that it is another level up, with all the attendant increases in productivity, ease of making big (architectural) changes and so on. Along with bringing in pre-designed IP, it takes design up to the transactional level.

Details on the Insight Presentation are on the Calypto website hereand on the DAC webtsite here.

Share this post via:

Comments

There are no comments yet.

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