We want to verify the (JTAG) debug system of the core in our simulation environment. Are there any prewritten test vectors/test benches available?
Applies to: ARM7TDMI
We don't have a test bench which verifies that Multi-ICE will work with a particular ASIC design.
You need do nothing special to make Multi-ICE work with your design. The only important points are as follows:
- When the core is in debug, it will indicate internal cycles on nMREQ (high) and SEQ (low). Your memory system MUST make sure that it will not respond to what appear to be ARM write cycles when nMREQ is high, since this is likely to result in memory corruption. Note also that the address bus and control outputs from the ARM7TDMI may change asynchronously with respect to MCLK while the core is in debug state. (Note - the AHB wrapper already does this).
- When the core needs to access the system memory from debug, nMREQ will go low with normal timing with respect to MCLK (as will the address bus and other control outputs), and the memory system should respond as normal. All system accesses performed in this way from debug state, will have the same timing as any other system access when the core is not in debug. The core ensures the timing will be the same. The important thing is that you don't gate the clock, or keep HGRANT low when in debug state - if the ARM can't perform memory accesses, then Multi-ICE won't work.
- nTDOEN is an active low signal. If you use this signal to enable the TDO pad output, you should make sure that you have got the polarity correct. If the TDO output pad is only enabled when nTDOEN is high, you will not be able to scan through the JTAG port.
- Finally, running one of the serial patterns (if you're not already doing production test serially) will enable you to check connectivity of the JTAG pins from the pads to the core.
Article last edited on: 2008-09-09 15:47:35
Rate this article
Disagree? Move your mouse over the bar and click