Differences
This shows you the differences between two versions of the page.
|
ac-is:lab-ie:lab02 [2023/11/19 23:01] ionut.pascal |
ac-is:lab-ie:lab02 [2023/11/23 13:54] (current) ionut.pascal |
||
|---|---|---|---|
| Line 33: | Line 33: | ||
| 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. | ||
| Line 44: | Line 44: | ||
| ==== 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. | ||
| - | - (5p) 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! | ||
| - | - (5p) 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 ===== | ||
