ChipScope - impact on design or not?

I used to believe that ChipScope did not have any impact on the design. 
I used to.

I have two FPGAs communicating on the PCB (LVDS). One of them (called 
source here) is doing some signal processing and sends the result to the 
destination FPGA. If I probe (with ChipScope) some internal results of 
the processing (FFT output) in the source, the data looks fine at the 
destination. However, if I remove the probe I get some interesting, but 
rather annoying, bit errors in the data received (and probed) at the 
destination.

Before probing at the source I thought this was an issue of signal 
integrity on the PCB, but the probing proved me wrong on that point. The 
source is a V2000 device and without the probing about 90% of BRAM and 
mults are utilized. I would think that by adding a ChipScope core PAR 
would have more troubles meeting timing constraints, and consequently 
deliver a design more prone to bit errors...

Maybe delivering the design with ChipScope still in it is my only 
choice, but it doesn't feel very good.

Anyone who have had similar experiences?


-- 
-----------------------------------------------
Johan Bernsp�ng, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

"Johan Bernsp&#4294967295;ng" <xjohbex@xfoix.se> wrote in message 
news:en11k1$f7u$1@mercur.foi.se...
>I used to believe that ChipScope did not have any impact on the design. I 
>used to.
>
> I have two FPGAs communicating on the PCB (LVDS). One of them (called 
> source here) is doing some signal processing and sends the result to the 
> destination FPGA. If I probe (with ChipScope) some internal results of the 
> processing (FFT output) in the source, the data looks fine at the 
> destination. However, if I remove the probe I get some interesting, but 
> rather annoying, bit errors in the data received (and probed) at the 
> destination.
>
Hi Johan,
Do you register all the signals in the IOBs using the dedicated IOB FFs? Rx 
and Tx? Are you using global clock buffers fed from the dedicated GCLK pins 
to clock these FFs?
If not, then any changes in the timing could bugger everything up if you've 
not constrained the timing between the parts properly. The Chipscope thing 
could be just coincidence, or maybe slowing the timing brings things back in 
to alignment.
HTH, Syms. 

Johan Bernsp=E5ng wrote:
> I used to believe that ChipScope did not have any impact on the design.
> I used to.
>
> I have two FPGAs communicating on the PCB (LVDS). One of them (called
> source here) is doing some signal processing and sends the result to the
> destination FPGA. If I probe (with ChipScope) some internal results of
> the processing (FFT output) in the source, the data looks fine at the
> destination. However, if I remove the probe I get some interesting, but
> rather annoying, bit errors in the data received (and probed) at the
> destination.
>
> Before probing at the source I thought this was an issue of signal
> integrity on the PCB, but the probing proved me wrong on that point. The
> source is a V2000 device and without the probing about 90% of BRAM and
> mults are utilized. I would think that by adding a ChipScope core PAR
> would have more troubles meeting timing constraints, and consequently
> deliver a design more prone to bit errors...
>
> Maybe delivering the design with ChipScope still in it is my only
> choice, but it doesn't feel very good.
>
> Anyone who have had similar experiences?
>
>
> --
> -----------------------------------------------
> Johan Bernsp=E5ng, xjohbex@xfoix.se
> Research engineer
>
> Swedish Defence Research Agency - FOI
> Division of Command & Control Systems
> Department of Electronic Warfare Systems
>
> www.foi.se
>
> Please remove the x's in the email address if
> replying to me personally.
> -----------------------------------------------

Yours is not an isolated experience. The company I work for had a
similar problem. The design failed, so they inserted chipscope to probe
the design. The design miraculously started working - before they even
had a chance to use the analyzer. They tried pulling chipscope out, and
it failed again. The solution was to ship it with the analyzer in
place. No one knows why it works, which is a bit freaky, but it does. I
would note that this was before my time - so I don't know the
particulars.

I would suspect marginal timing is at fault. Inserting chipscope
physically alters the P&R, and may inadvertantly improve timing,
pushing marginal timing just enough to be stable.

"radarman" <jshamlet@gmail.com> wrote:

