FPGA-based prototyping for different aims

Prototyping is not a push-button process and requires a great deal of care and consideration at its different stages. As well as explaining the effort and expertise during the next few chapters, we should also give some incentive as to why we should (or maybe should not) perform prototyping during our SoC projects.

Prototyping is not a push-button process and requires a great deal of care and consideration at its different stages. As well as explaining the effort and expertise during the next few chapters, we should also give some incentive as to why we should (or maybe should not) perform prototyping during our SoC projects.

A structured understanding of these project aims and why we should prototype will help us to decide if FPGA-based prototyping is going to benefit our next project.

Let us, therefore, explore each of the aims in Table 1 and how FPGA-based prototyping can help. In many cases we shall also give examples from the real world and the authors wish to thank in advance those who have offered their own experiences as guides to others in this effort.

Table 1: General aims and reasons to use FPGA-based prototypes

High performance and accuracy

Only FPGA-based prototyping provides both the speed and accuracy necessary to properly test many aspects of the design, as we shall describe. 

We put this reason at the top of the list because it is the most likely underlying reason of all for a team to be prototyping, despite the many different given deliverable aims of the project. For example, the team may aim to validate some of the SoC’s embedded software and see how it runs at speed on real hardware, but the underlying reason to use a prototype is for both high performance and accuracy. We FPGA-Based Prototyping Methodology Manual 27 could validate the software at even higher performance on a virtual system, but we lose the accuracy which comes from employing the real RTL. 

Real-time dataflow

Part of the reason that verifying an SoC is hard is because its state depends upon many variables, including its previous state, the sequence of inputs and the wider system effects (and possible feedback) of the SoC outputs. Running the SoC design at real-time speed connected into the rest of the system allows us to see the immediate effect of real-time conditions, inputs and system feedback as they change. 

Figure 14: Block diagram of HDMI prototype

A very good example of this is real-time dataflow in the HDMI™ prototype performed by the Synopsys IP group in Porto, Portugal. Here a high-definition (HD) media data stream was routed through a prototype of a processing core and out to an HD display, as show in the block diagram in Figure 14. We shall learn more about this design in chapter 10 when we consider IP usage in prototyping, but for the moment, notice that across the bottom of the diagram there is audio and HD video dataflow in real-time from the receiver (from an external source) through the prototype and out to a real-time HDMI PHY connection to an external monitor. By using a pre-silicon prototype, we can immediately see and hear the effect of different HD data upon our design, and vice versa. Only FPGA-based prototyping allows this real-time dataflow, giving great benefits not only to such multimedia applications but to many other applications where real-time response to input dataflow is required. 

Hardware-software integration

In the above example, readers may have noticed that there is a small MicroBlaze™ CPU in the prototype along with peripherals and memories, so all the familiar blocks of an SoC are present. In this design the software running in the CPU is used mostly to load and control the AV processing, however, in many SoC designs it is the software that requires most of the design effort. 

Given that software has already come to dominate SoC development effort, it is increasingly common that the software effort is on the critical path of the project schedule. It is software development and validation that governs the actual completion date when the SoC can usefully reach volume production. In that case, what can system teams do to increase the productivity of software development and validation?

To answer this question, we need to see where software teams spend their time, which we will explore in the next sections.

Modeling an SoC for software development

Software is complex and hard to make perfect. We are all familiar with the software upgrades, service packs and bug fixes in our normal day-to-day use of computers. However, in the case of software embedded in an SoC, this perpetual fine tuning of software is less easily achieved. On the plus side, the system with which the embedded software interacts, its intended use modes and the environmental situation are all usually easier to determine than for more general-purpose computer software. Furthermore, embedded software for simpler systems can be kept simple itself and so easier to fully validate. For example, an SoC controlling a vehicle sub- system or an electronic toy can be fully tested more easily than a smartphone which is running many apps and processes on a real-time operating system (RTOS). 

If we look more closely at the software running in such a smartphone, for example the Android™ software shown in Figure 15, then we see a multi-layered arrangement, called a software stack. This diagram is based on an original by software designer Frank Abelson in his book “Unlocking Android.” 

Taking a look at the stack, we should realize that the lowest levels i.e., those closest to the hardware, are dominated by the need to map the software onto the SoC hardware. This requires absolute knowledge of the hardware to an address and clock-cycle level of accuracy. Designers of the lowest level of a software stack, often calling themselves platform engineers, have the task of describing the hardware in terms that the higher levels of the stack can recognize and reuse. This description is called a BSP (board support package) by some RTOS vendors and is also analogous to the BIOS (basic input/output system) layer in our day-to-day PCs. 

Figure 15: The Android™ stack (based on source: “Understanding Android”)

The next layer up from the bottom of the stack contains the kernel of the RTOS and the necessary drivers to interface the described hardware with the higher level software. In these lowest levels of the stack, platform engineers and driver developers will need to validate their code on either the real SoC or a fully accurate model of the SoC. Software developers at this level need complete visibility of the behavior of their software at every clock cycle. 

At the other extreme for software developers, at the top layer of the stack, we find the user space which may be running multiple applications concurrently. In the smartphone example these could be a contact manager, a video display, an internet browser and of course, the phone sub-system that actually makes calls. Each of these applications does not have direct access to SoC hardware and is actually somewhat divorced from any consideration of the hardware. The applications rely on software running on lower levels of the stack to communicate with the SoC hardware and the rest of the world on its behalf. 

