Reducing tester-based silicon debug effort & time: Part 2 – A check-list of best practices
Must-do practice #5
The porthole base memory location must be initialized through the startup constrained random testing (CRT) code.
Issue Analysis We use portholes for information printing in the patterns. Specific system memory locations are to be used for this. This includes an 8-bit write in the porthole location. For some core-platform systems, there is always a Read-Modify-Write (RMW) for 8-16 bit writes to System RAM. But since the read part of the RMW is 32-bit, we will end up with ECC errors while writing 8-bit if we do not initialize these porthole base locations before handing through the startup CRT code.
Solution The porthole base memory location must be initialized through the startup CRT code. Generally these information prints are only required for debugging and development. As a result, the testbench must have provision for a switch that can be passed specifically for tester patterns, which will suppress the printouts but still allow use of the macros (such as for register access). This will eliminate the problem altogether.
Must-do practice #6
The linker files used for making the hex code to be loaded and executed should be such that the hex does not have any address holes in it.
Issue Analysis In case of holes, that portion of the memory would remain uninitialized/unwritten with the result that there is a high probability of code execution jumping to these empty locations and getting accesses (due to burst accesses), thus leading to exceptions and ECC errors.
Solution Ensure that the testbench infrastructure for tester patterns at simulation level does not leave any holes in the generated hex.
Must-do practice #7
Always use zero-padding or fillers at the end of the hex so that no un-initialized locations are accessed during executions involving long instruction pipelines, or instruction bus fetch width constraints, or burst accesses.
Issue Analysis PowerPC cores have long instruction pipelines, so they will prefetch some additional data while fetching one instruction. Also the core instruction bus will always fetch a minimum width read and may have burst accesses enabled. So if the end locations of the hex are not aligned, during fetching of some instructions the core may end up fetching data from uninitialized locations with random ECC values even though it is fetching a valid instruction. This may result in ECC errors which may cause the core to get exception flags and stop executing altogether.
Solution During the linker and make process, care should be taken to put some filler codes at the end of hex in such a way that whatever code it puts in memory will be aligned so that un-initialized memory location accesses occur because of the following: long pipelined accesses, burst accesses or minimum width of bus instruction fetches. This can be done by using scripts to do a zero-padding at the end of the hex.
Must-do practice #8
While doing Resim (resimulation), loadings should be kept to a minimum in the VFT environment. This can be done through the use of earlier functional gate level simulations (GLS) replicated in the resim testbench.
Issue Analysis In the case of some analog models and memories, some of these behavior need to be forced in the functional testbench, for example forcing x-generation logic, initialization of portholes memories, or programming test rows of flash. Currently in the resim environment the functional testbench isn’t ported as is. But the same design is used to create the VCD, so X-corruption can occur there too.
Solution Before starting Resim, such things should be replicated for Resim from VFT environment. Also, all necessary forcing or loading needs to be replicated from functional testbench to the resim environment.
Loading comments... Write a comment