>
>Johan Bernsp=E5ng wrote:
>> I used to believe that ChipScope did not have any impact on the design.
>> I used to.
>>
>> I have two FPGAs communicating on the PCB (LVDS). One of them (called
>> source here) is doing some signal processing and sends the result to the
>> destination FPGA. If I probe (with ChipScope) some internal results of
>> the processing (FFT output) in the source, the data looks fine at the
>> destination. However, if I remove the probe I get some interesting, but
>> rather annoying, bit errors in the data received (and probed) at the
>> destination.
>>
>> Before probing at the source I thought this was an issue of signal
>> integrity on the PCB, but the probing proved me wrong on that point. The
>> source is a V2000 device and without the probing about 90% of BRAM and
>> mults are utilized. I would think that by adding a ChipScope core PAR
>> would have more troubles meeting timing constraints, and consequently
>> deliver a design more prone to bit errors...
>>
>
>Yours is not an isolated experience. The company I work for had a
>similar problem. The design failed, so they inserted chipscope to probe
>the design. The design miraculously started working - before they even
>had a chance to use the analyzer. They tried pulling chipscope out, and
>it failed again. The solution was to ship it with the analyzer in
>place. No one knows why it works, which is a bit freaky, but it does. I
>would note that this was before my time - so I don't know the
>particulars.
>
>I would suspect marginal timing is at fault. Inserting chipscope
>physically alters the P&R, and may inadvertantly improve timing,
>pushing marginal timing just enough to be stable.

In my experience this is always due to not properly constraining the
timing for the design somewhere. Which just makes me wonder if the
tools from Xilinx can produce a list with paths which are not covered
by a timing constraint.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

"radarman" <jshamlet@gmail.com> wrote:
>
>
>Yours is not an isolated experience. The company I work for had a
>similar problem. The design failed, so they inserted chipscope to probe
>the design. The design miraculously started working - before they even
>had a chance to use the analyzer. They tried pulling chipscope out, and
>it failed again. The solution was to ship it with the analyzer in
>place. No one knows why it works, which is a bit freaky, but it does. I
>would note that this was before my time - so I don't know the
>particulars.
>
>I would suspect marginal timing is at fault. Inserting chipscope
>physically alters the P&R, and may inadvertantly improve timing,
>pushing marginal timing just enough to be stable.

Well, if I was a customer of yours, I wouldn't be best pleased at that. I 
like my products to work by decent engineering rather than be miracle 
powered. Perhaps you sell to the Vatican?

I suggest you leave and go and work for another company. Actually, as you're 
revealing dodgy stuff about what your company does, and you appear to be 
posting from work, you may not have much choice! :-(
Here's a late Crimbo pressie, try Googling "reverse dns". Then look up 
NNTP-Posting-Host.
HTH & HNY, Syms.

p.s. Please tell me that Chipscope isn't performing miracles in space 
guidance systems and helicopters. Lie to me if you have to. 

Symon wrote:

> Hi Johan,
> Do you register all the signals in the IOBs using the dedicated IOB FFs? Rx 
> and Tx? Are you using global clock buffers fed from the dedicated GCLK pins 
> to clock these FFs?
> If not, then any changes in the timing could bugger everything up if you've 
> not constrained the timing between the parts properly. The Chipscope thing 
> could be just coincidence, or maybe slowing the timing brings things back in 
> to alignment.
> HTH, Syms. 
> 
> 

Yes, all signals are registered in the IOBs. Yes, global clock buffers 
(and GCLK pins) are used. I have been thinking in terms of board 
de-skew, but it doesn't explain why it works with ChipScope and not 
without. And it seems like I'm not the only one experiencing what I 
described earlier, as radarman pointed out.

I will look through my constraints once more and also see if I can add 
some more pipelining in the design itself. I am certain that this is 
solvable without adding ChipScope. It is just a matter of designing the 
HW the right way... =) Right now it seems like I've chosen the wrong 
cost table though, PAR takes ages to complete.

/Johan

"Johan Bernsp&#4294967295;ng" <xjohbex@xfoix.se> wrote in message 
news:en2va1$9rn$1@mercur.foi.se...
> Symon wrote:
>
> Yes, all signals are registered in the IOBs. Yes, global clock buffers 
> (and GCLK pins) are used. I have been thinking in terms of board de-skew, 
> but it doesn't explain why it works with ChipScope and not without. And it 
> seems like I'm not the only one experiencing what I described earlier, as 
> radarman pointed out.
>
> I will look through my constraints once more and also see if I can add 
> some more pipelining in the design itself. I am certain that this is 
> solvable without adding ChipScope. It is just a matter of designing the HW 
> the right way... =) Right now it seems like I've chosen the wrong cost 
> table though, PAR takes ages to complete.
>
> /Johan

