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 <[email protected]> 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 <[email protected]> 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 >> ns HIGH 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, NiuChenhui <[email protected]> wrote: >> >>> 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 >>> >>> >>> >>
