Prev: Allocation
Next: Binary integer to ASCII string in HDL?
From: langwadt on 25 Jun 2010 13:27
On 25 Jun., 07:09, John Larkin
<jjlar...(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.
>

you don't happen to use the output of that flop somewhere in the
design?

you can't directly instantiate an output FF, but you can instantiate
a
DDR output FF, OFDDRCPE, with C1 tied low it might work.

-Lasse
From: Jeroen Belleman on 25 Jun 2010 17:59
On 06/25/2010 05:55 PM, John Larkin wrote:
>
> I'm still programming embedded stuff in 68K assembly. Dyno mode. The
> thing is, I finish a typical instrument's firmware in a week or two
> and have zero problems with the assembly and debug tools. And rarely
> find a bug in shipped products.[...]

That just confirms what I always say: A software tool is never
so reliable as after it has gone obsolete.

Jeroen Belleman
From: John Larkin on 25 Jun 2010 18:49
On Fri, 25 Jun 2010 23:59:10 +0200, Jeroen Belleman
<jeroen(a)nospam.please> wrote:

>On 06/25/2010 05:55 PM, John Larkin wrote:
>>
>> I'm still programming embedded stuff in 68K assembly. Dyno mode. The
>> thing is, I finish a typical instrument's firmware in a week or two
>> and have zero problems with the assembly and debug tools. And rarely
>> find a bug in shipped products.[...]
>
>That just confirms what I always say: A software tool is never
>so reliable as after it has gone obsolete.
>
>Jeroen Belleman

That's a simple consequence of software tools getting less reliable
every generation.

John

From: John Larkin on 3 Jul 2010 11:13
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.

John


From: krw on 3 Jul 2010 11:28
On Sat, 03 Jul 2010 08:13:53 -0700, 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.

I'm surprised that works. It didn't a couple of years ago, when I last used
Xilinx stuff. The other thing to watch is tristate forcing. I found they had
to be in the top level of the hierarchy to work right. Maybe that was just a
problem with Virtex4 and the PPC stuff, though.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Allocation
Next: Binary integer to ASCII string in HDL?