Mixed language test-bench of fpga-serial-mem-tester-1 VHDL-only RTL
fpga-serial-mem-tester-1
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
Description
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.