Mixed-language test-bench with Riviera-PRO

FPGA Serial Mem Tester Version 1 by Timothy Stotts

FPGA Serial Mem Tester Version 1 project and source code

Previous project posting on GitHub.io site


A small FPGA project of different implementations for testing byte-by-byte memory write/read bytes of a serial flash chip, N25Q. The design targets the Digilent Inc. Arty-A7-100T FPGA development board containing a Xilinx Artix-7 FPGA. Two peripherals are used: Digilent Inc. Pmod SF3, Digilent Inc. Pmod CLS. These are a SPI Flash peripheral, and a 16x2 character LCD peripheral.

The design is broken into two groupings: Xilinx AXI subsystem, VHDL-Only RTL.

The folder SF-Tester-Design-VHDL contains a Xilinx Vivado project with RTL sources containing only VHDL-2002 and VHDL-2008 modules. Plain HDL without a soft CPU or C code is authored to talk with board components, a N25Q SPI Flash 256Mbit, and a 16x2 character LCD peripheral.

In addition to the project’s VHDL RTL and Xilinx Vivado project, a VHDL-2008 test-bench was added. This test-bench provides a beginning of an OS-VVM verification environment. It starts out as derived from the VHDL-2008 test-bench added to the fpga-serial-acl-tester-1 project, as first mentioned in

VHDL Verification of fpga-serial-acl-tester-1 with open source tools

and also mentioned in

Mixed-language verification of fpga-serial-acl-tester-1 Verilog-only RTL

Currently only one test is implemented, providing both manual and automated checking of the Pattern A erase/program/test-read operation of the VHDL DUT (Device Under Test). The folder Work_Dir_RivPro contains a collection of scripts, executed by running the asim-run.do script within the Riviera-PRO TCL command-line. It compiles the VHDL RTL, the VHDL + Verilog test-bench, and runs the simulation for a duration of 30 seconds. Note that this script executes the behavioral simulation verification of the VHDL design with a mixed-language test-bench; and that the simulation is independent of the Vivado 2020.2 project. (It performs a pre-synthesis simulation.) As previously mentioned, it is note-worthy that the open source Verilog and VHDL simulators are not currently capable of performing mixed-language simulation; and that the Xilinx Vivado 2020.2 tool is not capable to the same degree, due to not supporting a used Verilog feature in mixed-mode (part of the N25Qxxx model), and not supporting several key VHDL-2008 language features used by OS-VVM libraries.

The test-bench was authored to instantiate the FPGA design, and also instantiate test-bench components to emulate the peripherals that the FPGA is designed to interact with. These are:

  • Board User Interface
    • 4 Basic LEDs
    • 4 RGB LEDs
    • 4 Switches
    • 4 Buttons
  • Board UART
    • Monitoring of FPGA UART output as ASCII Text
  • Clock and Reset Generator
  • Pmod CLS
    • Monitoring of received SPI data as ASCII Text with ANSI control sequences
  • Pmod SF3
    • A model that emulates the N25Q256A Micron flash chip by wrapping an instantiation of the vendor’s downloadable Verilog model. (See HOWTO in sources for details.)

Note that the OS-VVM test-bench can be configured to select different architectures of test-bench entities, exactly as described in the previous post

VHDL Verification of fpga-serial-acl-tester-1 with open source tools

As described in the prior post, the execution of the test-bench happens by compiling all project sources, and then selecting a VHDL Configuration as target to elaborate and simulate. In this way, an OS-VVM test-bench can be authored to exercise-and-monitor, verify, or both, an FPGA design whose RTL is one of: VHDL-only, Verilog-only, mixed VHDL and Verilog. The test-bench may also contain Verilog sources and be mixed-language itself. This is likely to take place when a peripheral connected to the FPGA has a Verilog model downloadable from the peripheral’s chip vendor’s website. (Note that the author is omitting mention of SystemVerilog RTL and other HDL languages, which can also be part of the RTL or test-bench code base.)

Of final note: to my knowledge, it is proper that the VHDL Configuration not specify architecture, port map, or generic map, of any source in hierarchy that is of a language other than VHDL. In this example, the Pmod SF3 model is authored as a VHDL entity/architecture that wraps a Verilog wrapper, that in turn wraps the Verilog behavioral chip model. This accomplishes making the Pmod SF3 model configurable from a VHDL Configuration, permitting multiple models, usage dependent upon Test. This also accomplishes wrapping the Verilog vendor model with a test-bench Verilog model that can hold pins at ‘0’ or ‘1’, as well as use VHDL-compatible port names for Component Instantiation in the VHDL Pmod SF3 wrapper. As such, the VHDL Configuration source would be:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

