Unifying Diversity -- A classic example of Reusability

Gaurav Jalan, SiRF Technology India Pvt. Ltd.
Sandeep Ahuja, SiRF Technology India Pvt. Ltd.
Noida - India
    
Abstract:

Globalization is the talk of the industry for quite some time. It brings us to the idea that; we now feel it’s time to work together more efficiently and more effectively. Companies are busy integrating efforts across the globe maximizing the gains on the wide spread expertise available, whether it is the teams working in different locations or different domains. In pursuit of meeting this objective of integrating resources while first silicon success remains the ultimate goal, several approaches are tried and reusability has emerged as a more comprehensive solution. Different teams, different domains and different locations have with them diversified expertise and methodologies and integrating them is a challenge in itself. This paper, as the topic suggests, discusses one such example wherein the diverse skill sets and domain expertise have been integrated successfully to reap the benefits of reusability.

Introduction

Diversity – a prominent keyword in the topic is a common phenomenon when developing a system involves reusing what is already available. The degree of diversity directly impacts the degree of reusability of what is available. Diversity arises mainly because what is already available might not have been developed keeping the current requirements in mind. Licensing IP is common and the available IPs may not have been developed in the language one wants them to be in. For obvious reasons, project teams still try to integrate these diverse modules to have the system working leading to early design wins.

This paper touches one such experience of efforts to unify the diverse components available. Given here is a brief introduction to the Bluetooth technology and the system. Further the paper focuses on the buildup of a verification environment wherein the designs as well as the verification components received as IPs in different hardware languages, from different teams and third party have been successfully integrated to verify the system. The design under discussion has been verified in a full random verification environment reusing the design and verification components developed in 7 different languages and still working hand in hand to meet the desired objective. So is reusability sounding complex? Well it might, but the returns you get are worth the efforts.

Overview of Bluetooth Technology

In 10th Century, Harald Blåtand (Bluetooth), the King of Denmark managed to unite Denmark and part of Norway into a single kingdom while Nordic states were warring. He was killed in 986 AD during a battle with his son. Despite dying without unifying all the Nordic nations, his name has become synonymous with a standard aimed at unifying the worlds of telecommunications and computing. Bluetooth is an open standard specification for a radio frequency (RF)-based, short-range connectivity technology defined as cable replacement for personal area network (PAN) that promises to change the face of computing and wireless communication. It is not a single company technology but is shared by many members of the Bluetooth SIG (Special Interest Group).
Bluetooth operates within the Industrial, Scientific and Medical (ISM) band at 2.4 GHz. A typical Bluetooth system will require

• An RF portion for receiving and transmitting data.
• A baseband processor
• Memory
• Interface to the host device.

The system under discussion treats the baseband as an IP with its own unit level test bench. RF portion is also treated as a separate IP with modulator and demodulator units verified standalone. Finally, SPI serial messaging is used so as to control the parameters in RF from the baseband and this also has a unit level test bench. For verification at the unit level some of the test benches reuse the models used during architecture evaluation as reference golden models against which the RTL designs have been functionally proven. This paper talks about how these unit level test benches developed during various stages of the project were reused to do system level verification.

Bluetooth baseband

Bluetooth Baseband is an external IP Core which comes with its own propriety testbench. Both RTL and testbench are in VHDL. The main verification strategy of the vendor is to have directed test cases, followed by full s/w validation on FPGA boards.

SiRF verification methodology doesn’t rely just on the directed test cases. The verification team focuses to prove that the system meets Bluetooth specs, using RTL simulations while the FPGA validation process happens in parallel.

Now the challenge was how to re-use any of the IP vendor’s testbench, directed test-suite and still prove it works with the modem designed in-house? In addition, random verification was desired to have enough confidence on the Baseband and Modem data path with long data streams to uncover bit extraction issues.

Specman/e test bench were planned and defined as it would provide the necessary constraint-random constructs. A detailed test- plan was written and the focusing on four interfaces a) AHB (Host Processor) b) SPI (Communication channel with RF) c) Modulator data path d) Demodulator data path.

A Bluetooth packet structure was defined using Specman/e. This could be randomly generated on the fly within any test sequence. As part of the re-use methodology it was decided to reuse 2 VHDL blocks from IP vendor’s test bench –

a) Packet generator – This module has a propriety bus interface (implemented in VHDL record data type) by which high level packet fields could be assigned, it then does computations (like HEC, CRC etc), serialize it and send out the bits on per clock basis.

