Forum Discussion
Occasional ContributorFailure on getting timing closure for custom transceiver (phy) interface + dcfifo
I'm designing a duplex serial interface using the "Custom PHY Intel FPGA IP". It's a single lane interface with PCS-PMA width=10 and fabric interface = 8. Since my data-rate is fairly low I've chosen nearly the lowest (base) data-rate possible for the serial interface which is 625 MBps. The transceiver runs at a reference clock of 62.5 Mhz and the rest of the FPGA design runs at 100 MHz. Therefor I've used 2 DCFIFOs to interface between the transceiver interface and the rest of the FPGA: One DCFIFO has the transceiver's tx_clk as read-clock and its tx_parallel_data = the DCFIFO's q-output and one DCFIFO has the transceiver's rx_clk as write_clock and its data-input is connected to the transceiver's rx_parallel_data. Obviously I've setup sdc constraints for both clocks. The problem is that I'm consistently getting timing-closure failures like:
-0.289 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a0 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a0~DUPLICATE stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk 0.000 0.941 0.652 1 -0.282 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a0 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a0 stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk 0.000 0.935 0.653 2 -0.189 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a1 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a1 stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk 0.000 0.936 0.747 3 -0.273 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a2 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a2 stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk 0.000 0.935 0.662 4 -0.117 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a3 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a3 stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk 0.000 0.935 0.818 5 -0.187 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a4 stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_v1q1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a4 stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk stm_trx_fbr_interface|trx_ip_inst|A5|transceiver_core|gen.av_xcvr_native_insts[0].gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk 0.000 0.935 0.748 6
So specifically the transceiver's txpmalocalclk is giving me a hard time. Anyone understands what's going on there?
I am not sure why the hold violation is not optimized by the tool. I have tried to adjust the Fitter Advanced settings, but I was unable to resolve the hold violation.
However, I noticed that the setup for the failing timing path has a significant positive slack window. I used the set_min_delay SDC on those paths with timing violations to compensate for the hold window, and I was able to resolve the violation.
Attached the project and the SDC list used:
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|tx_framer:stmbus_tx_framer|tx_framer_state.FRAMER_RESET_STATE}]
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|tx_framer:stmbus_tx_framer|tx_framer_state.FRAMER_FINISH_STATE}]
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_6vn1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a*}]
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|tx_framer:stmbus_tx_framer|\tx_framer_process:framer_counter[*]}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|tx_framer:adcbus_tx_framer|tx_framer_state.FRAMER_RESET_STATE}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|tx_framer:adcbus_tx_framer|tx_framer_state.FRAMER_FINISH_STATE}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_6vn1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a*}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|tx_framer:adcbus_tx_framer|\tx_framer_process:framer_counter[*]}]
Other changes made:
- Disable all the assignment setting.
- Add the I/O SDC constraint for the bidirectional port.
Best Regards,
Richard Tan
8 Replies
- RichardT_altera
Super Contributor
May I know if the failing timing path occurs in the Transceiver IP or the FPGA design?
If it is failing on the IP side, I will need to consult with the IP owner.
Could you please share your design by archiving the project (Project > Archive Project) so that I can investigate it further?
Best Regards,
Richard Tan
p/s: If you find any answers from the community or Intel Support to be helpful, we encourage you to mark them as the best answer or rate them 4/5 in the survey.
arno_vaDear Richard,
I'm not sure but from the looks of it, it seems the FPGA design is what's failing. Could it be that somehow the
tx_clkout()-outputs of the transceiver IP are not properly propagated to global clocks? I've trying forcing that in the assignment-editor but that doesn't to work.I've attached my design. Hopefully you can spot the issue.EDIT: To get an idea about my design, a (rough!) block diagram of my transceiver interface:Kind regards,Arno
- arno_va
Dear Richard,
Do you have any update on this?
Kind regards,
Arno
- RichardT_altera
I may need some time to check the design. Sorry for any inconvenience caused.
Best Regards,
Richard Tan
- RichardT_altera
Sorry, I am still looking into this. Will get back to you once I have any finding.
- RichardT_altera
I am not sure why the hold violation is not optimized by the tool. I have tried to adjust the Fitter Advanced settings, but I was unable to resolve the hold violation.
However, I noticed that the setup for the failing timing path has a significant positive slack window. I used the set_min_delay SDC on those paths with timing violations to compensate for the hold window, and I was able to resolve the violation.
Attached the project and the SDC list used:
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|tx_framer:stmbus_tx_framer|tx_framer_state.FRAMER_RESET_STATE}]
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|tx_framer:stmbus_tx_framer|tx_framer_state.FRAMER_FINISH_STATE}]
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_6vn1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a*}]
set_min_delay -2 -from [get_keepers {stmbus_fiber:stmbus_fiber_instance|tx_framer:stmbus_tx_framer|\tx_framer_process:framer_counter[*]}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|tx_framer:adcbus_tx_framer|tx_framer_state.FRAMER_RESET_STATE}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|tx_framer:adcbus_tx_framer|tx_framer_state.FRAMER_FINISH_STATE}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|fifo_async_16x32:tx_fifo_async_16x32|dcfifo:dcfifo_component|dcfifo_6vn1:auto_generated|a_graycounter_bu6:rdptr_g1p|counter5a*}]
set_min_delay -2 -from [get_keepers {adcbus_fiber:adcbus_fiber_instance|tx_framer:adcbus_tx_framer|\tx_framer_process:framer_counter[*]}]
Other changes made:
- Disable all the assignment setting.
- Add the I/O SDC constraint for the bidirectional port.
Best Regards,
Richard Tan
- arno_va
Dear Richard,
Thank you very much for your help, that fixed my issue once again.
Strange that Quartus is unable to automatically do this, but at least I understand now what to look for the next time it happens. Kind regards,
Arno
- RichardT_altera
Thank you for acknowledging the solution provided.
Now, I will transition this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out.
Thank you and have a great day!
Best Regards,
Richard Tan
