WikiLabs - Contribuții utilizator [ro]

Advanced Digital Systems

2025-05-28T15:13:57Z

Zhascsi:

* [https://users.dcae.pub.ro/~zhascsi/courses/add/add2.pdf Structured design with verilog]
* [https://users.dcae.pub.ro/~zhascsi/courses/add/add3.pdf Carry Lookahead Adder - iterative design]
* [https://users.dcae.pub.ro/~zhascsi/courses/add/add4.pdf Carry Lookahead Adder - recursive design]

== Test code for adder ==
<syntaxhighlight lang="SystemVerilog">
module test;

logic [31:0] a;
logic [31:0] b;
logic [32:0] s;

cla #(32) dut (.a(a), .b(b), .s(s));

initial begin
repeat(100) begin
#1
a = $random;
b = $random;
#1
if(s !== a + b)
$display("ERROR\n");
else
$display("OK\n");
end
end

endmodule
</syntaxhighlight>

== Projects ==

# [[MD5 Hash]]
# [[SHA-1 Hash]]
# [[SHA-256 Hash]]
# [[SHA-512 Hash]]
# [[AES Encryption]]
# [[DES Encryption]]
# [[RSA Encryption]]
# [[RC4 Stream Cypher]]
# [[Sorting Network]]
# [[Sum of Absolute Differences]]
# [[Sum of Squared Differences]]
# [[Artificial Neural Network]]
# [[Gaussian 2D Filter]]

2025-04-29T23:11:18Z

Zhascsi: Zhascsi a încărcat o versiune nouă pentru Fișier:Appl9 moore wave.png

Applications 9

2025-04-29T23:08:43Z

Zhascsi: /* Outputs */

Almost always the FSM is described behaviorally, leaving the CLC gate level generation and optimization to compiler/synthesizer. However, the usual behavioral description closely follows the block structure of the FSM, with one block that computes the transition function and another block that computes the output. The FSMs are of two categories:
* Moore FSM, whose outputs depend only on the current state
* Mealy FSM, whose outputs depend also on inputs

Most often the Mealy FSM is a delayed Mealy FSM. Its output depends on the previous state and on the input values at transition time.

== Exercise 1 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs remain asserted until reset.

[[Fișier: appl9_ex1.png]]

=== Moore FSM ===

The circuit may be designed as a Moore FSM, with two separate states for those two particular output configurations. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final states, '''R''' or '''U''', the automaton stays until reset. From any state the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_moore.png]]

=== State coding ===

It is not recommended to use explicit values whenever the state variable is used. To make code much more readable and easier to design and debug, the state values are parameters. Another advantage of using parameters is that the state explicit values are declared in a single place, at parameter declaration, therefore if their values need to be changed, only the parameter declaration is affected.

The state values are internal design options, therefore the parameters used for states are local ones. They are declared as local parameters, using the template '''localparam''' ''name''=''value''; The names of parameters are upper case letters, and may include digits and underline.

<syntaxhighlight lang = "verilog">
localparam STATE_S = 3'd0;
localparam STATE_P = 3'd1;
...
</syntaxhighlight>

'''Attention!'''
* The state values must be distinct! Otherwise you may end with a state having multiple names.
* Local parameter declarations are the first statements after the module interface. The order of statements for a module should be the following:
# '''module'''
# interface declaration (the list of inputs and outputs)
# localparam declarations
# internal wire and reg declarations
# description (structural with instantiations or behavioral with always processes and continuos assignments)
# '''endmodule'''

=== State transitions ===

All transitions are grouped in a single sequential '''always_ff''' process, with a '''case''' statement that groups transitions by current state.
The combinational function that computes the next state (the transition function) is implicitly described by the case statement and the statements for each case.
The state is updated sequentially because the '''always_ff''' process is sensitive only to the active clock edges.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst)
state <= STATE_S;
else begin
case(state)
STATE_S: begin
if(a)
state <= STATE_P;
else if(b)
state <= STATE_T;
else
state <= state; // stays in the same state
end
STATE_P: begin
if(b)
state <= STATE_R;
else
state <= state;
end
// other states with their transitions
default:
state <= STATE_S; // from undefined states jump to the initial state
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!
* The '''reg''' variable for the state must be declared with the required number of bits, which is the same as the number of bits declared for each value of the state value parameters.

=== Outputs ===

Since Moore outputs depend only on state they are described either through continuous assignments, or inside a combinational '''always_comb''' process.

If continuous assignments are used, the outputs are assigned logic expressions based on state:

<syntaxhighlight lang = "SystemVerilog">
assign y1 = (state == R);
</syntaxhighlight>

The combinational '''always''' process is preferred when state values are easier to group by states:
<syntaxhighlight lang = "SystemVerilog">
always_comb begin
case(state)
STATE_S: {y1, y2} = 2'b00;
STATE_P: {y1, y2} = 2'b00;
STATE_R: {y1, y2} = 2'b10;
// other states with their outputs
default: {y1, y2} = 2'b00;
endcase
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the combinational process are done with the blocking assignment operator, <syntaxhighlight lang="Verilog" inline>=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Create a new project in a new folder
* Design the automaton as the top level design entity
* Design a testbench with the input signals generated as in the figure below.
* Run simulation. If the design is correct the outputs should appear as in the figure.
* To implement the design assign BTN0, BTN1 and BTN2 to '''rst''', '''a''', and '''b''' inputs. Assign LED1 and LED2 to '''y1''' and '''y2''' outputs.

[[Fișier: appl9_moore_wave.png]]

== Exercise 2 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs are asserted for ONLY ONE CLOCK CYCLE.

[[Fișier: appl9_ex1.png]]

=== Mealy FSM ===

The circuit may be designed as a delayed Mealy FSM, with fewer states than if designed as a Moore FSM. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final state, '''V''', the outputs are active for one clock cycle, depending on the input values that determined the transition to it. All other transitions are with outputs '''0'''. From any state, the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_mealy.png]]

=== State transitions ===

The transition function is described in the same way as for the Moore FSM. However, there are only 4 states, therefore the '''state''' variable and the state value parameters have only 2 bits. The '''case''' inside the sequential process for transitions has also fewer cases.

=== Outputs ===

Since the delayed Mealy outputs depend both on the previous state AND the previous input values (at the last transition) they are described inside a sequential '''always_ff''' process.
The outputs must be declared of '''reg''' type.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst) begin
y1 <= 1'b0;
y2 <= 1'b0;
end
else begin
case(state)
STATE_S: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
// other states with their outputs
default: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Use the same project as before
* Redesign the automaton as a Mealy FSM
* The testbench should not be modified.
* Run simulation. If the design is correct the outputs should appear as in the figure below. The differences from the previous waveform are in the state values and output pulses.

[[Fișier: appl9_mealy_wave.png]]

== Exercise 3 ==

''Design an FSM for an automatic chocolate selling machine, which delivers chocolates at 2.5€. The machine accepts only coins of 50 cents and 1 euro, and does not return any change. When the amount of 2.5€ or more is reached, the machine delivers a chocolate and will resume the process, subtracting 2.5€ from the current amount. The process resumes with whatever amount remains after delivering, which may be 0 or 0.5€. ''

The inputs are the digital signals '''cents''', '''euro''' and '''ack'''.

When the user inserts a valid coin, the corresponding input, '''cents''' or '''euro''', is asserted and stays '''1''' for some clock cycles. The FSM considers the coin validated only after the corresponding input goes back to '''0'''.

The output is a digital signal, '''deliver''', that is asserted when the amount reaches or surpasses 2.5€ and stays asserted until the input '''ack''' is asserted. The FSM resumes the process after '''ack''' is deasserted.

The internal states of the FSM may be equivalent to the current amount, 0, 0.5, 1, 1.5, 2, 2.5 and 3 euros.

