SystemVerilog Behavioural Model (Interim Hand-in)

Deliverables

• All behavioural files should be placed in the directory: ~/design/fcde/verilog/behavioural

  This directory should contain the following verilog module files:

  • cpu_core.sv

    cpu_core module - joins control & datapath

  • control.sv

    control module - generates control signals

  • datapath.sv

    datapath module - includes alu, registers etc

  • alu.sv

    alu module

    Note: Most of you should find that there are enough modules listed here for your design. If you have any other modules that are instanced in the datapath, they should also exist in this directory. Each module requires a separate verilog file with an appropriate name (do not use `include to include module files since it will break the automated testing).
    e.g. a module registerFile containing the addressable registers and associated buses would be stored in a file called registerFile.sv.

  In addition the directory should contain the following files used to support the simulation:

  • opcodes.sv

    include file for your opcodes and other definitions

  • monitor.sv

    contains signal and function definitions helpful for monitoring your simulation

    also contains code that is responsible for termination the simulation

  • system.tcl

    NC-SystemVerilog simvision control file for your system

  • system.fig (optional)

    If present, an xfig picture file like this may be used to provide an advanced view of the processor in a simvision register window. This is the technique used in the example processor simulations.

• All program files should be placed in the directory: ~/design/fcde/verilog/programs

  The only program required for this handin is a multiplication program:

  This program reads a value from switches (memory location 2048) and stores the low byte (this will be Operand1), then the high byte (Operand2) and finally 0 (placeholder for Result) on the stack. It then calls a subroutine which takes the two operand values, multiplies them together using a shift and add algorithm and places the Result back on the stack. The subroutine then returns. The main routine will then take the result off the stack and write it to the LEDS (memory location 2049).

  A more detailed specification for this and other programs may be found on the web.

  This directory should contain the following verilog files:

  • multiply.sv

    This file is a verilog file containing a program module which creates the machime code hex file. The file uses the opcodes defined in your opcodes.sv file to make it more readable.

    An example file showing the file format is available on the web.

    Note that the code in this example does not meet the requirements of this handin, since there is no subroutine and hence no stack usage. This is because the simple example processor does not support these facilities.

  • multiply.asm

    This file is an assembly language file which follows the assembly language conventions for your processor. In addition to assembly language instructions, the file is likely to include program labels and assembler directives.

    An example file showing the file format is available on the web. In this example, program labels occur in the first column and are indicated by a full stop (e.g. ".start"). The other assembly language directives used are: ORG (origin) which tells us where the code should be placed in memory, EQU (equate) which assigns an address to a variable name and FCW (form constant word) which is used to include a constant within the code.

    Note that the label and directive standards used in the example (.label/ORG/EQU/FCW) are based on an assembler for 6809 machine code. You may want to use alternative assembler conventions for your assembly language files (e.g. the MIPS conventions given in Patterson & Hennessy).

    Since your processor supports immediates (unlike the simple processor example which supports only direct addressing mode), you should not need to use the FCW directive. Similarly you may not need the ORG directive unless you want gaps in your code (e.g. between the main routine and a subroutine). An alternative example file which uses neither FCW nor ORG is available on the web.

  • multiply.hex

    This file is a human readable machine code file in ascii hexadecimal format. It contains four digit hexadecimal instruction values separated by white space. It may optionally include instruction addresses which are four digit hexadecimal values preceded by the '@' character. At the begining of a simulation of the multiplication program, the machine code instructions will be loaded from this hex file into the ram.

    Although this file may be generated by hand, it is usually created automatically, either from a verilog program module or by an assembler program.

    A number of examples of this format are available on the web in case you wish to write these files by hand or produce an assembler for your processor.

    • Basic Format: This format lists only the instruction value. This is the format produced by a verilog program module.

    • Address/Data Format: This format includes both the instruction address and value. This is the format might be produced by a simple assembler.

    • Advanced Format: This format includes the instruction addresses for some instructions but not for all of them. Where an address is not included, it is assumed that the address is one greater than the address of the last instruction. This format gives the most compact hex files.

    • Other Formats: The addresses in the file do not need to be in order. This example format is a line by line hand compilation of the multiply.asm example file. For more details of the specification for these files see the $readmemh() section in the SystemVerilog reference guide.

  • multiply.txt (optional)

    This file is a merge of the assembly language file and the hex file. The first two columns are the address and machine code in hex format corresponding to the assembly language instruction which follows.

    An example file showing the file format is available on the web.

    Where an assembler exists, this is one of the output files from the assembler. It documenations the assembly process since it provides both the assembly language and the resulting machine code.

    At this stage you need not submit a file in this format. Although at some stage you will have to produce one for each of submitted programs since this is the preferred format for inclusion in your reports.

• CHECK

     cd ~/design/fcde/verilog
     ./simulate behavioural programs/multiply.sv 200 +define+switch_value=2569
  

  This should multiply 9 by 10 and put the result on the LEDs. Here I have set the simulation time to 200 clock cycles; you will need to modify this for your simulation. When you perform the handin preparation it will ask you for the simulation time.

Hand-in Script

• Run the command: prepare_fcde behavioural

  This will run some tests and then copy your design files into a "tar" format archive file "handin.tar". You can then submit this file via the handin system.

  It is suggested that you try out the handin script early (several days before the deadline). If your design fails the tests carried out in the handin script, it will fail automated testing.