AI-generated Key Takeaways
-
Instruction-level simulators for Coral NPU allow software testing without physical hardware, useful for system modeling, compiler validation, and software development.
-
There are two simulators: the faster MPACT-CoralNPU for functional equivalence and the cycle-accurate Verilog-based simulator for precise hardware performance and debugging.
-
Both simulators accept
.elfand.binfile formats, with.elfbeing generally preferred for its debugging information and memory configuration flexibility. -
Using the cycle-exact RVV simulator requires building it from source and running with the compiled program file and desired options.
-
Co-simulation utilizes both simulators concurrently to ensure consistent behavior and verify alignment with the RISC-V specification.
Overview
Instruction-level simulators allow users to simulate the Coral NPU processor and test their software without the need for physical hardware. The Coral NPU simulators can be used for system modeling, compiler validation, and software development.
Use the Verilog-based simulator to obtain precise, accurate results — exactly as would be seen on the Coral NPU hardware. You must model your system memories correctly to achieve this. This simulator is clock-cycle-accurate and so you are able to see what signals actually toggle by using the waveform generation option.
ELF file format for simulation
An .elf file is a standard binary file format used to load and execute
software
on embedded processors within a hardware simulator. It packages the compiled
code, data, and metadata needed for the simulation to function correctly.
The ELF format is the standard binary format used for executables, object code, and shared libraries in most Unix-based systems, including Linux and BSD.
An .elf file provides the initial state for the processor's memory. When the
simulation starts, the hardware's internal memory (block RAM) is loaded with
the code and data from the .elf file.
The ELF format allows the file to incorporate debugging information—specifically, symbol tables that map the machine code back to the original source code. This allows a debugger to help you troubleshoot your code during simulation by setting breakpoints and inspecting variables.
The common workflow when using .elf files in hardware simulation is:
- Software compilation: Write and compile the source code using a
cross-compiler that targets the specific processor in your hardware design.
The output is an
.elffile. - Adding the .elf to the project: Add the generated
.elffile to your hardware project, often within an integrated design environment (IDE). - Associating the .elf: Link the
.elffile to a specific processor instance in your hardware design. - Simulation: Run the hardware simulation. The simulator loads the contents
of the
.elffile into the simulated memory of the processor. - Debugging: Using the debugging tools in your IDE, you can interact with the running simulation, stepping through your software and hardware execution in a coordinated manner.
Using the cycle-exact RVV simulator
To get started using the cycle-exact Coral NPU simulator, first complete the setup steps given in Software prerequisites and system setup.
To build the RVV simulator executable from the source files, enter this command:
bazel build //tests/verilator_sim:rvv_core_mini_axi_sim
To start the simulator, enter:
bazel-bin/tests/verilator_sim/rvv_core_mini_axi_sim --binary program
To see a list of the command-line options (flags) available, use the –helpfull
option:
bazel-bin/tests/verilator_sim/rvv_core_mini_axi_sim --helpfull
| Option | Description |
|---|---|
--binary |
ELF or BIN binary program to execute |
--cycles |
Simulation cycles; default = 100000000 |
--debug_axi |
Enable AXI traffic debugging; default = false |
--instr_trace |
Log instructions to console; default = false |
--trace |
Dump VCD trace; default = false |
--helpfull |
Show these options |