You copied the Doc URL to your clipboard.

How do I dynamically enable tarmac output during RTL simulation?

Article ID: 266045597

Published date: 01 Nov 2018

Last updated: -

Applies to: Cortex-M0, Cortex-M0Plus, Cortex-M3, Cortex-M4


Can I enable and disable tarmac output during RTL simulation to avoid a large tarmac log file size in a long simulation run?


This knowledge article is intended for designers and validation engineers who have licensed the processor RTL description and who want to analyze processor behavior during a long simulation run.

Tarmac is a human-readable log file that records timestamped activity in the processor. Examples of timestamped activity include instruction opcodes that are executed or conditionally skipped, memory accesses, internal register value changes, and other events, such as exceptions. Tarmac logging, the creation of a tarmac log file, is useful for debugging any unexpected processor behavior and for understanding code performance.

Each processor contains the processor RTL and an example MCU design that incorporates a tarmac logger in the testbench for the MCU simulations. The designer can migrate the tarmac logger to their chip-level testbench to provide the same features.


The testbench for each of these Cortex-M processors has tarmac logging that is enabled by default. However, it is relatively straightforward to change these settings to create dynamically enabled tarmac logging. Dynamically enabled tarmac logging appears to produce correct tarmac, though note that sometimes there are artifacts in the log after tarmac logging is re-enabled.


The tarmac logger top level is instantiated in "example_tbench.v". There are five separate features of tarmac logging. Each feature has an independent enable bit declared as a 'reg' in the "tarmacDSM" level. The tarmac logging features can be enabled or disabled in the testbench by assigning 1 or 0 to these registers:






When dynamically enabled, the tarmac log seems identical to the corresponding segments of the full tarmac log. The only difference is the instruction count field, which is the second value inside the round brackets on "IS" and "IT" lines. The instruction counter does not increment while logging is disabled. Therefore, when logging is re-enabled, the instruction counter shows a value which is one more than the count of the last instruction before trace was disabled.


The tarmac logger is instantiated in the "cm4ik_sys.v" level of the Integration Kit, under the instance path of "utarmac.utarmacDSM". All other details are the same as for Cortex-M3.


The tarmac logger for Cortex-M0 is "cm0_tarmac.v", and is instantiated at the "tbench" level of the Integration Kit. An input signal port on this instance, "enable_i", that is tied off in the testbench, controls tarmac logging. However, if this signal is driven dynamically, the tarmac log appears correct when logging is enabled. The Cortex-M0 tarmac log does not include an instruction count.


The tarmac logger for Cortex-M0+ is "cm0p_tarmac.v" in the testbench. The tarmac logger has an input signal port, "en_i", to enable tarmac logging, which is tied high in the testbench. Driving this signal port dynamically allows you to start and stop logging, but there are some artifacts around the restarting of logging. These artifacts include, but are not limited to:

  • Misreported instruction fetch showing the last address that was fetched before logging was disabled. The misreported instruction fetch also shows the opcode values from the first instruction fetch after logging was re-enabled.

  • Delayed reporting of a register value change that took place while logging was disabled. The register value change is reported as happening at the same time as logging is re-enabled.


No workaround.


No example.

Related Information


Was this page helpful? Yes No