''Implement the FSM for the automatic chocolate selling machine using three push buttons for '''cents''', '''euro''' and '''ack''' inputs , an LED to indicate the '''deliver''' output, and another pushbutton for the reset (that resets the amount to 0).''

'''Hint'''

To easy the implementation and keep the FSM as simple as possible, the inputs '''cents''', '''euro''' and '''ack''', which are pulses of arbitrary length (that may last hundreds of thousands of clock cycles!), may be transformed to one cycle pulses, asserted during the clock cycle that follows the original pulse. The FSM uses these one clock cycle pulses to compute the transitions.

As an example, the '''euro''' input is transformed to '''euro_p''' internal signal, whose pulses last one clock cycle. These internal signal is further used by the FSM.

<syntaxhighlight lang = "SystemVerilog">
...

logic euro_d; // delayed version of the euro input
logic euro_p; // one clock cycle pulse to be used by the FSM
...
always_ff @(posedge clk) euro_d <= euro; // euro_d is the copy of euro input, shifted one clock cycle
assign euro_p = euro_d & ~euro; // euro_p is asserted one clock cycle after euro pulse has ended
...
</syntaxhighlight>

[[Fișier: appl9_ex3wave.png]]

Applications 9

2025-04-29T23:08:08Z

Zhascsi: /* State transitions */

Almost always the FSM is described behaviorally, leaving the CLC gate level generation and optimization to compiler/synthesizer. However, the usual behavioral description closely follows the block structure of the FSM, with one block that computes the transition function and another block that computes the output. The FSMs are of two categories:
* Moore FSM, whose outputs depend only on the current state
* Mealy FSM, whose outputs depend also on inputs

Most often the Mealy FSM is a delayed Mealy FSM. Its output depends on the previous state and on the input values at transition time.

== Exercise 1 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs remain asserted until reset.

[[Fișier: appl9_ex1.png]]

=== Moore FSM ===

The circuit may be designed as a Moore FSM, with two separate states for those two particular output configurations. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final states, '''R''' or '''U''', the automaton stays until reset. From any state the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_moore.png]]

=== State coding ===

It is not recommended to use explicit values whenever the state variable is used. To make code much more readable and easier to design and debug, the state values are parameters. Another advantage of using parameters is that the state explicit values are declared in a single place, at parameter declaration, therefore if their values need to be changed, only the parameter declaration is affected.

The state values are internal design options, therefore the parameters used for states are local ones. They are declared as local parameters, using the template '''localparam''' ''name''=''value''; The names of parameters are upper case letters, and may include digits and underline.

<syntaxhighlight lang = "verilog">
localparam STATE_S = 3'd0;
localparam STATE_P = 3'd1;
...
</syntaxhighlight>

'''Attention!'''
* The state values must be distinct! Otherwise you may end with a state having multiple names.
* Local parameter declarations are the first statements after the module interface. The order of statements for a module should be the following:
# '''module'''
# interface declaration (the list of inputs and outputs)
# localparam declarations
# internal wire and reg declarations
# description (structural with instantiations or behavioral with always processes and continuos assignments)
# '''endmodule'''

=== State transitions ===

All transitions are grouped in a single sequential '''always_ff''' process, with a '''case''' statement that groups transitions by current state.
The combinational function that computes the next state (the transition function) is implicitly described by the case statement and the statements for each case.
The state is updated sequentially because the '''always_ff''' process is sensitive only to the active clock edges.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst)
state <= STATE_S;
else begin
case(state)
STATE_S: begin
if(a)
state <= STATE_P;
else if(b)
state <= STATE_T;
else
state <= state; // stays in the same state
end
STATE_P: begin
if(b)
state <= STATE_R;
else
state <= state;
end
// other states with their transitions
default:
state <= STATE_S; // from undefined states jump to the initial state
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!
* The '''reg''' variable for the state must be declared with the required number of bits, which is the same as the number of bits declared for each value of the state value parameters.

=== Outputs ===

Since Moore outputs depend only on state they are described either through continuous assignments, or inside a combinational '''always''' process.

If continuous assignments are used, the outputs are assigned logic expressions based on state:

<syntaxhighlight lang = "SystemVerilog">
assign y1 = (state == R);
</syntaxhighlight>

The combinational '''always''' process is preferred when state values are easier to group by states:
<syntaxhighlight lang = "SystemVerilog">
always_comb begin
case(state)
STATE_S: {y1, y2} = 2'b00;
STATE_P: {y1, y2} = 2'b00;
STATE_R: {y1, y2} = 2'b10;
// other states with their outputs
default: {y1, y2} = 2'b00;
endcase
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the combinational process are done with the blocking assignment operator, <syntaxhighlight lang="Verilog" inline>=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Create a new project in a new folder
* Design the automaton as the top level design entity
* Design a testbench with the input signals generated as in the figure below.
* Run simulation. If the design is correct the outputs should appear as in the figure.
* To implement the design assign BTN0, BTN1 and BTN2 to '''rst''', '''a''', and '''b''' inputs. Assign LED1 and LED2 to '''y1''' and '''y2''' outputs.

[[Fișier: appl9_moore_wave.png]]

== Exercise 2 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs are asserted for ONLY ONE CLOCK CYCLE.

[[Fișier: appl9_ex1.png]]

=== Mealy FSM ===

The circuit may be designed as a delayed Mealy FSM, with fewer states than if designed as a Moore FSM. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final state, '''V''', the outputs are active for one clock cycle, depending on the input values that determined the transition to it. All other transitions are with outputs '''0'''. From any state, the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_mealy.png]]

=== State transitions ===

The transition function is described in the same way as for the Moore FSM. However, there are only 4 states, therefore the '''state''' variable and the state value parameters have only 2 bits. The '''case''' inside the sequential process for transitions has also fewer cases.

=== Outputs ===

Since the delayed Mealy outputs depend both on the previous state AND the previous input values (at the last transition) they are described inside a sequential '''always_ff''' process.
The outputs must be declared of '''reg''' type.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst) begin
y1 <= 1'b0;
y2 <= 1'b0;
end
else begin
case(state)
STATE_S: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
// other states with their outputs
default: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Use the same project as before
* Redesign the automaton as a Mealy FSM
* The testbench should not be modified.
* Run simulation. If the design is correct the outputs should appear as in the figure below. The differences from the previous waveform are in the state values and output pulses.

[[Fișier: appl9_mealy_wave.png]]

== Exercise 3 ==

''Design an FSM for an automatic chocolate selling machine, which delivers chocolates at 2.5€. The machine accepts only coins of 50 cents and 1 euro, and does not return any change. When the amount of 2.5€ or more is reached, the machine delivers a chocolate and will resume the process, subtracting 2.5€ from the current amount. The process resumes with whatever amount remains after delivering, which may be 0 or 0.5€. ''

The inputs are the digital signals '''cents''', '''euro''' and '''ack'''.

When the user inserts a valid coin, the corresponding input, '''cents''' or '''euro''', is asserted and stays '''1''' for some clock cycles. The FSM considers the coin validated only after the corresponding input goes back to '''0'''.

The output is a digital signal, '''deliver''', that is asserted when the amount reaches or surpasses 2.5€ and stays asserted until the input '''ack''' is asserted. The FSM resumes the process after '''ack''' is deasserted.

The internal states of the FSM may be equivalent to the current amount, 0, 0.5, 1, 1.5, 2, 2.5 and 3 euros.

''Implement the FSM for the automatic chocolate selling machine using three push buttons for '''cents''', '''euro''' and '''ack''' inputs , an LED to indicate the '''deliver''' output, and another pushbutton for the reset (that resets the amount to 0).''

'''Hint'''

To easy the implementation and keep the FSM as simple as possible, the inputs '''cents''', '''euro''' and '''ack''', which are pulses of arbitrary length (that may last hundreds of thousands of clock cycles!), may be transformed to one cycle pulses, asserted during the clock cycle that follows the original pulse. The FSM uses these one clock cycle pulses to compute the transitions.

