Accelerated System DV Through Reuse

© 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 1

Accelerated System DV Through Reuse

Edward Arthur/John Cashman/Tim Ganley/Mark StricklandCisco Systems, Inc.


Agenda

Why Perform Multi-ASIC Simulation?

The Challenges of Multi-ASIC Simulation

The Socketsim Tool

The Testbench Methodology

Other System Simulation Considerations

Summary


The RealityCisco is a large geographically diverse companyLarge 10M+ gate ASICs are developed by different teamsEach team could (and probably will) have its own tool flow and methodologySystem simulation typically occurs late in development cycleThe chips need need to interoperate!


System Level Bugs – Connection Error

Each ASIC works on its own, but is not connected consistently with the ASIC specs at the higher level

ASICX

ASICY

Out[1]

Out[0]

In[0]

In[1]Problem


System-Level Bugs – Specification Mismatch

Each component matches its spec, but system does not work

translate input value A to

output value B

System Spec

ASICX

ASICY

System Block Diagram

translate A to 5 translate 6 to B

ASIC X Spec ASIC Y Spec

RTL TB= RTL TB=Sim OK Sim OK

Problem


ASIC DV Escape – Broad Input Behavior

Not all combinations of possible input space were tried in ASIC DV; specific behavior from source ASIC causes a problem

ASIC X Spec

A5 clocks

B12 clocks

CThis combination not tested in DV for Y and

reveals a bug

ASICX

ASICY

ASIC Y Spec

A1 to 200 clocks

B1 to 200 clocks

C

ABC

40,000 timing combinations


Commonly Discovered System Issues

FIFO Depth Assumptions – e.g. SPI4.2 LMax on/offPhysical layer interface interoperability – e.g. Flow ControlInternal header transport and signaling protocol interoperability – e.g. Priority bit interpretationReset SequencePerformanceValidation of end-to-end flow control


Agenda



The Socketsim Tool



Summary


System Simulation Challenges

Technical issues– System resources (memory) – Different high-level verification languages (HVLs)– Encrypted IP tied to specific simulators– Porting a design to a different simulator – Different versions of the same HVLs or simulators– Operating System dependencies– Work around language issues


The Problem

How do we rapidly get to multi-ASIC simulation?


Generic Testbench Structure

Drivers

Monitors

Scoreboard

DUT

Testbench Environment (ENV)

Running on a single system (SYS)

Scoreboard

ENV

DUTdriver

monitorBFM

SYS

drivermonitor

BFM


2-Chip Environment• Traditional 2-Chip Environment would take too much effort (i.e. combining testbenches, re-architecting ENVs)

Scoreboard

ENV

DUT

SYS

drivermonitor

BFMdriver

monitorBFM

Scoreboard

ENV

DUT1

SYS

DUT2driver

monitorBFM

drivermonitor

BFMdriver

monitorBFM

Scoreboard

ENV

DUT

SYS

drivermonitor

BFMdriver

monitorBFM


Ideal 2-Chip Environment

SOC

KET

Goal reuse as much a possible A socket accomplishes this goal!

• Maintain ENV and SYS of both simulations

Scoreboard

ENV1

DUT1driver

monitorBFM

SYS1

drivermonitor

BFM

Scoreboard

ENV2

DUT2driver

monitorBFM

SYS2

drivermonitor

BFM


Solution

Socketsim Tool – Chip-to-chip interfaces communicate over sockets

Testbench Methodology – Chip-level testbenches written for reuse at system-level


Agenda



The Socketsim Tool



Summary


What is the Socketsim tool?PLI application which monitors Verilog signals and propagates signal changes across sockets between environments

Provides virtual wires between two testbenches running on different systemsEach environment syncs up each “heartbeat”

VerilogVPI – PLIMPICH

MPICHVPI – PLIVerilog

socket


Socketsim tool

Similar to Avery Design SimCluster tool http://www.avery-design.com

~2,800 lines of C/C++ codeMPI underneath (MPICH 1.2.5.2)VCS (V7.2R18+) and NC (5.3+) supportedLinux and Solaris supportedNo additional license required ☺

VerilogVPI – PLIMPICH

MPICHVPI – PLIVerilog

socket


Socketsim PLISender

Register callback on changes of inputs to socketSave all changes up to delta cycle

ReceiverReplay changes on outputs of socket applying at each time slice

Implied wire delay over socket equal to delta cycle

SENDER:@heartbeatsend buffer

