V4 and NBTI question, again..

Antti,

As usual, I will answer your questions below,

Aust-snip-

No, no damage at all. It is the classic NBTI Vt shift of the pmos devices (trapped charges). This is 30 years old. Nothing new here, except that the DCM balance for high frequency operation (anything greater than 300 MHz falls into this category because of the new differential balanced delay lines) is affected by non-use (ie the DCM is stuck at 0, or stuck at 1). The effect is slight, and only affects the DCM for high frequency mode. It also requires a high ambient temperature (like 85C). It also requires time. Any interruption or change allows recovery.

And if it is, is it fully self healing (unlimited number

Unlimited. The time to shift back is roughly equal to the time to shift. The more shifting that goes on, the more the shift diminishes, and actually stops (becomes a total non-issue, all charge traps are filled). Just leaving the device unpowered allows shift back as well. The only way we were able to affect the operational specifications was in the burn in (>1000 Hrs, all Vcc's at ABS MAX, temp at ABS MAX). Taking one of these devices after burn-in, and using it for awhile, made it meet specifications again...

Don't know about the availability of the macros. I do know that some of it is now built into the software (so you don't even need to know).

The need for the work-around macros diminshes as we see that this issue is probably a complete NON ISSUE. Obviously, anyone who thinks they will be subjetc to this, please contact your FAE to discuss it in full. The last 10 discussions have resulted in "no problems" so I doubt you are affected, but one can never be sure.

Just did my best. As for 'once and for all,' I doubt I am that good. Anything more?

Hi Austin

you are pretty good ! :) nothing more at the moment, thank you,

Antti

"Austin Lesea" schrieb im Newsbeitrag news: snipped-for-privacy@xilinx.com...

damging

there

'workaround'

mid

guess

Austin,

:) no, question answered!

Antti

Antti, you can download the verilog macro from the website. In order to get the VHDL one, you have to ask. The VHDL one is not really ready, it has a number of things in it that won't synthesize properly under synplify. Both versions use a pair of counters that are asynchronously reset by a level on the incoming clock. The design has some potential metastability hazards, and because of the set up, I suspect won't detect clock presence reliably with higher frequency clocks. The design is also a little on the resource intensive side, and can be made quite a bit smaller by rethinking the clock detection and using a shift register for saving the calibration constants rather than lut ram (eliminates the addressing and decodes). The other issue is that you really need to jump through hoops to keep the macro from getting trimmed out during map if it is for an unused DCM. The patch in 7.1 puts the macro in after map, so that it doesn't get trimmed out, however, if the other gotchas in 7.1 are forcing you to 6.3 then you need to come up with a null DCM on your own (there is supposedly a strategic patch for 6.3, but I have not been able to find it yet).. Either way, you need to load a bitstream right away to avoid the NBTI all together.

The function of the macro is actually rather simple. Basically, it has a clock sense circuit that detects missing clock in and missing feedback (you don't need the feedback detect logic if you are doing the feedback inside the FPGA). The sense logic in the macro is a little hokey, and uses more area than it needs to. A state machine basically waits for no clock to be detected, then it reads the DRP port on the DCM at addresses

42h, 51h and 4Eh and stores them in LUT RAM. It then writes "0000" to 4E, apparently this shuts off the DCM outputs, and then it cycles through 4 states in sequence that write values alternately to 42 and

1. These apparently tweak the internal calibration to keep the delay lines toggling. It continues to cycle through those 4 states until clock is restored (or reset is released). When that happens, it writes the stored values for 42,51 and 4E back into the DRP port, triggers a DCM reset and goes back to the initial state. I rewrote the macro using srl16s for the drp value storage (this eliminates the addressing logic), and used my own clock detection circuit that cuts the clock detection circut size to less than 30% of the original. I also cleaned up the state machine so that it is a single machine rather than a conglomeration of smaller machines. The clock for the detect circuit is a ring oscillator divided down to about 8 Mhz. Xilinx routes it on local routing rather than on a clock net, probably to avoid using up clock nets for designs that use a lot of clocks. I also made a null DCM macro which basically removes the clock detect logic, and alters the reset logic.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Ray -

Thanks for that very useful description.

Bob Perlman Cambrian Design Works

Howdy Antti (or Austin),

Could you point me to where you saw something official from Xilinx (unfortunately a newsgroup posting isn't official) about the DCM recovering its max frequency specs after being configured or unpowered for a period of time? All I can find is a description it degrading.

BTW, the following answer record may be of interest to you and others:

Thanks,

Marc

Marc,

Contact your FAE for information.

The information packet on this subject states the shift in Vt is reversable.

Aust> Antti Lukats wrote:

As does everything I found in general on NBTI by searching google with "NBTI"

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Ray,

Nice thing about and old well known behavior. It is old, and well known!

Aust> Aust>

Howdy Ray,

Google had found me a few mentions of it sometimes being irreversable under certain conditions - hence the question. Perhaps I'm misunderstanding it, or it doesn't apply to the problem that the V4's have. Here's the best reference:

Best regards,

Marc

Marc,

The "degradation lock-in" at higher temperatures for NBTI must be something that happens beyond 125C. We do not see any signs of irreversable Vt shift.

Then again, how can they tell it isn't hot carrier injection (HCI)? The two causes of Vt shift are similar, but are from different physical processes.

Aust> Ray Andraka wrote: