Systemc a complete digital system modeling language a case study
Sponsored Links
This presentation is the property of its rightful owner.
1 / 12

SystemC: A Complete Digital System Modeling Language: A Case Study PowerPoint PPT Presentation


  • 108 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

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


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


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

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


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

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


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)


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

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.


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


  • Login