System Level Design Languages:An Example and SSimBoard

By -
An Example :SSimBoard

In this chapter, we will describe a simple system, used as an example to describe UML diagrams. In the hardware design environment, the increase in the size of designs and the number of design inputs cause the simulation process to become very time-consuming. Our example system is an accelerator board for improving speed of circuit model simulation (SPICE simulation).

Figure 86.3 shows a view of this system. As shown in this figure, this system consists of two main parts: a master and a slave. The master part in this system can be a general PC. The user, who needs to simulate a SPICE design, interacts with the master via a Graphic User Interface (GUI). The slave, in contrast, is a board including a CPU and a memory module. SPICE simulation task is performed by the slave via a SPICE simulation program that is installed on its CPU. The interconnection between master and slave is performed via a parallel port. Therefore, there are drivers for parallel ports in both master and slave sides.

System Level Design Languages-0199

The slave board, which we will refer to as SSimBoard, attaches to the computer system handling the simulation via a parallel port. The simulator program and necessary drivers are placed in the board’s memory.

The designer sends his or her design file and the design input vectors to the slave board via the parallel port from the GUI in the master side. Then the simulation process starts by running the simulator program on the SSimBoard’s processor. Since this processor has no other task to perform, it helps the designer to perform faster simulation runs. If the circuit to be simulated is very large, or if there are a large number of input stimuli, this board can either only simulate a part of the circuit or simulate the circuit for only a portion of input stimuli. The partitioning strategy must be defined by the master side via GUI.

We use C++ for the design of software parts (GUI and driver in the master side, and SPICE simulator and driver in the slave side), and SystemC for its hardware parts (CPU and memory modules in the slave side).

System Level Design Languages-0200

As shown in Figure 86.3, we have to develop the following components for our system:

• SPICE simulator: This program is a software program that accepts a SPICE model and simulates the values on the lines in a defined duration of time.

• Graphical user interface (GUI): To load the hardware design and its test vectors, there needs to be a program that the designer can work with. This GUI also shows the received results of the simulation.

• Port driver: A driver for communication between SSimBoard and the computer needs to be developed (in this case, for parallel port).

• A CPU model: For developing the hardware part (slave), we need to model the components of this board. One of these components is a CPU. We have chosen the Sayeh CPU (a simple academic processor) as our CPU. Any other CPU can be used in this design. As stated earlier, we want to develop our hardware models in SystemC.

• A memory model: Another hardware component which needs to be included in SSimBoard is a memory model. This model works with the Sayeh CPU.

As the final result of the system, we will have a board attached to a PC via the PC’s parallel port and a SPICE simulator is loaded on it, and a software program on the PC that communicates with this board in a user-friendly manner. The scenario a user has to follow to work with this system is listed in the following steps and is shown in Figure 86.4.

1. The hardware designer (who is the user of this system) describes his or her circuit in SPICE.

2. The designer develops test data for his or her SPICE model.

3. The designer connects SSimBoard to the computer and switches on the board.

4. The designer runs the GUI and sends a specified design and input vector files through this GUI to SSimBoard.

5. The designer starts the simulation process by issuing the start SPICE simulate command through the GUI.

6. The SPICE simulation process runs on the SSimBoard CPU. During this process, the user can perform other programs on the PC.

7. Completion of the SPICE simulation is announced by SSimBoard to the PC via the parallel port connecting the two systems. The user becomes aware of this through the GUI.

8. The user can receive the simulation result through the GUI.

9. The GUI will show the simulation result in a graphical mode.

System Level Design Languages-0201

To design this system, we implement the necessary software components of SSimBoard and PC in C++, design the hardware of SSimBoard CPU and memory in SystemC, and cosimulate these two parts in a C++ environment. On the SSimBoard side the software components are its parallel port driver and a SPICE simulator; and on the PC side, a parallel port driver and GUI constitute its software components. After coverification of hardware and software parts, we can follow the hardware manufacturing steps (synthesis, postsynthesis simulation, layout generation, manufacturing the ICs, PCB generation, etc.) to create our SSimBoard.

The design process we are pursuing is shown in Figure 86.2. In this process, we model our system in UML and analyze different parts of the system with UML diagrams. With a suitable CASE tool, a code generator tool in this case, we automatically generate the structure of the necessary codes from our models. The other advantage of modeling before developing the codes of the system is that the system specification can be refined in this stage. In many cases, when we develop our codes and implement several parts of our system, we confront several problems in our early specification. Correcting these problems sometimes leads to changing the whole design (and even throwing away the codes we have already developed).

Having a strong modeling and analysis tool is also useful in fixing problems that are found in the later design stages. This means that if we face a problem after code development and we need to redesign the system, the redesigning process will be easier than redesigning without a proper set of CASE tools.

The section that follows discusses UML 2.0 diagrams. In each part a simple example related to the SSimBoard design is shown.

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