Embed Size (px)
Citation preview
Integration of Hardware Assertions in Systems-on-Chip
Jeroen Geuzebroek Bart [email protected] [email protected]
NXP Semiconductorscitation count: 14 / conference: ITC’08
2013.03.18 Reporter: PCLee
Assertions in silicon help post-silicon debug by providing observability of internal properties within a system which are otherwise hard to observe. Besides generating synthesizable assertions, they also need to be integrated in a design.
In this paper we have shown how hardware assertions can be integrated in existing on-chip debug infrastructures, i.e., in a scan-based run-stop debug infrastructure and in a debug trace infrastructure. Experimental results on an industrial test SoC show that assertion based bus protocol checkers can be integrated with less than 1% additional area cost, including both the hardware assertions and the additional logic required to integrate the assertions in the SoC.
Abstract
What’s the problem: Today’s SoC integrate more elements than before. It makes
SoC becomes more complex. Add additional design, debug support in such a complex
architecture will cause more area cost.
Proposed method: How hardware assertions can be integrated in existing on-
chip debug infrastructure. 。Scan-based infrastructure。Trace-based infrastructure
Introduction
Related work
[14-16]: Public literature.Integrate assertion
processor together on a single chip.
Lack of detail about how to access and configure these processors.
[18-21]: Commercial tool.
Automate integrate assertion circuits on chip.
Dont disclose their internal work.
This paper
Scan-based infrastructure: On-chip debug events come from hardware or software breakpoints. Off-chip debug events come from external debugger via IEEE 1149.1. Hardware breakpoints is not known at design time. Stop conditions will be
programmed using a debugging tool. (cost higher area)
Integrate assertions in this architecture: Assertions act as a stop event. For more flexibility, enable and disable mechanism is needed. The property is known at design time. (hard-coded to minimize area cost)
Assertion checker enabling strategy One assertion, one register.(cost high) Enable or disable all assertion.(not flexible) Groups of assertions. (trade-off between
flexibility and area cost)
Integration of assertions in a scan-based run-stop debug infrastructure
Two types of result of assertion: Errors: Treat as hardware breakpoints. Warnings: Don’t stop system, just record in debug status register.
Disadvantage : Scanning out the serial debug status register is slow. Multiple violations of the same assertion will not be detected. The assertion
should raise until debug register capture this signal.
Results and disadvantage of scan-based assertion
Debug trace infrastructure: Trace signal for more observability. Store in trace memory or dump via UART port immediately.
Integrate assertions in this architecture: Record result of assertions in debug trace module. The amount of assertion data that can be output for each cycle is limited.
。 Number of assertion is grater than number of output bit
The size of result is limited.
Integration in a debug trace infrastructure
Dynamic ID selector ID for every assertions. (-
bit)Assertion fire signal
Up to n = assertions can add. (e.g..: 16-bit width can put assertions) Disadvantage:
Just one assertion each clock cycle. If < m, unused bit will appear.
m bit
Example: Priority strategy
Group k assertions into s sets.
Advantages: Multiple violating assertions are clear.
Dynamic set selector
Checking target Assertions for local properties that have been fully verified do not need to put in
hardware. Only global properties assertions are needed.
Bus protocol checker for experiment is described by PSL language. And translate them into RTL by MBAC. The assertion support logic(RTL) is also ready. AXI bus – 85 assertions MTL bus - 25 assertions OCP bus – 60 assertions
Addition area = all assertions + assertion support logic
Use both scan-based and trace-based infrastructure.
Area cost of assertion hardware
The reason for AXI assertions area increase rapidly is because of 2 of 85 assertions need more detail for checking.
Experiment result(65nm)
Communication Bus: AXI and MTL
Gate count table of AXI, AXI* and MTL bus protocol checker.
Area cost of bus protocol checkers in EN-II
285681 gate counts 59136 gate counts80% reduce
Area of scan-based infrastructure: 14 debug control register – 257 GE 770 debug status register – 13551 GE 756 debug status register – 13305 GE (without 2 complex assertions)
Area of assertion support logic: (ub: unused bit, k: # of a set, s: set)
Total area cost:
Total area of EN-II is 10M Ges: The ratio of assertion checker is 3.03% and 0.76% separately.
Total area cost
76% reduction
This paper’s conclusion: This paper shown how hardware assertions can integrate into existing
debug infrastructure. In scan-based architecture, IEEE 1149.1 TAP controller can be used to
control assertions, capture results and stop system. In trace infrastructure, problem of embedding assertions into debug trace
module have solved by dynamic converter. The additional hardware cost is low.(3.03% for all. 0.76% for omitting 2
assertions.)
My conclusion: This paper proposes method about how to integrate assertions in SoC. Make trade-off between area cost and observability of dynamic selection
can be referenced.
Conclusion
