Hi all.
I have some things to discuss about Source Synchronous representation in TimeQuest.
I attached the project, which is slightly modified version of Source Synchronous Analysis with TimeQuest by Ryan Scoville - https://forums.intel.com/s/createarticlepage?articleid=a3g0P0000005RIKQA2&artTopicId=0TO0P000000MWKBWA4&action=view
The project is an example of Source Synchronous design,
where FPGA is a transmitter, it shifts the clock, it is the same edge transfer mode, DDR. Inside the project there is a PLL which shifts the clock by 90 degrees, DDIO and registers for creation data to transmit. Clock goes out also using DDIO.
Constraints are as in the example, only set_false_path was added to leave FR and RF paths (for setup) away from analysis.
So, what is the discussion.
First of all, in order to check timing, I used Report Clock Transfers command
and report_timing command on the clock transfer between system clock (inst8|pll_1_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk) and clock going out of FPGA (ssync_tx_clk)
The first interesting thing is - it could be seen that Quartus successfully
detects paths where Launch clock is FPGA system clock which creates data and Latch clock is shifted version of system clock which goes out from FPGA port and which we described using create_generated_clock command. But it could be seen that Quartus chose PLL output - (inst8|pll_1_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk) as a starting point (from Node column).
Here is a figure from Technology Map viewer to represent one of those paths
And the first question is - why it is so? Why PLL output is the starting point of that path?
My explanation is that it is because of mux located inside DDIO block in Cyclone V. The output of that mux is controlled by clock from PLL, and this mux naturally enables DDR regs to go out to IO Buf. But I'm asking if it is a right explanation.
The second thing is that if we inspect that path - look at the detailed Data Path report
we will see in my opinion a bit strange behaviour - in Data Required Path
Clock starts from input pin, but starts at 2 ns. It is not what should be in a real world, because timing starts in Data Arrival Path at 0 ns time -
and clock gets shifted inside PLL, and the right report for Data Required Path should start from 0 ns time and should get a 2 ns inside the PLL.
So the second question is - why it is so? There is no reflection of clock phase shift inside detailed path analysis - the shift is incorporated at the start of the analysis.
Thanks in advance.
--
Best regards,
Ivan
Link Copied
Hi YY.
Thank you.
As about your answer.
About my first question - as for the data path, there are no constant values on DATAINHI and DATAINLO. DATAINHI and DATAINLO connected to synchronizers, which are in turn connected to input ports.
And yes, output of the PLL is connected to the MUXSEL, CLKHI and CLKLO.
So it is a strange situation, where as I understand, we need to consider the whole DDIO and a mux as its ending element as a one trigger-like sequential element, which launches data to the output port.
My question was is it a right explanation, or not. It looks like previous customer (sstrell) who tried to answer that question said "it doesn't make sense that you're seeing data path analysis with a PLL output as the from node."
So it is an interesting case, isnt' it?
As my second question - maybe my question was not descriptive enough, my question was not why I'm seeing 2ns in the latch edge time under Data Required Path,
but why in the Detailed Data Path report we start the clock Path from the input pin and it starts from 2 ns?
Again, I can post my question:
"clock gets shifted inside PLL, and the right report for Data Required Path should start from 0 ns time and should get a 2 ns inside the PLL.
So the second question is - why it is so? There is no reflection of clock phase shift inside detailed path analysis - the shift is incorporated at the start of the analysis."
I can try to explain that - for example - "clock shifts inside PLL aren't represent in the timing path report".
--
Best regards,
Ivan
Hi,
From the design, the DATAINHI and DATAINLO are connected to 1'h1 and 1'h0.
In general, you would see clock sources as the starting point of timing paths in a "clock-as-data" scenario, when a clock feeds a data input pin of a register (or an output pin with a "data-like" constraint like set_output_delay).
Looking at the circuit in netlist viewer, it seems that the PLL output is driving "CLKHI", "CLKLO" and "MUXSEL" inputs of the DDIO_OUT blocks. Looking at the timing path report (pasted below), it looks like the MUXSEL input is modeled as a data input (as opposed to a clock input). So, we have a "clock-as-data" path, where the PLL output clock is driving the ssync_tx_data pin (via MUXSEL of the DDIO), which has a set_output_delay constraint, creating a valid timing path.
So, Timing Analyzer behavior looks correct.
The clock is 0ns from input pins, get shifted by 2ns through the PLL . This clock inst8|pll_1_inst|altera_pll_i|general[1].gpll~PLL_OUTPUT_COUNTER|divclk has 2ns delay compared to inst8|pll_1_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk, which is why the latch clock edge is 2ns but not 0ns.
Thanks.
