The Tempterature Sensor IP Introduces a Synchronous Clock That Breaks Timing Requirements

[SimonRavn]

We have just added the "Temperature Sensor Intel® FPGA IP" (based on the "Intel® Stratix® 10 ADC") to a large design to be able to monitor the FPGA die's core temperature while it is running. However, with this addition a 250MHz clock ("altera_int_osc_clk") is introduced into the system which is by default treated as synchronous with our systems' clock, introducing major clock skew that make half our clocks violate the timing requirements and implementation impossible since our clocks are not compatible with this new clock.

After investigating the issue, we found that this clock is introduced in one of three .sdc files that are automatically generated for the IP component, but despite our best efforts we have been unable to add constraints to this clock through changing/adding .sdc files that would have it be treated as asynchronous (such as by using set_clock_groups-asynchronous-group[our clocks]-group[get_clocks {altera_int_osc_clk}] ). When we look into the list of .sdc files in the Timing Analyzer we find that these generated files always are read after our files, as shown below where an extra file (async.sdc) was added at the end of the project's .qsf file which still ended up being read before the generated files:

Our main .sdc file with constraints for our system is simply called "quartus.sdc"

Is it in any way possible to make this added clock asynchronous to our clocks, so that it no longer breaks our system?

[FvM]

Hi,

I see that Temperature Sensor IP uses two clocks, external clock up to 100 MHz and internal oscillator for SDM. As far as I understand, external ports are only using external clock, domain crossing to internal oscillator is handled inside the IP.

Thus I don't understand how a timing violation is brought up.

Regards

Frank

[SimonRavn]

Hey Frank,

Yes, there are no timing violations in the crossing itself within the IP, however, the fitter seems to try to align our clocks with the new clock as if they were in some way synchronous, introducing a detrimental amount of clock skew to our clocks, from which the violations arise. Or that is at least what it seems like when we look at the issue.

Let me just attach the Hold Transfers tables from the timing report of the system compiled with and without the IP (and therefrom the added clock):
Our system's hold transfers report for our many clocks before adding the IP with its new clock, where we also see the worst-case hold slack is a non-issueOur system's hold transfers report after adding the IP as the only change, with the new clock highlighted, where we see the relationship found between one of our clocks and the new clock, and we also see the effect on the worst-case slack of a few of our clocks from which violations occur

With the new "altera_int_osc_clk" clock we get the timing unsafe classification with our 5 MHz clock, since there are no constraints for the relationship between our clock for our wrapper module that interfaces with the IP and the new clock.

We have for example in our "quartus.sdc" file set clock groups so that our "dsp_jtag_tck" and "etm_swclk" clocks are viewed as asynchronous to all other clocks in our system, wherefrom their paths to other clocks are treated as false and classified as ignored relations. We would like to do the same with the "altera_int_osc_clk" clock, but have so far been unable to. This is why I asked if it was possible to set the new clock as asynchronous to ours, so that the fitter does not destroy our clocks due to the addition of that clock.

[SimonRavn · Accepted solution]

For anyone that have a similar issue in the future, this part of our timing problems with the temp sensor was resolved by getting the Timing Analyzer to write a new .sdc file for the project as that combines all previously given .sdc file constraints into one, in which we could find the generated create_clock constraint used for the altera_int_osc_clk clock. In our case it was:

create_clock -name {altera_int_osc_clk} -period 4.000 -waveform { 0.000 2.000 } [get_nodes {*|intosc|oscillator_dut~oscillator_clock}]