fooling the compiler
in [Design]
|
From: krw on 3 Jul 2010 13:46 On Sat, 03 Jul 2010 17:32:28 GMT, nico(a)puntnl.niks (Nico Coesel) wrote: >John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>On Fri, 25 Jun 2010 17:20:21 GMT, nico(a)puntnl.niks (Nico Coesel) >>wrote: >> >>>John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>> >>>> >>>> >>>>We have a Spartan6/45 that's talking to 16 separate SPI A/D >>>>converters. The data we get back is different, but the clock and chip >>>>select timings are the same. To get the timing right, avoiding routing >>>>delays, we need our outgoing stuff to be reclocked by i/o cell >>>>flipflops. >>>> >>>>So what happens is that we have one state machine running all 16 SPI >>>>interfaces. We tell the software that we want the adc chip select >>>>flops in i/o cells. The compiler decides that all are seeing the same >>>>input signal, so reduces them to one flipflop. Then it concludes that >>>>that flipflop can't be in an i/o block, and builds it that way. The >>>>resulting routing delays are deadly. >>>> >>>>We couldn't find a way to force these 16 flops into IOBs. Really. >>> >>>Constraints usually help. In that case it should duplicate logic (if >>>this option is on) to meet timing specifications. >> >>Turns out, according to Xilinx, that IOB=TRUE (which is a suggestion >>to the compiler) works, but IOB=FORCE (which is supposed to be >>mandatory) doesn't. We just left the shift register in there. > >Another way to force flipflops in an IOB is to specify a short delay >for the output flip-flop to pad path. The problem I see with that is that it can't be verified (what can, I suppose) until after PAR is run. By using synthesis attributes the results can be seen in the technology view (or whatever they call it today). |