Design Exercise 4 - Preparation for Handin

This document discusses the operation of the script that checks design exercise 4 and prepares the handin.tar file for electronic submission:

    prepare_vlsi desex4

Before creating the handin.tar file, basic file checks, more file checks and simulation checks are performed:

Basic File Checks

In each case the script will check that the file exists and has the correct format (e.g. it checks that scandtype.mag exists and is a magic file with technology tsmc180).

Checks for Magic files in ~/design/magic/tsmc180/cell_lib directory
- scandtype.mag
- scanreg.mag
- trisbuf.mag
- buffer.mag
- mux2.mag
- fulladder.mag
- xor2.mag
- inv.mag
- nand2.mag
- nand3.mag
- nor2.mag
- nor3.mag
- halfadder.mag
- and2.mag
- or2.mag
- nand4.mag
- tielow.mag
- tiehigh.mag
- rowcrosser.mag
- leftbuf.mag or leftend.mag
- rightend.mag
the script should not complain about missing cells where these cells are not part of your team's cell library
Checks for Magic files in ~/design/magic/tsmc180/bitslice directory
- bitslice.mag
- datapath.mag
- control.mag
- multiplier.mag
the last two of these are optional (i.e. if they do not exist the submission will still be accepted)
Checks for SystemVerilog behavioural, structural and stimulus files in ~/design/magic/tsmc180/bitslice/behavioural directory
- control.sv
- control_stim.sv
- multiplier.sv
- multiplier_stim.sv
- multiplier.tcl
Checks for SystemVerilog gate level files in ~/design/magic/tsmc180/bitslice/gate_level directory
- control.sv
Checks for SystemVerilog netlist, header and stimulus files in ~/design/magic/tsmc180/bitslice/extracted directory
- bitslice.vnet
- bitslice.sv
- bitslice_stim.sv
- datapath.vnet
- datapath.sv
- datapath_stim.sv
- control.vnet
- control.sv
- multiplier.vnet
- multiplier.sv
the last four of these are optional (i.e. if they do not exist the submission will still be accepted)
A note on duplicate filenames
1. multiplier...
  In the file list above, multiplier.sv is mentioned twice.
  In the behavioural directory, the multiplier.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 multiplier.sv file is the header file for the multiplier.vnet netlist extracted from the complete multiplier chip (as described on page 12 of the specification document).
  If you are not submitting a complete multiplier chip, the multiplier files in the extracted directory should not exist.
2. control...
  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 multiplier 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.

More File Checks

Checks that Magic leaf cells contain no hierarchy
- scandtype
- scanreg
- trisbuf
- buffer
- mux2
- fulladder
- xor2
- inv
- nand2
- nand3
- nor2
- nor3
- halfadder
- and2
- or2
- nand4
- tielow
- tiehigh
- rowcrosser
- leftbuf or leftend.mag
- rightend
Checks hierarchy for the bitslice cell
The bitslice cell should instance only cells from the list of leaf cells above.
Checks hierarchy for the datapath cell
The datapath cell should instance only the bitslice cell.
Checks hierarchy for the control cell
The control cell (if it exists) should instance only cells from the list of leaf cells above.

Simulation checks

Simple multiplication check
This test uses your system to perform a single multiplication 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 multiplier.sv file are not as specified below:
```
    input [7:0] Operand1, Operand2;
    input Req;
    input Clock, nReset;
    output [7:0] Result;
    output Done;
```
Simple bitslice scan path test
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 4 dtypes/registers, the SDO pulse should be produced 4 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 Result;
    output SDO;
```
Simple datapath scan path test
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 32 dtypes/registers, the SDO pulse should be produced 32 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 Add, Decrement;
    input EnableOp1, EnableOp2, EnableZero, EnableA, EnableACC;
    input LoadA, LoadB, LoadACC, LoadR;
    input Clock, nReset, Test, SDI;
    output [7:0] Result;
    output Underflow;
    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:
```
    input [7:0] Operand1, Operand2;
    input Clock, nReset, Test, SDI;
    output [7:0] Result;
    output SDO;
```
* note that a type 3 datapath may support a 16-bit Result output rather than the 8-bit version shown above

Handin

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

4-7-2024