fooling the compiler
in [Design]
|
From: John Larkin on 25 Jun 2010 01:09 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. The fix is to fool the compiler into thinking the flipflop states are not the same. Turns out the the synchronous clear inputs to the flops are unused in our design. My suggestion was to ground an input pin, run that into the serial input of a 16-bit shift register, and route the sr taps to the clears of the 16 output flops. The compiler can't know that these levels are in fact always low, so has to gen 16 different flops. *Then* it allows the flops to be forced into IOBs. Rob has a better idea, just make a 16-bit SR that generates a thermometer code on powerup, namely walk a 1 into it, and have the sr output bits un-clear the i/o flops sequentially. The compiler isn't smart enough catch onto that, and we don't need to ground a pin. It works. Isn't that all perfectly stupid? The Altera folks are coming to make their pitch tomorrow. This story may amuse them. John
From: Sylvia Else on 25 Jun 2010 01:34 On 25/06/2010 3:09 PM, John Larkin wrote: > Rob has a better idea, just make a 16-bit SR that generates a > thermometer code on powerup, namely walk a 1 into it, and have the sr > output bits un-clear the i/o flops sequentially. The compiler isn't > smart enough catch onto that, and we don't need to ground a pin. The compiler isn't smart enough in its current version. You may be laying a trap for the future if you use a technique that relies on the compiler not performing an analysis that it could perform in principle, but just doesn't at the moment. I suppose it doesn't matter if you sure that neither this circuit, nor any variant of it, will ever be processed by a newer version of the compiler. Sylvia.
From: glen herrmannsfeldt on 25 Jun 2010 03:05 In comp.arch.fpga Sylvia Else <sylvia(a)not.here.invalid> wrote: > On 25/06/2010 3:09 PM, John Larkin wrote: >> Rob has a better idea, just make a 16-bit SR that generates a >> thermometer code on powerup, namely walk a 1 into it, and have the sr >> output bits un-clear the i/o flops sequentially. The compiler isn't >> smart enough catch onto that, and we don't need to ground a pin. > The compiler isn't smart enough in its current version. You may be > laying a trap for the future if you use a technique that relies on the > compiler not performing an analysis that it could perform in principle, > but just doesn't at the moment. That could only happen if the compiler figured out that you weren't looking at the output for the first 16 cycles. You can know that, but normally the compiler can't assume that. That is, with the assumption that the SR initializes to zero and clocks a 1 in. -- glen
From: Uwe Bonnes on 25 Jun 2010 04:46 In comp.arch.fpga 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. > The fix is to fool the compiler into thinking the flipflop states are > not the same. Turns out the the synchronous clear inputs to the flops > are unused in our design. My suggestion was to ground an input pin, > run that into the serial input of a 16-bit shift register, and route > the sr taps to the clears of the 16 output flops. The compiler can't > know that these levels are in fact always low, so has to gen 16 > different flops. *Then* it allows the flops to be forced into IOBs. > Rob has a better idea, just make a 16-bit SR that generates a > thermometer code on powerup, namely walk a 1 into it, and have the sr > output bits un-clear the i/o flops sequentially. The compiler isn't > smart enough catch onto that, and we don't need to ground a pin. > It works. > Isn't that all perfectly stupid? Did you try to attach a (* KEEP = "TRUE" *) attribute to the registers in question? I had a similar problem with registers meant to get places in an IOB absorbed by the feeding BRAM -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
From: John_H on 25 Jun 2010 06:31
On Jun 25, 1:09 am, John Larkin <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > > We couldn't find a way to force these 16 flops into IOBs. Really. In Synplify, this common type of situation is easily handled with the "syn_preserve" directive which is different than Synplify's "keep" used for wires in my Verilog code. It's good to get intimate with your compiler's list of attributes and directives. While it's often "pushing the rope" to get the results you expect, it's good to become more expert at pushing. - John_H |