We can generalize that, at each layer of the stack, a software developer only needs a model with enough accuracy to fool his own code into thinking it is running in the target SoC. More accuracy than necessary will only result in the model running more slowly on the simulator. In effect, SoC modeling at any level requires us to represent the hardware and the stack up to the layer just below the current level to be validated and optimally, we should work with just enough accuracy to allow maximum performance. 

For example, application developers at the top of the stack can test their code on the real SoC or on a model. In this case the model need only be accurate enough to fool the application into thinking that it is running on the real SoC, i.e., it does not need cycle accuracy or fine-grain visibility of the hardware. However, speed is important because multiple applications will be running concurrently and interfacing with real-world data in many cases. 

This approach of the model having “just enough accuracy” for the software layer gives rise to a number of different modeling environments being used by different software developers at different times during an SoC project. It is possible to use transaction-level simulations, modeled in languages such as SystemC™, to create a simulator model which runs with low accuracy but at high enough speed to run many applications together. If handling of real-time, real-world data is not important then we might be better considering such a virtual prototyping approach. 

However, FPGA-based prototyping becomes most useful when the whole software stack must run together or when real-world data must be processed. 

Example prototype usage for software validation

Only FPGA-based prototyping breaks the inverse relationship between accuracy and performance inherent in modeling methodologies. By using FPGAs we can achieve speeds up to real-time and yet still be modeling at the full RTL cycle accuracy. This enables the same prototype to be used not only for the accurate models required by low-level software validation but also for the high-speed models needed by the high-level application developers. Indeed, the whole SoC software stack can be modeled on a single FPGA-based prototype. A very good example of this software validation using FPGAs is seen in a project performed by Scott Constable and his team at Freescale ® Semiconductor’s Cellular Products Group in Austin, Texas.

Freescale was very interested in accelerating SoC development because short product life cycles of the cellular market demand that products get to market quickly not only to beat the competition, but also to avoid quickly becoming obsolete. Analyzing the biggest time sinks in its flow, Freescale decided that the greatest benefit would be achieved by accelerating their cellular 3G protocol testing. If this testing could be performed pre-silicon, then Freescale would save considerable months in a project schedule. When compared to a product lifetime that is only one or two years this is very significant indeed. 

Protocol testing is a complex process that even at high real time speeds require a day to complete. Using RTL simulation would take years and running on a faster emulator would still have taken weeks, neither of which was a practical solution. FPGAs were chosen because that was the only way to achieve the necessary clock speed to complete the testing in a timely manner. 

Protocol testing requires the development of various software aspects of the product including hardware drivers, operating system, and protocol stack code. While the main goal was protocol testing, as mentioned, by using FPGAs all of these software developments would be accomplished pre-silicon and greatly accelerate various end product schedules. 

Freescale prototyped a multichip system that included a dual core MXC2 baseband processor plus the digital portion of an RF transceiver chip. The baseband processor included a Freescale StarCore ® DSP core for modem processing and an ARM926™ core for user application processing, plus more than 60 peripherals. 

A Synopsys HAPS ® -54 prototype board was used to implement the prototype, as show in Figure 16. The baseband processor was more than five million ASIC gates and Scott’s team used Synopsys Certify ® tools to partition this into three of the Xilinx ® Virtex ® -5 FPGAs on the board while the digital RF design was placed in the fourth FPGA. Freescale decided not to prototype the analog section but instead delivered cellular network data in digital form directly from an Anritsu™ protocol test box. 

Older cores use some design techniques that are very effective in an ASIC, but they are not very FPGA friendly. In addition, some of the RTL was generated automatically from system-level design code which can also be fairly unfriendly to FPGAs owing to over-complicated clock networks. Therefore, some modifications had to be made to the RTL to make it more FPGA compatible but the rewards were significant. 

Figure 16: The Freescale ® SoC design partitioned into HAPS ® -54 board

Besides accelerating protocol testing, by the time Freescale engineers received first silicon they were able to:

• Release debugger software with no major revisions after silicon.

• Complete driver software.

• Boot up the SoC to the OS software prompt.

• Achieve modem camp and registration.

The Freescale team was able to reach the milestone of making a cellular phone call through the system only one month after receipt of first silicon, accelerating the product schedule by over six months.

To answer our question about what FPGA-based prototyping can do for us, let’s hear in Scott Constable’s own words:

“In addition to our stated goals of protocol testing, our FPGA system

prototype delivered project schedule acceleration in many other areas,

proving its worth many times over. And perhaps most important was the

immeasurable human benefit of getting engineers involved earlier in the

project schedule, and having all teams from design to software to

validation to applications very familiar with the product six months before

silicon even arrived. The impact of this accelerated product expertise is

hard to measure on a Gantt chart, but may be the most beneficial.

“In light of these accomplishments using an FPGA prototype solution to

accelerate ASIC schedules is a “no-brainer.” We have since spread this

methodology into the Freescale Network and Microcontroller Groups and

also use prototypes for new IP validation, driver development, debugger

development, and customer demos.”

This example shows how FPGA-based prototyping can be a valuable addition to the software team’s toolbox and brings significant return on investment in terms of product quality and project timescales.