English
Unique Approach to Verification of Complex SoC Designs
Arie Komarnitzky, Nadav Ben-Ezer, Eugene Lyubinsky - AAI (Avnet ASIC Israel Ltd.)
Tel Mond, Israel
Abstract :
AAI (Avnet ASIC Israel Ltd.) recently designed and implemented a group of SoC devices that connect several IPs from different vendors with customer specific IPs, around an industry standard AHB bus. Functional verification of these devices was achieved by a unique method of running mainly C written tests at system level on the device RTL model, in this way cutting design cycle times and avoiding using expensive verification methodologies.
Contrary to unavoidable parts of system connectivity, glue logic and vendor acceptance tests whose code entry is in RTL format, all application specific scenarios and parts of connectivity and acceptance tests were written in C or C++. These tests were translated to machine code using a compiler tool from the software development tools kit that is supplied by the CPU vendor.
This approach is assuming full logic verification of all IPs by their respective vendors, either by silicon validation platforms or by design, and therefore, limits IP verification at system level to a small set of acceptance tests, transferring the main verification effort to focus on connectivity testing and application specific scenarios provided by the end customer.
The verification examples used in this article are based on the following 0.18um designs - ARC based digitizer for notebook PCs, MIPS based wireless multimedia processor for HDTV and ARM based vision processor for automotive applications.
System overview
AHB based SoC devices usually consist of the following building blocks – AHB bus matrix, vendor IP on AHB, customer specific IP on AHB, ahb2apb Bridge, vendor peripherals on APB and customer configuration registers on APB:
AHB bus protocol is common in SoC designs and offers two types of ports – master ports that allow the device to initiate transactions on the bus and slave ports that respond to master’s requests.
IPs that connect to master ports like CPU or DMA request bus transactions, while IPs that connect to slave ports are on chip memories, external memory controller, high speed communication IP and engines for data acceleration or encryption that respond to bus requests.
Customer IP is typically an application specific mix of the above and can connect as AHB master or slave or both.
APB is used for lower performance peripherals, such as serial interfaces, GPIO, timers, watchdog and customer specific configuration and control registers.
Configurable AHB bus matrix and arbiter are available as IP from several vendors and used when arbitration is required. Simple AHB configurations with limited arbitration requirements like single master per system mode were implemented without need for such IP.
A mix of the above AHB components appears in the following example designs –
Design A - ARC based digitizer:
Design B - MIPS based wireless multimedia processor:
Design C - ARM based vision processor:
Simulation environment
SoC hardware is usually coded in verilog or VHDL hardware description language. Some IPs were represented as encrypted RTL, bus functional models or cycle accurate C based SWIFT model.
The system simulation environment is RTL test bench, that basically consists of SoC hardware, a wrapper to configure simulation modes, a set of checkers for correct interface behavior and test code that is preloaded into one of the SoC memories and fetched to the CPU from one of the AHB slave interfaces. Test pass or fail indication is written to predefined registers for regression purpose or output to chip interface for silicon test purposes.
Application C/C++ code is developed on a CPU software development platform and translated to machine code by CPU compiler tools. To debug an application SW fail in simulation, it is possible to display the original software code progress in parallel with the simulation run.
In design A, we used NC-verilog logic simulator, Metaware software development environment to generate ARC machine code from C++ and PDISP behavioral model to display op codes during simulation for debug purposes.
For IP verification purposes, the default SoC master (usually CPU) is sometimes replaced by a BFM (bus functional model) that translates an input test file comprised of a simple set of commands to initiation of AHB transactions.
IP verification
When a complex external IP comes in form of a generator, it often includes a testbench and a set of several standalone acceptance tests.
In addition to IP standalone verification, we use these tests and testbench to verify IP connectivity in system by replacing the CPU master with AHB master from the IP verification suite, connecting the external stub to IP pins and rerun of the acceptance tests.
We performed this verification of USB1.1 in design A by replacement of CPU with a vendor-supplied BFM and by connecting the USB host from the testbench to USB PHY:
We complemented vendor supplied patterns suite with a C++ test that verified USB entrance to suspend mode and system wakeup interrupt assertion upon resume, since this power saving modes are system dependant.
Another example of IP that was verified in this manner is the EBI memory controller in design B. Here we replaced MIPS CPU by vendor provided BFM and initiated read and write transactions to external SRAM and flash models:
Peripherals verification
APB peripherals integration is usually straightforward - a simple access to the peripheral with minimal external logic is enough to determine that the peripheral is alive.
For example, UART is verified using loop back technique where RX and TX are connected to each other in simulation environment. We added PSL direction and connectivity checkers to make sure that RX and TX actually connect to their respective pins:
// 115KHz UART clock:
always
#4347.8 uart_clk =~ uart_clk;
// UART loop back:
always @ (posedge uart_clk)
begin
urxd = UTXD;
end
assign URXD = urxd;
// loop back checkers for direction and connectivity:
// psl assert always (UTXD->next(URXD)) @ (posedge uart_clk);
// psl assert always (~UTXD->next(~URXD)) @ (posedge uart_clk);
// URXD checker that uart interrupt is
// turned off and urxd direction.
// Interrupt recognition is done by the CPU
wait(top_tb.xxx.user_ctrl_bus[11] === 1'b1)(turn 0n)
#5000;
force urxd =1'b1;
#1000;
force urxd =1'b0;
Rarely, peripherals access is complex and considerable effort is spent to write software driver in order to make sure that the theory of operation of this peripheral in the system is well defined.
For example, we wrote a 450-code lines long driver to access both CAN controllers in design C while the testbench hardware was a simple chain of CANA to CANB.
Application specific IP verification
Standalone verification of customer IP is typically done in separate test bench or by reduction of the full system simulation environment.
The first method was used in chip A to verify customer digitizer engine IP -
while the second was used in chip C to verify customer vision processor engine -
Customer IP is handled differently from vendor IP since it is usually only partially verified standalone and the bulk of tests that are needed to verify the IP are actually application code that runs at system level.
System verification
System level verification checks the connectivity of the system and correct system behavior under sample application code with special focus to assure correct customer IP behavior at system level.
To test the connectivity on every design we ran a test that accesses the whole memory map of the device.
Application code is usually written in C/C++ by our customers, as part of their SW development effort and subsets of it are readily available w/o additional effort for system verification purpose.
System verification quality depends on how similar this code is to the actual application.
The best verification in this mode is achieved in designs such as example A where the application scenario test that runs on RTL model is the full system code that is running on system validation board.
System level tests are running on the full SoC verification environment from early RTL assembly stages and all passing tests are added to the regression test suite.
All system tests pass and enter regression before the device RTL is frozen.
System verification is continued through all design stages until layout to assure correct implementation of the RTL.
After synthesis, we ran RTL2gates and gates2gates formal verification; static timing analysis and gate level simulations to assure correct netlist behavior. We compared the layout to netlist using LVS signoff tools.
The loop was closed when the same application code that was used to verify RTL passed on the sample chips that were tested on customer evaluation board.
Summary
AAI recently demonstrated on several SoC designs that functional verification of complex SoC can be achieved mainly by connectivity and application specific tests written in C or C++.
While expensive verification methodologies are necessary to assure full coverage during IP development, our approach to SoC verification targets assurance of system connectivity vs. system spec and correct system behavior under application software that will actually run on the device.
This approach is cost effective not only due to faster C code entry vs. RTL, but also because of heavy reuse of application code coming from system SW development for RTL verification purposes.
Tel Mond, Israel
Abstract :
AAI (Avnet ASIC Israel Ltd.) recently designed and implemented a group of SoC devices that connect several IPs from different vendors with customer specific IPs, around an industry standard AHB bus. Functional verification of these devices was achieved by a unique method of running mainly C written tests at system level on the device RTL model, in this way cutting design cycle times and avoiding using expensive verification methodologies.
Contrary to unavoidable parts of system connectivity, glue logic and vendor acceptance tests whose code entry is in RTL format, all application specific scenarios and parts of connectivity and acceptance tests were written in C or C++. These tests were translated to machine code using a compiler tool from the software development tools kit that is supplied by the CPU vendor.
This approach is assuming full logic verification of all IPs by their respective vendors, either by silicon validation platforms or by design, and therefore, limits IP verification at system level to a small set of acceptance tests, transferring the main verification effort to focus on connectivity testing and application specific scenarios provided by the end customer.
The verification examples used in this article are based on the following 0.18um designs - ARC based digitizer for notebook PCs, MIPS based wireless multimedia processor for HDTV and ARM based vision processor for automotive applications.
System overview
AHB based SoC devices usually consist of the following building blocks – AHB bus matrix, vendor IP on AHB, customer specific IP on AHB, ahb2apb Bridge, vendor peripherals on APB and customer configuration registers on APB:
AHB bus protocol is common in SoC designs and offers two types of ports – master ports that allow the device to initiate transactions on the bus and slave ports that respond to master’s requests.
IPs that connect to master ports like CPU or DMA request bus transactions, while IPs that connect to slave ports are on chip memories, external memory controller, high speed communication IP and engines for data acceleration or encryption that respond to bus requests.
Customer IP is typically an application specific mix of the above and can connect as AHB master or slave or both.
APB is used for lower performance peripherals, such as serial interfaces, GPIO, timers, watchdog and customer specific configuration and control registers.
Configurable AHB bus matrix and arbiter are available as IP from several vendors and used when arbitration is required. Simple AHB configurations with limited arbitration requirements like single master per system mode were implemented without need for such IP.
A mix of the above AHB components appears in the following example designs –
Design A - ARC based digitizer:
Design B - MIPS based wireless multimedia processor:
Design C - ARM based vision processor:
Simulation environment
SoC hardware is usually coded in verilog or VHDL hardware description language. Some IPs were represented as encrypted RTL, bus functional models or cycle accurate C based SWIFT model.
The system simulation environment is RTL test bench, that basically consists of SoC hardware, a wrapper to configure simulation modes, a set of checkers for correct interface behavior and test code that is preloaded into one of the SoC memories and fetched to the CPU from one of the AHB slave interfaces. Test pass or fail indication is written to predefined registers for regression purpose or output to chip interface for silicon test purposes.
Application C/C++ code is developed on a CPU software development platform and translated to machine code by CPU compiler tools. To debug an application SW fail in simulation, it is possible to display the original software code progress in parallel with the simulation run.
In design A, we used NC-verilog logic simulator, Metaware software development environment to generate ARC machine code from C++ and PDISP behavioral model to display op codes during simulation for debug purposes.
For IP verification purposes, the default SoC master (usually CPU) is sometimes replaced by a BFM (bus functional model) that translates an input test file comprised of a simple set of commands to initiation of AHB transactions.
IP verification
When a complex external IP comes in form of a generator, it often includes a testbench and a set of several standalone acceptance tests.
In addition to IP standalone verification, we use these tests and testbench to verify IP connectivity in system by replacing the CPU master with AHB master from the IP verification suite, connecting the external stub to IP pins and rerun of the acceptance tests.
We performed this verification of USB1.1 in design A by replacement of CPU with a vendor-supplied BFM and by connecting the USB host from the testbench to USB PHY:
We complemented vendor supplied patterns suite with a C++ test that verified USB entrance to suspend mode and system wakeup interrupt assertion upon resume, since this power saving modes are system dependant.
Another example of IP that was verified in this manner is the EBI memory controller in design B. Here we replaced MIPS CPU by vendor provided BFM and initiated read and write transactions to external SRAM and flash models:
Peripherals verification
APB peripherals integration is usually straightforward - a simple access to the peripheral with minimal external logic is enough to determine that the peripheral is alive.
For example, UART is verified using loop back technique where RX and TX are connected to each other in simulation environment. We added PSL direction and connectivity checkers to make sure that RX and TX actually connect to their respective pins:
// 115KHz UART clock:
always
#4347.8 uart_clk =~ uart_clk;
// UART loop back:
always @ (posedge uart_clk)
begin
urxd = UTXD;
end
assign URXD = urxd;
// loop back checkers for direction and connectivity:
// psl assert always (UTXD->next(URXD)) @ (posedge uart_clk);
// psl assert always (~UTXD->next(~URXD)) @ (posedge uart_clk);
// URXD checker that uart interrupt is
// turned off and urxd direction.
// Interrupt recognition is done by the CPU
wait(top_tb.xxx.user_ctrl_bus[11] === 1'b1)(turn 0n)
#5000;
force urxd =1'b1;
#1000;
force urxd =1'b0;
Rarely, peripherals access is complex and considerable effort is spent to write software driver in order to make sure that the theory of operation of this peripheral in the system is well defined.
For example, we wrote a 450-code lines long driver to access both CAN controllers in design C while the testbench hardware was a simple chain of CANA to CANB.
Application specific IP verification
Standalone verification of customer IP is typically done in separate test bench or by reduction of the full system simulation environment.
The first method was used in chip A to verify customer digitizer engine IP -
while the second was used in chip C to verify customer vision processor engine -
Customer IP is handled differently from vendor IP since it is usually only partially verified standalone and the bulk of tests that are needed to verify the IP are actually application code that runs at system level.
System verification
System level verification checks the connectivity of the system and correct system behavior under sample application code with special focus to assure correct customer IP behavior at system level.
To test the connectivity on every design we ran a test that accesses the whole memory map of the device.
Application code is usually written in C/C++ by our customers, as part of their SW development effort and subsets of it are readily available w/o additional effort for system verification purpose.
System verification quality depends on how similar this code is to the actual application.
The best verification in this mode is achieved in designs such as example A where the application scenario test that runs on RTL model is the full system code that is running on system validation board.
System level tests are running on the full SoC verification environment from early RTL assembly stages and all passing tests are added to the regression test suite.
All system tests pass and enter regression before the device RTL is frozen.
System verification is continued through all design stages until layout to assure correct implementation of the RTL.
After synthesis, we ran RTL2gates and gates2gates formal verification; static timing analysis and gate level simulations to assure correct netlist behavior. We compared the layout to netlist using LVS signoff tools.
The loop was closed when the same application code that was used to verify RTL passed on the sample chips that were tested on customer evaluation board.
Summary
AAI recently demonstrated on several SoC designs that functional verification of complex SoC can be achieved mainly by connectivity and application specific tests written in C or C++.
While expensive verification methodologies are necessary to assure full coverage during IP development, our approach to SoC verification targets assurance of system connectivity vs. system spec and correct system behavior under application software that will actually run on the device.
This approach is cost effective not only due to faster C code entry vs. RTL, but also because of heavy reuse of application code coming from system SW development for RTL verification purposes.
Related Articles
- Getting started in structured assembly in complex SoC designs
- Bridging the Gap between Pre-Silicon Verification and Post-Silicon Validation in Networking SoC designs
- Guidelines for complex SoC verification
- Managing Complex SoC verification using plan based verification techniques
- OCP VIP: A cost effective and robust qualification process for multimedia and telecom SoC designs
New Articles
Most Popular
|
E-mail This Article | 
|
|
Printer-Friendly Page |