As an example, the '''euro''' input is transformed to '''euro_p''' internal signal, whose pulses last one clock cycle. These internal signal is further used by the FSM.

<syntaxhighlight lang = "SystemVerilog">
...

logic euro_d; // delayed version of the euro input
logic euro_p; // one clock cycle pulse to be used by the FSM
...
always_ff @(posedge clk) euro_d <= euro; // euro_d is the copy of euro input, shifted one clock cycle
assign euro_p = euro_d & ~euro; // euro_p is asserted one clock cycle after euro pulse has ended
...
</syntaxhighlight>

[[Fișier: appl9_ex3wave.png]]

Applications 9

2025-04-29T23:07:09Z

Zhascsi: /* Exercise 2 */

Almost always the FSM is described behaviorally, leaving the CLC gate level generation and optimization to compiler/synthesizer. However, the usual behavioral description closely follows the block structure of the FSM, with one block that computes the transition function and another block that computes the output. The FSMs are of two categories:
* Moore FSM, whose outputs depend only on the current state
* Mealy FSM, whose outputs depend also on inputs

Most often the Mealy FSM is a delayed Mealy FSM. Its output depends on the previous state and on the input values at transition time.

== Exercise 1 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs remain asserted until reset.

[[Fișier: appl9_ex1.png]]

=== Moore FSM ===

The circuit may be designed as a Moore FSM, with two separate states for those two particular output configurations. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final states, '''R''' or '''U''', the automaton stays until reset. From any state the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_moore.png]]

=== State coding ===

It is not recommended to use explicit values whenever the state variable is used. To make code much more readable and easier to design and debug, the state values are parameters. Another advantage of using parameters is that the state explicit values are declared in a single place, at parameter declaration, therefore if their values need to be changed, only the parameter declaration is affected.

The state values are internal design options, therefore the parameters used for states are local ones. They are declared as local parameters, using the template '''localparam''' ''name''=''value''; The names of parameters are upper case letters, and may include digits and underline.

<syntaxhighlight lang = "verilog">
localparam STATE_S = 3'd0;
localparam STATE_P = 3'd1;
...
</syntaxhighlight>

'''Attention!'''
* The state values must be distinct! Otherwise you may end with a state having multiple names.
* Local parameter declarations are the first statements after the module interface. The order of statements for a module should be the following:
# '''module'''
# interface declaration (the list of inputs and outputs)
# localparam declarations
# internal wire and reg declarations
# description (structural with instantiations or behavioral with always processes and continuos assignments)
# '''endmodule'''

=== State transitions ===

All transitions are grouped in a single sequential '''always''' process, with a '''case''' statement that groups transitions by current state.
The combinational function that computes the next state (the transition function) is implicitly described by the case statement and the statements for each case.
The state is updated sequentially because the '''always''' process is sensitive only to clock edges.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst)
state <= STATE_S;
else begin
case(state)
STATE_S: begin
if(a)
state <= STATE_P;
else if(b)
state <= STATE_T;
else
state <= state; // stays in the same state
end
STATE_P: begin
if(b)
state <= STATE_R;
else
state <= state;
end
// other states with their transitions
default:
state <= STATE_S; // from undefined states jump to the initial state
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!
* The '''reg''' variable for the state must be declared with the required number of bits, which is the same as the number of bits declared for each value of the state value parameters.

=== Outputs ===

Since Moore outputs depend only on state they are described either through continuous assignments, or inside a combinational '''always''' process.

If continuous assignments are used, the outputs are assigned logic expressions based on state:

<syntaxhighlight lang = "SystemVerilog">
assign y1 = (state == R);
</syntaxhighlight>

The combinational '''always''' process is preferred when state values are easier to group by states:
<syntaxhighlight lang = "SystemVerilog">
always_comb begin
case(state)
STATE_S: {y1, y2} = 2'b00;
STATE_P: {y1, y2} = 2'b00;
STATE_R: {y1, y2} = 2'b10;
// other states with their outputs
default: {y1, y2} = 2'b00;
endcase
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the combinational process are done with the blocking assignment operator, <syntaxhighlight lang="Verilog" inline>=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Create a new project in a new folder
* Design the automaton as the top level design entity
* Design a testbench with the input signals generated as in the figure below.
* Run simulation. If the design is correct the outputs should appear as in the figure.
* To implement the design assign BTN0, BTN1 and BTN2 to '''rst''', '''a''', and '''b''' inputs. Assign LED1 and LED2 to '''y1''' and '''y2''' outputs.

[[Fișier: appl9_moore_wave.png]]

== Exercise 2 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs are asserted for ONLY ONE CLOCK CYCLE.

[[Fișier: appl9_ex1.png]]

=== Mealy FSM ===

The circuit may be designed as a delayed Mealy FSM, with fewer states than if designed as a Moore FSM. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final state, '''V''', the outputs are active for one clock cycle, depending on the input values that determined the transition to it. All other transitions are with outputs '''0'''. From any state, the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_mealy.png]]

=== State transitions ===

The transition function is described in the same way as for the Moore FSM. However, there are only 4 states, therefore the '''state''' variable and the state value parameters have only 2 bits. The '''case''' inside the sequential process for transitions has also fewer cases.

=== Outputs ===

Since the delayed Mealy outputs depend both on the previous state AND the previous input values (at the last transition) they are described inside a sequential '''always_ff''' process.
The outputs must be declared of '''reg''' type.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst) begin
y1 <= 1'b0;
y2 <= 1'b0;
end
else begin
case(state)
STATE_S: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
// other states with their outputs
default: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Use the same project as before
* Redesign the automaton as a Mealy FSM
* The testbench should not be modified.
* Run simulation. If the design is correct the outputs should appear as in the figure below. The differences from the previous waveform are in the state values and output pulses.

[[Fișier: appl9_mealy_wave.png]]

== Exercise 3 ==

''Design an FSM for an automatic chocolate selling machine, which delivers chocolates at 2.5€. The machine accepts only coins of 50 cents and 1 euro, and does not return any change. When the amount of 2.5€ or more is reached, the machine delivers a chocolate and will resume the process, subtracting 2.5€ from the current amount. The process resumes with whatever amount remains after delivering, which may be 0 or 0.5€. ''

The inputs are the digital signals '''cents''', '''euro''' and '''ack'''.

When the user inserts a valid coin, the corresponding input, '''cents''' or '''euro''', is asserted and stays '''1''' for some clock cycles. The FSM considers the coin validated only after the corresponding input goes back to '''0'''.

The output is a digital signal, '''deliver''', that is asserted when the amount reaches or surpasses 2.5€ and stays asserted until the input '''ack''' is asserted. The FSM resumes the process after '''ack''' is deasserted.

The internal states of the FSM may be equivalent to the current amount, 0, 0.5, 1, 1.5, 2, 2.5 and 3 euros.

''Implement the FSM for the automatic chocolate selling machine using three push buttons for '''cents''', '''euro''' and '''ack''' inputs , an LED to indicate the '''deliver''' output, and another pushbutton for the reset (that resets the amount to 0).''

'''Hint'''

To easy the implementation and keep the FSM as simple as possible, the inputs '''cents''', '''euro''' and '''ack''', which are pulses of arbitrary length (that may last hundreds of thousands of clock cycles!), may be transformed to one cycle pulses, asserted during the clock cycle that follows the original pulse. The FSM uses these one clock cycle pulses to compute the transitions.

As an example, the '''euro''' input is transformed to '''euro_p''' internal signal, whose pulses last one clock cycle. These internal signal is further used by the FSM.

<syntaxhighlight lang = "SystemVerilog">
...

