CS代考 ELE00011H Digital Engineering Coursework Assessment 2021/22 SUMMARY DETAILS

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 4 Testing and verification
– 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: 20% Mark breakdown [80 marks]:
 General issues (e.g. documentation, layout and comments, structural issues): 10 marks
 Task 4A (e.g. VHDL code, testbench, simulation): 45 marks
 Task 4B (e.g. VHDL code, testbench, simulation): 15 marks
 Task 4C (e.g. VHDL code, testbench, simulation): 10 marks

Task A: Test Pattern Generation
The aim in this task is to define a minimal (or almost minimal) set of test patterns to exhaustively test the circuit of Figure 1 for detectable single stuck-at faults.
The procedure to be followed consists of the following steps:
For each kind of logic gate in the circuit (AND, OR, NOR), perform fault collapsing to identify equivalent and dominated faults.
For each kind of logic gate in the circuit (AND, OR, NOR), specify equivalent and dominated/dominant faults. Show your derivation.
Consider the remaining (non-dominated and non-equivalent) faults for each gate of the circuit of Figure 1. Considering that a fault on the output of a gate is equivalent to the fault on the input of the following gate, and considering the fault collapsing rules (see lecture slides and results of 3.1.1), this should lead to a significant reduction of the fault list.
The complete list
Node A s-a-0 Node D s-a-0 Node G s-a-0 Node I0 s-a-0 Node K s-a-0
of possible faults is:
Node A s-a-1 Node D s-a-1 Node G s-a-1 Node I0 s-a-1 Node K s-a-1
Node B s-a-0 Node E s-a-0 Node H s-a-0 Node I1 s-a-0 Node L s-a-0
Node B s-a-1 Node E s-a-1 Node H s-a-1 Node I1 s-a-1 Node L s-a-1
Node C s-a-0 Node C s-a-1 Node F s-a-0 Node F s-a-1 Node I s-a-0 Node I s-a-1 Node J s-a-0 Node J s-a-1
Note: Due to fanout, I0 and I1 will have to be considered as different from I. This is because a fault could affect only one of the two branches (metal lines) of the fanout. For example, a fault I0 s-a-1 would cause the input to the NOR gate (I0) to be stuck at Vcc, but both I and I1 would be operating correctly. In practice, you can postulate the presence of a “gate” where I splits into I0 and I1. The fault collapsing rules for this “gate” are that there is NO equivalence or dominance between the three lines.
3.1.2: Listallnon-equivalentandnon-dominatedfaultsforthecircuitofFigure1(i.e. starting from the full list above, eliminate all equivalent and dominated faults). Show your work by identifying the reason for the eliminations (e.g., X s-a-0 is equivalent to Y s-a-1)

For each fault on the list in step 2, use the D algorithm to define a test pattern that will detect that fault at the output L, or to show that it is undetectable. In the report, show your work using a table of the form (see example in module slides):
Js-a-1ABCDEFGHII0 I1 J KL
Step 3 1 1
D’ 1 X X X D’ 1 X X X D’
3.1.4: 3.1.5:
Listthetestpatterns(A-FinputsandexpectedoutputL,inthisorder)requiredto detect all detectable faults in the circuit and how they were derived using the D algorithm. Indicate any undetectable faults separately and show how you determined that they cannot be detected. At this stage, “don’t care” input values should be labelled as ‘X’.
Compare the test patterns and determine whether any of the patterns can be merged. Two patterns can be merged when all resolved inputs (i.e., non-X) are equal. This will not necessarily be the case, depending on your fault list and the application of the D algorithm (in which case, you should specify that this is the case). Note that it might be useful to keep track of alternatives in the D algorithm output (e.g. 0-X or X-0 for C and D).
Indicate which test patterns in the list above can be merged (if any).
Listthereducedtestpatternsrequiredtoexhaustivelytestthecircuit.Atthisstage,all “don’t care” values should be resolved to 0s (technically, 1s would work too, but 0s are slightly better) and D/D’ to 1s and 0s. Hint: at this stage, you should have reduced the set to 7 or 8 patterns.
Foreachtestpattern,performfaultsimulationtodetermineallfaultsthatthepattern is able to detect. In other words, determine which of the faults on the original list (step 2) are detected by each of the vectors you found at 3.1.5. Use a table and list the faults for each vector alphabetically.

Task B: Built-In Self-Test (BIST)
All files for this experiment are contained in the .zip archive available in the module website. If you extract this folder within a directory that contains no spaces, you should be able to work directly within the directory by opening the .xpr file.
The project contains a set of VHDL files that implement the circuit of Figure 1 with a fault injection mechanism that allows the simulation of the following faults:
 Node E stuck-at-1
 Node H stuck-at-0
 Node F stuck-at-0
