ContributionsMost RecentMost LikesSolutionsRe: 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...). qcrypt:test.rbf:8068: unexpected end-of-file Hi When running Qcrypt on my working RBF configuration file I get the following result: C:\Users\steve>D:/intelFPGA/21.1/quartus/bin64/qcrypt --encrypt --keyfile=keyfile.key --keyname=key1 --keystore=otp test.rbf test_qcrypt.rbf Intel qcrypt 1.5 built at 12:02:50 on Aug 15 2017 Copyright (C) 2015-2017 Intel Corporation. All Rights Reserved. qcrypt:test.rbf:8068: unexpected end-of-file Any clues as to what could be wrong would be appreciated - I am confused as the unencrypted RBF file works fine with passive serial configuration.. Thanks Steve SolvedRe: Passive serial versus active serial configuration -- swap using Convert Programming Files utility Hi Farabi Quick update with some results for posterity: JIC files always same size regardless of generated from active or passive serial SOF files... passive serial RBF files generated from active serial SOF files are approximately twice as big as passive serial RBF files generated directly by Quartus -- not sure why this would be but means is more attractive to make the default build passive serial I have programmed a platform with a JIC converted from passive serial SOF and it has programmed and runs correctly with MSEL pins set to active serial configuration mode... Regards Steve Re: Passive serial versus active serial configuration -- swap using Convert Programming Files utility Thanks Farabi That is good news and will save some effort managing configuration method between old and new target systems Regards Steve Passive serial versus active serial configuration -- swap using Convert Programming Files utility Hi Probably a dumb question but can the configuration method be managed using the Quartus "Convert Programming Files" utility for instance: Quartus project Device and Pins Configuration Scheme = ASx1 :: can generated SOF image be converted to properly functional passive serial RBF image using Convert Programming Files? Quartus project Device and Pins Configuration Scheme = PS :: can generated SOF image be converted to properly functional active serial JIC image using Convert Programming Files? This would save constantly changing Quartus project device and pin assignments (and rebuilding) according to the configuration method selected... Thanks Steve SolvedRe: FPGA passive serial configuration -- detect as PCIe device in Linux after configuration Thank you corestar will try this out Regards Steve