logic euro_d; // delayed version of the euro input
logic euro_p; // one clock cycle pulse to be used by the FSM
...
always_ff @(posedge clk) euro_d <= euro; // euro_d is the copy of euro input, shifted one clock cycle
assign euro_p = euro_d & ~euro; // euro_p is asserted one clock cycle after euro pulse has ended
...
</syntaxhighlight>

[[Fișier: appl9_ex3wave.png]]

Applications 9

2025-04-29T23:06:23Z

Zhascsi: /* Exercise 1 */

Almost always the FSM is described behaviorally, leaving the CLC gate level generation and optimization to compiler/synthesizer. However, the usual behavioral description closely follows the block structure of the FSM, with one block that computes the transition function and another block that computes the output. The FSMs are of two categories:
* Moore FSM, whose outputs depend only on the current state
* Mealy FSM, whose outputs depend also on inputs

Most often the Mealy FSM is a delayed Mealy FSM. Its output depends on the previous state and on the input values at transition time.

== Exercise 1 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs remain asserted until reset.

[[Fișier: appl9_ex1.png]]

=== Moore FSM ===

The circuit may be designed as a Moore FSM, with two separate states for those two particular output configurations. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final states, '''R''' or '''U''', the automaton stays until reset. From any state the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_moore.png]]

=== State coding ===

It is not recommended to use explicit values whenever the state variable is used. To make code much more readable and easier to design and debug, the state values are parameters. Another advantage of using parameters is that the state explicit values are declared in a single place, at parameter declaration, therefore if their values need to be changed, only the parameter declaration is affected.

The state values are internal design options, therefore the parameters used for states are local ones. They are declared as local parameters, using the template '''localparam''' ''name''=''value''; The names of parameters are upper case letters, and may include digits and underline.

<syntaxhighlight lang = "verilog">
localparam STATE_S = 3'd0;
localparam STATE_P = 3'd1;
...
</syntaxhighlight>

'''Attention!'''
* The state values must be distinct! Otherwise you may end with a state having multiple names.
* Local parameter declarations are the first statements after the module interface. The order of statements for a module should be the following:
# '''module'''
# interface declaration (the list of inputs and outputs)
# localparam declarations
# internal wire and reg declarations
# description (structural with instantiations or behavioral with always processes and continuos assignments)
# '''endmodule'''

=== State transitions ===

All transitions are grouped in a single sequential '''always''' process, with a '''case''' statement that groups transitions by current state.
The combinational function that computes the next state (the transition function) is implicitly described by the case statement and the statements for each case.
The state is updated sequentially because the '''always''' process is sensitive only to clock edges.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst)
state <= STATE_S;
else begin
case(state)
STATE_S: begin
if(a)
state <= STATE_P;
else if(b)
state <= STATE_T;
else
state <= state; // stays in the same state
end
STATE_P: begin
if(b)
state <= STATE_R;
else
state <= state;
end
// other states with their transitions
default:
state <= STATE_S; // from undefined states jump to the initial state
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!
* The '''reg''' variable for the state must be declared with the required number of bits, which is the same as the number of bits declared for each value of the state value parameters.

=== Outputs ===

Since Moore outputs depend only on state they are described either through continuous assignments, or inside a combinational '''always''' process.

If continuous assignments are used, the outputs are assigned logic expressions based on state:

<syntaxhighlight lang = "SystemVerilog">
assign y1 = (state == R);
</syntaxhighlight>

The combinational '''always''' process is preferred when state values are easier to group by states:
<syntaxhighlight lang = "SystemVerilog">
always_comb begin
case(state)
STATE_S: {y1, y2} = 2'b00;
STATE_P: {y1, y2} = 2'b00;
STATE_R: {y1, y2} = 2'b10;
// other states with their outputs
default: {y1, y2} = 2'b00;
endcase
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the combinational process are done with the blocking assignment operator, <syntaxhighlight lang="Verilog" inline>=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Create a new project in a new folder
* Design the automaton as the top level design entity
* Design a testbench with the input signals generated as in the figure below.
* Run simulation. If the design is correct the outputs should appear as in the figure.
* To implement the design assign BTN0, BTN1 and BTN2 to '''rst''', '''a''', and '''b''' inputs. Assign LED1 and LED2 to '''y1''' and '''y2''' outputs.

[[Fișier: appl9_moore_wave.png]]

== Exercise 2 ==

''Design an automaton that determines the order in which two buttons are pressed. The buttons generate logic signals, '''a''' and '''b''', that are '''1''' if the corresponding button is pressed. The automaton has two logic outputs, '''Y1''' and '''Y2'''. '''Y1''' is asserted if '''a''' was pressed first, followed by '''b'''. '''Y2''' is asserted if '''b''' was pressed first, followed by '''a'''. The outputs are asserted for ONLY ONE CLOCK CYCLE. The reset is active '''0'''.''

[[Fișier: appl9_ex1.png]]

=== Mealy FSM ===

The circuit may be designed as a delayed Mealy FSM, with fewer states than if designed as a Moore FSM. In the graph below only the transitions to different states are shown. If their conditions are not met, the FSM stays in the current state, whatever it is. In the final state, '''V''', the outputs are active for one clock cycle, depending on the input values that determined the transition to it. All other transitions are with outputs '''0'''. From any state, the reset forces the FSM to its initial state, '''S'''.

[[Fișier: appl9_mealy.png]]

=== State transitions ===

The transition function is described in the same way as for the Moore FSM. However, there are only 4 states, therefore the '''state''' variable and the state value parameters have only 2 bits. The '''case''' inside the sequential process for transitions has also fewer cases.

=== Outputs ===

Since the delayed Mealy outputs depend both on the previous state AND the previous input values (at the last transition) they are described inside a sequential '''always''' process.
The outputs must be declared of '''reg''' type.

<syntaxhighlight lang = "SystemVerilog">
always_ff @(posedge clk) begin
if(~rst) begin
y1 <= 1'b0;
y2 <= 1'b0;
end
else begin
case(state)
STATE_S: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
// other states with their outputs
default: begin
y1 <= 1'b0;
y2 <= 1'b0;
end
endcase
end
end
</syntaxhighlight>

