Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
Re: Timing constriants difference between functional and te
Usually there are some differences. In many cases functional mode is more strict, so it may not always absolutely necessary to check both modes STA, but unless you know the DFT structures really well, it's definitely a good idea to check both modes.
Re: Timing constriants difference between functional and te
Well, here are a few examples (I'm sure there are many more):
1. Clock sources used for high-speed/at-speed scan may be different for test and functional modes, because the number and speed of clocks provided by manufacturing test equipment are usually limited compared to those in an actual system.
2. Low-speed scan test mode uses scan path for shift, which can have a lot of hold time violations that don't exist in functional mode.
3. High-speed Memory BIST requires timing constraints on the MBIST logic, but that logic generally isn't used in functional mode.
4. JTAG / boundary scan / Test Controller logic needs timing constraints that don't exist in functional mode.
5. False and multi-cycle paths will be different in test/functional mode.
Again, I'm sure there are more. That's all I can think of off the top of my head. Hope it helps.
Re: Timing constriants difference between functional and te
Those are good points.
I read that sometimes center aligned clocking in functional mode become edge aligned clocking in test mode also complicates the timing closure between test & functional mode.
I couldnt understand the reason behind this.Why can the clock phase be different between test & functional mode?
Re: Timing constriants difference between functional and te
fail1 said:
Those are good points.
I read that sometimes center aligned clocking in functional mode become edge aligned clocking in test mode also complicates the timing closure between test & functional mode.
I couldnt understand the reason behind this.Why can the clock phase be different between test & functional mode?
Great question. If I understand you correctly, the reason is related to my item #1 above. In test mode, the clock sources may be (often are) very different from those in functional mode.
So, for example, in a real system (functional mode) maybe CLK is input to PLL, which outputs CLKA (some multiplied and/or divided version of CLK). Also maybe CLKB is an input from another external I/O other than PLL. If CLKA flops exchange data with CLKB flops, you need careful constraints and synchronizing flops or FIFOs on the clock boundaries for functional mode.
But say CLKB is faster than the MFG tester can make. Now we have to make CLKB internally somehow. Maybe it's CLKA divided by 2 or something. But now CLKB is based on CLK/CLKA latency. So in test mode CLKB's phase is different relative to CLKA than in functional mode.
Realistic example numbers in case you need it: CLK = 100MHz, PLL is x3, CLKA = 300MHz, CLKB = 150MHz. Tester MAX clock rate is 125MHz. In that case, we can't make CLKB from external as in the case in the system/functional mode because tester max is too slow. But we can divide CLKA / 2 internally and use it. But it will have a different phase than in normal functional mode. So timing constraints and timing closure gets harder, or at least different (multi-mode.)
I don't think I directly addressed your center/edge-aligned question, mostly because I don't fully understand it (can you clarify?) but I think you should be able to see how clock phases, both absolute and relative, could be different in test vs. functional mode.
For example: in functional mode, data is exchanged between clock domain A and clock domain B. But in test mode, they are separate scan chains, so all paths form A <-> B are false paths. Maybe not a great example since you would want to try to test those paths in test mode too, but it's not always possible to do so.
You might have added MCPs in test mode around logic BIST or memory BIST, especially with BIST logic that generates go/no-go pass/fail flags.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
