Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish
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

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish
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

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish
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 --

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish
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

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

2016-03-10 Thread Jack Hickish
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