ChipScope - impact on design or not?

To discover the unconstrained paths in a design, run trce  with the -u 
option.

Regarding the original posting, as well as the followup "design runs
with chipscope, but fails to run without", there are lots of specific
causes for this, all falling into the category of unconstrained, or 
misconstrained
path.

Debugging obscure timing problems is a lot like debugging obscure logic
problems.  The secret is to add test circuitry that helps isolate the 
problem
area.  Once isolated, problem and solution eventually will surface.

The statement that the design is marginal was a correct one.  I think
by adding chipscope, it pushed the design from margininally not working
to marginally working.  Unfortunately, temp, voltage and process variation
will ensure that some units will wind up working only intermittantly.

I would start out looking at -u option report.  That will tell if there are
really unconstrained paths in design.  Then look at any asynchronous
interfaces, clk domain crossings, etc.  These are the big culprits in
route specific marginal operation.

-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
"Colorado based Xilinx design consultant"

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:4594dfae.2834004272@news.kpnplanet.nl...
> "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 

Symon wrote:
> "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.

It isn't that uncommon for these embedded logic analyzers to alter
performance, and it isn't a poor reflection on my employer. This was
their _first_ FPGA based system, and it was a _prototype_ - not a
production system. It shipped in the sense that it was designed under
contract, but it is incapable of flying - it was built out evaluation
boards and ribbon cables.

It has only been in the last few years that they felt FPGA's could
reasonably compete with purely optical/analog solutions, and the system
in question was a testbed to validate that premise. The actual
production hardware doesn't use FPGA's at all. When that prototype
worked, and exceed the performance of the legacy systems, they decided
to start moving in that direction, and started hiring more EE's and
FPGA developers to support it - hence why I am here.

I would say that by recognizing their limitations, and hiring skilled
EE's and FPGA developers, shows that they do care about their products.
Quite frankly, I feel better knowing that - because my previous
employer didn't. I know I feel comfortable with quality of the products
that go out of here, and from what I've heard, so do our customers. I
won't go into detail, but our systems are considered top notch in the
field that they serve.

Now, when your done patting yourself on the back, why don't you
consider this. The prototype in question was developed in XPS, using
stock components for the firmware. The guys who did the firmware
weren't FPGA developers, they were software developers - and they
didn't write any of the HDL themselves. I've noticed that ISE is
constantly spitting out warnings about some of the stuff that comes out
of XPS, so, I would argue that perhaps the dodgy stuff came from
Xilinx, not the guys who did the original design.

Phil Hays <spampostmaster@comcast.net> wrote:

>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
>

Thanks for the info! (also to John)

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

Phil Hays wrote:


This part got munged in posting.  I'll try again.

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


Blank lines added to prevent unwanted wrapping. Sorry about that.


-- 
Phil Hays

Hi radarman,
First let me apologise for my terrible piss-take/smart-ass posting style, 
occasionally it gets me in trouble.
Anyway, I'm glad you took the opportunity to post and clarify exactly the 
situation when your company apparently 'shipped' something that was maybe 
not of the highest quality.
I was trying to make the point that this is a public forum and it's not hard 
(a dumbass like me can do it) for folks to find out who employs you. 
Including your competitors. If you go back and read your original post, 
would you put that on your company website?
After all's said and done, we're agreed that Chipscope can change the 
operation of a design. To stop this happening the designer must be very 
careful with their timing constraints.
Best regards, Syms. 

Symon wrote:
> Hi radarman,
> First let me apologise for my terrible piss-take/smart-ass posting style,
> occasionally it gets me in trouble.
> Anyway, I'm glad you took the opportunity to post and clarify exactly the
> situation when your company apparently 'shipped' something that was maybe
> not of the highest quality.
> I was trying to make the point that this is a public forum and it's not hard
> (a dumbass like me can do it) for folks to find out who employs you.
> Including your competitors. If you go back and read your original post,
> would you put that on your company website?
> After all's said and done, we're agreed that Chipscope can change the
> operation of a design. To stop this happening the designer must be very
> careful with their timing constraints.
> Best regards, Syms.

No problem - I was a bit pissy myself. I normally connect through a
private proxy service, but I haven't had the chance to get my network
at home completely working since the move.   Normally, when you trace
it back, my posts appear to originate from 192.168.x.x address, through
my home ISP's network. :)

The heads up is a good point, though. I will be more careful about
posting potentially harmful information in the future, regardless of my
network settings. After re-reading my original post, I could see how
that could be potentially damaging out of context.

Thanks,
-Seth

Johan Bernsp=E5ng wrote:

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

"Test what you fly, fly what you test".

John Retta wrote:
> To discover the unconstrained paths in a design, run trce  with the -u 
> option.
> 
> Regarding the original posting, as well as the followup "design runs
> with chipscope, but fails to run without", there are lots of specific
> causes for this, all falling into the category of unconstrained, or 
> misconstrained
> path.
> 
> Debugging obscure timing problems is a lot like debugging obscure logic
> problems.  The secret is to add test circuitry that helps isolate the 
> problem
> area.  Once isolated, problem and solution eventually will surface.
> 
> The statement that the design is marginal was a correct one.  I think
> by adding chipscope, it pushed the design from margininally not working
> to marginally working.  Unfortunately, temp, voltage and process variation
> will ensure that some units will wind up working only intermittantly.
> 
> I would start out looking at -u option report.  That will tell if there are
> really unconstrained paths in design.  Then look at any asynchronous
> interfaces, clk domain crossings, etc.  These are the big culprits in
> route specific marginal operation.
> 

Thanks for your comments. There are a few clk domain crossings in the 
design, though all clocks are derived from the same input clk. There are 
also some asynchronous interfaces and over the next few days I will look 
through all of these.

Thanks John and Phil for the -u option. I wasn't aware of that previously.

Happy New Year to all of you!

/Johan