Hi Johan,
Are the Rx IOBs using the iob_delay feature to make sure you have negative 
hold time?
Does your UCF file have the IO timing constraints in it?
What data rates are the connections?
Is the data transfer system source synchronous?

BTW, I say adding Chipscope isn't 'solving' the problem. It's just hiding it 
until it re-appears, invariably one week before your next pay rise 
appraisal!

Cheers, Syms. 

=?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se> wrote:

>Symon wrote:
>
>> Hi Johan,
>> Do you register all the signals in the IOBs using the dedicated IOB FFs? Rx 
>> and Tx? Are you using global clock buffers fed from the dedicated GCLK pins 
>> to clock these FFs?
>> If not, then any changes in the timing could bugger everything up if you've 
>> not constrained the timing between the parts properly. The Chipscope thing 
>> could be just coincidence, or maybe slowing the timing brings things back in 
>> to alignment.
>> HTH, Syms. 
>> 
>> 
>
>Yes, all signals are registered in the IOBs. Yes, global clock buffers 
>(and GCLK pins) are used. I have been thinking in terms of board 
>de-skew, but it doesn't explain why it works with ChipScope and not 
>without. And it seems like I'm not the only one experiencing what I 
>described earlier, as radarman pointed out.

Also check internal signals. I once got stung by using a clock as an
input signal. For some reason a clock period constraint doesn't cover
such a path. It caused the same symptoms you described.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Symon wrote:
> "Johan Bernsp&#4294967295;ng" <xjohbex@xfoix.se> wrote in message 
> news:en2va1$9rn$1@mercur.foi.se...
>> Symon wrote:
>>
>> Yes, all signals are registered in the IOBs. Yes, global clock buffers 
>> (and GCLK pins) are used. I have been thinking in terms of board de-skew, 
>> but it doesn't explain why it works with ChipScope and not without. And it 
>> seems like I'm not the only one experiencing what I described earlier, as 
>> radarman pointed out.
>>
>> I will look through my constraints once more and also see if I can add 
>> some more pipelining in the design itself. I am certain that this is 
>> solvable without adding ChipScope. It is just a matter of designing the HW 
>> the right way... =) Right now it seems like I've chosen the wrong cost 
>> table though, PAR takes ages to complete.
>>
>> /Johan
> 
> Hi Johan,
> Are the Rx IOBs using the iob_delay feature to make sure you have negative 
> hold time?
> Does your UCF file have the IO timing constraints in it?
> What data rates are the connections?
> Is the data transfer system source synchronous?
> 
> BTW, I say adding Chipscope isn't 'solving' the problem. It's just hiding it 
> until it re-appears, invariably one week before your next pay rise 
> appraisal!
> 
> Cheers, Syms. 
> 
> 


Well, the RX IOBs at the destination has IOBDELAY = NONE. I got the 
impression that it was the way to go after browsing through various 
appnotes etc. The data transfer is source synchronous, so maybe 
inserting a IOBDELAY on the transfer clock would be the way to go. The 
transfer rate is 200 MHz by the way.

My UCF does have timing constraints, including the data transfer clock. 
However, talking about it, I reviewed the UCF in the destination design 
and found a typo there on the constraint on the data clock. That might 
be the error I'm looking for (so far I have concentrated mostly on the 
source FPGA).

/Johan

Nico Coesel wrote:
 
> In my experience this is always due to not properly constraining the
> timing for the design somewhere. Which just makes me wonder if the tools
> from Xilinx can produce a list with paths which are not covered by a
> timing constraint.

Yes. A few examples of how to produce timing reports with a list of
unconstrained paths follow.


From the command line:

trce -v 10 -u 1000 design.ncd -o design.twr
(the -u option is for list unconstrained paths)


From Tcl:

timing_analysis new analysis -name $reportname
timing_analysis set $reportname analysis_type timing_constraint
timing_analysis set $reportname report_datasheet true
timing_analysis set $reportname report_timegroups true
timing_analysis set $reportname analyze_unconstrained_paths 1000
timing_analysis set $reportname paths_per_constraint 10
timing_analysis set $reportname report_name $reportname
timing_analysis set $reportname report_format ascii
timing_analysis run $reportname


From the GUI:

In the process window
  implement design
    place and route
      post place and route static timing properties:
report uncovered paths      | 1000


-- 
Phil Hays