WP_Term Object
(
    [term_id] => 45
    [name] => Aldec
    [slug] => aldec
    [term_group] => 0
    [term_taxonomy_id] => 45
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 102
    [filter] => raw
    [cat_ID] => 45
    [category_count] => 102
    [category_description] => 
    [cat_name] => Aldec
    [category_nicename] => aldec
    [category_parent] => 157
)
            
WIKI Multi FPGA Design Partitioning 800x100
WP_Term Object
(
    [term_id] => 45
    [name] => Aldec
    [slug] => aldec
    [term_group] => 0
    [term_taxonomy_id] => 45
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 102
    [filter] => raw
    [cat_ID] => 45
    [category_count] => 102
    [category_description] => 
    [cat_name] => Aldec
    [category_nicename] => aldec
    [category_parent] => 157
)

Webinar alert – Taking UVM to the FPGA bank

Webinar alert – Taking UVM to the FPGA bank
by Don Dingee on 04-08-2016 at 4:00 pm

UVM has become a preferred environment for functional verification. Fundamentally, it is a host based software simulation. Is there a way to capture the benefits of UVM with hardware acceleration on an FPGA-based prototyping system? In an upcoming webinar, Doulos CTO John Aynsley answers this with a resounding yes.

Random constraint solvers are a big part of UVM, and a perfect job for a simulator. At some point, UVM testbenches get down to an executable model of the logic. While it is certainly possible to simulate that as well, we know simulation is far slower than hardware execution of the same logic in an FPGA-based prototyping platform or a hardware emulator. In fact, the UVM environment may be too efficient, creating a volume of test vectors that may overwhelm a software simulator and blow up test execution times.

 It’s a known problem, and there are many ways to solve it with transactors facilitating communication from the host simulation to a hardware platform. Aynsley is partnering with Aldec to show how the combination of the Aldec HES-DVM platform and the Doulos Easier UVM Code Generator can deliver a faster solution. We’ve seen in previous Aldec posts they support SCE-MI and the SV-Connect interface for SystemVerilog DPI calls from a host to the HES-DVM.

That creates the possibility of acceleration for UVM – how exactly should this be accomplished? It would be great if there were automagic, but this is a case where judicious designer assistance comes into play. Conceptually, one could partition UVM code into two parts: a proxy that stays on the host system, and a synthesizable piece that can be placed into the FPGA-based system. The proxy is untimed, while the hardware-executable portion carries the timing dependencies.

The payoff in this approach is letting UVM do its job, which is generating a comprehensive set of test vectors for maximum coverage executable in a reasonable amount of time with acceleration.

In the April 13[SUP]th[/SUP] webinar (with two sessions for preferred time zones), Aynsley and Aldec engineer Chris Szczur will take on the question of UVM partitioning for hardware acceleration. They will show how SCE-MI is used, and more importantly give an example of the coding, compilation, and execution with a UVM simulation running in conjunction with Aldec’s FPGA-based accelerator platform.

Registration for this webinar is free on the Doulos site:

Acceleration-Ready UVM

For those interested in a bit of pre-event homework, the Doulos Easier UVM Coding Guidelines include a section on split transactors, as well as a complete list of best practices in UVM. More on the Aldec HES-DVM platform is also available online.

Share this post via:

Comments

There are no comments yet.

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