SystemC: A Complete Digital System Modeling Language: A Case Study Reni 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 Hardware functionality can be modeled by mapping the functionality of sub- blocks 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 C 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 * 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 } Each function models a hardware block functionality with timing check functions

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 NameC Model(Only XDR protocol) SC Model (DDR,DDR2,DDR3,X DR protocol) Code Length(*1) 8000 lines6500 lines Shared Object Size 600KB2.7MB Average Full 512 Mb XDR Memory Sweep Time(*3) 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 v 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 Thin pin layer interface(Transactor) Testbench 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