'''Attention!'''
* All assignments inside the sequential process are done with the nonblocking assignment operator, <syntaxhighlight lang="Verilog" inline><=</syntaxhighlight>
* Don't forget the '''default''' case!

=== Requirements ===
* Use the same project as before
* Redesign the automaton as a Mealy FSM
* The testbench should not be modified.
* Run simulation. If the design is correct the outputs should appear as in the figure below. The differences from the previous waveform are in the state values and output pulses.

[[Fișier: appl9_mealy_wave.png]]

== Exercise 3 ==

''Design an FSM for an automatic chocolate selling machine, which delivers chocolates at 2.5€. The machine accepts only coins of 50 cents and 1 euro, and does not return any change. When the amount of 2.5€ or more is reached, the machine delivers a chocolate and will resume the process, subtracting 2.5€ from the current amount. The process resumes with whatever amount remains after delivering, which may be 0 or 0.5€. ''

The inputs are the digital signals '''cents''', '''euro''' and '''ack'''.

When the user inserts a valid coin, the corresponding input, '''cents''' or '''euro''', is asserted and stays '''1''' for some clock cycles. The FSM considers the coin validated only after the corresponding input goes back to '''0'''.

The output is a digital signal, '''deliver''', that is asserted when the amount reaches or surpasses 2.5€ and stays asserted until the input '''ack''' is asserted. The FSM resumes the process after '''ack''' is deasserted.

The internal states of the FSM may be equivalent to the current amount, 0, 0.5, 1, 1.5, 2, 2.5 and 3 euros.

''Implement the FSM for the automatic chocolate selling machine using three push buttons for '''cents''', '''euro''' and '''ack''' inputs , an LED to indicate the '''deliver''' output, and another pushbutton for the reset (that resets the amount to 0).''

'''Hint'''

To easy the implementation and keep the FSM as simple as possible, the inputs '''cents''', '''euro''' and '''ack''', which are pulses of arbitrary length (that may last hundreds of thousands of clock cycles!), may be transformed to one cycle pulses, asserted during the clock cycle that follows the original pulse. The FSM uses these one clock cycle pulses to compute the transitions.

As an example, the '''euro''' input is transformed to '''euro_p''' internal signal, whose pulses last one clock cycle. These internal signal is further used by the FSM.

<syntaxhighlight lang = "SystemVerilog">
...

logic euro_d; // delayed version of the euro input
logic euro_p; // one clock cycle pulse to be used by the FSM
...
always_ff @(posedge clk) euro_d <= euro; // euro_d is the copy of euro input, shifted one clock cycle
assign euro_p = euro_d & ~euro; // euro_p is asserted one clock cycle after euro pulse has ended
...
</syntaxhighlight>

[[Fișier: appl9_ex3wave.png]]

2025-04-29T22:54:13Z

Zhascsi: Zhascsi a încărcat o versiune nouă pentru Fișier:Appl9 mealy wave.png

Digital Integrated Circuits (lab)

2025-04-29T22:46:10Z

Applications 8

2025-04-21T21:36:22Z

Zhascsi:

A random access memory is an address-based data storage block, with a highly regular structure, which may be logically defined either as a bi-dimensional array of bits, or a uni-dimensional list of data words. Each row of the array, or each item of the list has a unique address. The addresses form a contiguous set of integers, starting from zero and running up to the highest address which defines the size of the address space, usually a power of 2. The memory capacity is therefore the number of address locations, N, times the width of the memory location (or of the memory word), W. These two numbers are the main parameters of any memory:
* N - the number of address locations, also the number of words;
* W - the number of bits for each location, or the data word width;
The storage capacity is N x W bits, but the memory capacity may also be given in bytes.

Being a vector of words or a bidimensional array of bits, the memory could be described using a single bidimensional variable, usually declared as a vector of multibit '''reg''' items. A memory array of N locations, with W bits per location is declared as:

<syntaxhighlight lang = "SystemVerilog">
logic [W-1: 0] memory [0: N-1];
</syntaxhighlight>

'''Attention!'''
* the width of the word is declared as usual, with msb as the left index, <syntaxhighlight lang="SystemVerilog" inline>[msb:0]</syntaxhighlight>
* the length of the memory is declared after the variable name, and starts with 0, the right index being the highest index of the vector, <syntaxhighlight lang="SystemVerilog" inline>[0:endindex]</syntaxhighlight>

There are two kinds of memories:
* read-only memories
* writable memories

Memories can also be classified by their synchronous or asynchronous character:
* asynchronous - read data is immediately available at the output, write is performed as into a latch
* synchronous - all operations are synchronized by one of the clock edges.

== Exercise 1 ==
=== ROM - Read-Only Memory ===

It may be described as a purely combinational logic circuit, whose output (data) is a logic function of its input (address). The transcoder from [[Applications 4#transcoder|Applications 4]] is nothing else than a ROM, with '''value''' input acting as an address that selects a particular location from where data is read and sent out as '''seg'''. There it was described behaviorally with a '''case''' statement that had a branch for each combination of input value bits.

[[Fișier: appl8_rom.png]]

A more flexible description employs a single memory array, declared as a vector of '''reg''' variables, and a statement that assigns the selected (addressed) element of the memory vector to the memory output.

<syntaxhighlight lang = "SystemVerilog">
assign dout = memory[addr];
</syntaxhighlight>

=== Memory initialization task ===

Memory arrays may be initialized with predefined values from a text file using verilog system tasks '''$readmemb''' and '''$readmemh'''. '''$readmemb''' reads predefined values given in binary, while '''$readmemh''' is used if values are given in hexadecimal. These verilog system tasks have two mandatory arguments and two optional arguments, in the following order:
# initialization filename, given as a string (between double quotes)
# the memory array variable name
# the start address (optional)
# the end address (optional)
If the start and end addresses are not given, the memory array is initialized from the first address (address zero) until the last address or until the end of initialization file is reached.

If the memory initialization file, ''meminit.txt'', resides in the project's folder, and the memory array to be initialized is '''mem''' inside the memory instance '''dut''', the testbench may initialize the memory right at the beginning of the simulation:

<syntaxhighlight lang="Verilog">
initial $readmemb("../../meminit.txt", dut.mem);
</syntaxhighlight>

If the initialization is intended to be done for the implemented memory, the initialization process must be placed inside the memory module, in which case the memory array name is just the variable array to be initialized:

<syntaxhighlight lang="SystemVerilog">
initial $readmemb("../../meminit.txt", mem);
</syntaxhighlight>

The filename, the first argument of '''$readmemb''' and '''$readmemh''' tasks, may be given either relative to the simulation folder (as in the previous two examples), or as the complete absolute filename, with the pathname starting from the linux root, '''/''', for example <syntaxhighlight lang="Verilog" inline>"/home/student/rom/meminit.txt"</syntaxhighlight> if ''meminit.txt'' file resides in the project's folder ''rom'', created in the student's home directory ''/home/student''.

=== Memory initialization file ===

The initialization file is a text file with values written in binary (using '''0''' and '''1''' symbols) or in hexadecimal (using digits and letters '''a''' to '''f''', either uppercase of lowercase). Values are separated by white spaces, tabs or newlines. Comments (started with '''//''' as in verilog) are ignored. An example of a binary initialization file:
<syntaxhighlight lang = "bash">
// four values in binary text format
00000011
00001111
00111111
11111111
</syntaxhighlight>

The same initialization sequence, but given as a hexadecimal text file:
<syntaxhighlight lang = "bash">
// four values in hexadecimal text format
03
0f
3f
ff
</syntaxhighlight>

* Start a new project, '''rom''', in a newly created folder '''rom'''
* Create a new verilog file ''rom.sv'' that describes a 16x8 ROM using a vector variable and a continuous assignment.
* Create a testbench, '''rom_tb''', that drives the input of '''rom''' with a sequence of addresses from 0 to highest one. Run simulation.
* Open a text editor, write some values in binary format on successive lines, and save the file into the ''rom'' folder with the name ''meminit.txt''
* In the testbench module add an '''initial''' process with a single statement that calls the system task for memory initialization. Run simulation.
* Assign the segments of a display to '''dout''', and 4 switches, from SW3 to SW0, to '''addr'''.
* In the '''rom''' module add an '''initial''' process with a single statement that calls the system task for memory initialization. Pay atention how its second argument is given - the array variable is now directly accesible. Compile the project and program the FPGA.

== Exercise 2 ==
=== RAM - Read-Write Memory ===

A synchronous memory reacts only on clock edges. The addresses are sampled at clock edges, the output changes also on clock edges, and the write is performed on clock edges too.

[[Fișier: appl8_ram.png]]

The FPGA has dedicated blocks for memory implementation, the so called ''ram blocks'', or ''ramblocks''. In order for the synthesis to map a memory description to a ''ramblock'', the sequential description must conform to a template:
<syntaxhighlight lang="SystemVerilog">
always @(posedge clk) begin
if(~we) // if write is enabled,
mem[addr] <= wdata; // update the addressed location to wdata value
rdata <= mem[addr]; // data read from the addressed location is transferred to the output
end
</syntaxhighlight>

