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
105 Views
Registered: ‎06-07-2012

EMCCLK and watchdog

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
3 Replies
71 Views
Registered: ‎01-22-2015

Re: EMCCLK and watchdog

@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
45 Views
Registered: ‎06-07-2012

Re: EMCCLK and watchdog


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
34 Views
Registered: ‎01-22-2015

Re: EMCCLK and watchdog

@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