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.
FPGA sensitivities
Started by ●September 25, 2020
Reply by ●September 25, 20202020-09-25
On 2020-09-25 15:16, John Larkin wrote:> > > 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.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 ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●September 25, 20202020-09-25
On Fri, 25 Sep 2020 16:49:51 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 2020-09-25 15:16, John Larkin wrote: >> >> >> 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. > >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 HobbsI 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 by ●September 25, 20202020-09-25
fredag den 25. september 2020 kl. 23.53.06 UTC+2 skrev John Larkin:> On Fri, 25 Sep 2020 16:49:51 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > >On 2020-09-25 15:16, John Larkin wrote: > >> > >> > >> 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. > > > >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 > > 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. >yeh, I've not seen such issues and that is even running at 90'C occationally
Reply by ●September 25, 20202020-09-25
On Fri, 25 Sep 2020 15:54:29 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:>fredag den 25. september 2020 kl. 23.53.06 UTC+2 skrev John Larkin: >> On Fri, 25 Sep 2020 16:49:51 -0400, Phil Hobbs >> <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >> >On 2020-09-25 15:16, John Larkin wrote: >> >> >> >> >> >> 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. >> > >> >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 >> >> 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. >> > >yeh, I've not seen such issues and that is even running at 90'C occationally > >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 by ●September 25, 20202020-09-25
lørdag den 26. september 2020 kl. 01.16.43 UTC+2 skrev John Larkin:> On Fri, 25 Sep 2020 15:54:29 -0700 (PDT), Lasse Langwadt Christensen > <langwadt@fonz.dk> wrote: > > >fredag den 25. september 2020 kl. 23.53.06 UTC+2 skrev John Larkin: > >> On Fri, 25 Sep 2020 16:49:51 -0400, Phil Hobbs > >> <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> > >> >On 2020-09-25 15:16, John Larkin wrote: > >> >> > >> >> > >> >> 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. > >> > > >> >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 > >> > >> 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. > >> > > > >yeh, I've not seen such issues and that is even running at 90'C occationally > > > > > > 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. >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 by ●September 25, 20202020-09-25
On Saturday, September 26, 2020 at 5:16:21 AM UTC+10, John Larkin wrote:> 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.Voltage switching logic is sensitive to supply voltage. When I was working for the Nijmegen University science workshop, we got a complaint from the electron spin resonance group that the TTL-based timer that we'd built for them some years earlier (before my time) was producing exactly 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 output 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, with the timing edges coming out of an ECLinPS MC100EP195 - actually an ECLinPS MC100EL195 but that doesn't seem to exist any more https://www.onsemi.com/pub/Collateral/MC10EP195-D.PDF 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 delays worth of data every 25nsec which gave us enough precisely located timing 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 by ●September 25, 20202020-09-25
On Fri, 25 Sep 2020 17:47:35 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:>l�rdag den 26. september 2020 kl. 01.16.43 UTC+2 skrev John Larkin: >> On Fri, 25 Sep 2020 15:54:29 -0700 (PDT), Lasse Langwadt Christensen >> <langwadt@fonz.dk> wrote: >> >> >fredag den 25. september 2020 kl. 23.53.06 UTC+2 skrev John Larkin: >> >> On Fri, 25 Sep 2020 16:49:51 -0400, Phil Hobbs >> >> <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >> >> >> >On 2020-09-25 15:16, John Larkin wrote: >> >> >> >> >> >> >> >> >> 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. >> >> > >> >> >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 >> >> >> >> 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. >> >> >> > >> >yeh, I've not seen such issues and that is even running at 90'C occationally >> > >> > >> >> 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. >> > >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 foreverThat was considered, but it's temperature and core-voltage dependant, so it's not some dumb memory map error.> >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 >memoryI'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. Claude Bernard
Reply by ●September 26, 20202020-09-26
On Fri, 25 Sep 2020 19:41:48 -0700, jlarkin@highlandsniptechnology.com wrote:>On Fri, 25 Sep 2020 17:47:35 -0700 (PDT), Lasse Langwadt Christensen ><langwadt@fonz.dk> wrote: > >>l�rdag den 26. september 2020 kl. 01.16.43 UTC+2 skrev John Larkin: >>> On Fri, 25 Sep 2020 15:54:29 -0700 (PDT), Lasse Langwadt Christensen >>> <langwadt@fonz.dk> wrote: >>> >>> >fredag den 25. september 2020 kl. 23.53.06 UTC+2 skrev John Larkin: >>> >> On Fri, 25 Sep 2020 16:49:51 -0400, Phil Hobbs >>> >> <pcdhSpamMeSenseless@electrooptical.net> wrote: >>> >> >>> >> >On 2020-09-25 15:16, John Larkin wrote: >>> >> >> >>> >> >> >>> >> >> 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. >>> >> > >>> >> >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 >>> >> >>> >> 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. >>> >> >>> > >>> >yeh, I've not seen such issues and that is even running at 90'C occationally >>> > >>> > >>> >>> 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. >>> >> >>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 > >That was considered, but it's temperature and core-voltage dependant, >so it's not some dumb memory map error. > >> >>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 > >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.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 by ●September 26, 20202020-09-26
