A reconfigurable design-for-debug infrastructure for SoCs

Enabling efficient post-silicon debug by clustering of hardware-assertions

“…In these arrangements c is number of the trace-register that can be embedded into trace data, m is the number of hardwareassertion inside each cluster and s is the number of the clusters. For example, in our test case, AMBA 3 AXI Bus protocol all these configuration are valid: (2,3,28), (1,4,22), (1,5,17), (1,6,15) , (1,8,11), (1,9,10), (1,14,9), (1,15,7).…”

“…We have synthesis our experiments on all valid configurations. TABLE I shows that the configuration (1,7,13) is the best configuration for resource usage. For energy consumption, configuration (1,8,11) is the best.…”

“…TABLE I shows that the configuration (1,7,13) is the best configuration for resource usage. For energy consumption, configuration (1,8,11) is the best. (2,3,28) 28.70 0.21 (1,4,22) 28.50 0.21 (1,5,17) 28.42 0.20 (1,6,15) 28.11 0.20 (1,7,13) 28.02 0.18 (1,8,11) 28.20 0.17 (1,9,10) 28.32 0.20 (1,14,9) 28.40 0.21 (1,15,7) 28.70 0.22 No clustering 29.01 0.32…”

“…The existing pre-silicon verification techniques which rely on the formal or functional (dynamic verification) cannot guarantee that the first-silicon works perfectly without any bug. Almost two thirds of newly manufactured SoCs product suffers from bugs at the first silicon [1]. Logic errors are still among the main causes of failures, including the fact that pre-silicon verification is applied to the model of the IC, and not the actual product [6].…”

“…The increase in the time-to-market of new products may cause the significant loss of market share, or even complete loss of revenue [1]. Therefore, as soon as the first silicon becomes available, it is required to identify any bug either in the design (corner cases) or the bugs related to manufacturing such as process variation and packaging.…”