UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
461 Views
Registered: ‎06-07-2012

EMCCLK and watchdog

Jump to solution

Hi,

I would have a question related to the Watchdog clock and the EMCCLK on Artix-7.

Normally, we use the internal CCLK (at +/- 50%) set to 50 MHz and CFGMCLK(Approx 65 MHz as defined in UG470) to load the FPGA in SPIx4 mode.  We use the multiboot feature to have a reliable golden code and a multiboot (upgrade) code.  We configure the watchdog timeout value according to the timer_cfg.xls file given to me by a nice Xilinx Employee during a WebCase exchange.

That Excel spreadsheet takes into account the minimal, typical and maximal CCLK frequency and the minimal, typical and maximal CFGMCLK frequency to find the optimal timer range.  That is based, from what I understand, on the fact that althouth the internal CCLK frequency can be at a large range of value (+ or - 50%), the internal CFGMCLK that drives the watchdog somewhat tracks the CCLK frequency.  In other words, you can't have the CCLK running at it`s minimal frequency and the CFGMCLKrunning at its maximal value in the same chip.  So far, so good.

 

However, when we need to run a PCIe interface, there is a hard limit on the total configuration time to be compliant with PCIe spec.  The -50% CCLK tolerance doesn't work with PCIe spec.  The solution is to use an external clock and connect it to EMCCLK. Tada!, we program always within the limits!

 

But then, what happens to the Watchdog? I mean, If I go on the watchdog mechanism, I don't care about the PCIe spec, but then I have a very fixed EMCCLK at 50 MHz and a CFGMCLK between 35 MHz and 90 MHz if I understand correctly.  The timer_cfg.xlsx doesn't find a valid timer value in that case.

 

Is my assumption that CFGMCLK will go from 35 to 90 MHz valid when using the EMCCLK?  Is there any trick to find the correct timer value when using EMCCLK?

 

Thanks,

 

jf

0 Kudos
1 Solution

Accepted Solutions
290 Views
Registered: ‎01-22-2015

Re: EMCCLK and watchdog

Jump to solution

@jlarin 

     …fails the same way with a wrap-around to the golden code...  Your FPGA then is stuck in uprogrammed state forever.
Yes.  If the upgrade/update image fails to setup the watchdog timer properly then this can happen.  A major reason for using the barrier images (per XAPP1247) is that they will always (in theory) setup the watchdog timer properly – even if the upgrade/update image is missing.  We use barrier images for multiboot operation and find that they work as advertised.  Here’s what we do and my understanding of how it all works.

When you have the board at your facility, the barrier images are written to PROM at locations just-above and just-below the space where your update/upgrade image is stored.  Also while the board is at your facility, the golden image is written to PROM.  The update image can be written to PROM at your facility or in the field. 

During the multiboot process, FPGA configuration starts at the golden image but then immediately jumps to the first barrier image which properly sets up the watchdog timer for a short timeout period.  If the update image is missing or early parts of the update image are corrupted, then the watchdog timer setup done by the first barrier image will result in a timeout and cause proper fallback to the golden image. 

If the update image is present and early parts of the update image properly setup the watchdog timer, then FPGA configuration from the update image proceeds.  However, if later parts of the update image are corrupted then (in theory) the second barrier image will be read.  This second barrier image sets up the watchdog timer for a short timeout period – and when this short timeout occurs, a proper fallback to the golden image will occur. 

Mark

5 Replies
427 Views
Registered: ‎01-22-2015

Re: EMCCLK and watchdog

Jump to solution

@jlarin 

     Is my assumption that CFGMCLK will go from 35 to 90 MHz valid when using the EMCCLK?
Yes - roughly. The watchdog timer clock is CFGMCLK divided by 256, or 125-380 KHz as shown in Table 5-37 in UG470.  The watchdog timer clock runs independently of the EMCCLK.

     But then, what happens to the Watchdog?
Your setting for the 30-bit watchdog counter value, TIMER_VALUE, determines the watchdog timer timeout period. So, for a watchdog timer clock of 125-380 KHz, the maximum timeout period will range from 8600s to 2800s.

     The -50% CCLK tolerance doesn't work with PCIe spec.
     The timer_cfg.xlsx doesn't find a valid timer value in that case.
     Is there any trick to find the correct timer value when using EMCCLK?
I have not seen timer_cfg.xlsx. I recall that the PCIe bootup spec is 120ms after power-ON. Do you want the watchdog to timeout at about 60ms, giving you time to attempt another configuration of the FPGA in time to meet the 120ms bootup spec?  I’m not sure what you are trying to do?

Cheers,
Mark

0 Kudos
Contributor
Contributor
401 Views
Registered: ‎06-07-2012

Re: EMCCLK and watchdog

Jump to solution

markg@prosensing.com wrote:

@jlarin 

      The -50% CCLK tolerance doesn't work with PCIe spec.

     The timer_cfg.xlsx doesn't find a valid timer value in that case.
     Is there any trick to find the correct timer value when using EMCCLK?
I have not seen timer_cfg.xlsx. I recall that the PCIe bootup spec is 120ms after power-ON. Do you want the watchdog to timeout at about 60ms, giving you time to attempt another configuration of the FPGA in time to meet the 120ms bootup spec?  I’m not sure what you are trying to do?

 


