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 thi
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/53
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 wrote:
> To turn off the PAR check I did the following:
>
> In the file mlib_devel/xps_base/X
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
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 th
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 st
6 matches
Mail list logo
