SystemC: A Complete Digital System Modeling Language: A Case Study

1. SystemC: A Complete Digital System Modeling Language: A Case Study Reni John(rjohn@rambus.com) Rambus Inc.

2. 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

3. C vs. SC Modeling Methodology & Features 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 • 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

4. Basic DRAM Model Architecture cmd/addr EXECUTION UNIT DECODER SCHEDULER CORE tdata rdata REGISTER 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

5. 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

6. SC Based Approach cmd_base ddrx_cmd xdrx_cmd ddr_cmd ddr2_cmd ddr3_cmd xdr_cmd xdr2_cmd • 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

7. 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

8. Protocol Specific DRAM model DDR3 DDR DRAM TLM Model XDR DDR2 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

9. Study Comparison Results *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)

10. 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.

11. Performance & Architecture Analysis cmd/addr cmd/addr DRAM TLM Model SCV Traffic Generator & Checker tdata tdata XMC XDR rdata rdata • 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.

12. Verification Testbench XMC XIO DRAM TLM Model Verilog Verilog 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