An Example: A Data Acquisition System

By -
An Example: A Data Acquisition System

Suppose we have a device that outputs data in periodic intervals. This output data is needed to be processed and analyzed by a Data Acquisition System (DAQS). The requirement is to design and implement this data acquisition system. There are questions that need to be answered before we are able to complete this design.

• What is the period of data preparation by the device? This specifies the worst-case delay of DAQS.

• What is the maximum budget for developing this system? This leads to the type of hardware we want to use in implementing DAQS.

• What are the main functions (operations) in this system? This is the most important implementation-related question.

• What is the system’s memory limitation? This gives us an estimate of the size of our system’s buffer and the number of registers and memory blocks.

Suppose that the data-sending rate is F, which means that the worst-case delay of DAQS is T (=1/F). Also assume that the maximum budget for the DAQS project is B. The functions that DAQS must perform

in a reasonable time include:

• FindMin: finds the minimum value of data it has received at any point in time.

• FindMax: finds the maximum value of data it has received at any point in time.

• FindVariance: finds the variance of the data it has received at any point in time.

• FindDifference: calculates the difference between two consecutive data.

• CheckRange: compares the received data with the low and high thresholds. It will display an error message if the data is out of range.

• FindAverage: calculates the average of the received data at any point in time.

• FindMean: calculates the mean of a number of most recent data. The accuracy of the result of this task depends on the number of recently stored data.

• Display: displays the received data, the result of each operation, and the probable error messages. Figure 86.46 shows a schematic view of DAQS.

System Level Design Languages-0231We can implement each operation by a separate function. For example, the FindMin function is implemented and shown in Figure 86.47.

After implementing all functions, we are ready to put all these functions together in the main() function. These functions can be placed one after another, or be executed in different processes.

When this model is completed we need to evaluate it. This can be done by applying large amounts of data to the DAQS C++ model and studying timing and memory usage of each of its functions. Alternatively, we can perform this analysis by performance analysis tools.

After analyzing the time and memory consumed for each part, and comparing them with T (time limit) and B (budget limit), we can decide and answer the following questions:

• What type of communication we should put between the device and DAQS?

• Can we implement DAQS on a general-purpose PC (fully software-based) or should we manufacture a special board for it (implement a few or all parts in hardware)?

• If we should construct a special-purpose board for DAQS (due to time or budget limitations), which parts can still be implemented in software?

• If we have a special-purpose board and we also have software parts, what processor should we use for our software parts? What existing CPU meets our requirements and limitations?

• Which parts should be executed in parallel and which parts can be executed sequentially?

• How much memory should we use for a required exactness in our calculations? How much memory can we use in DAQS?

After answering all of the above questions, if our specification still does not meet our requirements, we have to refine our system or change our limitations. By performance analysis, a set of questions and a set of critical decisions in the system design can be answered which could not be answered without a large amount of implementations being done. In the performance analysis process, high-level languages like C and C++ play a very important role to decrease the design time and increase the speed of defining a design specification and functional verification.

Our Coverage of C/C++

In this section, we discussed an overview of two high-level programming languages (C and C++). These two high-level languages are useful for developing an early prototype of a design from its model. This prototype is useful for performance analysis and partitioning of the design. The next step in a system level design can be adding more details to hardware parts defined in this step, and developing them in a more hardware-related language. The language used for this purpose can be SystemC that is discussed in the next section.

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