Prev: The urge to kill
Next: high quality Puma shoes wholesale
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.
From: Nico Coesel on 3 Jul 2010 13:32
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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico(a)nctdevpuntnl (punt=.)
--------------------------------------------------------------
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: The urge to kill
Next: high quality Puma shoes wholesale