Clock constrains for GPIO IP core of arria 10

[lambert_yu]

Hi, all

  fpga : 10ax115N3f45I1sg

  quartus : 18.0.0 standard version

  Now I'm using GPIO IP core to design using bus lvds. And for this IP, I use half rate design, read and wirte use seperate clocks. IP design likes below:

   gpio_ip gpio_ip_inst(

   .fr_ck_in ()

  .hr_ck_in ()

.dout()

.fr_ck_out()

.hr_ck_out()

.oe()

.din()

.pad_io()

.pad_io_n()

);

fr_ck_in = 2* hr_ck_in; fr_ck_out = 2* hr_ck_out;

 din belongs to hr_ck_out domain. like below:

  always @ (posedge hr_ck_out, posedge rst)

 if(rst)

   din <= #1 4'h0;

else

  din <= #1 din + 4'h1;

Now for the input, I saw the din as the async input; And for the output, I will not output the source clock. (async output)

 fr_ck_out/hr_ck_out; fr_ck_in/hr_ck_in are all from the same PLL

/////output

 And for output hr_ddio, I found that for  the din (din[0] and din[2]， din[1] and din[3]) generated current rising edge of hr_ck_out, it will output at hr_ddio_dout at the next rising edge and falling edge of hr_ck_out. And from the timing analysis result, there's no timing violation. And I didn't found any timing path from din to hr_ddio_dout and only exist the path from din to dr_ddio_datain*. So I don't think there necessary need to set all output ddio timing constrain, right?

///input

 And for input, just because it belongs to async input, there's no necessary need to set the ddio timing constrains and only make sure fr_ck_in and hr_ck_in from the same PLL, right?

////result.

  So, for the only constrain for the GPIO design, it only need one constrain: derive_pll_clocks, right?

BRs,

Lambert

[ShengN_Intel]

Hi,

I think you still need to properly constraint the input and output delay (external device) check this link https://www.intel.com/content/www/us/en/docs/programmable/683780/22-1/full-rate-or-half-rate-ddio-input-register.html

You probably will still get unconstraint paths for I/O.

Thanks,

Regards,

Sheng

[lambert_yu]

Hi, Sheng

   Thanks for your response.

  But in my view,

 ///////for input

  For input, I only used it as async input (neighter system_sync nor source sync design), so for the timing path, I need care fr_clk -> hr_clk (clock domain crossing), and hr_clk domian(for the registers in the core, it uses the hr_clk continue to process the data). And because fr_clk and hr_clk comes from the same PLL output, I think "derive_pll_clock" constrain will be okay.

///// for output

 For output, I only used it as async output (neighter system_sync nor source sync design).

  For input din[3:0] (data from hr_clk domain),  and there's hr_clk -> hr_clk, hr_clk-> fr_clk, fr_clk->port(just because async design, there's no clock output), so tool will need only analysis hr_clk-> hr_clk, and hr_clk->fr_clk.

  (1) Just because there's hr_ddio and fr_ddio, I need follow "Opposite-Edge Capture Edge-Aligned Output" to set the DDR constrians for each *_ddio part or only set the DDR constrians for only fr_ddio?

  (2) And because I used the output as async output without clock output, I will not set the output delay and only need to set the exception constrain?

  Reason for "Opposite-Edge Capture Edge-Aligned output":

   As in the picture, din input is aligned to the rising edge ck_hr, and hr_ddio will capture the din[0] at the falling edge and capture the din[2] at the next rising edge. dout will be delayed one-cycle of ck_hr (as the red rectangular), right?

BRs,

Lambert

[ShengN_Intel]

Hi Lambert,

I had further confirmed with my team that since you're using async input and async output (neighter system_sync nor source sync design) so not need to set input delay and output delay, just timing exceptions will do.

And because fr_clk and hr_clk comes from the same PLL output, I think "derive_pll_clock" constrain will be okay

Yes, the derive_pll_clocks constraint will take care of the clock relationships from the PLL

 (1) Just because there's hr_ddio and fr_ddio, I need follow "Opposite-Edge Capture Edge-Aligned Output" to set the DDR constrians for each *_ddio part or only set the DDR constrians for only fr_ddio?

I think your mentioned situation suits well to "Opposite-Edge Capture Edge-Aligned Output" if check this document illustration https://cdrdv2-public.intel.com/653688/an433.pdf. For "Opposite-Edge Capture Edge-Aligned Output", do not use any multicycle or delay exceptions for opposite-edge transfers. The only exceptions necessary for correct timing analysis are false path exceptions.

So, set false path DDR constraints to only fr_ddio will do like example show in this link https://www.intel.com/content/www/us/en/docs/programmable/683780/22-1/full-rate-or-half-rate-ddio-output-register.html

[lambert_yu]

Hi, Sheng

   In AN443, in my view, I think it's for input and output interface constrains which are for the path between DDIO and pad. And for the false path exception constrains, it needs data_clock and virtual clock (for input) or output_clock (for output), and if I add virtual clock or output_clock, I think it presents system or source-sync design? I feel confused. How do you think about it?

BRs,

Lambert

[ShengN_Intel]

Hi Lambert,

Then I think you don't need to create the virtual clock or output_clock anymore. For set_false_path, use others instead of get_clocks.

You only need to set_false_path if got any timing violation, but seems like your timing is clean then probably don't need to set_false_path as well.

[ShengN_Intel]

Hi Lambert,

May I know you still got any problem with your sdc constraints?

Thanks,

Regards,

Sheng

[lambert_yu]

Hi, Sheng

   Just because I designed one very simple project and there's only the instance as in the first message. And there's no timing violation. But I want to know which suitable constriants will I need to add (which I provided and related analysis is correct?)  in one large project in the future. I have little confidence about this part.

BRs,

Lambert

[ShengN_Intel · Accepted solution]

Hi Lambert,

Probably should be fine since there's no timing violation.

Since that's asynchronous input and output so not need to set input delay and set output delay. Without set input delay and set output delay, you wouldn't see any timing violation one.

Thanks,

Regards,

Sheng

[lambert_yu]

Hi, Sheng

   Thanks for your response. I expect that there's no timing issue for this part in the future real project.

BRs,

Lambert