Severe timing penalty from clken signal in PFB

[talonmyburgh]

From what I can see, in the PFB module compiles, the ce trace also runs some distance through the design. I am unable to clock the design in casper_wbpfb/wbpfb_vivproj at 200MHz as the trace from the ce runs all the way to gen_wideband_fft.gen_fft_r2_wide_streams[0].u_fft_r2_wide/gen_fft_r2_wide.gen_separate.u_separator/gen_separators[1].u_separate/adder_1/u_output_pipe/gen_pipe_n.out_dat_p_reg[1][0]/CE uninterrupted.

@mschiller-nrao is it usual to have to pipeline the ce signal?

[talonmyburgh]

This issue is only apparent when compiling the PFB... perhaps because with the addition of the PFB_FIR (unlike my prior timing tests which were just of the FFT), the ce must travel further...

[mschiller-nrao]

My first question... Do we actually need a clock enable? I HATE clock enables, partially because of this reason. data valid, which appear to be in the SOSI input are often a better approach to gating input data, because they naturally end up pipelined through the design.

There is use for clock enable, eg when you want to do low power design. But I'm not sure that should be our focus if we can't fet a reasonable

I'm just starting on the effort to review what CE is doing and if there is another approach to fix it, perhaps more feedback later today.

[talonmyburgh]

Well if we decide we want to do without it, then we can remove it. I'm hoping it'll be substantially less work than remove rst.

[mschiller-nrao]

I mean the testbenches just drive it to ‘1’….. But I don’t know if the legacy casper block has such a signal From: Talon ***@***.***> Sent: Thursday, November 9, 2023 9:04 AM To: talonmyburgh/casper_dspdevel ***@***.***> Cc: Matthew Schiller ***@***.***>; Assign ***@***.***> Subject: Re: [talonmyburgh/casper_dspdevel] Severe timing penalty from clken signal in PFB (Issue #44) {External} Well if we decide we want to do without it, then we can remove it. I'm hoping it'll be substantially less work than remove rst. — Reply to this email directly, view it on GitHub<#44 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A6RX4EDO5B6W2TX4J5HIPTLYDTPEDAVCNFSM6AAAAAA7ERR4UWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBTHA4TEMRSGE>. You are receiving this because you were assigned.Message ID: ***@***.******@***.***>> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#44 (comment)", "url": "#44 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[talonmyburgh]

@amartens says there is no ce in the legacy casper block. This is an ASTRON thing.

[mschiller-nrao]

Then I'd recommend you drive it to '1' in the top level wrapper your using in Xilinx or just remove it from the block in it's entirety.

[mschiller-nrao]

Which actually brings up an interesting question on wb_fft as well... Does the casper block have CE on the wb_fft? if not we should consider removing it there as well..

CE is dangerous for timing. (though it can be good for power consumption in some applications)

[talonmyburgh]

No ce enables anywhere in legacy CASPER. Can probably just remove it. I can't get to it for a couple weeks as I'm travelling but worth discussing in the meeting.