01-09-2019 04:14 AM - edited 01-10-2019 01:32 AM
When using a MIG in a design, there seems to be no possibility to use the XADC for monitoring all the 6 supply voltages.
According to Mig User Guide (ug586) and AR51687, if I use both the XADC and MIG in a design, I have to provide the temperature to the MIG via device_temp_i[11:0] port asynchronously. The 12 bits should be taken from the XADC upper bits of the temperature read value. With ug480 this means that the MIG gets the temperature on a 1.9 degree grid (smallest possible change).
UG586 also states: "It should be updated at a minimum of once every 116 μs and there is no limit on the maximum update rate.".
Why is there such a tight requirement for a temperature value?
If temperature would rise by 2 degrees every 116 µs that is a very steep rate which will most likely damage the board, chip, solder and so on. And if the temperature rises slower than 2 degrees per 116µs then a lower update rate should be possible.
Also, what is meant by "should be updated"?
a) I should read the XADC value every 116 µs and forward it to the MIG. (i.e. I don't have to care how often the XADC updates the value, for example XADC could update it every 2nd read only).
If it's a) then this collides with the fact that the temperature is provided as 12 bits asynchronously, i.e. the MIG has no means to know how often I've read that value from the XADC, it can only observe a real change of the value.
or is it:
b) The XADC sampling cycle should be less than 116µs (i.e. the MIG needs a real (averaged) temperature value every 116µs, not just the last value again).
If it's b) then this collides with the statement from ug586:
"Averaging should be set to 16, but 64 or 256 is acceptable if already set for other XADC channels."
With averaging 64, there is no way to configure the XADC such that it updates the temperature in less than 320µs, which would violate the 116µs requirement.
There is another interesting question here:
What does the MIG do with an asynchronous temperature value anyways? It could change at any time, even if the MIG is just sampling it, so the MIG would get a completely random value in that case. Of course there are means of getting it synchronized, but they collide with ug586's "there is no limit on the maximum update rate".
01-18-2019 12:39 PM
The reason for the tight temperature requirement follows the same reasons as to why the MIG core needs to insert periodic reads every 1us; it's to maintain a tight timing relationship across the interface's PHY elements that are spanning multiple banks in the FPGA. UG586 talks about this in the Dynamic Calibration and Periodic Read Behavior and Temperature Monitor sections starting on page 158 and 159 respectively. A link to the latest version is in my signature.
As for "Should be updated" that's implying the maximum update period is 116us and you can go down as low as you want. Here "asynchronously" means the value on the device_temp bus can change at any point and doesn't need to be synchronized to any clock domain. Having it occur every 116us means it's periodic and doesn't say anything about its synchronicity.
01-21-2019 06:49 AM
The reason for the tight temperature requirement follows the same reasons as to why the MIG core needs to insert periodic reads every 1us; it's to maintain a tight timing relationship across the interface's PHY elements that are spanning multiple banks in the FPGA.
While there is sound reasoning for the 1µs reads for clock drift in ug586, there is no reasoning whatsoever for the 116µs limit in the next section on "temperature". In the real world temperatures do not change that fast, and therefore the drift due to temperature cannot be that fast as to requrire 116µs update rate.
Though there is a hint that the 116µs limit was merely copied from one place to the other. From ug586:
The tempmon configures the XADC for continuous looping on the XADC calibration and temperature measurement, both with averaging. This generates an updated temperature measurement every 116 μs.
So, if the MIG instantiates the XADC, it configures it for 116µs updates.
And then also from ug586:
In this case, you must drive and periodically update the device_temp_i[11:0]. It should be updated at a minimum of once every 116 μs and there is no limit on the maximum update rate.
So, if the user instantiates the XADC then the minimum update rate must be also 116µs.
This is a hint that the 116µs limit was merely copied from the default MIG-XADC config, and there was no measurement verify that limit. That's probably why the section on temperature measurement doesn't tell you what happens when you violate that 116µs, while the other section on the 1µs read limit does.
there is no limit on the maximum update rate
This is not true.
When looking at the sychronizer in mig_*tempmon.v we can see that the
temperature value is only taken if it is stable for at least 16 ui_clk clock cycles (see sync_cntr).
At 100 MHz that means 0.16 µs. If we update any faster than that, the
MIG will never see a temperature update - all updates will be blocked by the synchronizer.
So there *is* a limit on the maximum update rate.
As for "Should be updated" that's implying the maximum update period is 116us
Unfortunately that tells nothing about what an "update" is.
It's like saying "to update you have to update".
In my previous post I gave options a) and b) about what an 'update' could mean (XADC read interval *or* XADC update cycle).
Is it not possible to choose between those options?
If it is option b) (real XADC update cycles), then I would really like to know how to
configure the XADC for 64-averaging. This is clearly allowed from ug586, but is
impossible to configure with cycle times below 320µs.
01-21-2019 09:02 AM
Unfortunately this does neither explain why its the 116µs, nor what an "update" actually is.
Just because there's 1µs read interval for clock drift compensations, doesn't mean that temperature can change as fast as to make 116µs update intervals necessary.