Department of Electronic Engineering
ELE00011H Digital Engineering Coursework Assessment 2021/22 SUMMARY DETAILS
This coursework (Lab Report) contributes 50% of the assessment for this module. Clearly indicate your Exam Number on every separate piece of work submitted.
Submission is via the VLE module submission point. The deadline is 12:00 noon on 25 February 2022, Spring Term, Week 7, Friday. Please try and submit early as any late submissions will be penalised. Assessment information including on late penalties is given in the Statement of Assessment.
Copyright By PowCoder代写 加微信 powcoder
ACADEMIC INTEGRITY
It is your responsibility to ensure that you understand and comply with the University’s policy on academic integrity. If this is your first year of study at the University then you also need to complete the mandatory Academic Integrity Tutorial. Further information is available at http://www.york.ac.uk/integrity/.
In particular please note:
● Unless the coursework specifies a group submission, you should assume that all submissions are individual and should therefore be your own work.
● All assessment submissions are subject to the Department’s policy on plagiarism and,
wherever possible, will be checked by the Department using Turnitin software.
UG Students: MSc Students:
ELE00011H Digital Engineering ELE00121M Digital Engineering for MSc
Laboratories: Session 1 Debouncers – Implementation and simulation
– ALL LABS SHOULD BE DONE IN GROUPS OF TWO STUDENTS
– A mark penalty will apply to single-student submissions unless agreed in advance
– Any issues related to groups (conflicts) should be communicated as soon as possible
– ALL LABS SHOULD BE INDIVIDUAL SUBMISSIONS
Report formatting:
There is no formal report structure – you will be marked on the items listed within each lab script. Most reports will include code printout and simulation screenshots – see Lab 1 appendices for guidelines.
The reports for labs 1 – 4 must be handed in, together in a single zip archive, via the VLE by the deadline indicated on the front page of the script. A single submission should be handed in for each group (by any member of the group).
Each lab report, containing all the material required in the order specified, should be submitted as a separate PDF file. The exam numbers of all members of the group should be printed on the front page of each PDF.
The PDF files must be named Yxxxxxxx-Yxxxxxxx_DE_Lab#.pdf, where the Yxxxxxxx are the exam numbers of the group members (normally two for UG students, one for MSc students) and # is the lab number.
In all cases, read carefully the instructions on the VLE submission page. Failure to follow the instructions could lead to your assignment not being marked and in any case to a mark penalty.
Submission weight on module mark: 7.5% Mark breakdown [30 marks]:
● General issues (e.g. documentation, layout and comments, structural issues): 10 marks
● Undergraduate students:
o Task 1A (e.g. VHDL code, testbench, simulation): 20 marks ● MSc students:
o Task 1A (e.g. VHDL code, testbench, simulation): 15 marks o Task 1B (e.g. VHDL code, testbench, simulation): 5 marks
Task A: Debouncer implementation and simulation by parameterization [all students]
Note: this exercise will use the Fibonacci memory circuit you designed in Lab 3a of the VHDL last year (last term for MSc students). You are welcome to re-use the same VHDL files. If you made mistakes in your code, integrate any feedback you have received, as the code will be again marked for quality: if you have not kept a copy of your submission and feedback, let me know!
NOTE: if you do not remember the procedure to create new projects, launch simulations, etc., please refer to lab 1 of the VHDL module (the script is still online on the module website).
To retrieve the code, create a new project, then import your VHDL files from the previous project. To do so, click on “Add Sources”, then select “Add or create design sources”. In the next window, click on “Add Files” and navigate to the VHDL files you want to import (do not include your testbench at this stage). Double-click on the files to add them the list, then tick the box next to “Copy sources into project”. Click “Finish”. The files should now be in your Design Sources list. Repeat the procedure for your testbench, this time selecting “Add or create design sources” in the pop-up window. The TB should appear in your Simulation Sources. Note that you will also need to include the DigEng.vhd library (downloadable from the module wiki) in your project (import it using the same procedure as above).
As you probably have noticed, the Xilinx debouncer you used in Digital Design is quite poor. In this task, you will design a more efficient debouncer. The schematic layout for the new debouncer is the following:
Note the reset-less DFF at the output of the counter. Also, the box labelled “=N-1” is a simple combinational comparator that outputs ‘1’ when the input is equal to N-1 (you have done several of these in the VHDL module, usually to generate “done” signals – the when/else VHDL construct is ideal for this).
Create a new entity (name it something sensible, but not “debouncer”, as that name is already in use by the Xilinx version) and implement the circuit. Can you understand how it works? Describe its operation as comments to the entity.
First, you will need to create a parameterizable counter (it might be simpler to create a separate entity and use it as a component). Use the code provided in the slides from the parameterizable VHDL lecture last year/term. If the counter is a component, make sure to include a generic map and a generic input to your debouncer as well. In any case, the debouncer entity should receive a generic value that sets the maximum value of the counter (in the figure, the generic is N for a counter from 0 to N-1).
Next, replace the Xilinx debouncers with the new version in the top level of your circuit. You will need to add a generic map to the instantiation and a new generic input. Set the default value of the generic to 50000000 (50 million): considering that the FPGA board uses a 100Mhz clock, this will provide a default debounce of (approximately) 0.5 seconds (any button press shorter than 0.5 seconds will be ignored). This is the value that will be used by the tools when you synthesize your circuit.
Of course, simulating for 50 million cycles is impossible. However, parameterization will help.
Open you existing testbench and add the generic map to the UUT. Set the generic value in the map to 6. Now the debouncer will trigger for every pulse longer than 5 clock cycles (i.e. any pulse that includes at least 5 rising edges of the clock). Because this is longer than the Xilinx debouncer, you might have to make your pulses longer in the stimulus process of your TB. Also, in order to test the new debouncer, try some shorter and longer pulses to verify that the debouncer operates correctly (ignores short pulses and transform
long pulses into a single pulse of 1 clock period). Observe the internal signals of the debouncers to verify that it operates as expected. Make sure to describe your testing strategy in the comments.
Synthesize the circuit and verify that the implementation uses the “real” debouncer (check the size of the counter that is generated by synthesis: does it match what you expect?)
Finally, implement the circuit on the board (the same XDC file you designed for the previous lab should still work). You should now be able to verify easily that short presses are being ignored!
The report for this lab should include, in this order:
▪ The commented VHDL code for the complete circuit, including all sub-components.
▪ The commented VHDL testbench for the simulation.
▪ The output of the simulation, including all significant internal signals. Note that the objective of this
task is to verify the operation of the debouncers, so while it is important to show that the circuit as a whole is working correctly, you will also need to show that, in particular, the debouncers are operating as expected.
▪ The “RTL Component Statistics” and “RTL Hierarchical Component Statistics” parts of the synthesis report. What is the size of the counters? Is it what you expected?
▪ Screenshots of the following schematics, together with a short analysis of how they match your VHDL code: (1) RTL top level with the ROM expanded; (2) RTL debouncer; (3) Synthesis top level with the ROM expanded.
Task B: Simulating alternative versions [MSc only]
The procedure you followed in Task A works extremely well when you can use parameterization to simulate smaller components and implement larger versions of the same components. While not devoid of potential problems (something that works with one timescale does not necessarily always work with different timings – e.g. when FSMs are involved) it nevertheless allows you to simulate the same hardware that will be implemented, even if “scaled down”.
However, in some cases this approach might not be possible, either because parameterization (and hence “scaling down”) is impossible or because you want to have to flexibility of simulating alternative implementations. In these cases, a more “general-purpose” solution is available through the use of the if-generate VHDL construct. Note however that this solution does not allow you to test the hardware that will actually be implemented, which will therefore have to be verified separately. It should therefore be used with a lot of caution!
Create a new project and import all the VHDL files from the previous task (including the Xilinx debouncer). Open the top level file and add a new generic “Simulation” of type Boolean. Set the default value to FALSE. This implies that in synthesis the value will be false, whereas in simulation you can override the value with a generic map.
Next, scroll down to the COUNT debouncer and replace the current instantiation to something like the following (the precise names depend on your choice in task A):
— Debounce count input – simulation version
SIM_CNT_DEBOUNCE: if SIMULATION generate
Count_Debouncer: entity work.Debouncer
end generate;
CLK => clk,
Sig => count,
Deb_Sig => deb_count
— Debounce count input – implementation version
IMP_CNT_DEBOUNCE: if not SIMULATION generate
Count_Debouncer: entity work.Debouncer_new
GENERIC MAP (LIMIT => DEB_LIMIT)
CLK => clk,
Sig => count,
Deb_Sig => deb_count
end generate;
Do the same for the RESET input.
Now open your testbench and add the new generic to the generic map of the UUT, setting its value to TRUE. The simulation will now use the Xilinx debouncer, while the implementation will use your new debouncer instead. You should not need to modify the input stimuli, except that you might want to re-visit your delays (as the Xilinx debouncer will accept all inputs longer than 2 clock cycles).
Implement the design in the boards and verify that it still operates as in task A.
The report for this lab should include, in this order:
▪ The commented VHDL code for only the components that were modified from task A (probably only the top level).
▪ The commented VHDL testbench for the simulation.
▪ The output of the simulation, including all significant internal signals. Note that the objective of this
task is to verify the if-generate construct, so make sure to show that the debouncers are operating as expected.
▪ The “RTL Component Statistics” and “RTL Hierarchical Component Statistics” part of the synthesis report. What is the size of the counters? Is it what you expected?
APPENDIX A: Report Guidelines – VHDL code
Example of good code printout:
● relevant comments (see appendix C)
● proper indenting (always align properly the code and use monospaced fonts)
● try to avoid breaking VHDL structures (e.g. processes, multiplexers) across page boundaries and
wrapping lines
● syntax highlighting greatly improves readability
library ieee;
use ieee.std_logic_1164.all;
— Positive-edge parameterizable left-shift register with serial load — and asynchronous reset
entity shift_reg is
WIDTH : positive := 8
rst : in std_logic;
clk : in std_logic;
load : in std_logic;
lsb : in std_logic;
output : out std_logic_vector(WIDTH-1 downto 0) — parallel data out
end shift_reg;
architecture BHV of shift_reg is
signal reg : std_logic_vector(WIDTH-1 downto 0); — register output
— Process for shift register – asynchronous reset
process(clk, rst) begin
if (rst = ‘1’) then
reg <= (others => ‘0’);
elsif (rising_edge(clk)) then if (load = ‘1’) then
— asynchronous reset to zero
reg <= reg(WIDTH-2 downto 0) & lsb; -- shift in the new LSB by concatenating -- the lsb input on the right-hand side
end process; output <= reg; end BHV;
-- register size
-- active-high reset
-- active-high load signal -- serial data in
How to achieve this using Notepad++ and Microsoft Word. A portable PC version of Notepad++ can be downloaded from the module wiki.
● Open the VHDL file in Notepad++
● Use menu command “Plugins” > “NppExport” > “Copy all format to clipboard” (note that this
command is installed by default in the portable version, but might require an additional plug-in in
some of the later versions of Notepad++)
● Paste in Microsoft Word using the “Keep source formatting” option
● Note that Notepad++ and Word should also be used to spell-check your comments and to
adjust indenting/line wrapping!
Example of non-acceptable code printout (minimal comments, indenting correct but much too deep, proportional font, no syntax highlighting, comment lines wrapping):
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity shift_reg is
generic (WIDTH : positive := 8); — size of register
port (rst clk
: in std_logic; : in std_logic;
output : out std_logic_vector(WIDTH-1 downto 0) );
end shift_reg;
architecture BHV of shift_reg is
signal reg : std_logic_vector(WIDTH-1 downto 0);
— shift-left register with asynchronous reset and load sh_reg: process(clk, rst)
if (rst = ‘1’) then
reg <= (others => ‘0’); elsif (rising_edge(clk)) then
if (load = ‘1’) then
reg <= reg(WIDTH-2 downto 0) & lsb;
concatenating the lsb input on the right-hand side end if;
end if; end process sh_reg;
output <= reg; end BHV;
: in std_logic; : in std_logic;
-- shift in the new LSB by
APPENDIX B: Report Guidelines – Simulation screenshots
Example of good simulation screenshot (for illustration only):
Examples of not acceptable simulation screenshots:
APPENDIX C: Report Guidelines – Commenting
Examples of good code comments:
● Avoid “obvious” comments (e.g.: “input port”, “counter is incremented”, “A gets value ‘0’”, “go
back to 0”). Comments should add information that is not immediately obvious from the code.
● Short descriptions of the function of entity, I/O ports, any components, and any internal signals
should always be included. Comments should be about the design of the circuit, not about VHDL
● There is often redundancy in these comments (especially when I/O ports of the entity are directly
connected to the I/O ports of the components), but it is usually easier to cut and paste than to selectively remove comments.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL;
-- Control logic for a garage door opener
-- The entity contains a FSM component to control the door and a counter to -- generate a one-second pause required by the operation of the FSM
entity control_logic is
port (clock : in std_logic;
reset : in std_logic;
button : in std_logic; -- remote control button
bottom_sensor : in std_logic; -- door sensor: high when door closed top_sensor: in std_logic; -- door sensor: high when door open
-- door motor control: 00 - stop; 01 - close; 10 - open; 11 - unused Motor : out std_logic_vector (1 downto 0));
end control_logic;
architecture Behavioral of control_logic is
signal count_en : STD_LOGIC; -- enable for one-second pause counter
signal one_second : STD_LOGIC; -- high for 1 clock cycle when one second is reached constant SECOND : natural := 100000000; -- number of clock cycles corresponding
-- to one second in real time (100MHz clock) signal Counter : unsigned (26 downto 0); -- vector for one-second counter
-- (100M = 27 bits)
-- Counter to one second (see SECOND constant)
-- Rising edge, synchronous reset to 0, and enable count_one_sec : process (clock)
if (rising_edge(clock)) then
if (reset = '1') then
Counter <= (others => ‘0’);
if (count_en = ‘1’) then
if (Counter = SECOND) then Counter <= (others => ‘0’);
Counter <= (Counter + 1); end if;
end process count_one_sec;
-- Finite State Machine for a garage door opener
door: entity work.garage_door_FSM PORT MAP( reset => reset,
clock => clock,
button => button, — remote control button
bottom_sensor => bottom_sensor, — high when door closed
top_sensor => top_sensor, — high when door open
one_second => one_second, — high for 1 period when one second wait is over — door motor control: 00 – stop; 01 – close; 10 – open; 11 – unused
Motor => Motor,
count => count_en — enable signal for one-second pause counter
— This signal will be ‘1’ for a single clock cycle when the counter has reached 100M
one_second <= '1' when (Counter = SECOND and count_en = '1') else '0'; end Behavioral;
Some counter-examples (i.e. “bad” comments):
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
-- Entity declaration
entity control_logic is
port (clock : in std_logic; -- I/O ports
reset : in std_logic;
button : in std_logic;
bottom_sensor : in std_logic;
top_sensor: in std_logic;
Motor : out std_logic_vector (1 downto 0));
end control_logic;
architecture Behavioral of control_logic is
-- Internal signals for the control logic
signal sig1, sig2 : STD_LOGIC;
signal Counter : unsigned (26 downto 0);
-- Counter
proc_inst : process (clock)
if (rising_edge(clock)) then
if (reset = '1') then -- when reset is high
Counter <= (others => ‘0’); — counter goes to 0
if (sig1 = ‘1’) then –when the counter is enabled
if (Counter = 100000000) then — if the counter has reached 100000000
Counter <= (others => ‘0’); — then it goes back to 0
Counter <= (Counter + 1); -- otherwise it increments by one
end if; end if; end if; end if;
end process proc_inst;
Inst: entity work.garage_door_FSM PORT MAP(
reset => reset, clock => clock, button => button, bottom_sensor => bottom_sensor,
top_sensor => top_sensor, one_second => sig2, Motor => Motor, count => count_en);
— sig2 is equal to ‘1’ when the counter is equal to 100000000 and is enabled, otherwise
sig2 <= '1' when (Counter = 100000000 and sig1 = '1') else '0';
end Behavioral;
Testbench commenting:
● Avoid “obvious” comments (e.g.: “A gets value ‘0’”). Comments should add information that is not immediately obvious from the code.
● Always include a description of your test strategy, right before your input process. This should provide an overview of the test and explain your choice of test patterns (i.e. why did you pick these patterns and not others, and why are they sufficient to test the operation of the circuit.
● Inside the test process, describe (where necessary) how the specific test patterns relate to the test strategy.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com