The block diagram of the circuit is the following:
INPUT[5:0]
MODE TEST[5:0]
L_ERR L_ID[?:0]
DB DB B_TEST B_RST
In practice, this circuit exploits some of the techniques described in the lecture for the test and verification of combinational circuits.
 The bus INPUT[5:0] carries the “standard” inputs to the logic circuit, inputs that are de- gated by the multiplexer when in test mode.
 L_OUT is the output of the combinational logic.
 B_F[1:0] is a 2-bit bus that encodes the fault be injected (00 for no fault, 01 for E s-a-1, 10
for H s-a-0, 11 for F s-a-0).
 B_TEST is a (de-bounced) signal driven by a push-button. When the push-button is pressed, the circuit will “lock” the fault set by B_F and enter test mode (see below).
 B_RST will reset the test logic (injected fault, state of the test).
 L_ERR is a single-bit output that should have value 1 if the test logic has detected a fault in
the circuit. It should then remain 1 until the test logic is reset.
 L_ID will represent a unique ID for the test pattern that has allowed the fault to be detected.
Examine the internal logic of the BIST system. When the B_TEST button is pressed, the UUT will be de-gated from its standard inputs and subjected to the set of test patterns you have derived in task 1. If no fault is detected, the unit should then resume normal operation. The internal block diagram of the BIST unit is shown in Figure 3.

Your task will be to define and instantiate a single-port distributed RAM using an IP component (see Appendix) to store the test patterns defined in task 1. Two important things to note:
1. The figure above, with two separate memories to store inputs and expected outputs, is a functional description only: you should not instantiate two RAMs, but only a single one, storing the output as the LSB of a 7-bit data word.
2. Normally, a ROM would be the most appropriate memory type for this circuit, since its contents do not need to be modified. However, a bug in the Xilinx tools seems to affect ROMs, and therefore you should use a RAM with the write enable and data inputs set to 0.
If a fault is detected, the circuit freezes, the L_ERR output signals that a fault has been detected (value 1) and the L_ID output shows the ID of the test pattern that detected the fault (in practice, its address within the memory). The B_RST button is then used to reset the system to the original state.
Define a testbench that will verify the operation of the circuit, including all possible fault scenarios given the three faults specified above (remember that only a single fault can be injected each time).
3.2.1: Print out the memory content file.
3.2.2: Print out the VHDL testbench.
3.2.3: Print out screenshots of the behavioural simulation for the system. The screenshot(s) should show, in readable format, all inputs and outputs of the circuit as well as the internal signal MODE and the address and output data of all internal memories, for:
– The operation of the fault-free circuit for at least two different combinations of inputs
– The complete test cycle when no fault is present
– The complete test cycle when each of the three faults is present

Task C: System-level IP – the Digital Clock Manager and Chipscope
In this task, you will implement the design above in the Xilinx boards, use the Digital Clock Manager to control its operational frequency and then observe its operation within the device using Chipscope.
Note that an XDC file is included in the project, but assumes 4 bits for the fault ID, so if you use fewer you will have to edit it.
Part I: the Digital Clock Manager
The oscillator on the Xilinx board provides a 100MHz clock. However, we wish to run our design at 25MHz. To obtain the correct frequency, you should define an internal clock signal, different from the input, generated using a Digital Clock Manager.
In the Project Manager, click on “IP Catalog”. This will open a new tab, containing a long list of IP components (organised in folders). Search for “clocking” and double-click on “Clocking Wizard”. This will launch a multi-tab graphical interface that allows you to configure the clock manager.
Start by giving the component a name (e.g. “clock_manager” or something similar). Select the “Clocking Options” tab. There are several (sometimes very complex) options related to the input clock. The most important value is the definition of the input clock frequency, which should be already set to100MHz as long as you have selected the correct devices and boards in your project. You can leave the default values as they are (feel free to have a browse).
Now select the “Output Clocks” tab. Here, you will define the clock frequencies that will be output from your clock manager. By default, clk_out1 is always a “copy” of the input clock. Even if you will not use it, leave it for good practice. Tick the box next to clk_out2 and set the “Requested Frequency” to 25.000 (MHz). Because 25 is a simple value to obtain from 100, the actual frequency should also be 25MHz (try something like 17.3MHz to see where approximation comes into play). You can leave the phase shift at 0 and the duty cycle at 50%. Scroll down and un-tick the boxes next to “Reset” and “Locked”.
Click OK, then “Generate”. This will add a new IP component to your project that you can use as any other component, by instantiating it in your code. Note that, with this and just about all other IP components, the Xilinx text editor generates a “false” error stating that the component cannot be found (you can verify that this is a false positive by checking that the manager has been correctly placed as a sub-component of your top level design in the Sources pane).

