Arthur q207

Accelerated System DV
Through Reuse

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

Presentation_ID © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 1

Agenda

Why Perform Multi-ASIC Simulation?
The Challenges of Multi-ASIC Simulation
The Socketsim Tool
The Testbench Methodology
Other System Simulation Considerations
Summary


The Reality
Cisco is a large geographically diverse company
Large 10M+ gate ASICs are developed by different teams
Each team could (and probably will) have its own tool flow and
methodology
System simulation typically occurs late in development cycle
The 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

ASIC ASIC
X Y

Out[1] In[0] Problem
Out[0] In[1]


System-Level Bugs – Specification Mismatch

Each component matches its spec, but system does not
work
System Spec ASIC X Spec ASIC Y Spec

translate input
value A to
translate A to 5 translate 6 to B Problem
output value B

System Block Diagram RTL = TB RTL = TB
ASIC ASIC
X Y Sim OK Sim OK


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 ASIC
X A Y
B
C

ASIC X Spec ASIC Y Spec

A A
5 clocks 1 to 200 clocks
B B 40,000 timing
12 clocks 1 to 200 clocks combinations
This combination not C C
tested in DV for Y and
reveals a bug


Commonly Discovered System Issues

FIFO Depth Assumptions – e.g. SPI4.2 LMax on/off
Physical layer interface interoperability – e.g. Flow
Control
Internal header transport and signaling protocol
interoperability – e.g. Priority bit interpretation
Reset Sequence
Performance
Validation 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
Scoreboard
BFM BFM
DUT monitor monitor
driver driver
DUT
Testbench
Environment (ENV)
ENV
Running on a SYS
single system
(SYS)


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

Scoreboard Scoreboard
BFM BFM BFM BFM
monitor monitor monitor monitor
driver driver driver driver

DUT DUT

ENV ENV
SYS SYS

Scoreboard
BFM BFM BFM
monitor monitor monitor
driver driver driver

DUT1 DUT2

ENV
SYS


Ideal 2-Chip Environment
Goal reuse as much a possible
A socket accomplishes this goal!
• Maintain ENV and SYS of both simulations


BFM BFM BFM BFM
DUT1 SOCKET DUT2

ENV1 ENV2
SYS1 SYS2


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 systems
Each environment syncs up each “heartbeat”
Verilog
VPI – PLI
MPICH

socket

MPICH
VPI – PLI
Verilog


Socketsim tool

Similar to Avery Design SimCluster tool
http://www.avery-design.com
~2,800 lines of C/C++ code
MPI underneath (MPICH 1.2.5.2)
Verilog
VCS (V7.2R18+) and NC (5.3+) supported VPI – PLI
MPICH
Linux and Solaris supported
socket
No additional license required ☺
MPICH
VPI – PLI
Verilog


Socketsim PLI
Sender
Register callback on
changes of inputs to socket
SENDER:
Save all changes up to delta SENDER: @heartbeat
cycle @signal change send buffer
save value/time to remote host
to buffer
Receiver
Replay changes on outputs
of socket applying at each
time slice
Implied wire delay over RECEIVER:
Blocks waiting
socket equal to delta cycle for buffer,
playback
changes


Socketsim Verilog instances – SPI4.2

// “Left ASIC” side // “Right ASIC” side
socketsim #(.IN_WIDTH(20), socketsim #(.OUT_WIDTH(20),
.OUT_WIDTH(20)) .IN_WIDTH(20))
socket(.ins({tb_spi_tx_data[15:0],
tb_spi_tx_ctl, socket(.outs({NpRxData[15:0],
tb_spi_rx_stat[1:0], NpRxControl,
tx_sync}), NpTstat[1:0],
.outs({tb_spi_rx_data[15:0], rx_sync}),
tb_spi_rx_ctl,
tb_spi_tx_stat[1:0], .ins({NpTxData[15:0],
rx_sync})); NpTxControl,
NpRstat[1:0],
tx_sync}));


More Socketsim Features
Bidirectionals supported
Heartbeat user configurable at runtime
Multiple point-to-point connections allowed
ChipA has interfaces to ChipB and ChipC
Compression supported for wiiiiiiiiiiiiiide buses
Peers communicate directly
HVL↔HVL communication
Use Verilog tasks as wrappers for signals which cross the socket


Agenda

The Socketsim Tool
Summary


Testbench Methodology
Borrowed from Cadence eRM methodology
Decouple 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

Put these local drivers in PASSIVE mode


BFM BFM BFM BFM
DUT DUT
SOCKET

ENV ENV
SYS SYS


Mechanism for synchronizing test flow
Start Simulation

Testflow synchronization – sync up Reset() Reset()
the various phases of each
environment with sideband signal
Init() Init()
Phases will have different
durations
Main() Main()

Socket
Post() Post()

End() End()

ENV1 ENV2

End Simulation


Other Sideband Signaling
Messaging 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)

Sequence Sequence
driver driver


BFM BFM SOCKET BFM BFM
DUT DUT

ENV ENV
SYS SYS

cfg
Backpressure information
event


Passing Configuration via File
File I/O - for on-the-fly configuration synchronization
Both ENVs could read common file
One ENV could write cfg, the other read it

Write_ascii_struct() Read_ascii_struct()

Sequence Sequence
driver driver


BFM BFM BFM BFM
SOCKET

DUT DUT

ENV ENV
SYS SYS


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 scoreboard
Scoreboard 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 + overhead
10%-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 Analysis
Parameters which will affect performance
Multiprocessor server
Cache thrashing
Memory contention
CPUs of same speed
Heartbeat duration
Varying amount work/heartbeat
How many sockets
Socket width
Startup 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 (Cadence
eRM) 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)


Arthur q207

Recommandé

Recommandé

Contenu connexe

Similaire à Arthur q207

Similaire à Arthur q207 (20)

Plus de Obsidian Software

Plus de Obsidian Software (20)

Arthur q207