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 <[email protected]> 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 <[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 >>>> >>>> >>>> >>> >
