prepare_vlsi desex4Before creating the handin.tar file, basic file checks, more file checks and simulation checks are performed:
the script should not complain about missing cells where these cells are not part of your team's cell library
the last two of these are optional (i.e. if they do not exist the submission will still be accepted)
the last four of these are optional (i.e. if they do not exist the submission will still be accepted)
In the file list above, divider.sv is mentioned twice.
In the behavioural directory, the divider.sv file is the structural model which instances the behavioural model of the control unit to the extracted model of the datapath (as shown on page 8 of the specification document). In the extracted directory, the divider.sv file is the header file for the divider.vnet netlist extracted from the complete divider chip (as described on page 12 of the specification document).
If you are not submitting a complete divider chip, the divider files in the extracted directory should not exist.
In the file list above, control.sv occurs three times.
The three control.sv files are the behavioural model in the behavioural directory, the gate level netlist (the output from the Genus synthesis) in the gate_level directory and the header file for the extracted control.vnet transistor level netlist in the extracted directory.
Even if you are not submitting a complete divider chip, the control files in the magic directory and the extracted directory should still exist although failure to submit these files will not result in the submission being rejected.
The bitslice cell should instance only cells from the list of leaf cells above.
The datapath cell should instance only the bitslice cell.
The control cell (if it exists) should instance only cells from the list of leaf cells above.
This test uses your system to perform a single division calculation. It will observe the result but make no judgement as to whether the answer is correct.
The simulation will fail if the inputs and outputs for the divider.sv file are not as specified below:
input [7:0] Operand1, Operand2; input Req; input Clock, nReset; output [7:0] Quotient, Remainder; output Done;
This test places a one clock cycle pulse on the Scan Data In (SDI) input of the bitslice module and checks to see that there is a corresponding pulse on the Scan Data Out (SDO) output. For a design with 5 dtypes/registers, the SDO pulse should be produced 5 cycles after the SDI pulse indicating that the scan path is correctly wired.
The simulation will fail if the inputs and outputs for the bitslice.sv do not include those which should be common to all bitslice designs:
input Operand1, Operand2; input Clock, nReset, Test, SDI; output Quotient, Remainder; output SDO;
This test places a one clock cycle pulse on the Scan Data In (SDI) input of the datapath module and checks to see that there is a corresponding pulse on the Scan Data Out (SDO) output. For a design with 40 dtypes/registers, the SDO pulse should be produced 40 cycles after the SDI pulse indicating that the scan path is correctly wired.
If you have opted for a type 1 datapath, the simulation will fail if the inputs and outputs for the datapath.sv file are not as specified below:
input [7:0] Operand1, Operand2; input Subtract, Increment; input EnableD, EnableACC, EnableOp1, EnableOp2; input LoadD, LoadR, LoadC, LoadQ, LoadACC; input Clock, nReset, Test, SDI; output [7:0] Quotient, Remainder; output nBorrow, Overflow; output SDO;
If you have opted for an alternative datapath then you will have different control signals and different feedback signals. In this case the simulation will only check for the signals that should be common to all datapath designs:
For a type 2 datapath these are:
input [7:0] Operand1, Operand2; input Clock, nReset, Test, SDI; input ShiftIn; output [7:0] Quotient, Remainder; output nBorrow, nZ; output SDO;
For a type 3 datapath these are:
input [7:0] Operand1, Operand2; input Clock, nReset, Test, SDI; output [7:0] Quotient, Remainder; output SDO;
For a handin.tar file to be automatically created all the file checks must succeed (basic file checks and more file checks).
Although a design that doesn't pass the simulation checks does not meet the specification, such a design will still create a handin.tar file. This allows students who are experiencing difficulties, to make a submission based on their current design and then to get on with the documentation.
The more organized students will use the script early to help them with their debugging. Only once they are happy with their designs will they consider submitting the handin.tar file.
Iain McNally
3-12-2024