Mapping Out The Value Of TLM Modeling

I have written about the value of system-level design and moving up to next level of abstraction numerous times. This fall one of the most interesting steps of progress towards effective system-level design and emphasis on the importance of embedded software has been made by the two big FPGA vendors Altera and Xilinx. Both vendors have announced devices combining programmable logic of up to several million ASIC gate equivalents with hard implementations of ARM Cortex-A9 based multiprocessor sub-systems. Both vendors have also announced virtual prototypes for their devices. The Xilinx Zynq platform encourages extensibility with user logic at the TLM level by offering an “Extensible Virtual Platform”, which means design teams can create a model for software development even before the RTL of the user defined logic is developed, either by hand or using high-level synthesis.

How do we quantify the value of extending a platform like Zynq at the transaction-level? Well, let me take a shot at it. Let’s consider the following design flow:

The green boxes represent IP being reused, the grey boxes are development processes like “High-Level Synthesis” or “RTL Simulation”. The orange boxes represent development results like transaction-level models (TLM) or RTL on the hardware side and Firmware or Real Time Operating Systems (RTOS) on the software side.

The flow starts on the left hand side with functional IP and system modeling prior to making partitioning decisions between hardware and software. Once that partitioning has been made, software development progresses in the top half from starting from C coding and software IP through compile, debug, linking and lifecycle management. The result is a software stack of applications mapped on middleware which runs on RTOSs together with drivers and the low-level firmware.

In the bottom half you can see hardware development progressing from TLMs with high-level synthesis or manual RTL development to RTL verification. The verified RTL is implemented into silicon, which is eventually is integrated into boards and the final hardware product. Not that dissimilar to the software stack, hardware is hierarchical containing hardware IP and sub-systems creating complex systems on chip to be integrated in boards and products.

In the center you can see the integration of hardware and software. Virtual prototyping allows the integration of software on TLM abstracted hardware early on. Once RTL is available, RTL simulation, albeit slow, allows low level software connections. Once RTL gains stability, hardware acceleration and emulation allow faster execution of software in the hardware context, and when RTL is stable FPGA based prototyping offers even higher execution speed. The different techniques are deliberately illustrated as overlapping and connected – they are used in parallel and more and more also in hybrid use modes.

The illustration above shows a standard ASIC design flow, and for the Xilinx Zynq device it would not look that different, except that users find a pre-defined multicore subsystem. They can add their differentiating capabilities in hardware by developing RTL for the programmable fabric, which depending on the device type can hold between 430K and 3.5M ASIC Gate equivalents.

So why is TLM extensibility so crucial? Let’s look at the development effort necessary to extend a design. In a previously published article called “Improving Software Development and Verification Productivity Using Intellectual Property (IP) Based System Prototyping” I did use the averaged data of 12 projects analyzed by IBS. Both software and hardware development was measured in length and effort.

The next graph shows the resulting map of steps measured by IBS:

The development steps include application, utility and OS software development, as well as development of specification and RTL followed by verification and implementation. This map can be re-drawn to show both effort and elapsed time as shown below.

On the vertical axis the height of the boxes indicated the percentage of overall development effort for hardware and software. The combined software tasks account in average for about 45% of the project effort. On the horizontal axis I charted the elapsed time per development step as percentage of the time it takes to get from RTL development to tapeout.

Above chart shows that waiting with the integration until RTL is available and can be mapped into the FPGA fabric of Zynq, significantly delays the time at which software can be integrated. RTL development can account for several months in schedule at significant effort especially for verification.

Luckily the Zynq virtual platform is extensible at the TLM level. This allows hardware software integration and software development well before RTL is coded and verified. Voila, you can get more information about the extensible virtual platform for Zynq here.