2013.03.18 Reporter: PCLee

1. Integration of Hardware Assertions in Systems-on-ChipJeroenGeuzebroek Bart Vermeulenjeroen.geuzebroek@nxp.com bart.vermeulen@nxp.comNXP Semiconductorscitation count: 14 / conference: ITC’08 2013.03.18 Reporter: PCLee

2. Abstract • Assertions in silicon help post-silicon debug by providing observabilityof 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.

3. Introduction • 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 complexarchitecture 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

4. Related work [18-21]: Commercial tool. Automate integrate assertion circuits on chip. [14-16]: Public literature. Integrate assertion processor together on a single chip. Lack of detail about how to access and configure these processors. Dont disclose their internal work. This paper

5. Integration of assertions in a scan-based run-stop debug infrastructure • 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)

6. Results and disadvantage of scan-based assertion • 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.

7. Integration in a debug trace infrastructure • 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.

8. Dynamic ID selector ID for every assertions. (-bit) Example: Priority strategy Assertion fire signal m bit • 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.

9. Dynamic set selector • Group k assertions into s sets. • Advantages: • Multiple violating assertions are clear.

10. Area cost of assertion hardware • 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.

11. Experiment result(65nm) • The reason for AXI assertions area increase rapidly is because of 2 of 85 assertions need more detail for checking.

12. Area cost of bus protocol checkers in EN-II • Communication Bus: AXI and MTL • Gate count table of AXI, AXI* and MTL bus protocol checker. 59136 gate counts 285681 gate counts 80% reduce

13. Total area cost • 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. 76% reduction

14. Conclusion • 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 observabilityof dynamic selection can be referenced.