nyuuzyou/wikis huggingface dataset:
Fsm3s

<html><style type="text/css">
table.fsm3 {border-collapse: collapse;}
table.fsm3 tr th { padding: 5px 10px; border: 1px #000 solid; }
table.fsm3 tr td { text-align:center; border: 1px #000 solid; }
</style></html>
See also: State transition logic for this FSM
The following is the state transition table for a Moore state machine with one input, one output, and four states. Implement this state machine. Include a synchronous reset that resets the FSM to state A. (This is the same problem as Fsm3 but with a synchronous reset.)
StateNext stateOutput
in=0in=1
AAB0
BCB0
CAD0
DCB1
Fsm hdlc

Synchronous HDLC framing involves decoding a continuous bit stream of data to look for bit patterns that indicate the beginning and end of frames (packets). Seeing exactly 6 consecutive 1s (i.e., 01111110) is a "flag" that indicate frame boundaries. To avoid the data stream from accidentally containing "flags", the sender inserts a zero after every 5 consecutive 1s which the receiver must detect and discard. We also need to signal an error if there are 7 or more consecutive 1s.
Create a finite state machine to recognize these three sequences:
*0111110: Signal a bit needs to be discarded (disc).
*01111110: Flag the beginning/end of a frame (flag).
*01111111...: Error (7 or more 1s) (err).
When the FSM is reset, it should be in a state that behaves as though the previous input were 0.
Here are some example sequences that illustrate the desired operation.
Discard 0111110:
<wavedrom>
{ signal: [{ name: "clk", wave: "p.........." },
 { name: "in", wave: "x01....0x..", node:".......a..." },
 { name: "disc", wave: "0.......10.", node:"........b.." },
 { name: "flag", wave: "0.........." },
 { name: "err", wave: "0.........." },
], edge: [ 'a-~>b']
 }
</wavedrom>
Flag 01111110:
<wavedrom>
{ signal: [{ name: "clk", wave: "p..........." },
 { name: "in", wave: "x01.....0x..", node:"........a..." },
 { name: "disc", wave: "0..........." },
 { name: "flag", wave: "0........10.", node:".........b.." },
 { name: "err", wave: "0..........." },
], edge: [ 'a-~>b']
 }
</wavedrom>
Reset behaviour and error 01111111...:
<wavedrom>
{ signal: [{ name: "clk", wave: "p.............." },
 { name: "reset", wave:"x10.......|...." },
 { name: "in", wave: "x.1.......|.0x.", node:"........a...c." },
 { name: "disc", wave: "0.........|...." },
 { name: "flag", wave: "0.........|...." },
 { name: "err", wave: "0........1|..0.", node:".........b...d." },
], edge: [ 'a-~>b', 'c-~>d']
 }
</wavedrom>
Implement this state machine.
Fsm onehot

Given the following state machine with 1 input and 2 outputs:
Suppose this state machine uses one-hot encoding, where state[0] through state[9] correspond to the states S0 though S9, respectively. The outputs are zero unless otherwise specified.
Implement the state transition logic and output logic portions of the state machine (but not the state flip-flops). You are given the current state in state[9:0] and must produce next_state[9:0] and the two outputs. Derive the logic equations by inspection assuming a one-hot encoding. (The testbench will test with non-one hot inputs to make sure you're not trying to do something more complicated).
Fsm ps2

The PS/2 mouse protocol sends messages that are three bytes long. However, within a continuous byte stream, it's not obvious where messages start and end. The only indication is that the first byte of each three byte message always has bit[3]=1 (but bit[3] of the other two bytes may be 1 or 0 depending on data). 
We want a finite state machine that will search for message boundaries when given an input byte stream. The algorithm we'll use is to discard bytes until we see one with bit[3]=1. We then assume that this is byte 1 of a message, and signal the receipt of a message once all 3 bytes have been received (done). 
The FSM should signal done in the cycle immediately after the third byte of each message was successfully received.
=== Some timing diagrams to explain the desired behaviour ===
Under error-free conditions, every three bytes form a message:
<wavedrom>
{ signal: [{ name: "clk", wave: "p........." },
 { name: "reset", wave:"10........" },
 { name: "in[3]", wave:"x1x.1x.1x." },
 { name: "done", wave: "x0..10.10." },
],
foot:{
 tock:[, 'byte1', 'byte2', 'byte3','byte1', 'byte2', 'byte3','byte1', 'byte2', 'byte3'] } }
</wavedrom>
When an error occurs, search for byte 1:
<wavedrom>
{ signal: [{ name: "clk", wave: "p..........." },
 { name: "reset", wave:"10.........." },
 { name: "in[3]", wave:"x1x.0.1x.1x." },
 { name: "done", wave: "x0..10...10." },
],
foot:{
 tock:[, 'byte1', 'byte2', 'byte3','?', '?', 'byte1','byte2', 'byte3', 'byte1', 'byte2', 'byte3'] } }
</wavedrom>
Note that this is not the same as a 1xx sequence recognizer. Overlapping sequences are not allowed here:
<wavedrom>
{ signal: [{ name: "clk", wave: "p..........." },
 { name: "reset", wave:"10.........." },
 { name: "in[3]", wave:"010101......" },
 { name: "done", wave: "x0..10..10.1" },
],
foot:{
 tock:[, 'byte1', 'byte2', 'byte3','?', 'byte1','byte2', 'byte3', 'byte1','byte2', 'byte3' ] } }
</wavedrom>
Fsm ps2data

See also: PS/2 packet parser.
Now that you have a state machine that will identify three-byte messages in a PS/2 byte stream, add a datapath that will also output the 24-bit (3 byte) message whenever a packet is received (out_bytes[23:16] is the first byte, out_bytes[15:8] is the second byte, etc.).
out_bytes needs to be valid whenever the done signal is asserted. You may output anything at other times (i.e., don't-care).
For example:
<wavedrom>
{ 
config:{hscale:2},
signal: [{ name: "clk", wave: "p........." },
 { name: "reset", wave:"10........" },
 { name: "in[7:0]", wave:"x=========", data:['08', '01', '02', '38', 'ff', 'fe', '08', '03', '04'] },
 { name: "in[3]", wave:"x10.10.10." },
 { name: "done", wave: "x0..10.10." },
 { name: "out_bytes", wave:"x...=x.=x.", data:['080102', '38fffe', '080304'] },
],
foot:{
 tock:[, 'byte1', 'byte2', 'byte3','byte1', 'byte2', 'byte3','byte1', 'byte2', 'byte3'] } }
</wavedrom>
Fsm serial

In many (older) serial communications protocols, each data byte is sent along with a start bit and a stop bit, to help the receiver delimit bytes from the stream of bits. One common scheme is to use one start bit (0), 8 data bits, and 1 stop bit (1). The line is also at logic 1 when nothing is being transmitted (idle).
Design a finite state machine that will identify when bytes have been correctly received when given a stream of bits. It needs to identify the start bit, wait for all 8 data bits, then verify that the stop bit was correct. If the stop bit does not appear when expected, the FSM must wait until it finds a stop bit before attempting to receive the next byte.
=== Some timing diagrams ===
Error-free:
<wavedrom skin="narrow">
{ signal: [{ name: "clk", wave: "p.........................." },
 { name: "reset", wave:"10........................." },
 { name: "in", wave:"1.0x.......10x.......1..0x." },
 { name: "done", wave: "0...........10........10..." },
],
foot:{
 tock:['idle', , 'start', , , , 'data', , , , , 'stop', , , , , , , , , , 'stop', , , 'start'] } }
</wavedrom>
Stop bit not found. First byte is discarded:
<wavedrom>
{ signal: [{ name: "clk", wave: "p.........................." },
 { name: "reset", wave:"10........................." },
 { name: "in", wave:"1.0x.......0.10x.......10x." },
 { name: "done", wave: "0.......................10." },
],
foot:{
 tock:['idle', , 'start', , , , 'data', , , , , '?','?!', , 'start', , , , 'data', , , , , 'stop' ] } }
</wavedrom>
Fsm serialdata

See also: Serial receiver
Now that you have a finite state machine that can identify when bytes are correctly received in a serial bitstream, add a datapath that will output the correctly-received data byte. out_byte needs to be valid when done is 1, and is don't-care otherwise.
Note that the serial protocol sends the least significant bit first.
=== Some timing diagrams ===
Error-free:
<wavedrom skin="narrow">
{ signal: [{ name: "clk", wave: "p.........................." },
 { name: "reset", wave:"10........................." },
 { name: "in", wave: "1.01.010.1010.10..1.01..0x." , node: "...A.......B.C.......D.", phase:0 },
 { name: "done", wave: "0...........10........10..." },
{ name: "out_byte",wave: "x...........=x........=x...", data:['4b', '62'] },
],
edge: ['A<->B 0x4b', 'C<->D 0x62'],
foot:{
 tock:['idle', , 'start', , , , 'data', , , , , 'stop', , , , , , , , , , 'stop', , , 'start'] } }
</wavedrom>
Fsm serialdp

See also: <vlgstat tc="fsm_serialdata">Serial receiver and datapath</vlgstat>
We want to add parity checking to the serial receiver. Parity checking adds one extra bit after each data byte. We will use odd parity, where the number of 1s in the 9 bits received must be odd. For example, 101001011 satisfies odd parity (there are 5 1s), but 001001011 does not.
Change your FSM and datapath to perform odd parity checking. Assert the done signal only if a byte is correctly received and its parity check passes. Like the <vlgstat tc="fsm_serial">serial receiver FSM</vlgstat>, this FSM needs to identify the start bit, wait for all 9 (data and parity) bits, then verify that the stop bit was correct. If the stop bit does not appear when expected, the FSM must wait until it finds a stop bit before attempting to receive the next byte.
You are provided with the following module that can be used to calculate the parity of the input stream (It's a TFF with reset). The intended use is that it should be given the input bit stream, and reset at appropriate times so it counts the number of 1 bits in each byte.
module parity (
 input clk,
 input reset,
 input in,
 output reg odd);
 always @(posedge clk)
 if (reset) odd <= 0;
 else if (in) odd <= ~odd;
endmodule
Note that the serial protocol sends the least significant bit first, and the parity bit after the 8 data bits.
=== Some timing diagrams ===
No framing errors. Odd parity passes for first byte, fails for second byte.
<wavedrom skin="narrow">
{ signal: [{ name: "clk", wave: "p............................" },
 { name: "reset", wave:"10..........................." },
 { name: "in", wave: "1.01.010.101.0.10..1.01...0x." , node: "...A.......B..C.......D.", phase:0 },
 { name: "done", wave: "0............10.............." },
{ name: "out_byte",wave: "x............=x..............", data:['4b', '62'] },
],
edge: ['A<->B 0x4b', 'C<->D 0x62'],
foot:{
 tock:['idle', , 'start', , , , 'data', , , , , 'parity', , , , , , , , , , , 'parity', , , , 'start'] } }
</wavedrom>
Gates

Ok, let's try building several logic gates at the same time. Build a combinational circuit with two inputs, a and b.
There are 7 outputs, each with a logic gate driving it:
* out_and: a and b
* out_or: a or b
* out_xor: a xor b
* out_nand: a nand b
* out_nor: a nor b
* out_xnor: a xnor b
* out_anotb: a and-not b
Gates4

Build a combinational circuit with four inputs, in[3:0].
There are 3 outputs:
* out_and: output of a 4-input AND gate.
* out_or: output of a 4-input OR gate.
* out_xor: output of a 4-input XOR gate.
To review the AND, OR, and XOR operators, see <vlgstat tc=andgate/>, <vlgstat tc=norgate/>, and <vlgstat tc=xnorgate/>.
See also: <vlgstat tc="gates100">Even wider gates</vlgstat>.
Gatesv

You are given a four-bit input vector in[3:0]. We want to know some relationships between each bit and its neighbour:
* out_both: Each bit of this output vector should indicate whether both the corresponding input bit and its neighbour to the left (higher index) are '1'. For example, out_both[2] should indicate if in[2] and in[3] are both 1. Since in[3] has no neighbour to the left, the answer is obvious so we don't need to know out_both[3].
* out_any: Each bit of this output vector should indicate whether any of the corresponding input bit and its neighbour to the right are '1'. For example, out_any[2] should indicate if either in[2] or in[1] are 1. Since in[0] has no neighbour to the right, the answer is obvious so we don't need to know out_any[0].
* out_different: Each bit of this output vector should indicate whether the corresponding input bit is different from its neighbour to the left. For example, out_different[2] should indicate if in[2] is different from in[3]. For this part, treat the vector as wrapping around, so in[3]'s neighbour to the left is in[0].
Gatesv100

See also the shorter version: <vlgstat tc=gatesv>Gates and vectors</vlgstat>.
You are given a 100-bit input vector in[99:0]. We want to know some relationships between each bit and its neighbour:
* out_both: Each bit of this output vector should indicate whether both the corresponding input bit and its neighbour to the left are '1'. For example, out_both[98] should indicate if in[98] and in[99] are both 1. Since in[99] has no neighbour to the left, the answer is obvious so we don't need to know out_both[99].
* out_any: Each bit of this output vector should indicate whether any of the corresponding input bit and its neighbour to the right are '1'. For example, out_any[2] should indicate if either in[2] or in[1] are 1. Since in[0] has no neighbour to the right, the answer is obvious so we don't need to know out_any[0].
* out_different: Each bit of this output vector should indicate whether the corresponding input bit is different from its neighbour to the left. For example, out_different[98] should indicate if in[98] is different from in[99]. For this part, treat the vector as wrapping around, so in[99]'s neighbour to the left is in[0].
Lemmings1

<html></html>
<html></html>
The game Lemmings involves critters with fairly simple brains. So simple that we are going to model it using a finite state machine.
In the Lemmings' 2D world, Lemmings can be in one of two states: walking left or walking right. It will switch directions if it hits an obstacle. In particular, if a Lemming is bumped on the left, it will walk right. If it's bumped on the right, it will walk left. If it's bumped on both sides at the same time, it will still switch directions.
Implement a Moore state machine with two states, two inputs, and one output that models this behaviour.
<wavedrom>
{ signal: [{ name: "clk", wave: "p.............." },
 { name: "bump_left", wave: "0....10..1.0..." },
 { name: "bump_right", wave: "0.10.....1.0..." },
 { name: "walk_left", wave: "1.....0...10..." },
 { name: "walk_right", wave: "0.....1...01..." } ] }
</wavedrom>
See also: Lemmings2, Lemmings3, and Lemmings4.
Lemmings2

See also: Lemmings1.
In addition to walking left and right, Lemmings will fall (and presumably go "aaah!") if the ground disappears underneath them.
In addition to walking left and right and changing direction when bumped, when ground=0, the Lemming will fall and say "aaah!". When the ground reappears (ground=1), the Lemming will resume walking in the same direction as before the fall. Being bumped while falling does not affect the walking direction, and being bumped in the same cycle as ground disappears (but not yet falling), or when the ground reappears while still falling, also does not affect the walking direction.
Build a finite state machine that models this behaviour.
<wavedrom>
{ signal: [{ name: "clk", wave: "p............." },
 { name: "bump_left", wave: "0.10..1......." },
 { name: "bump_right", wave: "0..10........." },
 { name: "ground", wave: "1.....0...1..." },
 { name: "walk_left", wave: "1..01..0...10." },
 { name: "walk_right", wave: "0..10.......1." },
 { name: "aaah", wave: "0......1...0.." } ] }
</wavedrom>
See also: Lemmings3 and Lemmings4.
Lemmings3

See also: Lemmings1 and Lemmings2.
In addition to walking and falling, Lemmings can sometimes be told to do useful things, like dig (it starts digging when dig=1). A Lemming can dig if it is currently walking on ground (ground=1 and not falling), and will continue digging until it reaches the other side (ground=0). At that point, since there is no ground, it will fall (aaah!), then continue walking in its original direction once it hits ground again. As with falling, being bumped while digging has no effect, and being told to dig when falling or when there is no ground is ignored.
(In other words, a walking Lemming can fall, dig, or switch directions. If more than one of these conditions are satisfied, fall has higher precedence than dig, which has higher precedence than switching directions.)
Extend your finite state machine to model this behaviour.
<wavedrom>
{ signal: [
 { name: "clk", wave: "p............." },
 ['Inputs', { name: "bump_left", wave: "0...10........" },
 { name: "bump_right", wave: "0............." },
 { name: "ground", wave: "1.....0..1...." },
 { name: "dig", wave: "0.10.....10..." } ],
 ['Outputs', { name: "walk_left", wave: "1..0......1..." },
 { name: "walk_right", wave: "0............." },
 { name: "aaah", wave: "0......1..0..." }, 
 { name: "digging", wave: "0..1...0......" } ]
 ], 
foot:{
 tock:[, , ,,'bump ignored', ,, , , 'dig ignored', , ] 
 }
}
</wavedrom>
See also: Lemmings4.
Lemmings4

See also: Lemmings1, Lemmings2, and Lemmings3.
Although Lemmings can walk, fall, and dig, Lemmings aren't invulnerable. If a Lemming falls for too long then hits the ground, it can splatter. In particular, if a Lemming falls for more than 20 clock cycles then hits the ground, it will splatter and cease walking, falling, or digging (all 4 outputs become 0), forever (Or until the FSM gets reset). There is no upper limit on how far a Lemming can fall before hitting the ground. Lemmings only splatter when hitting the ground; they do not splatter in mid-air.
Extend your finite state machine to model this behaviour.
Falling for 20 cycles is survivable:
<wavedrom>
{ signal: [
 { name: "clk", wave: "p............" },
 { name: "ground", wave: "1.0...|..1..." },
 { name: "walk_left", wave: "1..0..|...1.." },
 { name: "aaah", wave: "0..1..|...0.." }, 
 ], 
foot:{
 tock:[, , ,1,2,3, '...', 18, 19, 20] 
 }
}
</wavedrom>
Falling for 21 cycles causes splatter:
<wavedrom>
{ signal: [
 { name: "clk", wave: "p............" },
 { name: "ground", wave: "1.0...|...1.." },
 { name: "walk_left", wave: "1..0..|......" },
 { name: "aaah", wave: "0..1..|....0." }, 
 ], 
foot:{
 tock:[, , ,1,2,3, '...', 18, 19, 20, 21, 'oops'] 
 }
}
</wavedrom>
Lfsr5

A linear feedback shift register is a shift register usually with a few XOR gates to produce the next state of the shift register. A Galois LFSR is one particular arrangement where bit positions with a "tap" are XORed with the output bit to produce its next value, while bit positions without a tap shift. If the taps positions are carefully chosen, the LFSR can be made to be "maximum-length". A maximum-length LFSR of n bits cycles through 2n-1 states before repeating (the all-zero state is never reached).
The following diagram shows a 5-bit maximal-length Galois LFSR with taps at bit positions 5 and 3. (Tap positions are usually numbered starting from 1). Note that I drew the XOR gate at position 5 for consistency, but one of the XOR gate inputs is 0.
Build this LFSR. The reset should reset the LFSR to 1.
Module

By now, you're familiar with a module, which is a circuit that interacts with its outside through input and output ports. Larger, more complex circuits are built by composing bigger modules out of smaller modules and other pieces (such as assign statements and always blocks) connected together. This forms a hierarchy, as modules can contain instances of other modules.
The figure below shows a very simple circuit with a sub-module. In this exercise, create one instance of module mod_a, then connect the module's three pins (in1, in2, and out) to your top-level module's three ports (wires a, b, and out). The module mod_a is provided for you — you must instantiate it.
When connecting modules, only the ports on the module are important. You do not need to know the code inside the module. The code for module mod_a looks like this:
module mod_a ( input in1, input in2, output out );
 // Module body
endmodule
The hierarchy of modules is created by instantiating one module inside another, as long as all of the modules used belong to the same project (so the compiler knows where to find the module). The code for one module is not written inside another module's body (Code for different modules are not nested).
You may connect signals to the module by port name or port position. For extra practice, try both methods.
=== Connecting Signals to Module Ports ===
There are two commonly-used methods to connect a wire to a port: by position or by name.
==== By position ====
The syntax to connect wires to ports by position should be familiar, as it uses a C-like syntax. When instantiating a module, ports are connected left to right according to the module's declaration. For example:
mod_a instance1 ( wa, wb, wc ); 
This instantiates a module of type mod_a and gives it an instance name of "instance1", then connects signal wa (outside the new module) to the first port (in1) of the new module, wb to the second port (in2), and wc to the third port (out). One drawback of this syntax is that if the module's port list changes, all instantiations of the module will also need to be found and changed to match the new module.
==== By name ====
Connecting signals to a module's ports by name allows wires to remain correctly connected even if the port list changes. This syntax is more verbose, however.
mod_a instance2 ( .out(wc), .in1(wa), .in2(wb) ); 
The above line instantiates a module of type mod_a named "instance2", then connects signal wa (outside the module) to the port named in1, wb to the port named in2, and wc to the port named out. Notice how the ordering of ports is irrelevant here because the connection will be made to the correct name, regardless of its position in the sub-module's port list. Also notice the period immediately preceding the port name in this syntax.
Category:Modules
Module add

You are given a module add16 that performs a 16-bit addition. Instantiate two of them to create a 32-bit adder. One add16 module computes the lower 16 bits of the addition result, while the second add16 module computes the upper 16 bits of the result, after receiving the carry-out from the first adder. Your 32-bit adder does not need to handle carry-in (assume 0) or carry-out (ignored), but the internal modules need to in order to function correctly. (In other words, the add16 module performs 16-bit a + b + cin, while your module performs 32-bit a + b).
Connect the modules together as shown in the diagram below. The provided module add16 has the following declaration:
module add16 ( input[15:0] a, input[15:0] b, input cin, output[15:0] sum, output cout );
Category:Modules
Module addsub

An adder-subtractor can be built from an adder by optionally negating one of the inputs, which is equivalent to inverting the input then adding 1. The net result is a circuit that can do two operations: (a + b + 0) and (a + ~b + 1). See Wikipedia if you want a more detailed explanation of how this circuit works.
Build the adder-subtractor below.
You are provided with a 16-bit adder module, which you need to instantiate twice:
module add16 ( input[15:0] a, input[15:0] b, input cin, output[15:0] sum, output cout );
Use a 32-bit wide XOR gate to invert the b input whenever sub is 1. (This can also be viewed as b[31:0] XORed with sub replicated 32 times. See <vlgstat tc=vector4>replication operator</vlgstat>.). Also connect the sub input to the carry-in of the adder.
Changes
*2020-02-15: Output signal name changed from result to sum.
Category:Modules