Hi markg@prosensing.com ,

Regarding PCIe spec, actually it is 100 ms for the PCIe spec and 100 ms for the ATX power supply spec.  When designing an add-in card, you can add both 100 ms delay.  So from when the power becomes good on the PCIe edge connector, you add the time for the Power-supply becomming valid on the FPGA supply pins, add the FPGA power-on-reset and Program Latency (Tpl and Tpor from xilinx Datasheet) and add the bitstream configuration time.  If the result is under the 200 ms from ATX and PCIe spec, you are good!

Regarding the timer_cfg.xlsx file, it was given to me by a Xilinx employee through a WebCase resolution in 2014.  I haven't found it anywhere on Xilinx web site so it must be an internal ressource.  By posting my e-mail, I hoped that a Xilinx Employee could send me an updated version or what replaces it. (Hi @kkaur ! I hope you are doing well!)

Regarding what I want to do, yes having time for another attempt to configure the FPGA before the PCIe bootup spec would be nice, but it is impossible for the following reasons:

First, the boot time with the clock at 50 MHz and the SPI is 4x mode is 90 ms. So with a very precise Watchdog clock, I could put the timeout at 91 ms.  Then when the code goes in fall to the golden, it reverts to SPI x1, so it will take another 360 ms to boot.  That's never going to be under the 200 ms. Still, that isn't a problem because whenever it happens (the device isn't seen on the PCIe bus), the customer can always do a warm-reboot of the PC which will not cause a reload of the FPGA (because the power is already there) and the device will then be seen on the PCIe bus.  Then the software will fix the programming issue without having the customer to send the board back to factory. That is good enough.

So what I actually want to get a recommended procedure to take into account the worst case frequency variation and get a valid timeout value programmed. Sadly the variations on some of the clock is very large (+/- 50%) but in reality, the clock is much closer to the typical value. So if it works on actual board close to nominal, it doesn't mean it will also work in the worst cases and thoses cases and those cases must be covered by design, not by test.

 

Best Regards,

 

jf

 

0 Kudos
390 Views
Registered: ‎01-22-2015

Re: EMCCLK and watchdog

Jump to solution

@jlarin 

…the customer can always do a warm-reboot of the PC which will not cause a reload of the FPGA (because the power is already there) and the device will then be seen on the PCIe bus. Then the software will fix the programming issue without having the customer to send the board back to factory. That is good enough.
Very nice!

…what I actually want to get a recommended procedure to take into account the worst case frequency variation and get a valid timeout value…
If FPGA configuration nominally takes 90ms (as you say) then set the watchdog counter value, TIMER_VALUE = 2.0*380,000 = 760,000.  For the watchdog timer clock variation from 125-380 KHz (ie. +/- 50%), this will result in timeout from 2.0 - 6.1 seconds. Thus, (timeout+reconfiguration) will never occur (in a statistical sense) during the initial 90ms configuration period - but will occur well before the customer warm-boots the PC.

0 Kudos
Contributor
Contributor
310 Views
Registered: ‎06-07-2012

Re: EMCCLK and watchdog

Jump to solution

We further looked at this and using a larger watchdog value will not work.  We have encountered that situation on the bench.  What happens when the timer is longer than required is that the QSPI flash wraps-around to the beginning of the flash where there is a watchdog timer reset and jump in the golden code.  Then the configuration logic retries to load the upgrade code, which fails the same way with a wrap-around to the golden code...  Your FPGA then is stuck in uprogrammed state forever.

I guess that there is no solution to use a fixed watchdog value when using an EMCCLK.  The solution I saw is to use barrier images as explained in XAPP1247. I haven't tried it yet (mostly because it cannot be done with our existing software). but it looks like it would fix the problem I see.

 

jf

0 Kudos
291 Views
Registered: ‎01-22-2015

Re: EMCCLK and watchdog

Jump to solution

@jlarin 

     …fails the same way with a wrap-around to the golden code...  Your FPGA then is stuck in uprogrammed state forever.
Yes.  If the upgrade/update image fails to setup the watchdog timer properly then this can happen.  A major reason for using the barrier images (per XAPP1247) is that they will always (in theory) setup the watchdog timer properly – even if the upgrade/update image is missing.  We use barrier images for multiboot operation and find that they work as advertised.  Here’s what we do and my understanding of how it all works.

When you have the board at your facility, the barrier images are written to PROM at locations just-above and just-below the space where your update/upgrade image is stored.  Also while the board is at your facility, the golden image is written to PROM.  The update image can be written to PROM at your facility or in the field. 

During the multiboot process, FPGA configuration starts at the golden image but then immediately jumps to the first barrier image which properly sets up the watchdog timer for a short timeout period.  If the update image is missing or early parts of the update image are corrupted, then the watchdog timer setup done by the first barrier image will result in a timeout and cause proper fallback to the golden image. 

If the update image is present and early parts of the update image properly setup the watchdog timer, then FPGA configuration from the update image proceeds.  However, if later parts of the update image are corrupted then (in theory) the second barrier image will be read.  This second barrier image sets up the watchdog timer for a short timeout period – and when this short timeout occurs, a proper fallback to the golden image will occur. 

Mark