Skip to content

Latest commit

 

History

History
119 lines (103 loc) · 5.42 KB

REAME.md

File metadata and controls

119 lines (103 loc) · 5.42 KB
Raw

LM32 Cluster Testbench

This directory contains a minimal setup to run the LM32 Cluster. The VHDL code is the same as used in the TimingReceiver. Therefore the testbench can be used to develop/test/investigate lm32 firmware without using SignalTap.

Required Software

The Code is a mix of Verilog (the LM32 processor) and VHDL (all the rest) and uses vendor (Intel/Altera) FPGA-Primitives.

  • GHDL is needed for VHDL simulation (version >= 1.0)
  • Verilator is needed for Verilog simulation (version >= 4.038)
  • Quartus needs to be installed to compile the vendor libraries.
  • hdlmake is needed to generate a list of HDL sourcefiles (the version of hdlmake from bel_projects will work)
    • run make hdlmake_install in the bel_projects directory
  • lm32-elf-gcc is needed to compile the firmware (the lm32-toolchain from bel_projects will work)
    • run make lm32-toolchain in the bel_projects directory
  • gtkwave is needed to view the simulated signals.
  • g++ is needed to compile the code generated by Verilator
  • etherbone and saftlib need to be installed if to interact with the simulated hardware.

Compile the testbench

In the bel_projects directory, the make target lm32-toolchain has to be built (if not done already). The $QUARTUS_PATH environment variable has to be set to where quartus is installed (e.g. /opt/altera/18.1/), the makefile needs it to compile the Intel/Altera vendor libraries.

To build the testbench call make To build and run the testbench call make run

[michael@acopc064 test]$ make run
...
eb-device: /dev/pts/14
waiting for client, simulation stopped ...  connected, simulation continues

The eb-devide is also written into the temporary file /tmp/simbridge-eb-device and can be used to call eb-tools on (in a different terminal). For example

[michael@acopc064 test]$ cat /tmp/simbridge-eb-device
dev/pts/14
[michael@acopc064 test]$ eb-ls `cat /tmp/simbridge-eb-device `
BusPath        VendorID         Product   BaseAddress(Hex)  Description
1              0000000000000651:2ba55191             10000M Simulat.=>WB bridge
2              0000000000000651:aa7bfb3c                 0m WB4-MSI-Bridge-GSI 
3              0000000000000651:fab0bdd8               800  GSI:MSI_MAILBOX    
4              0000000000000651:eef0b198             80000  WB4-Bridge-GSI     
4.1            0000000000000651:aa7bfb3c                 0M WB4-MSI-Bridge-GSI 
4.2            0000000000000651:3a362063             80100  FPGA_RESET         
4.3            0000000000000651:10041000             c0000  LM32-CB-Cluster    
4.3.1          0000000000000651:10040086             c0000  Cluster-Info-ROM   
4.3.2          ---
4.3.3          ---
4.3.4          ---
4.3.5          0000000000000651:54111351             e0000  LM32-RAM-User      
4.3.6          0000000000000651:aa7bfb3c                 0M WB4-MSI-Bridge-GSI 
4.4            0000000000000651:1ac4ca35             80000  uart-output        
4.5            000000000000ce42:de0d8ced             80010  wr-pps-mockup

Firmware

The testbench contains a firmware/ directory with a simple firmware that responds to MSIs by writing to the Mailbox. The testbench contains a program interact.cpp wich can communicate with the firmware using saftlib.

The interact program (make interact) first sends a single MSI to the firmware and triggers the following endless loop:

  • The firmware will respond to that MSI by sending an MSI to the host.
  • The host will respond to that MSI by sending an MSI to the firmware.

The output of running the interact program looks like this:

[michael@acopc064 test]$ ./interact `cat /tmp/simbridge-eb-device`
OpenDevice::OpenDevice("dev/pts/12")
OpenDevice first,last,mask = 0,ffff,ffff
msi_target_adr for poll check: 00019868
needs polling? no
msi_adr of host: 0x15cfc
SLOT of LM32: 0
SLOT of HOST: 1
triggerMSI: 0
receiveMSI:     0
triggerMSI: 1
receiveMSI:     1
triggerMSI: 2
receiveMSI:     2
triggerMSI: 3
...

In the testbench the UART of the LM32-Cluster is connected to a test file output. After running the simulation the produced output can be seen with

[michael@acopc064 test]$ cat uart_output.txt 
start loop
pCpuMsiBox = 0x80000800
pMyMsi     = 0x0
hello world 0
hello world 1
hello world 2
hello world 3
hello world 4
hello world 5
...

While the simulation runs, the UART ouptut of the LM32-Cluster can be observed with "tail -f uart_output.txt".

Simulation parameters

The runtime of the simulation can be controlled in the makefile by modifying the --stop-time=1000us argument in the run target. The simulation generates .vcd files for the LM32 core and a simulation.ghw file for the vhdl part of the simulation. Both file types can be opened and analyzed with gtkwave. Simulation speed can be improved massively if signal output is reduced. Generation of .vcd files can be prevented by adding the -n parameter to the ./gvi calls in the makefile. Generation of .ghw files can be prevented by removeing the --wave=simulation.ghw option from the run target in the makefile If only specific vhdl signals are of interest, do the following:

  • create a file of all signals: ./testbench --wave=simulation.ghw --write-wave-opt=signals.txt
  • modify the signal file signals.txt (erase all signals that are not of interest)
  • run the simulaiton: ./testbench --wave=simulation.ghw --read-wave-opt=signals.txt
  • only those signals that are listed in signals.txt will be present in simulation.ghw