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

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


  • 97 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

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

Reni John([email protected])

Rambus Inc.


Motivation

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

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

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

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

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

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

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

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

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

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