Breaking The Three Laws

 

Comparison of Prototyping bridge vs. Hybrid Prototypes

DesignWare Hybrid IP Prototyping Kits

This week Synopsys’ announced the availability of the DesignWare Hybrid IP Prototyping Kits: http://www.synopsys.com/IP/ip-accelerated/Pages/hybrid-ip-prototyping-kits.aspx The Synopsys DesignWare® Hybrid IP Prototyping Kits pre-integrate a Virtualizer™ Development Kit (VDK) and a DesignWare IP Prototyping Kit to accelerate IP prototyping, software development and integration of DesignWare IP in 64-bit ARM®-based designs. Hybrid IP Prototyping Kits enable designers to accelerate hardware/software integration and full system validation, thus reducing the overall product design cycle. The included Linaro® Linux® software stack, reference drivers, and pre-verified DesignWare IP reference design allow users to start implementing and validating IP in an SoC context in minutes.

Now I’ve spoken about Hybrid Prototyping a number of times, the most recent was Valuable Software Driven Validation where I discussed how users are deploying Hybrid Prototyping to accelerate IP validation. The DesignWare Hybrid IP Prototyping Kit of course comes with validated IP, Synopsys does that work, but many IP’s required customized drivers which are application specific. It’s this software development, within the context of a CPU subsystem, which the kit focuses on accelerating.

I was asked a question this week which I think is important to clarify, what is the difference between a prototyping bridge and Hybrid Prototyping. A prototyping bridge is a native PCIe host to prototype physical connection with standard interfaces such as AMBA AXI to connect to the user design under test in the hardware. This is what I have previously called a memory mapped interface. Synopsys provides such a prototyping bridge example, you can find it in SolvNet buried in the HAPS documentation

HAPS Prototyping bridge example on SolvNet

A prototyping bridge like this is good for test cases where you want to stream data to a design under test on the prototyping hardware. You will need to write a customized PCIe driver, which is memory mapped on the host workstation, which you build on top of to create the custom application test code.

HAPS PCIe Prototyping Bridge example

Within the small context of this need the prototyping bridge works well. However its usefulness reduces very quickly due to the following limited capabilities

  • Only provides  1x AXI master and 1x AXI slave interface, what happens if you need more?
  • No support for mixing with other AMBA protocols or sideband signals (interrupt, GPIO, etc.)
  • No control over the AMBA protocol parameters (you get what you get through the PCIe interface)
  • Manually effort to instantiate into design (Might require changes in golden RTL to fix interfaces offered)

I’m not saying there is not a place for this type of prototyping bridge, our own DesignWare USB IP team use such a bridge to enable the standard, off the shelf PCIe based USB host drivers to be tested against the IP. It’s a standalone environment and as the driver is PCIe based it’s not directly reusable when the IP is integrated into a  the end ARM/ARC/MIPS/Tensilica/Other SoC.

Enter Hybrid Prototyping from Synopsys. Hybrid has none of the restrictions as noted above with a prototyping bridge. You can insert multiple transactors into a design, configure them to your direct need in an automated fashion. With Hybrid the software that you are running is the same as the end SoC software, as in in the example of an ARM-based SoC you are executing ARM code.

Hybrid Prototyping design with CPU subsystem and RTL design

The key to Hybrid Prototyping is the transactors. A transactor translate between the Virtual SystemC abstract level across to cycle accurate protocol specific pin level interface. Synopsys delivers off the shelf transactors for the AMBA protocols and more. There are two sides of a transactors, the software side and the RTL hardware side.

HAPS high level view of Hybrid Prototyping transactors

On the software side, the interface which is exposed to the user is the abstracted SystemC level interface, read/write etc. This is what software engineers understand, the transactor looks just like the software that they are used to coding against. All the nitty gritty engineering of the transactors is done by Synopsys so the user can become immediately productive.

HAPS Transactor, Software side

On the hardware side, the interface is RTL, again all the deep protocol stuff is done by Synopsys so the engineers instantiate the transactor into their design just like any other AMBA based design block.

HAPS Transactor Hardware side

The HAPS ProtoCompiler flow automatically understands the transactors and seamlessly connects up the physical interface, UMRBus, with no user intervention.

The Virtualizer environment delivers amazing software debug as well, here is a view of the software debug capabilities which the DesignWare Hybrid IP Prototyping kit delivers.

VPExplorer, amazing software debug

So in a comparison of a prototyping bridge and Hybrid Prototyping, Hybrid wins hands down.

  • Predefined environment, fully supported, configurable, automatic hook-up in user design
  • Runs SoC specific software which can be directly run on the final product
  • Multiple protocols, multiple instances per design
  • Amazing software debug, especially for multi-core

In most cases a Hybrid Prototyping environment can replace the use of a prototyping bridge because it can also be driven via a C/C++ or native TCL interface, just like what you would do with the prototyping bridge. The additional advantage is that the same environment can easily be expanded to a full Hybrid Prototype with Virtual Prototype connection without having to change the design.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn