Transcript SystemC: A Complete Digital System Modeling Language: A

SystemC: A Complete Digital
System Modeling Language: A
Case Study
Reni John([email protected])
Rambus Inc.
Motivation
 Hardware System Modeling is a very critical part of
the overall system design cycle for a hardware chip
 More scalability and reusability needed in the
modeling space to help close the design faster
 SystemC has all the required entities to serve
complete language for modeling Digital Systems
 DRAM Memory Modeling Case Study
 Modeling Environments
C vs. SC Modeling Methodology & Features
C
•Hardware functionality can
be modeled by mapping
the functionality of subblocks to functions with
data passing between them
represented as data
structures
•To enable reusability and
scalability the model
architecture has to be
designed very carefully due
to absence of OO features
•Concept of time only
exists with an external
simulator requiring a
license
SC
•Functional-blocks represented as
objects with ports, exports forming
the main source of communication
b/w two objects with each class
respecting the TLM interface/custom
interfaces/channels
•Concept of inheritance makes the
design scalable and reusable once
the understanding of the design
domain is available and grasped
•SC builds upon as a library of the
C++ language with its own
simulation kernel which is open
source , giving freedom to use all
the C++ constructs and advantages
of the Object Oriented techniques
•No license if simulated with OSCI
Basic DRAM Model Architecture
DECODER: Decodes the incoming command/address.
SCHEDULER: Schedules the commands in queue to
be executed now/later in time
EXECUTION UNIT: Checks timing errors/status and
also stores/fetches to/from the core
CORE: Contains the data structures representing the
memory
REGISTER: Contains the Control and Status Registers
for the DRAM
C Based Approach
DRAM C Model Top Pseudo Code
void dram_main( void *
Each function models a
hardware block
functionality with timing
check functions
dram,
SimTime
simtime,
cmd_pkt
cmd_in,
void **
rd_data,
void *
wr_data){
GetDramhandle(dram);// Gets the current DRAM handle.
CoreTimingCheck(((PTDRAM) dram)->core);//Performs the core timing
checks.
DecCmd(&cmd_in);// Decode and Validate Commands.
if (cmd_in.OP) { SchedCmd(((PTDRAM) dram)->exec_q, &cmd_in); } //
schedule command(s), if any
ConstraintCheck();//// check for dependency violations.
ExecCmd(rd_data, wr_data); // execute commands
}
SC Based Approach
•Basic modules in the SC model are objects
constructed using OO techniques
•Above figure demonstrates a transaction class
hierarchy of how multiple command structures are
formed using the reusable base classes
•This same thought applies to the sub-system blocks
helps in achieving a scalable and easily configurable
model
Details of DRAM SC model
•All the major blocks eg .DECODER, SCHEDULER,
EXECUTION, CORE, REGISTER, TRANSACTOR are
sc_module type
•Contains only one SC_THREAD and 4 SC_METHOD
processes in the TLM system
•Infrastructure classes(SC_REPORT_ERROR,
SC_TRACE ..) used for reporting and waveform trace
dump
•Uses STL(map, vector, queue) for storage of core data
and other complex data structures
Protocol Specific DRAM model
Transactors instantiating Basic DRAM Model
•Signal level protocol details lie in the specific
transactor
•Basic model not including the serializer/deserializer
for the command/datapath makes it suitable for
performance analysis
•More accurate and complete model can be built by
adding the specific transactor which can be used in
the System Level Verification
Study Comparison Results
Parameter Name
C Model(Only
XDR protocol)
SC Model
(DDR,DDR2,DDR3,X
DR protocol)
Code Length(*1)
8000 lines
6500 lines
Shared Object
Size
Average Full 512
Mb XDR Memory
Sweep Time(*3)
600KB
2.7MB
23mins(Cadence
NCVerilog 6.11)
16mins(Run with g++)
*1: The code length for the C model included its own
libraries and infrastructure code
*3: The average run time was recorded with the output
logs turned off. Every memory location was read and
written following the DRAM’s timing protocol. Machine
details(Linux v2.6.9-67.0.7 x86_64)
Model Usage
• Environments where the DRAM model was used:
• Performance & Architecture Exploration
• DRAM : If the DRAM architecture is not finalized
then SC model can be used to try different types of
hardware architectures eg.(Threading, Bank Sets
etc.)
• MC : Memory Controller early architecture and
performance analysis requires DRAM models
• Verification
• DRAM : Early DRAM models aid in the
development of VIP(Verification IP) for the
DRAM RTL.
• Sub-Systems : The DRAM models also helped in
the verification of MC and Physical Interface
Module.
Performance & Architecture Analysis
•All Sub-Systems as Traffic Generator, XMC and XDR
are SC TLM models(TLM1.0). A thin layer in XMC
emulates the Physical Interface delays. Since
everything is programmed in SC the system enables a
number of architecure analysis options in a very less
time.
•Moreover different type of MC(DDR2,XDR etc.)
analysis can be done by just changing command line
options.
Verification
Testbench
Thin pin layer
interface(Transactor)
•Pin level signals forms the main interface between the
blocks
•Mixed language simulation(Verilog & SC) reduces
performance but provides a consistent platform to
verify the system