ARM CortexTM-M1
10
Prod uct Bri e f
Bus Functional Model (BFM)
Introduction
During the development of an FPGA-based SoC, there
are various stages of testing that can be undertaken. This
can involve some, or all, of the following approaches:
Hardware simulation using Verilog or VHDL
Software simulation using a host-based instruction
set simulator (ISS) of the SoC’s processor
Hardware and software co-verification using a
full-functional model of the processor in Verilog,
VHDL or SWIFT form, or using a tool such as
Seamless
BFM Usage Flow
The BFM acts as a pin-for-pin replacement of the
Cortex-M1 in the simulation of the SoC subsystem. It
initiates bus transactions on the native ARM Cortex-M1
bus, which are cycle-accurate with real bus cycles that
ARM Cortex-M1 would produce. It does not have the
ability, however, to implement real ARM Cortex-M1
instructions. The BFM may be used to run a basic test
suite of the SoC subsystem, using the skeleton system
testbench.
You can edit the SoC Verilog/VHDL to add new design
blocks. You can also fill out the system-level testbench to
include tasks that test any newly added functionality, or
add stubs to allow more complex system testing
involving the IP cores. The BFM input scripts can also be
manually enhanced to test out access to register
locations in newly added logic. In this way, you can
provide stimuli to the system from the inside (via the
ARM Cortex-M1 BFM), as well as from the outside (via
testbench tasks).
Timing Shell
There is a timing shell provided for each ARM Cortex-M1
variant wrapped around the BFM. Therefore, the BFM is
bus cycle accurate, and performs setup/hold checks to
model output propagation delays.
Debug
The ARM Debug Architecture uses a protocol converter
box to allow the debugger to talk directly to the core via
a JTAG port. In effect, the scan chains in the core that are
required for test are re-used for debugging. The core
uses the scan chains to insert instructions directly into
ARM Cortex-M1. The instructions are executed on the
core and depending on the type of instruction that has
been inserted, the core or the system state can be
examined, saved, or changed. The architecture has the
ability to execute instructions at a slow debug speed or
to execute instructions at system speed.
In debug mode, the user can perform the following
functions:
Core halt
Core stepping
Core register access
Read/Write to TCMs
Read/Write to AHB address space
Breakpoint
Watchpoints
The main debug components are the following:
Debug control registers – to access and control
debugging of the core
Breakpoint Unit (BPU) – to implement breakpoints
Data Watchpoint Unit (DW) – to implement
watchpoints and trigger resources
Debug memory interfaces – to access external
ITCM and DTCM
ROM table