Steve-Mowbray-ENLOccasional ContributorJoined 2 years ago53 Posts2 LikesLikes received3 SolutionsView All Badges
ContributionsMost RecentMost LikesSolutionsRe: How to tell Quartus my Arria10 target system CLKUSR frequency is 100MHz? Hi Aqid Thanks -- all understood -- my purpose is to identify why timing analyser reports CLKUSR at 125MHz when our design requires 100MHz -- and if there is a method to indicate to Quartus/Platform-Designer what CLKUSR frequency actually is or failing that if the incorrect CLKUSR frequency reported is in fact unimportant and can be ignored (our project does seem to mostly run as expected but there are some quirks which could be related to transceiver operation) Regards, Steve Re: How to tell Quartus my Arria10 target system CLKUSR frequency is 100MHz? Hi Farabi Rather than experimenting with cludge fixes I am focussing on the Platform Designer automatic generated: (*altera_attribute = "-name SDC_STATEMENT \"if { [get_collection_size [get_pins -compatibility_mode -nowarn ~ALTERA_CLKUSR~~ibuf|o]] > 0 } { create_clock -name ~ALTERA_CLKUSR~ -period 8 [get_pins -compatibility_mode -nowarn ~ALTERA_CLKUSR~~ibuf|o] }\"" *) associated with the transceiver reset sequencer instance in the design -- doesn't seem to be an obvious IP parameter to tell the instance that CLKUSR is at 100MHz rather than 125MHz... Regards, Steve Re: How to tell Quartus my Arria10 target system CLKUSR frequency is 100MHz? Thanks Frank -- yes that is my understanding -- my concern is by explicitly assigning the CLKUSR pin does Quartus infer that the pin is now a GPIO pin thus excluding transceiver use -- doing a project build now so will hopefully have some Quartus reporting to discuss shortly. Regards Steve UPDATE: build complete with interesting critical warning: Critical Warning (18326): The design pin 'clkusr' has been assigned to CLKUSR pin location 'Y15'. Quartus Prime auto-reserves the CLKUSR pin for calibration of transceivers and certain IOs. If the pin 'clkusr' will not be assigned a 100-125MHz clock, you must remove the location assignment on it. Otherwise, to remove the critical warning use the QSF assignment 'set_global_assignment -name AUTO_RESERVE_CLKUSR_FOR_CALIBRATION OFF'. So optimistic interpretation of the above implies that so long as clkusr pin has valid clock signal then transceivers will still calibrate correctly even when the global assignment is applied to suppress the critical warning... Digging through the Platform Designer synthesis files I found: (*altera_attribute = "-name SDC_STATEMENT \"if { [get_collection_size [get_pins -compatibility_mode -nowarn ~ALTERA_CLKUSR~~ibuf|o]] > 0 } { create_clock -name ~ALTERA_CLKUSR~ -period 8 [get_pins -compatibility_mode -nowarn ~ALTERA_CLKUSR~~ibuf|o] }\"" *) in "altera_a10_xcvr_reset_sequencer_211\synth\alt_sld_fab_altera_a10_xcvr_reset_sequencer_211_33t7nri.v" Re: How to tell Quartus my Arria10 target system CLKUSR frequency is 100MHz? Thanks Frank -- seems straightforward -- couple of questions before I fire up quartus -- is there any consequences for being explicit on this pin -- also any chance this clock is useable in the user logic as this would be useful "free" clock source? How to tell Quartus my Arria10 target system CLKUSR frequency is 100MHz? Timing analyser reports CLKUSR at 125MHz but target system has 100MHz on this pin to accommodate AS in combination with transceiver calibration as per the manuals -- there doesn't seem to be any consequences as the project seems to run fine but is a bit unsettling Re: Using PCIe HIP core clock out to drive IOPLL reference clock -- advise on set_false_path syntax Hi FvM So it seems when the base/parent clock for the 100MHz domain was the external crystal Quartus was treating it as an unrelated clock hence no timing failures and status/control bits between the clock domains have synchroniser depth of 2 -- when PCIe core clock out was substituted for the external crystal -- Quartus started treating both clocks as related even though decoupled using an IOPLL instance -- the following design constraints appear to correct the situation set_false_path -from [get_clocks {u0|pcie_hip|coreclkout}] -to [get_clocks {u0|iopll_1|*}] set_false_path -from [get_clocks {u0|iopll_1|*}] -to [get_clocks {u0|pcie_hip|coreclkout}] Thanks Steve Re: Using PCIe HIP core clock out to drive IOPLL reference clock -- advise on set_false_path syntax Hi FvM Ok so I found a data path between the two domains -- there is an Avalon-MM register with control bits that are passed to a component in the 100MHz domain -- confusingly the end point for these control bits has synchroniser depth of 2 and I am still unsure as to why timing would be good when the 100MHz domain was referenced to the external clock device and bad when referenced to an internal IOPLL driven by PCIe core clock out... Anyways I am testing the following design constraint: set_false_path -to {system_top:u0|psu_drv:u1|duty_cycle_ctrl_in} Will report back when build has completed Regards Steve Re: Using PCIe HIP core clock out to drive IOPLL reference clock -- advise on set_false_path syntax Hi FvM Yes agreed which is why I am out of my depth here -- there are no data paths between the 125MHz and 100MHz domains -- previously the 100MHz domain had its own dedicated crystal as shown below: In the external crystal configuration the project makes timing comfortably however the extra crystal has been removed from the design and using the PCIe core clock out as its substitute causes build timing to collapse... I note that PCIe core clock out appears to be spread spectrum for Arria 10 devices when measured on external pin which is great for EMC but perhaps is causing the fitter/timing-analyser difficulties? If solution is not to set a false path how do I tell Quartus to be relaxed about using core clock out as reference clock to the IOPLL instance? Regards Steve Using PCIe HIP core clock out to drive IOPLL reference clock -- advise on set_false_path syntax Hi Need advise on suitable set_false_path design constraint construction for the following scenario where PCIE HIP core clock out is used as the reference for an IOPLL instance: Impact of doing this is fitter takes much longer and result fails timing by a big margin so I am guessing a design constraint false path is required... My initial attempt at setting a false path set_false_path -from [get_clocks {u0|pcie_hip|coreclkout_hip}] -to [get_clocks {u0|iopll_1|refclk}] reports <from> and <to> arguments are empty collections I would be grateful for any guidance -- apologies for outright asking for someone to show me how to do this but I'm finding SDC file content and usage quite impenetrable... Thanks Steve SolvedRe: qcrypt:test.rbf:8068: unexpected end-of-file Sorted -- according to AN-556: "Encryption and compression cannot be used simultaneously in 20 nm FPGAs." Assignments->Settings->"Device and Pin Options..."->Configuration->"Generate compressed bitstreams" seems to be checked by default -- unchecked and the rebuilt RBF gets encrypted correctly by "Qcrypt" tool (at double the size...).