b) Packet monitor – This module reads in a serial packet stream, identify the header and payload bytes and give out this information on a proprietary VHDL record data type.
The test bench top is defined in Verilog. Instantiating the above VHDL modules in the test bench required Verilog wrappers which would convert the VHDL record data types into primitive Verilog data paths such that simulator would not complain during compilation.
Block diagram of the test bench used is shown in Figure 1.
 

Figure 1: Block diagram of the baseband testbench

For transmission data path checks, a random packet would be programmed in the Bluetooth memory (using AHB eVC); the Bluetooth core picks up this information, processes it and the serialized data is sent over TX_DATA line. This data is monitored, captured, dis-integrated into the same e structure and compared with the original random packet.

For reception data path checks, again a random packet would be generated, this high level data structure is provided to the packet generator, which processes the packet bit fields and sends out an ideal bit stream (zero-noise samples). Now this bit stream is passed through a sample converter which inverts certain samples on certain clock phases for each logical data bit. Bluetooth core extracts these samples and write out the payload buffers and other status flags on the memory. Another high level e packet data struct is made by reading back memory contents and comparing against the original packet.

Functional coverage for this block has been captured and analyzed in ‘e’.  SPI interface and AHB sequences are described in later sections.
 
Bluetooth RF

The Bluetooth RF section mainly consists of the modulator and the demodulator that is used for transmitting and receiving the signals on air respectively. The RTL for these designs have been developed in verilog and verified with a standalone ‘e’ test bench that has been reused as it is at the top level. The methodology used for verification involved developing a BFM in the e language for pumping data into the RTL. For functional correctness golden models have been used as reference. These golden models were written in C for architecture and performance evaluation. They have been reused with the e test benches to prove the functional equivalence of the RTL.

Block diagram of the modem test bench is shown in Figure 2. Following sub sections provide description of the modulator and the demodulator testbenches.
 
Click to enlarge

Figure 2: Block Diagram of modem testbench
Legend is applicable to all figures

Bluetooth modulator

The function of the Bluetooth modulator is to modulate the signals from the base band and transmit them through the antenna. The modulator RTL is a separate verilog module.
The test bench architecture consists of a Bluetooth random packet generator in ‘e’. Every time a packet is to be transmitted the generated packet is passed to the golden C model integrated with the ‘e’ test bench. This gives the reference data.
A BFM is developed in ‘e’ that pumps the packet into the RTL and a monitor collects the output. A scoreboard is developed in ‘e’ for comparison of the output on per clock basis with the reference output.

Bluetooth demodulator

The function of the Bluetooth demodulator is to demodulate the signals received at the antenna and pass them to the base band. The demodulator RTL is again a separate verilog module.

The test bench for unit level verification of demodulator is developed in ‘e’. The Bluetooth packet generated in ‘e’ is passed through the golden C models so as to modulate the packet, have it up converted, channelised and adding an interference channel to the actual channel. The BFM in the ‘e’ test bench picks the output from the C models and passes the same through the RTL as well as the golden C demodulator model so as to get the reference output. The monitor captures the output of the RTL and the scoreboard does the comparison of the RTL output with the output from the C demodulator model. The C models have been reused from the architecture evaluation platform and seamlessly integrated in the ‘e’ test bench such that the whole scheme is under control of the ‘e’ test bench which in turn facilitates all kinds of random Bluetooth packets. Functional cover points have been defined in ‘e’.

The software programmable register parameters for the modem are controlled using the AHB eVC and Verilog Bridge for AHB to APB interface.
 
SPI interface

To enable communication between the Bluetooth base band and the RF portions SPI interface has been used. The RTL for this interface is available in verilog. The unit level test bench to verify the same has been reused from the earlier projects where it was developed in SystemC following RMM guidelines for reusability. The test bench consists of a master to drive SPI transactions, a reference model that captured these transactions while RTL also is reacting to the same. On SPI write transactions both the RTL and reference models will update the registers and on SPI read both will respond. A response checker compares the output from the reference model and the RTL on SPI read. Functional cover points are defined using system verilog.

Host Interface (AHB eVC)

To be able to do read write through AHB interface AHB eVC was used. This is tightly integrated with vr_ad where high level register description can be written in e language structs. Both register level and bit level attributes can be easily defined. These are standard Cadence tools used in SiRF verification methodology.

