SYSTEMC Slide -1 -
Abstraction Layers for Hardware Design TRANSACTION-LEVEL MODELS (TLM) TLMs have a common feature: they implement communication among processes via function calls! Slide -2 -
Abstraction Layers for Hardware Design Slide -3 -
Purpose of Abstraction Layers Slide -4 -
Algorithmic Models JPEG Encoding Algorithm These are flowchart-style abstract models Slide -5 -
Functional Models Those models usually do not involve timing, so they are usually not used for performance evaluation. Example scenario: The initiator spawns a request to the target, waiting for an answer. The target module, which was waiting for such a request from the initiator, processes it, and then sends back the result to the initiator module. The initator module receives the answer, and can continue the simulation Slide -6 -
Functional Untimed Models In an Untimed TLM (UTLM) model, the delays for serving requests are not considered: Tasks are invoked based on the actual dependency chain (synchronization mechanism needs to be set up) but the simulated time is stuck to zero (tasks are virtually instantaneous)! Machine Time (not simulated time) Tasks performed in zero (simulated) time Slide -7 -
Functional Untimed Models: Concurrent Process Execution Casual dependencies that must be respected: The overall execution sequence is not prescribed as long as the dependencies are fulfilled Slide -8 -
Deterministic Behaviour STEP ACTION 1. Activate or resume a process 2. Read input data for control flow and data processing 3. Computation 4. Write output data if there is any 5. Return to Step 2 if more computation is required 6. Synchronization: a) If it is emit-synchronization, then return to Step 2 b) If it is receive-synchronization, then the process will be suspended Slide -9 -
Functional Timed Model In a Timed TLM (TTLM) model, timing information (functional delays) are annotated to account for the estimated time in performing a given task Tasks performed in zero (simulated) time Constructs are needed in the modeling language (e.g., wait calls) to enable Elapsing of simulated time Synchronization of tasks on timepoints Slide -10 -
Functional Timed Models Insertion of functional delays must not change causal dependencies Typical implementation: Wait(processing time); This construct interacts with the simulation engine Challenge: Define the delay of each possible path of the control flow. This may result into complex graphs and large sets of timing attributes Slide -11 -
From Untimed to Rough Functional Timed Models COMPUTATION = BEHAVIOUR COMMUNICATION = ABSTRACT CHANNELS Processing elements (PEs) Message-passing channels Sharing/contention on communication resources is not modelled COMPUTATION = BEHAVIOUR, APPROXIMATELY TIMED COMMUNICATION = PROTOCOL BUS CHANNEL Abstract TLM bus channels Bus arbiter arbitrates bus conflicts Early timing notion Slide -12 -
Bus Cycle Accurate (BCA) Models Time/cycle accurate communication Implication: pin accuracy Makes sense with timed computation Essentially, a refinement of level of abstraction for bus modelling CLOCK Slide -13 -
PE-Cycle Accurate Models Refinement of computation modeling P3 executes cycleaccurately P3 can be pinaccurate too Cycle Accuracy extended to the processing elements (e.g., clocked model of a FSM) Wrappers (if needed) convert data transfer from lower level of abstraction to higher level (for mixed-abstraction simulations) Slide -14 -
(Global) Cycle Accurate (CA) Models Both bus and processing elements modelled with clock-cycle level timing accuracy No wrappers needed Slide -15 -
(Global) Cycle Accurate (CA) Models Hardware-software co-design approach Slide -16 -
Register Transfer Level (RTL) models Cycle-accurate models may still hide the internal structure of the cores, while successfully capturing the behavior cycle-by-cycle They may just describe the operations performed in a clock cycle Structural Accuracy This is the first abstraction layer where the structure of the design becomes available In RTL models, the entire design is split into registers with flow of information between these registers at each clock cycle. RTL description captures the change in design at each clock cycle. Slide -17 -
Levels of Abstraction VHDL, intended as a specification langauge, is very exact in its nature and hence very verbose Verilog, intended as a simulation language, is much closer to C in style, in that it is terse and elegant to write but requires much more care to avoid nasty bugs Raising Level of Abstraction is necessary for managing complexity. Slide -18 -
Design Challenge I: Hardware/Software Co-design In complex systems, software developers must often wait for the hardware design to be finalized before they can begin detailed coding. Software developers must also wait for devices (ICs and printed circuit boards) to be manufactured to test their code in a realistic environment. This dependency creates a long critical path that may add so much financial risk to a project that it is never started. Slide -19 -
Design Challenge II: Hardware Implementation 1. A system engineer writes a C or C++ model of the system to verify the concepts and algorithms at the system level. 2. The parts of the C/C++ model to be implemented in hardware are manually converted to a VHDL or Verilog description for actual hardware implementation. Slide -20 -
Problems with the Current Methodology Manual Conversion from C to HDL Creates Errors The designer: 1. creates the C model, 2. verifies that the C model works as expected, and 3. translates the design manually into an HDL. This is very tedious and error prone. Disconnect Between System Model and HDL Model After conversion, the HDL model becomes the focus of development. The C model quickly becomes out of date as changes are made. Typically changes are made only to the HDL model and not implemented in the C model. Multiple System Tests Tests that are created to validate the C model functionality typically cannot be run against the HDL model without conversion. Not only does the designer have to convert the C model to HDL, but the test suite has to be converted to the HDL environment as well. Slide -21 -
Why not just C++? Concurrency support is missing (HW is inherently parallel) No notion of time (clock, delays) Communication model is very different from actual HW model (signals) Weak/complex reactivity to events Missing data types (logic values, bit vectors, fixed point math) PLAIN VANILLA C++ IS NOT USABLE! Slide -22 -
SystemC Objectives Objectives: Model HW with SW programming language Achieve fast simulation Provide support for Hardware modeling Hardware/software system design Challenge: Give hardware semantics to software models! Slide -23 -
SystemC C++ extensions C++ class library (libsystemc.a), which also delivers a modeling methodology HW semantics defined through the class library SystemC code is C++ code and can be freely mixed with C++ code Object-oriented style Basic component models (reusable!) Inheritance, polymorphism, templates,... Usually translated into traditional HDLs for hardware synthesis: From SystemC RTL to VHDL/Verilog RTL automatic conversion High-level synthesis (from SystemC functional models directly into Verilog/VHDL RTL. Slide -24 -
SystemC Infrastructure Slide -25 -
What is SystemC SystemC is a C++ class library and a methodology that you can use to effectively create a model of software algorithms, hardware architecture, and system-level designs. The SystemC Class Library has been developed by a group of companies forming the Open SystemC Initiative (OSCI): semiconductor + EDA companies Since 2011, merging with Accellera standards organization into the Accellera Systems Initiative You can use SystemC and standard C++ development tools to create a system-level model, quickly simulate to validate and optimize the design, provide the hardware and software development teams with an executable specification of the system. An executable specification is essentially a C++ program that exhibits the same behavior as the system when executed. Slide -26 -
Benefits of Executable Specification Avoids inconsistency and errors and helps ensure completeness of the specification. because you are essentially creating a program that behaves the same way as the system. Ensures unambiguous interpretation Whenever implementers are in doubt about the design, they can run the executable specification to determine what the system is supposed to be doing. Helps validate system functionality before implementation begins. Helps create early performance models of the system and validate system performance. Its testbench can be refined (or used as is) to test the implementation of the specification. This can provide tremendous benefits to implementers and drastically reduce the time for implementation verification. Slide -27 -
SystemC highlights Supports hardware and software co-design Developing an executable specification avoids inconsistency and errors Avoids wrong interpretation of the specification SystemC has a rich set of data types for you to model your systems It allows multiple abstraction levels, from high level design down to cycle-accurate RTL level Slide -28 -
SystemC and the Hardware/software co-design challenge UNTIMED TLM HARDWARE DEVELOPMENT TIMED TLM RTL SOFTWARE DEVELOPMENT FUNCTIONAL HW/SW REAL-TIME SOFTWARE SOFTWARE CODESIGN SOFTWARE VALIDATION Slide -29 -
Hardware Software Co-design Bebefits of using SystemC: Ability to start refining and testing software earlier, thereby reducing the overall development cycle. Ability to provide earlier and more realistic hardware/software trade off studies at a time when changes are easier, thus improving overall system quality. Ability to deliver executable models to customers both for validating the specification and driving changes, and acceleration of product adoption. Ability to cancel (or redefine) an unrealistic project before spending even larger sums of money Slide -30 -
Alternative: High-Level Synthesis from C/C++ 1. High-level synthesis from C/C++ is today a mainstream alternative option (e.g., Vivado Design Suite) 2. With SystemC: a. You can do high-level synthesis as well (not exactly the same as C/C++ though, see next slide) b. You can refine the design down into RTL, and convert from there Automatic High-Level Synthesis (not translation) from C to Verilog/VHDL RTL Slide -31 -
Why choosing SystemC? Refinement Methodology: The design is not converted from a C level description to an HDL in one large effort. The design is slowly refined in small sections to add the necessary hardware and timing constructs to produce a good design. Using this refinement methodology, the designer can more easily implement design changes and detect bugs during refinement. Slide -32 -
Why Choosing SystemC? Source: Forte System Design, https://www.youtube.com/watch?v=ismrfstewl0 Slide -33 -
Overall: SystemC and the Hardware Implementation Challenge Written in a Single Language the designer does not have to be an expert in multiple languages. SystemC allows modeling from the system level to RTL. Higher Productivity because the designer can model at a higher level. smaller code, that is easier to write and simulates faster than traditional modeling environments Testbenches can be reused from the system level model to the RTL model Saving conversion time. gives the designer a higher confidence that the system level and the RTL model implement the same functionality. Slide -34 -
SystemC Synthesis SystemC is not born to be a language for HW implementation (like Verilog & VHDL) Basic idea: define synthesizable SystemC subset for HIGH-LEVEL SYNTHESIS Commercial tools are available To infer RTL from TLM To translate from RTL to Verilog/VHDL [Celoxica 2005] Slide -35 -
SystemC contrasted with other design languages matlab Verilog VHDL System Verilog Vera e Sugar Jeda Slide -36 -
Open Community Licensing How to get SystemC? www.accellera.org SystemC v.2.3.2 availale (including TLM library) Slide -37 -