Performance Modeling and Analysis Using VHDL and System:SystemC Performance Models

By -
SystemC Performance Models

The performance models described herein take advantage of the C++ foundations of SystemC to provide a highly parameterizable simulation environment that loads most of the parameters at run time. Figure 77.38 shows the class definition for the top level of the simulation model, and the relevant comments. The top-level entity makes use of a pointer to an object of type SIM, declared in the header

Performance Modeling and Analysis Using VHDL and SystemC-0097

file generic.h, to allow the constructor arguments to be read in from the top_config.txt file rather than statically specified in the source code. When the simulation is loaded the SystemC constructor (SC_CTOR in the code) will be called. The constructor will create a streambuf object, a number of processors variable, a connection type variable, as well as a pointer variable to point to an object of type SIM. It will then open the top_config.txt file and associate it with the streambuf variable. Then it will read an unsigned value into the number of processors variable, then read an unsigned value into the connection type variable. Once those values are read in then the constructor uses the ‘new’ command to instantiate a new object of type SIM. The “new” command allows passing variable constructor arguments to the objects constructor, so the new SIM object’s constructor builds the object with the value of num_ processors processors, and the value of connect_type interconnect number. If the number of processors or interconnect type was specified via a template argument, or a fixed constructor value (e.g.: “simulation = new SIM(“it,9,1);”) in the source code then the simulation would have to be recompiled every time something was changed.

Notice that all the implementation details of the SystemC modules are declared in header files. This is the recommended way of describing models to compile the SystemC code for the ModelSim simulator. The included guards are also a must for any SC_MODULE definitions to ensure they are not included multiple times by the ModelSim SystemC compiler, SCCOM. The actual C++ file that is compiled to generate the simulation models is shown in Figure 77.39. The SC_MODULE_EXPORT(module_ class_name) is the function used to create the ModelSim model for the specified entity. The MTI_SYSTEMC compiler definition is defined specifically for compilation using SCCOM, and allows having a single set of code for both the ModelSim and reference simulator. Any ModelSim specific code can be placed inside a #ifdef MTI_SYSTEMC compiler directive statement so that the compiler only uses it when compiling for ModelSim. The #else statement prevents the ModelSim compiler from trying to compile the reference simulator-specific portions, and the #endif closes out the if else statement.

The generic.h header file defines the class SIM. It makes use of the shared base class my_basic_rw_port to declare a pointer that will allow assignment of an instantiation of any of the three channel types developed for the environment. The my_basic_rw_port base class definition is shown in Figure 77.40. Notice the use of the keyword virtual. Since the method is declared as virtual, all classes that inherit from this class must either provide, or inherit, an implementation for the read, write, and non_blk_write methods. This common interface is also what allows the type compatibility for pointer assignment used in the generic.h file. This is described in more detail in Section 77.5.4.

Comments

Post a Comment

Popular posts from this blog

SRAM:Decoder and Word-Line Decoding Circuit [10–13].

By -
Image
Decoder and Word-Line Decoding Circuit [10–13] Two kinds of decoders are used in SRAM: the row decoder and the column decoder. Row decoders are needed to select one row of word-lines out of a set of rows in the array. A fast decoder can be implemented by using AND/NAND and OR/NOR gates. Figure 52.7 shows the schematic diagrams of static and dynamic AND gate decoders. The static NAND-type structure is chosen due to its low power consumption, that is, only the decoded row transitions. The dynamic structure is chosen due to its speed and power improvement over conventional static NAND gates. From a low-voltage operation standpoint, a dynamic NOR-base decoding would provide lower delay times through the decoder due to the limited amount of stacking of devices. Figure 52.8 shows circuit diagrams of dynamic NOR gates. The dynamic CMOS gate as shown in Figure 52.8(a) consists of input- NMOSs whose drain nodes are precharged to a high level by a PMOS when a clock signal Φ is at a low lev...
Read more

ASIC and Custom IC Cell Information Representation:GDS2

By -
Image
GDS2 The Graphical Design System (GDS) format is a binary format developed by Calma Company in 1971 to convey IC layout information between IC designers and fabricators. Calma presented GDS2 format, the improved version of GDS, in 1978. Finally in 1991, when Cadence acquired Calma, GDS2 rights were transferred to it. In the design process, after the completion of routing and placement, design rule check (DRC) and layout versus schematic (LVS) are performed to verify the final layout. Then the verified layout, dumped in a GDS2 file, is transferred to IC foundries for fabrication. GDS2 File Format GDS2 is a standard mask layout intermediate format containing a single cell or a library of cells each of which includes a number of geometrical objects such as boundaries, paths, boxes, etc. These objects correspond to different layers of a cell where each layer is specified by a layer number and data type [3]. The file format of GDS2 is in binary. A GDS2 file contains a number of variable...
Read more

Timing Description Languages:SDF

By -
Image
SDF Standard Delay Format (SDF) is an ASCII format used to convey timing information between EDA tools. SDF was first developed by Cadence in 1990. Open Verilog International (OVI) approved SDF version 2 in 1993 and SDF version 2.1 and 3 in the following years. Improving SDF version 3 features, resulted in IEEE Standard 1497 [1]. Role of SDF in Design Process SDF can be used in different levels of a design process to annotate timing specifications, including timing data and constraints. Timing constraints are used during the forward-annotation process while timing data are applied during the back-annotation process. Forward-annotation process deals with porting timing constraints to synthesis, floorplanner, layout, and routing tools to meet the required constraints. During the design process, timing data can be back-annotated to analysis tools (including simulators, static timing analysis tools, etc.) to provide more accurate timing representations. SDF Structure An SDF f...
Read more