SiRF has developed an in-house Register Description Tool (RDT). RDT allows designers to write the register descriptions in XLS format which can extract to generate vr_ad register structs.

We treated these tools as IPs to our objective and created our sequences using high level read and write calls with named references to registers and control structures in memory.

Click to enlarge

Figure 3: Block diagram of system level test bench build on reusable components
NOTE: Color coding is used to differentiate language used to develop a reusable component

A classic example

With the blocks as described above available along with their unit level test benches the next challenge was to have an integrated system working so as to maximize reuse of the available test bench components and have the integrated verification environment up and running. The unit level test benches being compliant to the reuse methodology helped in porting and integrating these components to the chip level so as to run system level test scenarios.

A script written in Perl gives control to the verification engineer to simulate the test scenarios in batch or GUI modes. The randomness in the environment is controlled from this script and the random seed is passed to all different languages from here so that any scenario is reproducible by the script. Apart from the randomness and simulation flow that the script controls it also checks for the various errors and gives enough information in the log files for the user to start debugging the failing cases. Running same tests with different seed values or running regressions for all test suites with different seeds are other features of this Perl script.

To integrate the system, a top level Verilog test bench is defined with the whole system instantiated. The verification environment and test scenarios are extended in ‘e’.
Figure 3 is self explanatory for the kind of methodology adopted to verify the system. Virtual sequence controls the flow and from there on the arrows show the flow of data across the components.

On the SPI data path the master from the unit level SPI test bench is disabled and the reference model along with the response checker are active. The SPI transactions are directly controlled from the virtual sequence through the base band block. The reference model and response checker still monitors and verifies the transactions on the SPI data path.

On the modulator data path, the BFM from the unit level test bench is disabled. The Bluetooth packet from the packet generator is given to base band that passes this packet to the modulator RTL. The monitor on the modulator test bench is active and reads the packet. Once the packet is complete the monitor calls the golden C modulator model for this collected packet. Having the output from the modulator RTL and C model the scoreboard does the comparison.

On the receive data path, the packet generator gives the packet to the demodulator test bench that takes it through a series of C models to have data similar to the one received on air. This data is passed through the demodulator RTL and golden reference model to get the outputs. The unit level scoreboard is active for intermediate comparison. Further this data is passed from the demodulator block to the base band where the whole Bluetooth packet is reconstructed and given to the packet monitor. The packet generator also passes the packet to the base band checker so as to have an end to end comparison on the Bluetooth data path.

AHB eVC is plugged to provide ARM transactions to the base band and is controlled by the virtual sequence. Most of the functional coverage points are reused at the system level and new points have been defined in ‘e’ language to ensure coverage. The SPI model uses the coverage points defined in SystemVerilog.

Randomness in the environment targets the different parameters in the Bluetooth packet structure while generating the packet. Apart from this the other parameters randomized include the configuration of the modem RTL as well as the C model. This is also controlled from the e test bench for the modem. Further more the C models that pick the Bluetooth packet and modify them so as to resemble the incoming data on air for the demodulator have parameters that are randomized so as to simulate more real life traffic scenarios.
This fully functional, self checking automated verification environment developed has different languages talking to each other in both list/array and file based mechanism. The latter is used to recreate a failing scenario mainly when thousands of packets are running in a simulation and one of them fails. To save on the debug time and effort, the same test bench is able to replay that one failing packet and reproduce the failing scenario for debugging. Due to reusability of different components at top-level verification which were developed at unit level of verification, enormous time has been saved in successfully accomplishing the system verification of a complex system.

Conclusion

So if reusability has tremendous potential then where is the issue? Think about an orchestra and you think about music. But what if it is poorly synchronized? Will it result in music or noise? Same happens here. Key to reusability is planning in advance and executing the same till packaging of the reusable components. No matter which language or methodology is used, a well packaged reusable component can seamlessly be plugged from unit to chip level or across chips. And as they say “too many cooks spoil the broth”. Well, not always! The above example proves it.

References

- Bluetooth2.0+EDR specifications
- Cadence documentation on e/Specman
- Cadence documentation on eRM
- Cadence documentation on AHB eVC
- Cadence Incisive documentation
- System C language reference manual version 2.1

About the authors

Sandeep Ahuja is the ASIC DV Team Lead at SiRF Technology Noida Centre.

Gaurav Jalan is a Sr. Verification Engineer in ASIC DV team at SiRF Technology Noida Centre.