System Level Design Languages:Other Useful Classes and Methods

By -
Other Useful Classes and Methods

This section provides a brief overview of SystemC. There are many predefined classes and functions in SystemC that were not discussed. The following list shows functions not discussed here. The reader is referred to Refs. [6,7] for more details of SystemC and an explanation of functions listed below.

• sc_clock

• sc_time

• sc_event_queue

• sc_report

• sc_spawn

• FORK/JOIN

• sc_event_finder

• sc_attribute

• sc_exception

An Example: System Level Modeling of Sayeh CPU

In this section we will put together all the previously discussed concepts in a comprehensive CPU example. The example is the system level implementation of a simple CPU called Sayeh. Sayeh was first used as a benchmark example in several papers on CPU testing. It was then used in Ref. [8]. The example description of this CPU and its Verilog description appear in this reference. For the sake of completeness, a brief overview will be given in the following paragraph.

Sayeh has a register file that is used for data-processing instructions. It has a 16-bit data bus and a 16-bit address bus. This processor has 8- and 16-bit instructions (it has 29 instructions). Short instructions contain shadow instructions, which effectively pack two 8-bit instructions into a 16-bit word. Long instructions have the Immediate field that short instructions do not. Sayeh uses its register file for most of its data instructions. Addressing modes of this processor also take advantage of this structure. Because of this, the addressing hardware of Sayeh is a simple one and the register file output is used in address calculations. Sayeh components that are used by its instructions include the standard registers such as the Program Counter, Instruction Register, the Arithmetic Logic Unit, and Status Register. In addition, this processor has a register file forming registers R0, R1, R2, and R3 as well as a Window Pointer that defines R0, R1, R2, and R3 within the register file.

The SystemC codes of Sayeh are shown in Figure 86.70 (header file) and Figure 86.71 (implementation file). The testbench is shown in Figure 86.72. The SystemC codes for memory and other parts are not demonstrated.

Our Coverage of SystemC

In this section, a brief overview of SystemC for system level design was given using several examples. An early hardware-oriented specification of hardware parts in a system can be achieved by this language. These hardware prototypes can be cosimulated with software parts of a system. Another important point in developing hardware prototypes, which are also mentioned in this section, is to define an efficient communication between different hardware parts of a system. The next section discusses efficient ways of designing communication protocols using TLM.

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