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
)

A Self-Contained Software-Driven Prototype

A Self-Contained Software-Driven Prototype
by Bernard Murphy on 04-26-2017 at 7:00 am

You’re building an IP, subsystem or SoC and you want to use a prototype together with a software testbench to drive extensive validation testing. I’m not talking here about the software running on the IP/SoC processor(s); the testbench should wrap around the whole DUT. This is a very common requirement. The standard approach to addressing this need is to hook the prototype up to a host PC, run your testbench there and connect to the prototype through one of the standard interfaces.

But that’s not necessarily ideal. Your real design probably has all kinds of communication interfaces to the rest of the system to which it will ultimately connect, yet you’re constrained to pushing all that testbench activity through a relatively narrow pipe between the prototype and the PC. Of course that can be done, but wouldn’t it be nice to have wider and more realistic channels to connect the testbench to the DUT? That’s what Aldec offers through their HES-US-440 prototyping board, hosting both a Xilinx UltraScale FPGA to prototype the DUT and a Xilinx Zynq FPGA to act as the testbench host.

The UltraScale and Zynq devices are connected through 160 board traces (which can be used as 80 LVDS pairs), plus four high-speed GTX serial links. And of course there are plenty of standard interfaces (PCIe, USB, Gigabit Ethernet, ..) on both FPGAs. These can also be looped-back between the devices if needed. There are also FPGA mezzanine card (FMC) interfaces on both FPGAs – these can too be connected in loop-back. So yeah, you can model, in hardware, very wide, fast, direct and protocol-based interfaces between your software-driven testbench and your DUT.


Aldec cite probably a very common case for using this capability. You’re building an IP with an AXI interface and you particularly want to test that interface (probably with other standard interfaces also connecting to the IP), through your software testbench, to validate correct operation of your prototyped design. The Xilinx Vivado design software does all the heavy lifting for you by building the AXI Chip2Chip bridge between the two FPGAs (providing both master and slave interfaces). The Xilinx SDK handles the software interfaces to AXI on each side so you’re just left with the software you would have written anyway – for the processor in your IP and for the testbench. You can also skip the AXI port on the Zynq side and use a pre-configured Aldec setup for the Zynq, running Linux.

I can imagine all kinds of organizations who might find this solution appealing. Small shops building IP really need to prove out their designs before committing to testchips. This board could provide a very cost-effective way to do that (and to help build and test the drivers they’ll need to supply with the IP). Groups in larger organizations may also be interested if they want to do intensive testing but have limited access to approved prototyping platforms thanks to demand from multiple other groups. Teams building designs targeted to FPGAs may want to start prototyping quickly without the overhead of building test boards. Heck, I think I want one. It’s feels like a Raspberry Pi for serious applications requiring hardware reprogrammability and high-performance connectivity (though I’m sure a little pricier than the Raspberry Pi :cool:).

I should also note that Aldec also suggests this board as a solution for high-performance computing (HPC) applications. Here it would be used not as a prototype but as the production version of an accelerator. Perhaps Amazon, Google and Facebook might not need this approach, but this is an interesting idea for the rest of us. If you want to build your own accelerator for search, recognition, analytics, fintech, whatever you want to accelerate, this could be an appealing place to start. If it turns into a billion-dollar business you can always convert it to an ASIC, but until that happy day you can have a working solution up, running and proving itself in no time.

You can learn more HERE.

Share this post via:

Comments

There are no comments yet.

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