The Tempterature Sensor IP Introduces a Synchronous Clock That Breaks Timing Requirements
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...
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:
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.
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.
New Contributor
