Re: [casper] Timing error in dac_mkid or adc_mkid blocks
Thanks MAtt - the BUFR to BUFG change worked. It was not quite so simple as changing to your commit of mil_devel - there were far to many other changes to work with my older model file but just copying the file you mentioned over the one in my version of mlib_devel solved matters - hopefully this will work for others. On Fri, May 8, 2015 at 5:02 PM, Matt Strader mstra...@physics.ucsb.edu wrote: Ah, if it's a component switching limit, then the fix should be to swap a BUFR with a BUFG in the interface. See the change to xps_base/XPS_ROACH_base/pcores/dac_mkid_interface_v1_01_a/hdl/vhdl/dac_mkid_interface.vhd in this commit in my mlib_devel : https://github.com/mstrader/mlib_devel/commit/5308efb664d74166905d0fb141a38f14e493c453 I wasn't the one who made the change, so I don't know why this fixes anything but I know this problem comes up without it. Matt On Fri, May 8, 2015 at 1:42 PM, Jack Hickish jackhick...@gmail.com wrote: Hi Simon, Can you send me the model you're compiling, and the mlib_devel repo/branch you're using. This seems like it should really just be fixed. Thanks, Jack On Fri, 8 May 2015 at 13:36 Simon Dicker simon.dic...@gmail.com wrote: To turn off the PAR check I did the following: In the file mlib_devel/xps_base/XPS_ROACH_base/system.xmp.xs95t there is an option EnableParTimingError. On setting this to zero then I could get my system to compile. There seem to be several of these system.xmp files so depending on what your are building for the file may be different - if you try this and it works let us know. As to the cause of the timing error (it is far better to get rid of them) then I traced it down to the DAC_mkid block - A stripped down model with only a DRAM_LUT, a dac_mkid block and a adc_mkid block. gave the error but when I stripped out the dac_mkid block then the error went away. I tried playing with delays inside the block but this only made things worse. If it helps then it seems to be a component switching limit - using the timing analysis program and looking at the system.twr file of a failed build the errors occurred in the following networks (any suggestions on fixing this one would be interesting): Timing constraint: PERIOD analysis for net adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/dcm_clk derived from NET adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/drdy_clk PERIOD = 3.9062 ns HIGH 50%; duty cycle corrected to 3.906 nS HIGH 1.953 nS For more information, see Period Analysis in the Timing Closure User Guide (UG612). 2253 paths analyzed, 1505 endpoints analyzed, 0 failing endpoints 1 timing error detected. (0 setup errors, 0 hold errors, 1 component switching limit error) Minimum period is 3.999ns. Component Switching Limit Checks: PERIOD analysis for net adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/dcm_clk derived from NET adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/drdy_clk PERIOD = 3.9062 nsHIGH 50%; duty cycle corrected to 3.906 nS HIGH 1.953 nS Slack: -0.093ns (period - min period limit) Period: 3.906ns Min period limit: 3.999ns (250.063MHz) (Tbrper_I) Physical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Logical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Location pin: BUFR_X0Y11.I Clock network: adc1_clk Timing constraint: TS_adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk = PERIOD TIMEGRP adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk TS_adcmkid1_DRDY_I_p HIGH 50%; For more information, see Period Analysis in the Timing Closure User Guide (UG612). 0 paths analyzed, 0 endpoints analyzed, 0 failing endpoints 1 timing error detected. (1 component switching limit error) Minimum period is 3.999ns. Component Switching Limit Checks: TS_adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk = PERIOD TIMEGRP adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk TS_adcmkid1_DRDY_I_p HIGH 50%; Slack: -0.093ns (period - min period limit) Period: 3.906ns Min period limit: 3.999ns (250.063MHz) (Tbrper_I) Physical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Logical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Location pin: BUFR_X0Y11.I Clock network: adc1_clk
Re: [casper] Timing error in dac_mkid or adc_mkid blocks
To turn off the PAR check I did the following: In the file mlib_devel/xps_base/XPS_ROACH_base/system.xmp.xs95t there is an option EnableParTimingError. On setting this to zero then I could get my system to compile. There seem to be several of these system.xmp files so depending on what your are building for the file may be different - if you try this and it works let us know. As to the cause of the timing error (it is far better to get rid of them) then I traced it down to the DAC_mkid block - A stripped down model with only a DRAM_LUT, a dac_mkid block and a adc_mkid block. gave the error but when I stripped out the dac_mkid block then the error went away. I tried playing with delays inside the block but this only made things worse. If it helps then it seems to be a component switching limit - using the timing analysis program and looking at the system.twr file of a failed build the errors occurred in the following networks (any suggestions on fixing this one would be interesting): Timing constraint: PERIOD analysis for net adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/dcm_clk derived from NET adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/drdy_clk PERIOD = 3.9062 ns HIGH 50%; duty cycle corrected to 3.906 nS HIGH 1.953 nS For more information, see Period Analysis in the Timing Closure User Guide (UG612). 2253 paths analyzed, 1505 endpoints analyzed, 0 failing endpoints 1 timing error detected. (0 setup errors, 0 hold errors, 1 component switching limit error) Minimum period is 3.999ns. Component Switching Limit Checks: PERIOD analysis for net adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/dcm_clk derived from NET adcdac_tst1_adc_mkid/adcdac_tst1_adc_mkid/drdy_clk PERIOD = 3.9062 nsHIGH 50%; duty cycle corrected to 3.906 nS HIGH 1.953 nS Slack: -0.093ns (period - min period limit) Period: 3.906ns Min period limit: 3.999ns (250.063MHz) (Tbrper_I) Physical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Logical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Location pin: BUFR_X0Y11.I Clock network: adc1_clk Timing constraint: TS_adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk = PERIOD TIMEGRP adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk TS_adcmkid1_DRDY_I_p HIGH 50%; For more information, see Period Analysis in the Timing Closure User Guide (UG612). 0 paths analyzed, 0 endpoints analyzed, 0 failing endpoints 1 timing error detected. (1 component switching limit error) Minimum period is 3.999ns. Component Switching Limit Checks: TS_adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk = PERIOD TIMEGRP adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk TS_adcmkid1_DRDY_I_p HIGH 50%; Slack: -0.093ns (period - min period limit) Period: 3.906ns Min period limit: 3.999ns (250.063MHz) (Tbrper_I) Physical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Logical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Location pin: BUFR_X0Y11.I Clock network: adc1_clk Timing constraint: TS_adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk_0 = PERIOD TIMEGRP adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk_0 TS_adcmkid1_DRDY_I_n HIGH 50%; For more information, see Period Analysis in the Timing Closure User Guide (UG612). 0 paths analyzed, 0 endpoints analyzed, 0 failing endpoints 1 timing error detected. (1 component switching limit error) Minimum period is 3.999ns. Component Switching Limit Checks: TS_adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk_0 = PERIOD TIMEGRP adcdac_tst1_adc_mkid_adcdac_tst1_adc_mkid_dcm_clk_0 TS_adcmkid1_DRDY_I_n HIGH 50%; Slack: -0.093ns (period - min period limit) Period: 3.906ns Min period limit: 3.999ns (250.063MHz) (Tbrper_I) Physical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Logical resource: adcdac_tst1_dac_mkid/adcdac_tst1_dac_mkid/BUFR_inst/I Location pin: BUFR_X0Y11.I Clock network: adc1_clk On Tue, May 5, 2015 at 9:51 PM,
Re: [casper] Timing error in dac_mkid or adc_mkid blocks
Hi,simon, I'm meeting the same issue.I failed to compile the mdl which used to be compiled successfully. In my opinion,The timing error may be a compile EDK problem.So I want to Disable the timing error first. I have tried some compilations,I put the XPS% xset enable_par_timing_error 0 when the matlab promoting. Well it's a probability event,one of them show successfully complied but the left ones still met the timing error.I don't know what exact steps should be done if I want to Disable the timing error. The former discussion also give some information about this issue in casper-mail-list. Though they did not suggest Disabling the Treat timing closure failure as error , It didn't mention how to analysis and settled out this issue.(https://www.mail-archive.com/casper%40lists.berkeley.edu/msg03906.html).So for two things: 1)How to disable the timing error tips if I make sure I want to? 2)How to analysis this problem? Thanks for any help! peter
Re: [casper] Timing error in dac_mkid or adc_mkid blocks
Simon, I think you'll find that the timing error has been ignored in the past. John I have a timing error when I try and compile firmware containing the dac_mkid and adc_mkid yellow blocks and a LUT. I stripped out most of the code in the original bof file to just leave those blocks and still got the same errors). When compiling on a 64 bit linux system for a roach 1/sx95t I get the following error message: PAR could not meet all timing constraints. A bitstream will not be generated. To disable the PAR timing check: 1 Disable the Treat timing closure failure as error option from the Project Options dialog in XPS. Further back in the mat lab output is: -- Constraint|Check| Worst Case | Best Case | Timing | Timing | |Slack | Achievable | Errors |Score -- * PERIOD analysis for net mba15_srd1_adc_m | SETUP | 1.526ns| 2.380ns| 0| 0 kid/mba15_srd1_adc_mkid/dcm_clk derived | HOLD| -0.104ns|| 10160| 239632 from NET mba15_srd1_adc_mkid/mba15_srd1 | MINPERIOD | -0.093ns| 3.999ns| 1| 93 _adc_mkid/drdy_clk PERIOD = 3.9062 ns HI | | ||| GH 50% duty cycle corrected to 3.906 nS | | ||| HIGH 1.953 nS| | ||| -- * TS_mba15_srd1_adc_mkid_mba15_srd1_adc_mki | MINPERIOD | -0.093ns| 3.999ns| 1| 93 d_dcm_clk_0 = PERIOD TIMEGRP mba15_srd1_ | | ||| adc_mkid_mba15_srd1_adc_mkid_dcm_clk_0 T | | ||| S_adcmkid1_DRDY_I_n HIGH 50% | | ||| -- * TS_mba15_srd1_adc_mkid_mba15_srd1_adc_mki | MINPERIOD | -0.093ns| 3.999ns| 1| 93 d_dcm_clk = PERIOD TIMEGRP mba15_srd1_ad | | ||| c_mkid_mba15_srd1_adc_mkid_dcm_clk TS_ad | | ||| cmkid1_DRDY_I_p HIGH 50% | | ||| -- As far as I know this firmware has been compiled before - on the other hand it is possible that the timing error has just been ignored however that does not seem the safest of options. Has anyone else seen this problem? I've looked at adding delays in all sorts of places but so far no luck.
