Design For Debug Using DAFCA system

1. Design For DebugUsing DAFCA system Gadi Glikberg 15/6/06

2. What is SoC? • System-on-Chip is an idea of integrating all components of a computer or other electronic system into a single chip. It may contain digital, analog, mixed-signal, and often radio-frequency functions – all on one chip. A typical application is in the area of embedded systems.

3. The system’s different parts Signal Probe Network (SPN) is a MUX network that collects a group of signals and selects a subgroup of them to be brought to processing instruments (described below). An SPN is a transport instrument that does not modify its input signals. An SPN can be pipelined based on a user-specific number of stages. A local SPN transports signals from a single clock domain, while a global SPN extends across several clock domains.

4. The system’s different parts Debug Monitor (DEMON) analyzes a group of signals. A local DEMON is fed only by signals from the same clock domain via a local SPN, while a global DEMON is shared among signals from different clock domains arriving via a global SPN.

5. The system’s different parts Tracer contains a buffer memory that can record inputs signals. The recording of signals may be turned on or off by control signals (usually generated by a DEMON).

6. The system’s different parts Wrapper has signal analysis features much like a DEMON. Unlike a DEMON, any input signal of a wrapper may be transferred to an output without being modified, or may be replaced by an internally generated signal. A Wrapper processes signals from a single clock domain. Note a Wrapper does not have to completely wrap a block, but only a subset of its I/O ports

7. The system’s different parts CapStim is a Tracer whose memory may be preloaded with vectors. The CapStim operates by sending out the stored values and recording of new input stimuli.

8. Selecting the Debug Strategy

9. Where are my high-risk areas? • A core that has previously been verified and successfully used in other designs has a lower risk than a new core, except if it is used in new modes. • Project time constraints – Naturally some parts of the systems have longer time for verification then others. • Designer intuition is almost always more important than blind reliance on coverage measures.

10. An example system

11. How do we test the system? • First option – Use the SPN to select the corresponding signals. Use a DEMON to save the output vector. Read the result through the Jtag port and analyze outside in any waveform editor.

12. How do we test the system? • Second option – Use assertion based checkers. Assertions check signal behavior automatically. An assertion checks relations between signals during the operation of the system, and it fires when it detects misbehavior.

13. Assertions advantages • Bring you closer to the error – Debug process can begin immediately after the first assertion had fired. • Use pre-silicon methodology – assertions are commonly used on per-silicon. This feature enables to use this methodologies in real silicon. • All DEMONs can run their assertion simultaneously – After each group of wires was tested, a new test could be uploaded.

14. Taking a step back • Instead of looking at individual signals, a better idea would be to take a step back and look at the system in a transaction point of view. • The DEMON can act as a state machine and make sure that inter communication is proceeding as planed

15. Using the Wrapper • The wrappers offer an interesting debug option. A signal that was wrapped can be exchanged with a constant. Thus, we can check were a fault is (in the output or input component). This also enables us to test ECOs (Engineering Change Order) before actually issuing them!

16. scan dump • A future component named scan dump will enable to take snapshots of the systems register at a given moment. This way, when an assertion fires, the user can get not only the data in the tracers but the data stored in all of the system.

17. Which signals do we wrap? Wrappers are expansive in area, therefore they should putted mainly around high-risk areas such as: • new IP cores • new user-defined logic • logic implementing new or still-evolving standards • logic lacking good verification coverage (code coverage and/or assertion coverage)

18. Which signals do we tap? • signals identifying important transactions. Transactions are important since they allow understanding what is going on in the SoC; these signals are not limited to high-risk areas • signals needed as inputs to trigger circuits configured at run-time to recognize transactions

19. Which signals do we tap? • wrapped signals that the user also wants to record (note that just for analyzing a tap is not required) • status bits of all instruments • signals needed as inputs for assertions.

20. Sizing the Debug Infrastructure • All of the above debug possibilities eventually have a price. • The more debug features you add, the bigger the SoC becomes, and therefore it’s cost production rises. • Introducing extra ingredients into a system, even for debug, can be a cause for bugs in it self!

21. Summery Although one cannot precisely anticipate where errors will occur, the methodology introduced here, ensures that all risk areas and key circuits are thoroughly instrumented. The debug instruments support assertions, transactions, and in-silicon signal replacement. This approach significantly increases the probability that the instruments will be placed in locations that enable rapid insystem high-speed silicon debug.

22. END