Need help with timing constraints/closure for an EMIF design

[BKB]

Hi,

We have a design with 2 EMIFs with user clock at 200Mhz and it had more than 3.5 ns timing failure when the RS8 logic was added. With design changes and iterations the design still fails by 2ns.

The fit.fastforward report makes some suggestions to add register stages which I have passed on the designers and waiting response.

The report also makes suggestions to change asynchronous clears to synchronous clears. I haven't made the changes in the code but I set it in qsf

set_global_assignment -name FORCE_SYNCH_CLEAR ON

But the the fit.fastforward report mentions that the asynchronous clear are not converted to synchronous. Please review the review report and help with timing closure.

Best,

BB

[sstrell]

When trying to close timing on an EMIF, following the Fast Forward recommendations for Hyperflex is not where you should start.

Verify the options you've specified in the EMIF IP Parameter Editor and run the EMIF-specific timing reports in the Timing Analyzer.  What speed are you trying to run the EMIF at?

See the user guide here: https://www.intel.com/content/www/us/en/docs/programmable/683741/24-1-19-2-8/emif-ip-timing-closure.html

[BKB]

Hi sstrell,

Thanks for your response. I probably didn't gave a good description of the issue. EMIFs are not really an issue in this case. The design was  closing timing and working all right until we enabled/added some design and from closing timing, the timing failure shot to around 3.8 ns. This has been bought down to 2ii with design changes. This failure caused errors in the design so I started looking in to recommendations from fit.forward report.

As I mentioned earlier, I have forwarded the register addition suggestions to the designers. Regarding the change from asynchronous clear to synchronous clear, I enforced it in Quartus but it does not seem to take effect as the similar suggestions still persist in the fit.forward report. Hence uploaded the fit.forward reports and reached out for help. Please help with this large timigng. Let me know what other information I can provide.

Best,

BB

[sstrell]

It would be helpful to show a timing report from the timing analyzer to see what paths are actually failing timing.

[BKB]

The timing report file is beyond 1.6gb. With maximum compression its 51 MB. Is there a way that I upload that file. Here the maximum limit is 23 mb. I tried splitting the file with 7z but I got an error here when I tried to upload it.

Best,

BB

[sstrell]

No, you should just run Report Timing in the Timing Analyzer and you can filter on just paths with negative slack.  Why would this be 1.6 GB?

There's also the Report DDR task there.

[BKB]

Reports attached

[RichardTanSY_Altera]

Your report show a very high logic level with a 10-12 of levels of logic. This is not recommended as this will increase the delay on a timing path.

You will need to reduce the logic level to around 3 -5 by adding pipeline register. The number of logic level depends on your design requirement, you might need to reduce further to close timing. 
Take note that adding pipeline will increase the clock latency.

https://www.intel.com/content/www/us/en/docs/programmable/683664/19-3/reduce-logic-levels.html

Regards,

Richard Tan

[BKB]

Hi Richard

Thanks for reviewing the timing reports and making suggestions. We already went through inserting some pipeline stages and were able to lower the timing failure margin from  3.8 ns to around 2 ns. I was hoping someone might review the fit.fastforward suggestions and comment on why the quartus is not able to enforce the asynchronous clear to synchronous clear conversion. the fit.fforward report suggests that this might significantly improve the timing results. 

Best,

BB

[RichardTanSY_Altera]

I will need your design (Project > Archive Project) to investigate why the asynchronous clear to synchronous clear conversion is not taking place. The report alone does not provide enough information to determine the cause.

Alternatively, you can remove the asynchronous clear/reset by changing your code

example, use:

always @(posedge clk)

instead of

always @(posedge clk or negedge rst_n)

You may check AN917, 1.4.1. Reset Coding Techniques, for further details.

https://www.intel.com/content/www/us/en/docs/programmable/683539/20-4/an-917-reset-design-techniques-for-architecture.html

Regards,

Richard Tan

[RichardTanSY_Altera]

Any update on this?

Do you need further help in regards to this case?

Regards,

Richard Tan

[BKB]

Hi Richard,

Apologies for the delay in responding.

I will check with the team if we can share the design. I haven't still tried to change the reset to synchronous in the RTL. I will try doing that today or tomorrow and will update here what happens.

Best,

BB

[RichardTanSY_Altera]

Any update on this?

Regards,

Richard Tan

[BKB]

HI Richard

I haven't yet converted the asynchronous reset to synchronous.  I will get to it tomorrow.

I can share the archive of the design. Please let me know if I should upload it somewhere else or send to a any specific email address.

Best,

Bharat

[RichardTanSY_Altera]

I have email you the instructions on how to securely upload your design.

Please check your email inbox.

Regards,

Richard Tan

[BKB]

Hi Richard,

I have uploaded the design at the secure site you sent the information about. Please let me know if I can provide any further information.

Best,

Bharat

[RichardTanSY_Altera]

I have compiled your design. Could you let me know which register that the Quartus does not force it to synchronous clear? I don't see it in the technology map viewer or perhaps I have overlook.

Regards,

Richard Tan

[BKB]

Hi Richard, 

Below are some messages I see in the fit report. 

; Retiming Restrictions at Register #1: ;
; u_fpga_mem_subsystem_2|fpga_mem_subsystem_1_MC_0|mc|mc_half_0|mc_ior_row|memory_controller_row|u_rs8_decode|gen_p3_pipe.handshaking_phase3|TX_data[46] ;
; Node uses an asynchronous clear port

; Retiming Restrictions at Register #1: ;
; u_fpga_mem_subsystem_2|fpga_mem_subsystem_1_MC_1|mc|mc_half_0|mc_ior_row|memory_controller_row|u_rs8_decode|u_rs8_berl_l|handshaking_phaseA|TX_data[6]~RTM_41 ;
; Node uses an asynchronous clear port ;
; ;
; Retiming Restrictions at Register #2: ;
; u_fpga_mem_subsystem_2|fpga_mem_subsystem_1_MC_1|mc|mc_half_0|mc_ior_row|memory_controller_row|u_rs8_decode|u_rs8_berl_l|handshaking_phase1|TX_data[53]~RTM_541 ;
; Node uses an asynchronous clear port ;

Below is a message from fit.fastforward.rpt

; Retiming Restrictions at Register #16: ;
; u_fpga_mem_subsystem_2|fpga_mem_subsystem_1_MC_1|mc|mc_half_0|mc_ior_row|memory_controller_row|gen_rs8_pipe2.handshaking_pipeline_dec|TX_data[100]~RTM ;
; Node uses an asynchronous clear port

Those also form the path where I think the timing failures are. I did see many more messages earlier stating "cannot force asynchronous clear....". don't exactly remember the complete message. But with this build also I see timing failures for about 2.5 on 200MHz clock.

Best,

Bharat

[RichardTanSY_Altera]

I have checked with my team.

Unfortunately, the assignment can not change the aclr to sclr, you will need to change the code to use sclr port if possible.

Regards,

Richard Tan

[BKB]

Thanks Richard. 

Best, 

Bharat

[RichardTanSY_Altera]

By changing to the sclr port, it helps improve timing, bringing you a step closer to closing timing.

With that said, do you have any further inquiries regarding this case?

If not, I will proceed to transition this thread to community support.

Regards,

Richard Tan