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

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.

In comp.arch.fpga Sylvia Else
<s...@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 

In comp.arch.fpga John Larkin 
<j...@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                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

On Jun 25, 1:09=A0am, John Larkin
<jjlar...@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

I would be amazed if you cant get XST to keep all
16 flipflops. I know youcan do it in Synplify.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Am 25.06.2010 12:31, schrieb John_H:
> On Jun 25, 1:09 am, John Larkin
> <jjlar...@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.

Hmm, but is there a portable way to do these things? Something like C's
"volatile"?

Philipp

On Fri, 25 Jun 2010 15:34:20 +1000, Sylvia Else
<s...@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.
>
>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.

This design builds under v11 of the Xilinx software, but won't build
under v12, the "Spartan 6 optimized" version. So there's apparently no
worry that we'll ever compile it under more advanced compilers; they
seem to be getting worse, not better.

John

On Fri, 25 Jun 2010 08:46:30 +0000 (UTC), Uwe
Bonnes
<b...@elektron.ikp.physik.tu-darmstadt.de> wrote:

>In comp.arch.fpga John Larkin 
><j...@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

My Xilinx guy, a real pro at this sort of thing, tried everything,
"keeps" and "forces" and such. He thought my suggestion was
disgusting, which it certainly is, but it broke the logjam and let us
get on with our lives.

The real figure of merit of any fpga is a mimimal value of 

K = A/R

where A is the actual time you spend downloading, installing,
patching, and fighting with the tools, and R is a reasonable
design/sim/test time for the project. Xilinx's K value increases
steadily over time, and is now roughly 4.

John

On Jun 25, 8:26=A0am, Philipp Klaus Krause
<p...@spth.de> wrote:
> Am 25.06.2010 12:31, schrieb John_H:
>
> > On Jun 25, 1:09 am, John Larkin
> > <jjlar...@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.
>
> Hmm, but is there a portable way to do these things? Something like C's
> "volatile"?
>
> Philipp

I haven't done this recently, but in the previous versions of XST I
found you had to shut off "equivalent register removal" AND "resource
sharing" in the Synthesis properties, and also "equivalent register
removal" in the Map properties to fix the issue.  I have also used
the shift register start-up approach to make the registers non-
equivalent, but I didn't need to do that with all the switches
set properly.

HTH,
Gabor