* Start a new project, '''ram''', in a new folder '''ram'''
* Create a new verilog file ''ram.sv'' that describes a 16x4 RAM using a vector variable and a sequential '''always''' process that assigns to '''rdata''' output the value of the memory location selected by '''addr'''. In the same process update the same location with '''wdata''' value if '''we''' input is active (active at '''1''').
* Create a testbench, '''ram_tb''', which writes some data to four addresses, and then reads the same addresses in the same order, as indicated in the waveforms below. Don't forget the clock! Run simulation and check that the written data are correctly read afterwards.
* Assign LEDs to the output, switches to the '''addr''' and '''wdata''' inputs, a push button to the write enable input, and the board's source clock to '''clk''' input.
* Compile, program the FPGA and test the RAM. Set switches to an address and a data value, then briefly push the write enable button. The LEDs will change accordingly. Change the address and data and push again the write enable button. Change back the address switches and see if the previously written configuration reappears on LED.

[[Fișier: appl8_ram_wave.png]]

Digital Integrated Circuits (lab)

2025-04-21T21:28:15Z

Zhascsi:

# [[Applications 1 | Laboratory 1]]
# [[Applications 2 | Laboratory 2]]
# [[Applications 3 | Laboratory 3]]
# [[Applications 4 | Laboratory 4]]
# [[Applications 5 | Laboratory 5]]
# Test 1
# [[Applications 6 | Laboratory 6]]
# [[Applications 7 | Laboratory 7]]
# [[Applications 8 | Laboratory 8]]

== Verilog Tutorials ==
* [http://www.asic-world.com/verilog/veritut.html Verilog Tutorial] from ASIC World
* [http://chipverify.com/verilog/verilog-tutorial Verilog Tutorial] from Chip Verify
* [http://www.emmelmann.org/Library/Tutorials/docs/verilog_ref_guide/vlog_ref_top.html Verilog reference guide]

== Software ==
* [https://www.xilinx.com/products/design-tools/vivado/vivado-ml.html Vivado™ ML Standard Edition free]
* [https://wiki.dcae.pub.ro/images/2/24/VivadoNewProjectTutorial.pdf Vivado New Project Tutorial]

== Hardware ==
[https://www.realdigital.org/hardware/boolean Boolean Board] from RealDigital
* [https://www.realdigital.org/doc/02013cd17602c8af749f00561f88ae21 Boolean Board - user manual]
* [[Boolean Board - Pinout]]
To implement a circuit on Boolean Board you should select the following target device in Project Settings: '''xc7s50csga324-1'''

Applications 7

2025-04-13T15:15:05Z

Zhascsi: /* 32 bit Counter : Synchronous load */

The counter is one of the most used digital blocks and surely one of the best known outside the world of electronics. Any microprocessor has a program counter, without which it can not run programs on the computer. The program counter generates a sequence of memory addresses in ascending order, one in each clock period, and occasionally jumps in the program to an address other than the next one.

== Example 1 ==
=== 32 bit Counter : Behavioral description ===

[[File: appl7_cnt_32.png]]

The simplest counter of all, in terms of functionality, uninterruptedly generates an ordered sequence of numbers, cycle by cycle. An upward counter generates the sequence in increasing order: 0, 1, 2, 3, 4 a.s.o., After it reaches the highest number, with all bits 1, the next cycle it turns around to all bits 0.

As an automaton, the counter may be regarded as a register with an incrementer closing the outer loop. The behavioral description needs only a sequential '''always''' process to update the counter value, and an assignment for the next value of the counter.

<syntaxhighlight lang="SystemVerilog">
always_ff @(posedge clk) begin
cnt <= cnt + 1;
end
</syntaxhighlight>

* create a new project
* create a new source file for '''cnt32''', and describe it as shown above
* assign fpga pins to connect an external clock and LEDs to four of the output bits, as indicated below
* compile and program the FPGA. The red LEDs should be blinking, LED0 about once a second, LED1 twice slower, LED2 twice slower than LED1 a.s.o.

[[File: Zlab7_cnt_32_led.png]]

=== 32 bit Counter : Initial state ===

* in the same project add a verilog file for '''cnt32_tb'''. In the testbench you need only to generate the clock. Simulate and observe the counter output waveform.

Why the output of '''cnt32''' is completely unknown in simulation, whereas its output on FPGA works as expected?

However, if you looked carefully how the LEDs started blinking immediately after the FPGA had been programmed, you noticed that they started from a random configuration (some LEDs light on, the others off). The initial configuration of counter's internal flip-flops is unknown at power-up. They clearly settle after power-up at some logic values, but those values cannot be predicted. The simulator cannot guess them, so it starts with an unknown value, and incrementing an unknown value you get also an unknown value.

A workaround to initialize the '''cnt''' variable in simulation is to force its value from outside the '''cnt32''' module, directly from the testbench module.

During simulation we can have direct access to any (variable) signal inside the tested module if we use its full name, an unique name within the block hierarchy of the dut instance. The full name of a signal is written in the same way the full name of a variable in an object-oriented program is written:

<syntaxhighlight lang="verilog">
topInstanceName.signal

topInstanceName.blockInstanceName.signal

topInstanceName.blockInstanceName.subblockInstanceName.signal

</syntaxhighlight>

In the case of our counter, if in the test module its instance is named '''dut''', the '''cnt''' variable can be initialized in step 0 of the simulation directly from the testbench module:

<syntaxhighlight lang="verilog">
initial dut.cnt=0;
</syntaxhighlight>

This mode of access should be used with parsimony and only in test modules. It is not a synthesized statement and cannot be used in design modules! It is recommended to use direct access in test modules only for the purpose of reading (monitoring) variables that are not accessible trough the top-level design interface.

'''Attention!'''
* It is forbidden in a design module to use direct access to an internal signal of another module.

Much more elegant is to provide the counter with a reset or clear input, that is used to initialize the counter at the reset or to bring the counter to the initial state whenever needed.

=== 32 bit Counter : Reset ===

* add the '''rst''' pin to '''cnt32''' module, and change the sequential process such that the counter is set to 0 if reset is applied. '''rst''' is synchronous and active 1.
* add an initial process to the testbench to apply the reset pulse for at least two clock cycles. Rerun the simulation and see the effect of the reset.
* assign a pushbutton (BTN) to '''rst''' input.
* compile and program the FPGA

[[File: Zlab7 cnt 32 rst.png]]

=== 32 bit Counter : Count enable ===

It is useful for many counter applications to be able to sometime freeze the counting. An additional control signal, counter enable ('''ce'''), enables the counting only when it's active.

[[File: Zlab7_cnt_32_en.png]]

* add the '''ce''' pin to '''cnt32''' module, and change the sequential process such that the counting is enabled only if '''ce''' is 1.

<syntaxhighlight lang="SystemVerilog">
always_ff @(posedge clk) begin
if(rst) begin
// initialization at reset
end
else begin
// everything else, including count enable control
end
end
</syntaxhighlight>

* add another initial process to the testbench to change from time to time the '''ce''' value.
* assign a switch (SW0) to '''ce''' input
* compile and program the FPGA

=== 32 bit Counter : Synchronous load ===

Another very useful feature is to bring the counter state to whatever desired value ('''target''' value). This feature makes easy the design of frequency dividers and lots of counter based automata.

[[File: Zlab7_cnt_32_load.png]]

When load input ('''ld''') is active, the active clock edge causes the counter to load the value of the '''target''' input. If both control inputs ('''ld''' and '''ce''') are active, the load command has priority. All functions of this counter can be arranged in a table:

{| class="wikitable"
|- bgcolor="#ddeeff" align="left"
| ld || ce ||next cnt value|| function
|- bgcolor="#ddffdd" align="left"
|0 ||0 ||cnt ||freeze
|- bgcolor="#ddffdd" align="left"
|0 ||1 ||cnt+1 ||count
|- bgcolor="#ddffdd" align="left"
|1 ||X ||target ||load
|}

The X in the first row means that the value of '''ce''' input doesn't matter (it may be either '''0''' or '''1''') because '''ld''' has priority over '''ce'''. The truth table can thus be substantially compressed. Instead of two separate rows for the input combinations ('''ld'''='''1''', '''ce'''='''0''') and ('''ld'''='''1''', '''ce'''='''1'''), for which the function is the same (load), a single combination is used ('''ld'''='''1''', '''ce'''='''X''').

This compaction can also be used in Verilog table constructions, such as the 'case' statement. In order to use the X value in specifying the cases of the instruction, the alternative '''casex''' statement, which has the same format as the '''case''' statement, must be used:

<syntaxhighlight lang="verilog">
casex (expression_case)
value1: instruction1
...
default: instruction
endcase
</syntaxhighlight>

Unlike the '''case''' block, which admits only precise numerical values for each branch, the '''casex''' block allows some bits to be undefined for some branches. For example, the combinations for active '''ld''' can be combined into a single branch:

<syntaxhighlight lang="verilog">
casex({ld,ce})
2'b1X: out <= target;
// other cases
endcase
</syntaxhighlight>

which is equivalent to:

<syntaxhighlight lang="verilog">
case({ld,ce})
2'b10,
2'b11: out <= target;
// other cases
endcase
</syntaxhighlight>

* change '''cnt32''' behavioral description to conform to a synchronous counter with a synchronous load.
* add an '''initial''' process in the testbench to load a particular target value after some time. Try to reproduce the stimuli scenario from the figure below and see if you get the same output as in the figure:

[[File: Lab7_cnt_32_load_wave.png]]

Fișier:Lab7 cnt 32 load wave.png

2025-04-13T15:12:09Z

Zhascsi:

Applications 7

2025-04-13T12:18:35Z

Zhascsi: /* 32 bit Counter : Synchronous load */

The counter is one of the most used digital blocks and surely one of the best known outside the world of electronics. Any microprocessor has a program counter, without which it can not run programs on the computer. The program counter generates a sequence of memory addresses in ascending order, one in each clock period, and occasionally jumps in the program to an address other than the next one.

== Example 1 ==
=== 32 bit Counter : Behavioral description ===

[[File: appl7_cnt_32.png]]

The simplest counter of all, in terms of functionality, uninterruptedly generates an ordered sequence of numbers, cycle by cycle. An upward counter generates the sequence in increasing order: 0, 1, 2, 3, 4 a.s.o., After it reaches the highest number, with all bits 1, the next cycle it turns around to all bits 0.

As an automaton, the counter may be regarded as a register with an incrementer closing the outer loop. The behavioral description needs only a sequential '''always''' process to update the counter value, and an assignment for the next value of the counter.

<syntaxhighlight lang="SystemVerilog">
always_ff @(posedge clk) begin
cnt <= cnt + 1;
end
</syntaxhighlight>

* create a new project
* create a new source file for '''cnt32''', and describe it as shown above
* assign fpga pins to connect an external clock and LEDs to four of the output bits, as indicated below
* compile and program the FPGA. The red LEDs should be blinking, LED0 about once a second, LED1 twice slower, LED2 twice slower than LED1 a.s.o.

[[File: Zlab7_cnt_32_led.png]]

=== 32 bit Counter : Initial state ===

* in the same project add a verilog file for '''cnt32_tb'''. In the testbench you need only to generate the clock. Simulate and observe the counter output waveform.

Why the output of '''cnt32''' is completely unknown in simulation, whereas its output on FPGA works as expected?

However, if you looked carefully how the LEDs started blinking immediately after the FPGA had been programmed, you noticed that they started from a random configuration (some LEDs light on, the others off). The initial configuration of counter's internal flip-flops is unknown at power-up. They clearly settle after power-up at some logic values, but those values cannot be predicted. The simulator cannot guess them, so it starts with an unknown value, and incrementing an unknown value you get also an unknown value.

A workaround to initialize the '''cnt''' variable in simulation is to force its value from outside the '''cnt32''' module, directly from the testbench module.

During simulation we can have direct access to any (variable) signal inside the tested module if we use its full name, an unique name within the block hierarchy of the dut instance. The full name of a signal is written in the same way the full name of a variable in an object-oriented program is written:

<syntaxhighlight lang="verilog">
topInstanceName.signal

topInstanceName.blockInstanceName.signal

topInstanceName.blockInstanceName.subblockInstanceName.signal

</syntaxhighlight>

In the case of our counter, if in the test module its instance is named '''dut''', the '''cnt''' variable can be initialized in step 0 of the simulation directly from the testbench module:

<syntaxhighlight lang="verilog">
initial dut.cnt=0;
</syntaxhighlight>

This mode of access should be used with parsimony and only in test modules. It is not a synthesized statement and cannot be used in design modules! It is recommended to use direct access in test modules only for the purpose of reading (monitoring) variables that are not accessible trough the top-level design interface.

'''Attention!'''
* It is forbidden in a design module to use direct access to an internal signal of another module.

Much more elegant is to provide the counter with a reset or clear input, that is used to initialize the counter at the reset or to bring the counter to the initial state whenever needed.

=== 32 bit Counter : Reset ===

* add the '''rst''' pin to '''cnt32''' module, and change the sequential process such that the counter is set to 0 if reset is applied. '''rst''' is synchronous and active 1.
* add an initial process to the testbench to apply the reset pulse for at least two clock cycles. Rerun the simulation and see the effect of the reset.
* assign a pushbutton (BTN) to '''rst''' input.
* compile and program the FPGA

[[File: Zlab7 cnt 32 rst.png]]

=== 32 bit Counter : Count enable ===

It is useful for many counter applications to be able to sometime freeze the counting. An additional control signal, counter enable ('''ce'''), enables the counting only when it's active.

[[File: Zlab7_cnt_32_en.png]]

* add the '''ce''' pin to '''cnt32''' module, and change the sequential process such that the counting is enabled only if '''ce''' is 1.

<syntaxhighlight lang="SystemVerilog">
always_ff @(posedge clk) begin
if(rst) begin
// initialization at reset
end
else begin
// everything else, including count enable control
end
end
</syntaxhighlight>

* add another initial process to the testbench to change from time to time the '''ce''' value.
* assign a switch (SW0) to '''ce''' input
* compile and program the FPGA

=== 32 bit Counter : Synchronous load ===

Another very useful feature is to bring the counter state to whatever desired value ('''target''' value). This feature makes easy the design of frequency dividers and lots of counter based automata.

[[File: Zlab7_cnt_32_load.png]]

When load input ('''ld''') is active, the active clock edge causes the counter to load the value of the '''target''' input. If both control inputs ('''ld''' and '''ce''') are active, the load command has priority. All functions of this counter can be arranged in a table:

{| class="wikitable"
|- bgcolor="#ddeeff" align="left"
| ld || ce ||next cnt value|| function
|- bgcolor="#ddffdd" align="left"
|0 ||0 ||cnt ||freeze
|- bgcolor="#ddffdd" align="left"
|0 ||1 ||cnt+1 ||count
|- bgcolor="#ddffdd" align="left"
|1 ||X ||target ||load
|}

The X in the first row means that the value of '''ce''' input doesn't matter (it may be either '''0''' or '''1''') because '''ld''' has priority over '''ce'''. The truth table can thus be substantially compressed. Instead of two separate rows for the input combinations ('''ld'''='''0''', '''ce'''='''0''') and ('''ld'''='''0''', '''ce'''='''1'''), for which the function is the same (load), a single combintion is used ('''ld'''='''0''', '''ce'''='''X''').

This compaction can also be used in Verilog table constructions, such as the 'case' statement. In order to use the X value in specifying the cases of the instruction, the alternative '''casex''' statement, which has the same format as the '''case''' statement, must be used:

<syntaxhighlight lang="verilog">
casex (expression_case)
value1: instruction1
...
default: instruction
endcase
</syntaxhighlight>

Unlike the '''case''' block, which admits only precise numerical values for each branch, the '''casex''' block allows some bits to be undefined for some branches. For example, the combinations for active '''ld''' can be combined into a single branch:

<syntaxhighlight lang="verilog">
casex({ld,ce})
2'b1X: out <= target;
// other cases
endcase
</syntaxhighlight>

which is equivalent to:

<syntaxhighlight lang="verilog">
case({ld,ce})
2'b10,
2'b11: out <= target;
// other cases
endcase
</syntaxhighlight>

* change '''cnt32''' behavioral description to conform to a synchronous counter with a synchronous load.
* add an '''initial''' process in the testbench to load a particular target value after some time. Try to reproduce the stimuli scenario from the figure below and see if you get the same output as in the figure:

[[File: appl7_cnt_32_load_wave.png]]

Fișier:Zlab7 cnt 32 load.png

2025-04-13T12:16:09Z

Zhascsi:

Applications 7

2025-04-13T12:15:11Z

Zhascsi: /* 32 bit Counter : Count enable */

The counter is one of the most used digital blocks and surely one of the best known outside the world of electronics. Any microprocessor has a program counter, without which it can not run programs on the computer. The program counter generates a sequence of memory addresses in ascending order, one in each clock period, and occasionally jumps in the program to an address other than the next one.

== Example 1 ==
=== 32 bit Counter : Behavioral description ===

[[File: appl7_cnt_32.png]]

The simplest counter of all, in terms of functionality, uninterruptedly generates an ordered sequence of numbers, cycle by cycle. An upward counter generates the sequence in increasing order: 0, 1, 2, 3, 4 a.s.o., After it reaches the highest number, with all bits 1, the next cycle it turns around to all bits 0.

As an automaton, the counter may be regarded as a register with an incrementer closing the outer loop. The behavioral description needs only a sequential '''always''' process to update the counter value, and an assignment for the next value of the counter.

<syntaxhighlight lang="SystemVerilog">
always_ff @(posedge clk) begin
cnt <= cnt + 1;
end
</syntaxhighlight>

* create a new project
* create a new source file for '''cnt32''', and describe it as shown above
* assign fpga pins to connect an external clock and LEDs to four of the output bits, as indicated below
* compile and program the FPGA. The red LEDs should be blinking, LED0 about once a second, LED1 twice slower, LED2 twice slower than LED1 a.s.o.

[[File: Zlab7_cnt_32_led.png]]

=== 32 bit Counter : Initial state ===

* in the same project add a verilog file for '''cnt32_tb'''. In the testbench you need only to generate the clock. Simulate and observe the counter output waveform.

Why the output of '''cnt32''' is completely unknown in simulation, whereas its output on FPGA works as expected?

However, if you looked carefully how the LEDs started blinking immediately after the FPGA had been programmed, you noticed that they started from a random configuration (some LEDs light on, the others off). The initial configuration of counter's internal flip-flops is unknown at power-up. They clearly settle after power-up at some logic values, but those values cannot be predicted. The simulator cannot guess them, so it starts with an unknown value, and incrementing an unknown value you get also an unknown value.

A workaround to initialize the '''cnt''' variable in simulation is to force its value from outside the '''cnt32''' module, directly from the testbench module.

During simulation we can have direct access to any (variable) signal inside the tested module if we use its full name, an unique name within the block hierarchy of the dut instance. The full name of a signal is written in the same way the full name of a variable in an object-oriented program is written:

<syntaxhighlight lang="verilog">
topInstanceName.signal

topInstanceName.blockInstanceName.signal

topInstanceName.blockInstanceName.subblockInstanceName.signal

</syntaxhighlight>

In the case of our counter, if in the test module its instance is named '''dut''', the '''cnt''' variable can be initialized in step 0 of the simulation directly from the testbench module:

<syntaxhighlight lang="verilog">
initial dut.cnt=0;
</syntaxhighlight>

This mode of access should be used with parsimony and only in test modules. It is not a synthesized statement and cannot be used in design modules! It is recommended to use direct access in test modules only for the purpose of reading (monitoring) variables that are not accessible trough the top-level design interface.

'''Attention!'''
* It is forbidden in a design module to use direct access to an internal signal of another module.

Much more elegant is to provide the counter with a reset or clear input, that is used to initialize the counter at the reset or to bring the counter to the initial state whenever needed.

=== 32 bit Counter : Reset ===

* add the '''rst''' pin to '''cnt32''' module, and change the sequential process such that the counter is set to 0 if reset is applied. '''rst''' is synchronous and active 1.
* add an initial process to the testbench to apply the reset pulse for at least two clock cycles. Rerun the simulation and see the effect of the reset.
* assign a pushbutton (BTN) to '''rst''' input.
* compile and program the FPGA

[[File: Zlab7 cnt 32 rst.png]]

=== 32 bit Counter : Count enable ===

It is useful for many counter applications to be able to sometime freeze the counting. An additional control signal, counter enable ('''ce'''), enables the counting only when it's active.

[[File: Zlab7_cnt_32_en.png]]

* add the '''ce''' pin to '''cnt32''' module, and change the sequential process such that the counting is enabled only if '''ce''' is 1.

<syntaxhighlight lang="SystemVerilog">
always_ff @(posedge clk) begin
if(rst) begin
// initialization at reset
end
else begin
// everything else, including count enable control
end
end
</syntaxhighlight>

* add another initial process to the testbench to change from time to time the '''ce''' value.
* assign a switch (SW0) to '''ce''' input
* compile and program the FPGA

=== 32 bit Counter : Synchronous load ===

Another very useful feature is to bring the counter state to whatever desired value ('''target''' value). This feature makes easy the design of frequency dividers and lots of counter based automata.

[[File: appl7_cnt_32_load.png]]

When load input ('''ld''') is active, the active clock edge causes the counter to load the value of the '''target''' input. If both control inputs ('''ld''' and '''ce''') are active, the load command has priority. All functions of this counter can be arranged in a table:

{| class="wikitable"
|- bgcolor="#ddeeff" align="left"
| ld || ce ||next cnt value|| function
|- bgcolor="#ddffdd" align="left"
|0 ||X ||target ||load
|- bgcolor="#ddffdd" align="left"
|1 ||0 ||cnt ||freeze
|- bgcolor="#ddffdd" align="left"
|1 ||1 ||cnt+1 ||count
|}

The X in the first row means that the value of '''ce''' input doesn't matter (it may be either '''0''' or '''1''') because '''ld''' has priority over '''ce'''. The truth table can thus be substantially compressed. Instead of two separate rows for the input combinations ('''ld'''='''0''', '''ce'''='''0''') and ('''ld'''='''0''', '''ce'''='''1'''), for which the function is the same (load), a single combintion is used ('''ld'''='''0''', '''ce'''='''X''').

This compaction can also be used in Verilog table constructions, such as the 'case' statement. In order to use the X value in specifying the cases of the instruction, the alternative '''casex''' statement, which has the same format as the '''case''' statement, must be used:

<syntaxhighlight lang="verilog">
casex (expression_case)
value1: instruction1
...
default: instruction
endcase
</syntaxhighlight>

Unlike the '''case''' block, which admits only precise numerical values for each branch, the '''casex''' block allows some bits to be undefined for some branches. For example, the combinations for active '''ld''' can be combined into a single branch:

<syntaxhighlight lang="verilog">
casex({ld,ce})
2'b0X: out <= target;
// other cases
endcase
</syntaxhighlight>

which is equivalent to:

<syntaxhighlight lang="verilog">
case({ld,ce})
2'b00,
2'b01: out <= target;
// other cases
endcase
</syntaxhighlight>

* change '''cnt32''' behavioral description to conform to a synchronous counter with a synchronous load.
* add an '''initial''' process in the testbench to load a particular target value after some time. Try to reproduce the stimuli scenario from the figure below and see if you get the same output as in the figure:

[[File: appl7_cnt_32_load_wave.png]]