library osvvm;
context osvvm.OsvvmContext;

library work;
use work.all;
configuration test_default_fpga_regression of fpga_serial_mem_tester_testharness is
  for simulation
    for u_fpga_serial_mem_tester_testbench : fpga_serial_mem_tester_testbench
      use entity work.fpga_serial_mem_tester_testbench(simulation)
      generic map(
        -- Total execution time of approximately less than 8 iterations
        -- of 1/32 flash size testing if timing characteristics are
        -- sped-up by documented factor. Number of iterations were
        -- determined empirically with simulator.
        parm_simulation_duration => 30000 ms, 
        parm_log_file_name => "log_test_default_fpga_regression.txt"

      for simulation
        for uut_fpga_serial_mem_tester : fpga_serial_mem_tester
          use entity work.fpga_serial_mem_tester(rtl);
        end for;

        -- select
        for u_tbc_clock_gen : tbc_clock_gen
          -- specify the component architecture to generate
          -- the clock and reset
          use entity work.tbc_clock_gen(simulation_default);
        end for;

        for u_tbc_board_ui : tbc_board_ui
          -- specify the component architecture to emulate/
          -- monitor/check the user interface board components
          use entity work.tbc_board_ui(simulation_default);
        end for;

        for u_tbc_pmod_sf3 : tbc_pmod_sf3
          -- specify the component architecture to emulate/
          -- monitor/check the serial flash memory peripheral
          use entity work.tbc_pmod_sf3(simulation_default);
        end for;

        for u_tbc_pmod_cls : tbc_pmod_cls
          -- specify the component architecture to emulate/
          -- monitor/check the 16x2 LCD peripheral
          use entity work.tbc_pmod_cls(simulation_default);
        end for;

        for u_tbc_board_uart : tbc_board_uart
          -- specify the component architecture to emulate/
          -- monitor/check the UART terminal
          use entity work.tbc_board_uart(simulation_default);
        end for;
      end for;
    end for;
  end for;
end configuration test_default_fpga_regression;

Of note, the execution of the simulation with a VHDL RTL FPGA does not require a compilation of work.glbl and specifying that unit name with the VHDL configuration name, on the TCL command-line, when invoking the elaborate-simulate command asim. Only the configuration must be specified. From my understanding, work.glbl sets the global parameters for UNISIM and UNIMACRO declarations that were authored inside of Verilog sources rather than VHDL sources. With VHDL-Only RTL, it is not necessary to compile and specify work.glbl.

The TCL simulation script looks like this.

source ./asim-compile-osvvm.do
source ./asim-compile-work.do

asim +access +r -dbg work.test_default_fpga_regression
run -all

Note that the mentioned Micron vendor model for N25Q is Verilog; and for a reason only guessed by the author of this post, the asim command appears to require the specification of +access +r for the N25Q vendor model to simulate correctly, and not just for tracing and debugging the model’s inside logic. Refer to the scripts asim-compile-osvvm.do and asim-compile-work.do for further examples of compiling Verilog and VHDL into the same work library, while using VHDL Xilinx UNIMACRO macros in the RTL for hard FPGA resources such as MMCM, and block-RAM FIFOs.

To view the results of the default test, the folder Work_Dir_RivPro/Previous_Logs/ contains the OS-VVM transcript log output for 30 seconds of execution: log_test_default_fpga_regression and the Riviera-PRO tool transcript log output for 30 seconds of execution: transcript_test_default_fpga_regression . Note that these files are plain text compressed with LZMA compression tool XZ.

$ ls -lh Work_Dir_RivPro/Previous_Logs/
total 33M
-rw-r--r-- 1 timot 197609 688K Jan 30 16:55 log_test_default_fpga_regression.txt.xz
-rw-r--r-- 1 timot 197609  32M Jan 30 16:55 transcript_test_default_fpga_regression.txt.xz

The larger of the two text files is over a Gigabyte when uncompressed. The purpose of these transcripts is so the engineer can review the FPGA bus accesses against the N25Q flash chip model. The tester application hides the bus accesses with a convenient user interface that only states 1/32 of total memory accesses starting address, for the current point in execution. As such, this default test is not yet of sufficient logic to be consider an automatic checking as it does not monitor the bus signals; as well as it does not monitor the error count that is output to the UART and the Pmod CLS. Adding these pieces of logic would enable the default regression test to perform an automated regression.