The trace port: pins, clocks and the decision you make once
Whether you can trace your target is usually decided at PCB design time, by someone who was not thinking about coverage.
The most common reason a trace-based workflow does not happen is not the tool, the license or the protocol. It is that the pins are not routed.
A usable trace port requires more than spare pins. The design review should cover the implemented trace source, package pin availability, pin multiplexing, voltage domain, width and clocking, connector and return paths, signal integrity, security controls, expected sustained rate and the receiving hardware.
Board routing is easiest to address during hardware design and may be costly or impossible to add later. Some devices offer alternative on-chip or serial trace paths, so feasibility should be assessed before concluding that a missing parallel connector prevents trace entirely.
In brief
A usable trace port is a board property, not a tool property: the trace source must exist in silicon, its pins must be routed to a connector, and the sustained rate must fit the chosen link. That decision is cheapest at PCB design time and often impossible to retrofit later.
Three ways out of the chip
Parallel port. A handful of data pins plus a clock, driven at some multiple of the reference clock, often double data rate. Simple, well understood, and limited by the number of pins your package and board can spare. Four bits at 100 MHz DDR is a different world from sixteen bits at 200 MHz.
High-speed serial, where implemented. A vendor- or SoC-specific serial trace link - Aurora over FPGA transceivers is one example. Availability is not implied by the processor family. Far more bandwidth per pin, at the cost of a serial transceiver on both ends and rather more care in layout.
System interface. PCIe® or a comparable bus that already exists on the board. No dedicated trace pins, which is attractive - and the trace now shares bandwidth with the application, which is a form of intrusion. Whether that matters depends on how loaded the bus is.
There is a fourth option that is not really a way out: keep the trace on chip, in an internal buffer, and read it out afterwards. No external trace pins, and often low impact on the application bus - but trace generation, buffering, power and readout are not automatically effect-free. The recording length is whatever the buffer holds: state the capacity in bytes and convert it to time using your measured trace rate, rather than assuming a generic duration.
What actually decides it
Are the pins bonded out? Some parts have a trace unit whose pins are not brought to the package on your variant. Nothing on the board can fix that.
Are they routed to a connector? This is the frequent case: the silicon can do it, the schematic gave the pins to something else. A GPIO expander now occupies the trace port.
Is the connector one that tooling exists for? MIPI® 20, Mictor, or a vendor-specific arrangement. A custom pinout is workable, and it means an adapter.
Does the layout hold at the required clock? Trace outputs are among the fastest signals on a debug connector. Length matching, stubs and vias matter. The failure mode is not “no trace” but intermittent decode errors, which cost far more time to diagnose than getting it right would have cost.
The economics of getting this wrong
Reading the target-side design notes during schematic review costs about an hour. Discovering the same information after a board spin costs a board spin.
This is not a subtle argument, and yet in Accemic project work, missing trace routing has been a recurring and expensive feasibility failure. The reason is organizational rather than technical: the person laying out the board is optimizing for cost and area, the person who will need coverage evidence is not in the room, and trace pins look like a debug luxury until the schedule depends on them.
If you are designing a board today and there is any chance that somebody will later want structural coverage, timing evidence or a hard bug found on real hardware, the cheapest possible insurance is to route the trace port and place the connector. If it turns out unnecessary, you spent a connector footprint.
Our target-side technical notes are available on the documentation portal - access is provided on request - precisely so this conversation can happen before the board exists rather than after.
A word on evaluation boards
If you are choosing an evaluation board in order to try a trace-based workflow, check the trace port first and the peripherals second. A board with a usable trace connector is worth more for this purpose than a faster part whose trace pins go nowhere.
We keep a documented list of evaluation boards with usable trace ports across several vendors - ask us which boards fit your part, and see the supported targets matrix.
What to ask before you commit
- Does this part have an instruction trace source, and is it documented?
- Are its pins available on the package variant we are buying?
- Where do they go on our board, and to which connector?
- What bandwidth does that give us, and does our workload fit? The deciding input is how far the protocol compresses your control flow - measure it on your workload rather than assuming it.
- Does the toolchain we intend to use decode this protocol on this part?
Five questions. Answering them takes an afternoon before the layout and a project afterwards.
Next: is this target traceable at all? · ask us about a specific board
What this page establishes
- the design-review items that decide trace-port feasibility;
- the three ways a stream leaves the chip, with their trade-offs;
- why the routing decision belongs into hardware design, not into the tool evaluation.
Limitations
Everything here is device-specific: pin multiplexing, security state and implemented sinks differ per SoC. The layer-by-layer checklist is on target trace feasibility.
Sources
The pin and connector conventions referred to above are specified in:
- MIPI Parallel Trace Interface;
- CoreSight™ Architecture Specification (Arm® IHI 0029).