This shows you the differences between two versions of the page.
ac-is:lab-ie:lab02 [2023/11/19 22:58] ionut.pascal [Resources] |
ac-is:lab-ie:lab02 [2023/11/23 13:54] (current) ionut.pascal |
||
---|---|---|---|
Line 29: | Line 29: | ||
{{ ac-is:lab:lab00:d-flip-flop-timing.png?680 | Waveform}} | {{ ac-is:lab:lab00:d-flip-flop-timing.png?680 | Waveform}} | ||
<html><p align="center">Waveform</p></html> | <html><p align="center">Waveform</p></html> | ||
- | |||
=====The register===== | =====The register===== | ||
The flip-flop can store 1 bit of data. In order to extend the memory capacity, we can group several flip-flops together to store the data as a whole. When adding some controls and synchronizing the operations with the clock, we can call it a //register//. | The flip-flop can store 1 bit of data. In order to extend the memory capacity, we can group several flip-flops together to store the data as a whole. When adding some controls and synchronizing the operations with the clock, we can call it a //register//. | ||
A register, like any other sequencial circuits, is sensitive to //clk// signal and shall also consider the //reset//, synchronus or asyncronus. In order to control the acces to a bus, the main operations shall be taken into consideration: | A register, like any other sequencial circuits, is sensitive to //clk// signal and shall also consider the //reset//, synchronus or asyncronus. In order to control the acces to a bus, the main operations shall be taken into consideration: | ||
- | * reading - the current information is transported to the output of the module and put on the bus; | + | * reading - the current information is transported to the output of the module and put on the bus, controlled by ''oe'' (output enable); |
- | * writing - the information which is currently on the bus shall be saved inside. | + | * writing - the information which is currently on the bus shall be saved inside, controlled by ''we'' (write enable). |
The writing operation is synchronus; however, reading and reset can vary, depending on the usecase. | The writing operation is synchronus; however, reading and reset can vary, depending on the usecase. | ||
Analyse the block description below: | Analyse the block description below: | ||
{{ :ac-is:lab:lab06:register.png |}} | {{ :ac-is:lab:lab06:register.png |}} | ||
+ | |||
+ | ===== Exercises ===== | ||
+ | In order to implement the exercises, use the lab archive below, considering the simulator you have on your workstation. The files already have a Xilinx ISE / Vivado project that you are able to run; in addition, for this practice you already have a testing module; the checking will be performed visually during the lab practice. Follow the instructions and hints below and the zones marked with TODO in the corresponding files. | ||
==== Lab practice ==== | ==== Lab practice ==== | ||
+ | - Implement the **register**, by analysing the block diagram above and the implementation delails below: | ||
+ | * read is asynchronus: when ''oe'' is high, the ''out'' shall imediatelly be activated with the stored data; | ||
+ | * write is synchronus: when ''we'' is high, the input data found on the ''in'' is stored; the effect are seen at the next clock cycle; | ||
+ | * where should not be a dual access (write and read in the same time). | ||
+ | - Implement a simple **counter**, which increments it's value every clock cycle. The data shall be available to the output of the counter at any point. | ||
==== Home assignment ===== | ==== Home assignment ===== | ||
NOTE: You can start the implementation using the files from the lab practice and modify them accordingly! The work files for this will be uploaded later this week, however they will not contain any major improvements. | NOTE: You can start the implementation using the files from the lab practice and modify them accordingly! The work files for this will be uploaded later this week, however they will not contain any major improvements. | ||
- | - Implement the register considering both write and read operations are synchronus. Add a new port, //debug_output//, as an output with the same size, that will always show the content of the register. Upload a screenshot to prove that the read operation generates the result on the positive edge of the ''clk'' signal. | + | - (5p) Implement another type of **register**, considering both write and read operations are synchronus. Add a new port, //debug_output//, as an output with the same size, that will always show the content of the register. Upload a screenshot to prove that the read operation generates the result on the positive edge of the ''clk'' signal. |
* //Hint//: Synchronus operations are implemented in the sequencial blocks using the non-blocking assignments ''<='' | * //Hint//: Synchronus operations are implemented in the sequencial blocks using the non-blocking assignments ''<='' | ||
* //Hint//: Use the implementation from the lab as reference. | * //Hint//: Use the implementation from the lab as reference. | ||
* //Hint//: When adding the new port inside the working module //register//, don't forget to add it also in the test module! | * //Hint//: When adding the new port inside the working module //register//, don't forget to add it also in the test module! | ||
- | - Implement an enchanted counter, with 2 additinal inpus: ''direction'': 0 - counter increments it's value; 1 - counter decrement it's value and ''enable'': 0 - counter is disabled (the value remains the same) 1 - counter is enabled (it counts in the direction specified by the signal) | + | - (5p) Starting from exercise 2 from the lab practice, implement an **enchanted counter** with 2 additinal inpus: |
- | * //Hint//: Use the implementation from the lab as reference. | + | *''enable'': 0 - counter is disabled (the value remains the same) 1 - counter is enabled (it counts up or down, depending on the ''direction'' - see below) |
- | * //Hint//: Add relevant stimuli to the testcase to exercise all the possible behavior. Upload a screenshot and put a short description to explain the behavior that it is shown. | + | * ''direction'': 0 - counter increments it's value; 1 - counter decrement it's value |
+ | * //Hint//: Use the implementation from the lab as reference. | ||
+ | * //Hint//: Add relevant stimuli to the testcase to exercise all the possible behavior. Upload a screenshot and put a short description to explain the behavior that it is shown. | ||
===== Resources ===== | ===== Resources ===== | ||
Line 59: | Line 68: | ||
<ifauth @ac-is> | <ifauth @ac-is> | ||
- | |||
- | |||
- | |||
- | - registrul - variatii pentru citire / secvential sau combinational, cu comanda sau fara comanda | ||
- | - timer / counter - circuit pur secvential; niste implementari relativ la semnalul done: cand se face 1, cand nu. | ||
- | - exercitii cu operatori, atat pe partea secventiala cand si pe partea combinationala, pentru a demonstra logica. | ||
- | |||
- | |||
- | In order to implement the exercises, use the lab archive below, considering the simulator you have on your workstation. The files already have a Xilinx ISE / Vivado project that you are able to run; in addition, for this practice you already have a testing module; the checking will be performed visually during the lab practice. Follow the instructions and hints below and the zones marked with TODO in the corresponding files. | ||
- | |||
- | ==== Lab practice ==== | ||
- | - Implement an 8bit **Adder**, with 2 inputs and one output. | ||
- | - The implementation shall contain only continuous assignments; | ||
- | - The implementation shall use a procedural block; | ||
- | * //Hint//: Don't forget to consult the basics of Verilog from Lab0 until you are familiarized with the new programming language. | ||
- | * //Hint//: Follow the proper tutorial for understanding the simulation; skip the test-adding part if needed. | ||
- | - Add extra stimuli in order to have the carry bit exercised. | ||
- | * //Hint//: The values must be added in the //adder8_test//, the file which drives the stimuli to our module. | ||
- | - Implement a 4bit **Comparator** using only continuous assignments. This module has 2 inputs and 3 outputs ( less than, equal, grater than). | ||
- | * //Hint//: To verify a condition, '**?**' operator can be used. | ||
- | - Implement a 4:1 **Multiplexer**. Try to explain the generated waveform. | ||
- | - The implementation shall include a case construction. | ||
- | * //Hint//: Do not forget about the //default// state! | ||
- | - Let's make this tricky. Implement the multiplexor using the ' **?** ' operator. | ||
- | * //Note//: The ' **?** ' operator can replace //case// or //if-elseif-else// statements when using the **assign**. However, abusing it can lead to a not-so-understandable implementation | ||
- | |||
- | |||
- | |||
- | ==== Home assignment ==== | ||
- | For the home assignment, you should use the corresponding resources from below. | ||
- | - **(2p)** Change the adder8 module from exercise 1 by including a carry bit as an additional input. You can use any of //a// or //b// implementation. Add at least 5 data sets in adder8_test.sv, which will exercise the module and upload a screenshot with the simulation waveform to emphasize them. | ||
- | * //Hint//: You should modify the interface and the logic inside. | ||
- | * //Hint//: A complete testing shall exercise all of the inputs. | ||
- | - **(3p)** Change the implementation of the comparator, following the rules below: | ||
- | * Implement it using if constructs, using a procedural block; | ||
- | * Change the size of the inputs to 6 bits. | ||
- | * //Hint//: Do not forget to use the reg type when needed! | ||
- | * //Note//: In procedural blocks, the outputs shall have a value at any moment so that they do not become memory components at the synthesis level. Considering this, it is useful to initialize them in the beginning. | ||
- | - **(4p)** Implement a 8bit multiplier, with 2 inputs and one output. | ||
- | * //Hint//: Take as reference the adder8 module. | ||
- | * //Hint//: What is the size of the output? Consider the highest 8bit number. | ||
- | - **(4p)** Implement a tiny ALU (**A**rithmetical **L**ogical **U**nit), that shall be able to execute 16bit ADD and SUB operations. The ALU has 3 inputs, op1 (16bits), op2(16bits), sel(1bit) and 2 outputs, result(16bits) and carry(1bit). | ||
- | * //Hint//: Sel input selects the operation that is executed: 0 - ADD, 1 - SUB | ||
- | * //Hint//: You can use the concatenate operator { } in order to make the result a 17bit variable! | ||
- | * //Note//: When you operate the AL | ||
- | U inside a CPU, you have a fixed length bus available for all the data. | ||
- | |||
---- | ---- |