to remote host

RECEIVER:Blocks waiting

for buffer,playbackchanges

SENDER:@signal changesave value/time

to buffer


Socketsim Verilog instances – SPI4.2

// “Left ASIC” sidesocketsim #(.IN_WIDTH(20),

.OUT_WIDTH(20))socket(.ins({tb_spi_tx_data[15:0],

tb_spi_tx_ctl,tb_spi_rx_stat[1:0],tx_sync}),

.outs({tb_spi_rx_data[15:0],tb_spi_rx_ctl, tb_spi_tx_stat[1:0], rx_sync}));

// “Right ASIC” sidesocketsim #(.OUT_WIDTH(20),

.IN_WIDTH(20))

socket(.outs({NpRxData[15:0],NpRxControl,NpTstat[1:0],rx_sync}),

.ins({NpTxData[15:0],NpTxControl, NpRstat[1:0],tx_sync}));


More Socketsim FeaturesBidirectionals supported

Heartbeat user configurable at runtime

Multiple point-to-point connections allowedChipA has interfaces to ChipB and ChipC

Compression supported for wiiiiiiiiiiiiiide buses

Peers communicate directly

HVL↔HVL communicationUse Verilog tasks as wrappers for signals which cross the socket


Agenda



The Socketsim Tool



Summary


Testbench MethodologyBorrowed from Cadence eRM methodologyDecouple BFM’s driver from scoreboard

BFM’s drivers should not put objects onto scoreboard

Monitors watch wires in both directions and forward information to scoreboard

SOC

KET

Scoreboard

ENV

DUTdriver

monitorBFM

SYS

drivermonitor

BFM

Scoreboard

ENV

DUTdriver

monitorBFM

SYS

drivermonitor

BFM

Put these local drivers in PASSIVE mode


Mechanism for synchronizing test flow

Testflow synchronization – sync up the various phases of each environment with sideband signal

Phases will have different durations

Reset()

Init()

Main()

Post()

End()

ENV1

Reset()

Init()

Main()

Post()

End()

ENV2

End Simulation

Start Simulation

Sock

et


Other Sideband SignalingMessaging Semaphore – besides the data/control signals that pass across the socket, pass sideband signals during test for configuration, special event or sequence (i.e. backpressure event, register sequence)

Backpressureevent

cfginformation

SOC

KET

Scoreboard

ENV

DUTdriver

monitorBFM

SYS

drivermonitor

BFM

Scoreboard

ENV

DUTdriver

monitorBFM

SYS

drivermonitor

BFM

Sequence driver

Sequence driver


Passing Configuration via FileFile I/O - for on-the-fly configuration synchronization

Both ENVs could read common fileOne ENV could write cfg, the other read it

Write_ascii_struct() Read_ascii_struct()

Scoreboard

ENV

DUTdriver

monitorBFM

SYS

drivermonitor

BFM

Scoreboard

ENV

DUTdriver

monitorBFM

SYS

drivermonitor

BFM

Sequence driver

Sequence driver

SOC

KET


Testbench Methodology Summary

Recommended testbench methodology for multi-ASIC system simulation:

Each BFM’s driver should not put objects onto scoreboard Each BFM’s driver can be turned off (passive mode)Monitors will simply place data objects on the scoreboardScoreboard uses data objects from monitors, system state and transfer function to generate expected results


Agenda



The Socketsim Tool



Summary


Performance

All ENVs slow down to slowest ENV + overhead10%-40% slowdown seen

– Each environment must sync up every heartbeat which pegs performance to the slowest environment– Additional overhead comes from message passing over network


Performance AnalysisParameters which will affect performance

Multiprocessor serverCache thrashingMemory contentionCPUs of same speedHeartbeat durationVarying amount work/heartbeatHow many socketsSocket widthStartup time (compile/load/init/…)

More work needs to be done – we’ve only skimmed the surface


Agenda



The Socketsim Tool



Summary


Summary

The recommended testbench methodology (CadenceeRM) enables efficient chip-level testbench reuse at the system-level

Socketsim solves the problem of connecting chip-level environments to form system-level environments

- certain environments can only be simulated this way


Related Documentation

http://www.avery-design.com (SimCluster tool)

http://web.archive.org/web/20060429011636/http://www.avery-design.com/web/avery_hdlcon02.pdf (Paper describing socket simulation techniques)

Accelerated System DV Through Reuse

Technology

Transcript of Accelerated System DV Through Reuse