CASTalk.com

Fawnizu · Guest

Hello,

I realize that AMBA bus interface provides some test support. It has
the Test Interface Controller (TIC) which can interface to the ATE.

But what I'm wondering is, does the test architecture as defined in the
AMBA specification (rev.2) provide the mechanism to apply the test
vectors to the cores?

If yes, what kind of DFT does it support?

If not, does it mean that all the required DFT (scan chain, wrapper,
TAM, etc) has to be included by the test engineer?

Hope you can share your knowledge and experience using AMBA bus
(rev.2).

Thank you in advance,
Fawnizu

Guest

Hi,
I've been working with AMBA 2.0 for the last 2 years.
I personally developed the bus architecture and a Test Interface
Controller followin the AMBA specification.
The TIC provides a support for testing all the slaves on the bus. It is
a bus master that can operate like any other master, but is controlled
from an external bus interface (EBI). This means that it has no way to
access to internal cores if you don't provide a slave interface to what
you need to read/write. It is a substitute of the microcontroller on
the bus.
If you are considering to insert any DFT support, AMBA does not
standardize DFT structures and you should insert this hardware by your
own.
But if your system is quite complex it is convenient to include also
the TIC if you want to test each peripheral from the AHB/APB bus.
I successfully run some tests using an Agilent pattern generator and a
logic state analyzer on a prototype chip, testing memories and
peripherals.

Hope I answered your question.
Regards,
Massimo

Fawnizu wrote:

Faw · Guest

Hi Massimo,

Thank you for the explanation. Please correct if I'm wrong.

Based on your explanation, if all the cores in the SoC are full-scan
DFT inserted, and all test vectors and responses are available
externally, I would need to have a slave interface (i.e. core wrapper)
at the core under test (CUT) to accept the test vectors (through write
transfer from TIC/EBI) and apply the vectors to the full scan CUT. The
slave interface will have to perform the two functions above--accept
vector and apply vector to CUT. Is my statement correct?

Btw, when entering test mode (i.e. TIC is granted bus access), does the
whole SoC operate from the external test clock, TCLK? Or is it optional
to use TCLK?

Sorry for asking too many questions.

maco · Guest

Yes, you need a slave interface and some logic to translate your AHB
transfers into scan chain patterns. But if you have an AMBA-based SoC
and you need some test structures like scan chains you should also
evaluate to use a standard JTAG port. The TIC is very expensive in
terms of I/O pins since it requires 35 additional pins. You should
integrate a TIC if you suppose to use it also for testing system
peripherals without a scan chain.

The use of TCLK is not mandatory, I suppose. But you should consider a
lower frequency clock to prevent critical paths on the test paths
during synthesis. In many cases, in fact, the TIC timings could be
critical because its signals need to propagate from the chip boundaries
(the I/O pads) to the inner cores. Pay attention to this!
Regards,
Massimo

Faw · Guest

Yes, I completely agree with you regarding the test clock. Typical scan
frequency for full scan circuits is much lower than functional
frequency.

The 35 pins, I guess, are from the following.
32 pins for Add/Data lines
1 pin for TCLK (optional?)
1 pin for TREQA
1 pin for TREQB
1 pin for TACK

However, in the documentation, they mentioned that only two dedicated
pins are required: TREQA and TACK. The other pins can be shared with
functional pins through multiplexing. In your experience, is it
possible to do the sharing so we can reduce the required pins for
testing?

Thank you.

maco · Guest

In my experience it is possible to share all the TIC pins. If you
consider a low frequency clock for the TIC, this shouldn't affect TIC
transfers timings.
The only drawback is that you will not fully test the peripherals
sharing some I/O pins with the TIC. For instance, if you share the TIC
data bus with a memory controller data bus you have to deactivate the
memory controller when using the TIC and this means that you will not
test the memory controller with the TIC. In addition, consider that you
will have to insert a multiplexer on the data bus whose delay could be
critical when the bus is not used by the TIC.
Massimo

	CASTalk.com Forum Index -> Computer Architecture	All times are GMT
Page 1 of 1