You could always just try just throwing delays in there just to check it
fixes the compile, then at least you know that's the issue. Worrying about
making a filter implementation that is both valid and meets timing can then
come later.
Good Luck!
Jack
On Fri, 11 Mar 2016 at 01:52 Nilan
Hi Nilan,
Yeah, I figured that would be a problem... :)
Does something like this (which i confess I haven't read, but Fig 14 looks
potentially relevent) help? --
http://www.xilinx.com/support/documentation/white_papers/wp330.pdf
Jack
On Fri, 11 Mar 2016 at 01:21 Nilan Udayanga
I think if you can add latency in those multipliers / adders you'll
probably find your problem will go away. It's the blow path that's
breaking, so I don;t think you can get around ijnserting some registers to
split up thje logic stages --
Also, I don't think the problem is the software register, I think the
problem is present in both your designs, but in the "working" model the
compiler is optimizing away all the failing logic paths, which presumably
aren't actually doing anything given the way the blocks in the model are
connected
Hi Nilan,
It looks like there's a block called (something like) ppcm12/block_t_z2
with a huge logic delay -- from line 135 of the failing twr file --
Data Path Delay: 20.585ns (Levels of Logic = 12)(Component delays
alone exceeds constraint)
What is this block? It looks like it has some
5 matches
Mail list logo