FPGA sensitivities

I have a time-critical thing where the signal passes through an XC7A15 FPGA and does a fair lot of stuff inside. I measured delay vs some voltages:

1.8 aux no measurable DC effect 3.3 vccio no measurable DC effect

2.5 vccio ditto (key io's are LVDS in this bank)

+1 core -10 ps per millivolt!

If I vary the trigger frequency, I can see the delay heterodyning against the 1.8V switcher frequency, a few ps p-p maybe. Gotta track that down.

A spritz of freeze spray on the chip had practically no effect on delay through the chip, on a scope at 100 ps/div.

I expected sensitivity to core voltage, so we'll make sure we have a serious, analog-quality voltage regulator next rev.

The temperature thing surprised me. I was used to CMOS having a serious positive delay TC. Maybe modern FPGAs have some sort of temperature compensation designed in?

We also have a ZYNQ on this board that crashes the ARM core erratically, especially when the chip is hot. It might crash in maybe a half hour MTBF if the chip reports 55C internally; the FPGA part keeps going. At powerup boot from an SD card, it will always configure the PL FPGA side, but will then fail to run our application if the chip is hot. We're playing with DRAM and CPU clock rates to see if that has much effect.

Reply to
John Larkin
Loading thread data ...

Yecch, good to know--keeping the drift down to 1 ps requires the 1V supply to be stable to 100 ppm total. I don't think I've ever needed to use four-wire sensing on a logic supply, but you're probably going to have to.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

I don't expect to keep the delay stable to 1 ps over temperature. Below 1 ps/oC would wipe the competition. I do want to get the jitter down into the single digits of ps RMS.

I boogered the +1 volt (Zynq core) supply voltage up to 1.1 volts and the ARM crash thing went away. Or the crash temperature went way up. So we have a timing problem.

My engineers are working from home but one is burning me a new SD card to try, with slower clocks in the ARM and DRAM. I'll pop over soon and pick it up. She lives in a tiny rent-controlled apartment above Dolores Park. Her next-door neighbor on that block is one of the richest people in the world.

Reply to
John Larkin

fredag den 25. september 2020 kl. 23.53.06 UTC+2 skrev John Larkin:

yeh, I've not seen such issues and that is even running at 90'C occationally

Reply to
Lasse Langwadt Christensen

I just did some clean startups with a chip temp of 100c... after increasing the core voltage from 1.0 to 1.1. I'm thinking there may be a time window or race condition somewhere, not a simple speed failure. Maybe I could fix it by going down on voltage too.

The ARM and the fabric have different clocks and talk to one another a lot. I think they use the Wishbone bus.

This is going to be tedious to find. I'll let other people do that.

Reply to
John Larkin

A15

k
a

be

ure

to

ally

the interface to the ARM complex is AXI bus so is most of the xilinx cores one interesting quirk of AXI is that it has no timeout, so if you try to read and the slave doesn't respond the ARM will do nothing waiting forever

I'm assuming it runs linux, have you tried to plug in a serial port to see what it does? it is ARM software in the bootloader that configures the PL so something did run if it got that far, though it might only use internal memory

Reply to
Lasse Langwadt Christensen

Voltage switching logic is sensitive to supply voltage.

When I was working for the Nijmegen University science workshop, we got a c omplaint from the electron spin resonance group that the TTL-based timer th at we'd built for them some years earlier (before my time) was producing ex actly this kind of pico-second level jitter.

I reworked the relevant board with surface mount components. which left me enough extra space to fit in an ECLinPS stage that resynchronised the outpu t pulse to the 200MHz master clock. We then pushed the signal through a ECL

-toTTL converter and the jitter had gone away.

This impressed everybody no end, and we got the okay to do better timer, w ith the timing edges coming out of an ECLinPS MC100EP195 - actually an ECL inPS MC100EL195 but that doesn't seem to exist any more

formatting link

The bulk of the data handling was to be done in TTL/HCMOS - I couldn't find any memory that I cycle faster than 40MHz so we ended spitting out four de lays worth of data every 25nsec which gave us enough precisely located timi ng edges in that 25nsec to keep the electron spin resonance guys happy.

Of course, once we'd got the design nailed down (on hundreds of pages of A4 schematics), the electron spin resonance group got defunded, so we never built anything.

--
Bill Sloman, Sydney
Reply to
Bill Sloman

That was considered, but it's temperature and core-voltage dependant, so it's not some dumb memory map error.

I'll let my FPGA and C guys poke into the internals. Yes, it runs Linux. I have mostly verified that the ARM dies hard, not still running some of the simpler tasks.

As I understand it, it pulls a Xilinx-generated boot loader off the SD card, and that reads the config file and loads up the FPGA and then our c code. That runs out of cpu-local SRAM and it always loads the FPGA. But if it's warm, our application then crashes, instantly or within an hour. It runs out of DRAM and bangs the FPGA registers a lot. Our code programs a second FPGA, and if the application crashes at startup, that one doesn't program.

So, it could be a problem with DRAM, or it could be something wrong with the FPGA bus interface.

I was wondering if anyone else had a problem like this.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

I don't know if this is even remotedly related to your architecture but I had an ARM (NXP) parts randomly fail at higher temperatures, but below the specifications (70C) and the fix was to add 1 flash read wait-state. DRAM can have those too of course.

Reply to
boB

Am 26.09.20 um 04:41 schrieb snipped-for-privacy@highlandsniptechnology.com:

That leads to the question if it happens on more than one board.

Gerhard

Reply to
Gerhard Hoffmann

Four.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

We're currently debugging a ZYNQ 7045 that seems to lose some of its register programming when first coming up. Re-writing after boot seems to be our only workaround to the problem. So far just one board is exhibiting the problem. I don't believe it is a heat problem as we have a heatsink installed and air blowing on it, plus it happens on a cold start.

Buzz

Reply to
Buzz McCool

You might test to see if it is temperature sensitive. Just spritz it with a heat gun and freeze spray.

We're still seeing our problem on some boxes. It looks like the boot-time stuff, which runs in cpu SRAM, works, but then Linux crashes when the chip is warm.

Vcc_core = 1.1 volts fixes it. 0.92 breaks it hard. People are still hunting.

The tools for tracking down things like this are few.

Might be a DRAM problem, but it runs the DRAM test OK.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

Am 01.10.20 um 16:50 schrieb snipped-for-privacy@highlandsniptechnology.com:

Back in Z80 days I knew someone who could run DRAM tests all day long without a single error. And that was the only thing he could run on this Z80.

Turned out the Z80 supplies 7 Bits for refresh and he had bought 64K rams with 8 bit refresh. And LOTs of them.

The DRAM test program did its own refresh by addressing all possible row adresses.

Cheers, Gerhard

Reply to
Gerhard Hoffmann

This reminds me of a CP/M computer we built using a Z80 and DRAMs (with proper 7 bit refresh). The computer booted fine and run as long as it was not left idle for longer than some seconds. The idle period killed it totally.

After searching for the cause, it proved that the refresh circuitry was totally broken (a bad chip), so the DRAMs did not forget in milliseconds, but seconds.

--

-TV
Reply to
Tauno Voipio

Sometimes a DRAM can remember for many seconds without refresh.

We will look into possible refresh issues. We hadn't considered that.

Worst case, we could maybe run a little program that did refresh.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

On Thursday, 1 October 2020 at 07:50:45 UTC-7, snipped-for-privacy@highlandsniptechnology.com wrote: ..

I had a tricky problem with somewhat similar symptoms (I don't remember whether it was temperature-sensitive) but it also was cured by increasing the core voltage.

We worked with Xilinx on that and it seems that there can be package resonances in the 30-50MHz range (this was a Virtex 5 in a large package). Our system was running with a 168MHz clock and 5 time-slots but one of time-slots had no significant processing. The result was that we had 30A pulses in the supply current at ~33MHz.

I did a board spin to increase external decoupling without any improvement.

The fix we took into production that avoided the problem was to process random data during the fifth time slot to reduce the supply current perturbations.

kw

Reply to
keith

The official spec for 4164 DRAM chips says "refresh at least every 4ms".

In an Oric (6502A based) computer, a ULA is used to provide memory refresh as a side effect of building the TV picture. Suppressing the memory refresh by holding this ULA in a "reset" state for a second or so seems to have no effect on memory contents, even though this also stops the system 1MHz clock.

Everything comes back working when the reset is released.

It takes at least a couple of seconds of refresh/clock loss for corruption of screen memory contents or the system to crash (bad data/bad code in RAM, loss of dynamic registers in the 6502A).

Didn't expect that, so DRAM *is* more resilient than you'd think.

--
--------------------------------------+------------------------------------ 
Mike Brown: mjb[-at-]signal11.org.uk  |    http://www.signal11.org.uk
Reply to
Mike

We're using a Micron 64G DDR BGA part, which is "self refreshing" whatever that means. The data sheet is 132 pages. But there are a jillion parameters that the Vivado software uses to build the DRAM interface, so maybe we have one of those wrong. My guys like to tune for performance, and I like to tune for reliable and good enough.

An older version of this product used a 68332 CPU running at 16 MHz. Now we have dual ARM cores running at 600 MHz, with cache. We don't need to push anything.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

fredag den 2. oktober 2020 kl. 16.15.52 UTC+2 skrev snipped-for-privacy@highlandsniptechnology.com:

is it not the same part as on the microzed? try loading the standard linux image and see if that also crashes

Reply to
Lasse Langwadt Christensen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.