[Unfinished] [documentation]. Structure in Amy electronics-Test Platform (testbench ),

ArticleDirectory

• 1 always block and initial block
• 2 process statements
• 3. Time Series Control
• 4. latency Control
• 5. Event Control
• 6. Wait statement
• 7 timescale command
• 8. system control functions and tasks
• 9. User-defined functions and tasks

Content

IntegratedCodeWhat is different is that testbench OpenGL is executed in the simulator on the Computer Host. Many of the structures of testbench OpenGL are similar to those of C. We can include complex language structures and sequential statements in the code.Algorithm.

1 always block and initial block

There are two types of process statements: the always block and the initial block. Process statements in the always block can be used to simulate abstract circuits.

For the purpose of simulation, the always block can include a time series structure used to specify the same propagation latency as different structures, or a time series structure waiting for the specified event. The sensitive list can be ignored sometimes. For example, we use the following code snippet to simulate the clock signal. Every 20 time units of the signal are 0 ~ 1 is transformed once and always executed.

 
Alwaysbegin CLK = 1; #20; CLK = 0; #20); End
 

There are also process statements in the initial block, but they are only executed at the beginning of simulation. The simple syntax is as follows:

 
Initialbegin process statement; End
 

The initail block is often used to set the initial value of a variable. Note that the initial block cannot be integrated.

2 process statements

Process statements are applied to initial blocks, always blocks, functions, and tasks. The most common process statements are:

• Blocking assignment
• Non-blocking assignment
• If expression
• Case expression
• Loop expression

We have discussed blocking and blocking assignment, IF and case statements.

The cyclic structures supported by OpenGL include for, while, repeat, and forever. The simple syntax of the For Loop is:

 
For ([initial_assignment]; [end_condition]; [step_assignment]) begin [procedural_statements;] End
 

For example, we can use the following statement to clear the content of a 16-bit register file:

 
Integer I;... for (I = 0; I <16; I = I + 1) reg_file [I] = 0;
 

Note that if there is only one statement in the loop body, the begin and end restrictions can be omitted.

The simple syntax of the while loop is as follows:

 
While ([end_condition]) begin [procedural_statements;] End
 

The statements in the loop body are repeatedly executed until the specified termination condition [end_condition] is reached. For example, the operation of the above register file can be described using the while loop:

Integer I;... while (I <16) Begin reg_file [I] = 0; I = I + 1; en
 

The simple syntax of the repeat loop is as follows:

 
Repeat ([number]) begin [procedual_statements;] End
 

The statement in the loop body is repeatedly executed for a specified number of times, which can be specified through [number. For example, we can replace the above operation with a repeat loop:

 
Integer I;... repeat (16) begin [procedural_statements;] End
 

Forever loop, as its name indicates, repeats the execution of its subject until the simulation ends. The cyclic body usually contains a certain time sequence control structure, which causes periodical delays in execution. For example, we use another method to describe the clock signal. The signal is flipped once every 10 time units and runs forever.

 
Initialbegin CLK = 1' B0; forever #10 CLK = ~ CLK; End
 

3. Time Series Control

In testbench, you must specify the time when different signals are valid and invalid, or wait for an event or condition. There are three time series control structures:

• Latency control: # [delay_time]
• Event Control: @ ([event], [event],…]
• Wait statement: Wait ([boolean_expression])

In addition, there is a compiler instruction, 'timescale, which is also related to the time series specification.

4. latency Control

Latency control is indicated by the # symbol, followed by the time unit value of delay.

If the latency control is placed on the left side, the execution of the entire statement will be delayed. For example,

 
... #10 A = 1 'b0; #5 y = a | B ;...
 

Assuming that the current time is t, the preceding statement indicates that a gets 0 at T + 10, and after five time units (that is, at T + 15) A | B expression is calculated, and the result is assigned to y.

If the experiment control is placed on the right hand side, the expression is calculated immediately, but the operation is delayed before being assigned to the left side. For example:

 
... #10 A = 1 'b0; y = #5 A | B ;...
 

A is 0 at T + 10. A | B is calculated immediately (that is, at T + 10), but the result is assigned to Y at T + 15.

In general, we use latency control to generate incentives to replace propagation delay simulation. The following format makes the code more intuitive.

 
... A = 1 'b0; // A gets 0 #10; // The 0 value lasts 10 time unitsa-1 'b1; // A changes to 10 #5; // The 1 value lasts 5 time unitsa = 1' B0; // A changes to 0 #20 // The 0 value lasts 20 time units...
 

...

5. Event Control

The @ symbol is used to indicate the event control, and the sensitive list is used to specify the required event. Its usage is similar to the events in the always block. An event is the time when the signal in the sensitive list changes its value. You can add the posedge and negedge keywords to specify the desired hop edge (rising edge and falling edge ). In testbench, the statement can skip the delay and continue execution until the specified event occurs. A common application of event control is to use clock signals to synchronously generate incentives. For example, in the following code snippet, The en signal is activated for a period of time.

 
Localparam Delta = 1 ;... @ (posedge CLK); // wait for the rising edge of CLK # delta; // wait for Delta to avoid hold = Time violationen = 1'b1; // assert en to 1 @ (posedge CLK); // wait for the next rising edge of CLK # delta; // wait for Delta to avoid hold-time violationen = 1 'b0; // assert en to 0
 

In another way, we can deploy the assertions along the descent of the clock signal or remove the asserted en.

 
... @ (Negedge CLK) // wait for the falling edge of clken = 1' B1; // assert en to 1 @ (negedge CLK) // wait for the next falling edge of clken = 1 'b0 ;...
 

6. Wait statement

The wait statement is used to wait for a specified condition. The simple syntax is as follows:

 
Wait [boolean_expression]
 

Until [boolean_expression] is calculated as true, subsequent statements can skip the delay and continue execution. For example, we can write code like this:

 
Wait (State = read & mem_ready = 1 'b1) [statement_to_get_data];
 

We can also use wait statements to delay execution. For example, we can activate a signal when the number of counters reaches 15:

 
... Wait (counter = 4 'b1111); // wait until counter is 15... // continue
 

Wait statements sometimes require event control. The latter is waiting for the hop edge of a signal, while the former is waiting for a specified condition, which can sometimes be understood as level-sensitive.

7 timescale command

The compiler instructions are used to control compilation and preprocessing of the OpenGL code, which are indicated by the accent symbol. The accent is usually located in the upper left corner of the keyboard. The time-related command is the 'timescale command.

'Timescale [time_unit]/[time_precision]

Time_unit specifies the unit of measurement for timing and latency, while time_precision specifies the accuracy of the simulator.

For example, commands

 
'Timescale 10ns/1ns
 

The simulation unit is 10ns, and the precision is 1ns. When the latency in the following code is specified,

 
#5 y = A & B;
 

Indicates that the actual latency is 50ns (5 * 10ns ).

You can also specify the unit latency in decimal form, for example

#5.12345 y = A & B;
 

The actual latency is 51.2345ns. Because the precision is 1ns, the value is rounded to 51ns in simulation. The smaller the accuracy, the higher the accuracy of the simulation, but it will slow down the simulation speed.

The numbers of time_unit and time_precision can be 1, 10, and 100. The time units can be S, Ms, US, and NS) and PS (per second ).

8. system control functions and tasks

There is a set of predefined system functions in OpenGL, starting with $ to execute system-related operations, such as simulation control and file reading. The following describes some common functions and tasks.

Data Type Conversion Function

The $ unsigned and $ signed functions perform conversions between the unsigned number and the signed number type.

Simulation time function

The simulation time function returns the current simulation time, for example, $ time, $ stime, and $ realtime functions return the time in the form of 64-bit integers, 32-bit integers, and real numbers, respectively.

Simulation Control Task

There are two types of simulation control functions: $ finish and $ stop. The $ finish task is used to terminate the simulation and exit the simulator. The $ stop task is used to stop the simulation. In Modelsim, the $ stop task is returned to the interaction mode. In the development process, we sometimes stop in The Modelsim environment to further edit or test the waveform, so $ stop is used in the code.

Show task

In Modelsim, simulation results can be displayed in the form of waveforms or text. The four main display tasks are $ display, $ write, $ strobe, and $ monitor. Their syntax is similar. In Modelsim, the text is displayed on the control panel.

The syntax of $ display is similar to that of the print function in C language. Its simple syntax is:

$ Display ([format_string], [argument], [argument],...);
 

For example:

 
$ Display ("at % d; signal X = % B", $ time, X );
 

The result is as follows:

 
At 5100; signal X = 00110001
 

The most common transfer symbols include % d, % B, % O, % H, % C, % s, and % G, the values are decimal, binary, octal, hexadecimal, character, string, and real number.

The $ write task is almost the same as $ diplay, except that it is not displayed in the next row after execution. It is always displayed at the current position. Show the next line of characters \ n, must be manually added to create a line interrupt.

The time step concept can be used to create the simulation latency. Many activities can occur in each time step. $ Strobe is similar to $ display. Instead of executing immediately, the $ strobe task is executed at the end of the current simulation time step. It can avoid mismatched data display caused by competition risk.

$ Monitor tasks are very common commands. Since $ displat, $ write, and $ strobe tasks display text only once they are executed, $ monitor tasks display text when their parameters change. $ Monitor tasks provide a simple and flexible way to track simulation. For example, we can add the following code in testbench:

Initialbegin $ display ("time test_in0 test_in1 test_out"); $ monitot ("% d % B", $ time, test_in0, test_in1, test_out); End
 

The text simulation results displayed in the control panel of Modelsim are as follows (example ):

 
Time test_in0 test_in1 test_out 0 00 00 1 200 01 00 0 400 01 11 0...
 

File I/O system functions and tasks

Veirlog provides a set of functions and tasks used to access external data files. Files can be opened and closed through the $ fopen and $ fclose functions. $ Fopen Syntax:

 
[Mcd_names] = $ fopen ("[file_name]");
 

The $ fopen function returns a 32-bit file-related multi-channel description sub. We can think of this description as a 32-bit sign, which represents a file (that is, a channel ). Reserved bits are retained by LSB for standard output (console) only ). When the file called using the function is successfully opened, the returned description sub-value is set to one. For example, 0... 0010 indicates opening the first file, 0... 0100 indicates opening the second file, and so on. If the return value of the function is 0, the file cannot be opened successfully.

Once a file is opened, we can write data to it. Four available display system tasks are: $ fdisplay, $ fwrite, $ fstrobe, and $ fmonitor. The usage of these tasks is similar to the previous $ display, except that the first parameter is the description.

$ Fdisplay ([mcd_name], [format_string],...);
 

The following is a simple code snippet.

 
Integer LOG_FILE, both_file; localparam con_file = 32 'h0000 _ 0001; // leleinitial begin LOG_FILE = $ fopenz ("my_log"); If (LOG_FILE = 0) $ display ("fail to open log file"); // write console both_file = LOG_FILE | con_file; // write to both console and LOG_FILE $ fdisplay (both_file, "simulation started ");... // write to LOG_FILE only $ fdisplay (LOG_FILE ,...);... // write to $ fdisplay (both_file, "simulation ended"); $ fclose (LOG_FILE); End
 

Note that we can create a descriptive sub by bitwise operations on multiple descriptive sub-statements, such as the both_file variable. When both_file is used, you can operate the console and LOG_FILE at the same time.

There are two tasks that can load data from the file: $ readmemb, $ readmemh. These tasks assume that the external files store the memory-array content and read the content to a variable. $ Readmemb, $ readmemh assumes that the file formats are binary and hexadecimal, respectively. Their syntax format is:

$ Readmemb ("[file_name]", [mem_variable]); $ readmemh ("{file_name]", [mem_variable]);
 

The following section describes how to load an 8x4 storage array:

 
Reg [] v_mem [];... $ readmemb ("vector.txt", v_mem );
 

Vector.txt should contain eight 4-bit binary data separated by space.

With file operation functions and tasks, you can use external files to specify the test model and record the simulation results. The following is a case.

'Timescale 1ns/1 nsmodule eq2_file_tb; // signal declarationreg [1:0] test_in0, test_in1; wire test_out; integer LOG_FILE, lele_file, out_file; Reg [] v_mem []; integer I; // instantiate the circuit under testeq2_sop eq2_sop_inst (. A (test_in0 ),. B (test_in1 ),. aeqb (test_out); initial begin // setup output file LOG_FILE = $ fopen ("eqlog.txt"); If (! LOG_FILE) $ fdisplay ("cannot open log file"); lele_file = 32 'h0000 _ 0001; out_file = LOG_FILE | lele_file; // read Test Vector # readmemb ("vector.txt ", v_mem); // Test Generator iterating throught 8 pattens for (I = 0; I <8; I = I + 1) begin {test_in0, test_in1} = v_mem [I]; end // stop simulation $ fclose (LOG_FILE); $ stop; end // text displayinitial begin $ fdisplay (out_file, "Time test_in0 test_in1 test_out"); $ fdisplay (out_file, "(a) (B) (aeqb)"); $ fmoitor (out_file, "% 10d % B", $ time, test_in0, test_in1, test_out); endendmodule

The specified test patternis a 4-bit binary format and is stored in vector.txt. File Content:

 
00_000000000000001110_1010_0011_1111_0100_10
 

Note: "_" only serves to connect numbers. It is easy to differentiate digits by separation. It is used in the same way as in other regions of OpenGL.

The above file is loaded into the two-dimensional v_mem variable. Simulation results are written to the console and LOG_FILE. The LOG_FILE content is:

 
Time test_in0 test_in1 test_out (a) (B) (aeqb) 0 00 00 1 200 01 00 0 400 01 11 0 600 10 10 1 800 10 11 01000 11 00 11200 11 01 01400 00 10 0
 

LOG_FILE is a general text file that can be edited using another text editor.

9. User-defined functions and tasks

To be continued