ChipScope - impact on design or not?

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.

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.

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.

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.

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.

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

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

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 : snipped-for-privacy@rtc-inc.com web :

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.

Thanks for the info! (also to John)

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.

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.

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

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

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