Electronic – What options exist to verify Avalon-MM slave component

fpgaintel-fpgatestbench

I am writing an Avalon-MM slave. It shall connect to Nios II as master device. What options exist to write testbench for it? I must be sure that an Avalon-MM master can correctly read/write it.

I have come across something called Bus Functional Model but it is not clear how to use it.

How should I start?

Best Answer

I found that there are basically four options:

  1. Include the CPU (NIOS-II) itself in the simulation.
  2. Use an existing "open core" CPU design.
  3. Use a "bus functional model" (BFM).
  4. Create my own simulatable CPU and bus master interface.

I ended up using option 4.

The problem with option 1 is that the full-blown CPU is complex and simulates slowly. On chips that have "hard core" CPUs, a simulation model may not be available at all. The advantage is that it allows you to use the same software tools to write your tests that will be used for the application code.

Option 2 gets around the problem of not being able to simulate the application CPU, and often has the advantage of higher-level software tools, but many of them are complex (slow) to simulate, and they frequently have architectural quirks that may be difficult to work around. They may or may not come with the bus interface you need.

The problem with option 3 is that you have to explicitly specify the bus activity on a cycle-by-cycle basis, with no ability to react to the data you get back or otherwise change the flow of the test. The advantage is that it simulates very quickly.

In my case, I really needed to execute algorithms that could loop and branch, so a BFM was out. Also, this was on a Xilinx Zynq chip, so simulating the actual CPU was out of the question. I considered various "open source" CPU cores, but they seemed to be way too complex to learn for my needs. So, I created a very simple CPU that has a 32-bit data path, and created a companion AXI (in my case) bus master module for it. It was something I wanted to try doing anyway for other reasons. I wrote my tests using an assembler that I was already using for some other custom "soft" CPU cores.

It turns out that the CPU is also synthesizable, so I could use it the next time I need a CPU that I can embed in a design as well. And writing a different bus master module for, say, Avalon-MM would not be a big deal. Architecturally, the CPU is similar to the PDP-11 minicomputer and the MSP430 microprocessor. I made sure that it has basic features that make the support of high-level languages easy to implement — i.e., a GCC back end could be written for it.

Related Topic