Add the component into your design, making sure that the correct clocks are connected to the ports (you will need to create an internal STD_LOGIC signal for the slower clock and you can leave the clk_out1 port of the manager unconnected). Note that all your logic should use the new 25MHz clock (including the debouncers – which means that your simulations will now have to take into account a new duration for the button press!)
Run the behavioural simulation and ensure that the circuit still works. Note that the TB clock frequency can remain at 100MHz, but all your internal logic will work at 1/5th of whatever frequency you define for the clock! Also, the DCM needs more than 100ns to initialise, so increase the initial wait to at least 500ns (note: in some rare cases, 500ns might not be sufficient – this should be obvious from the simulations – in which case, you might have to increase it to 3000ns).
3.3.1: Explain, using a few words and graphs, the concepts of phase shift and duty cycle in a clock signal.
3.3.2: Print out screenshots of the behavioural simulation for the system. The screenshot(s) should show, in readable format, all the events and signals of the previous task (3.2.5) but also clearly display the new internal clock and how it affects the circuit.
You are now ready to implement the design on the board. Run the implementation process in the design tab. Confirm that the desired clock frequency is achievable by looking at the Design Runs tab, then follow the steps outlined in lab 1 to configure the board.
You can now verify that the circuit operates as predicted. Experiment with the board to verify the correct operation of the circuit.
Part II: The Integrated Logic Analyzer
The integrated logic analyser (ILA) is a powerful IP component available in FPGA devices.
While it is actually possible to integrate the ILA directly in your design by using an IP (in the same way as you integrated the digital clock manager above), a much more efficient approach is to integrate it separately during the synthesis process.
However, a slight modification to your VHDL is still necessary, in the form of compiler directives. Specifically, if you want to observe a specific signal through the ILA, you must make sure that the signal is not removed or renamed during the synthesis process!
In the Xilinx toolchain, this is done through the mark_debug attribute. Open your top level entity and add the following lines in the signal declaration area (between “architecture …” and “begin”):
attribute mark_debug : string;
attribute mark_debug : string;
attribute mark_debug of B_TEST_DB : signal is “true”;
attribute mark_debug of B_RST_DB : signal is “true”;
attribute mark_debug of VECTOR : signal is “true”;
attribute mark_debug of UUT_OUT : signal is “true”;
attribute mark_debug of B_F_SET : signal is “true”;
attribute mark_debug of L_ERR : signal is “true”;
attribute mark_debug of L_ID : signal is “true”;

Do the same for the following lines in the BIST_Ctrl entity:
attribute mark_debug : string;
attribute mark_debug of present_state : signal is “true”;
attribute mark_debug of L_ID_counter : signal is “true”;
Now launch the synthesis process. Once finished, click on “Set Up Debug”.
In the first window that appears, click on next. The following window should contain a list of the signals you have marked for debug.
By default, all signals will probably be set as “Data and Trigger” (i.e. they can be both observed and used to trigger the ILA). Change the setup as follows, identifying the (debounced) reset and enable as the only triggers:
In the next page, you can define the number of samples to be taken. Clearly the more samples (and the more signals) you select, the more memory will be required. In our case, 1024 (the minimum) will be more than sufficient, so you can just advance to the next page and then click “Finish”.
At this stage, an ILA has been added. At the bottom the Vivado window, a new tab (“Debug”) should have appeared, listing the probes you have just defined. Have a quick look at the clock used by the ILA (clk_out2 – the 25MHz clock) and keep it in mind for later.

Now click on “Generate Bitstream”. If there are no errors in your code, the tools will re-synthesize and re-implement the design. Open the hardware manager and connect to the board. If all has gone well, you should now see that the programming pop-up window includes both a bitstream file and a debug file:
When you program the device, a new tab will appear, looking somewhat similar to a simulation window (note that you can change the colours through the settings icon at the top right, just like a simulation window). But instead of running a simulation, you will be recording and displaying the value of the signals inside the device as it is running!
The first step is to define the trigger conditions, that is, the combination of values that will start the recording of the values on the lines you have defined. Press the “+” button on the trigger setup pane. We only specified two trigger signals (B_TEST_DB and B_RST_DB) so you will only have two choices. Double click on both of them to add them to the trigger setup window.

We want to trigger the ILA if either the reset or the test buttons are pressed. For both triggers, set the operator to “==”, the radix to [B], and the value to ‘1’. Then click on the little logic gate icon and set the trigger condition to “Global OR”.
The ILA will be triggered when either the RST or the TEST buttons are equal to binary value ‘1’. The trigger setup tab should look something like this:
The last step is to define the display parameters. The ILA is set to record 1024 samples and, by default, the display will show the 512 samples before and the 512 samples after the trigger. This does not really match the requirements of this circuit and, while this can be handled by zooming, redefining the capture settings is more efficient. Select the Settings tab and set it up as follows:
The ILA is ready. Launch it by pressing the play button. The scope is now waiting for the trigger to be activated. On the board, select a fault and start test mode. You should now be able to observe the signals as they change on the actual board. Play around with the interface to explore some of the options (keep in mind that you can save the settings and re-use your changes in future runs).

3.3.3: Print out the ILA window showing the values of the internal signals when the analyser is triggered for the fault-free cycle and for each of the three faults. Make sure that the signal names (including vectors) are the same as the original VHDL file and that the output matches your simulation

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com