- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lambert,
May I know you still got any problem with your sdc constraints?
Thanks,
Regards,
Sheng
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Sheng
Thanks for your response. I expect that there's no timing issue for this part in the future real project.
BRs,
Lambert
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page