Why Xilinx ChipScope (or similar FPGA OCI tool) is a *MUST* Have tool

Hello,

I possible should shut up already, but sometimes I just cant :) - ChipScope Pro is a *MUST* have thing ! ! !

I did take some time and prepared special webpage with ChipScope Pro screenshot explaing one situation where it would not been possible to achive the goal (100% working Serial ATA OOB detector with RocketIO) without the use of ChipScope Pro.

formatting link

Xilinx, anyone who can explain why rocketIO sees a "pseudo-random pattern" (as in the screenshot on the webpage above) I would like to hear it, but so long I see no other options as to look itself (with ChipScope).

There can be many different situations where "things happen" inside FPGA, things that you just need to visualize.

Quating Mike Teseler: "use devices from vendors that supply full timing specs.." - that is not always possible. Not only timing specs can be wrong, also the actual behaviour can be completly unexpected. Also when using first silicon dies of an packaged ASIC macrocell from the vendor who has not tested that silicon run itself, then there can be no proper timing specs at all.

Antti

formatting link

Reply to
Antti Lukats
Loading thread data ...

What I said was:

"Using devices from vendors who supply full timing specs and simulation models makes it (the use of simulation) possible."

I agree that ChipScope is a cool tool for characterizing unspecified interfaces, and I don't doubt that you need it for your work.

But I don't agree that

If I'm not driving nails, I don't use a hammer.

-- Mike Treseler

Reply to
mike_treseler

LOL, ok I give up, you win! ;)

oh smile - actually I admit that I still have a way to go learning proper simulations, and I also possible use ChipScope also in some cases where pure simulations could do. However there are pretty many scenarios where simulations do not deliver the results.

Antti

Reply to
Antti Lukats

I don't think there are that many. Could you provide us a list?

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

t.com...

pure

Hi Bob,

formatting link

just for you I created that list! There are only things that did pop-up easily. I guess there could a few others who could thing of some more cases where using ChipScope (or other OCI) is really required. And that would make the list long enough already I would say. :)

Antti

Reply to
Antti Lukats

I looked through your list, and most of the cases you cite are ways in which ChipScope can be used to augment simulation, not replace it. I have no problem with that. But if you're doing little or no simulation, and are using ChipScope in a Burn-And-Learn environment, well, you're probably not making the best use of your time.

I used ChipScope on a recent project, and it was, as you suggest, very handy. But I also wrote a suite of 175 simulation tests that, run together, take 5 days to complete. If I'd relied on ChipScope to do all of my initial testing and subsequent regression testing (and I can't overstress the importance of being able to make sure that a change or addition doesn't torpedo something else), we'd still be trying to get things working in the lab.

I think Mike Treseler is correct: use the tool that matches the job.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

n

proper

where

cases

make

Sure I did not want to say ChipScope shoud be considered primary before simulation or replace simulations. Only that in some pure simulations are not enough if not assisted in the use of on chip instrumentation in the FPGA verification phase. I kind of did assume that the designs that will will be used with ChipScope are either passed some formal verication or testbenching (succesfully!).

Antti

Sure, - after succesfull simulations try FPGA implementation if it works you are done, no problems. If still problems, try fix simulations and check again, if that doesnt help after 10 rounds of fixed problems then it is time for on chip probing.

Reply to
Antti Lukats

Antti, Here's my list!

1) Simulate or die. 2) That's it.

Seriously, ChipScope is a great tool for checking whether your hardware is working, perhaps for PCB faults, or level/SI problems. It can also be good for catching problems with live data if your simulation takes a long time, although a good simulation strategy breaks down a big design into smaller blocks which are much more manageable in terms of simulation time. Bob's point about regression testing can't be overstated. It can also be used to capture real data to feed into your simulation to make test benches easier to generate.

Finally, I could make ChipScope twice as useful overnight. Add a bloody clock enable to it.

Cheers, Syms.

Reply to
Symon

sure Symon! - "sure" translated from my mother tong means "die!" ;) - not kidding.

did you look ever at the signal is coming from RocketIO when there is no valid signal applied to the RXN/RXP? It is something NEVER documented in anywhere. It can be analyzed and the result of that can be used to determine if there is some burst or longer period of silence. Without capturing the real data its not possible to implement the logic. Not possible to simulate before you have at least once captured the real signal. There are other simular scenarios where pure simulations (without ever doing FPGA verification at all) will not work. Thats what I reffered too.

Sure, its the basic rule of digital designs - when you do it right (i.e. when you connect the wires) then it will always just work. From that if it works in simulations, it must work in FPGA? I bet most of us know that it isnt so. Something that works in simulation doesnt necessarily work without any change done in FPGA, by whatever reasons. Its a little bit better with ASIC, FPGA's and FPGA tools have too many things unknown or weird (to make the first FPGA tests always succesful after succesful simulation).

Did I say something very different? If the simulations work, but the hardware isnt then it may be good idea to look whats happening. Optionally capture real signal and improve the testbench, sure.

A version of ChipScope that has that improvement and not only that exists already. Well I dont know the release date but its coming. Really!

cheers Antti

Reply to
Antti Lukats

You want me dead? A little bit of an over reaction!! ;-)

determine

simulate

OK, but this is a hardware issue. And doing things like this is probably OK on the bench, but if Xilinx ever change the die (sure?!), or you buy from a different batch and the behaviour changes, what are you gonna do? They're not gonna support undocumented features.

without

Well, I'm finding it hard to recall an occasion when my simulator and real design differed. Maybe in the bad old days. So, I'll disagree on this point.

Excellent! I wonder how much they'll bump the price? ;-) Best, Syms.

Reply to
Symon

They don't disagree for me, but I certainly do see cases where a design with a fairly complex interaction with real world interfaces results in signal combinations that trigger unexpected behaviors. An example that comes to mind is a PCI interface on one side and a fairly complex backend on the other (not my design, but I ended up debugging it).

When this happens, simulating the exact signal combination generally reproduces the error in the testbench. And figuring out exactly what is going on and how to fix it is much easier within the testbench. But I find this much easier to do if I can find some signal within the FPGA that is not behaving as expected, narrowing down to a general area where the problem is. In the past, I used Xilinx "probes" for looking at these internal signals, but one of these days I'll give ChipScope a try; I had not tried it before because, well, there was no Linux version.

--
My real email is akamail.com@dclark (or something like that).
Reply to
Duane Clark

real

point.

Yes, PCI is a good example. Or better lets say a complex PCI design is a candidate of an design that may benefit from FPGA probing.

And also in generic, if you are doing FPGA verification of an design written by entity A, that is verified by an testbench written by entity B (or A even worse!) and if the design uses modifications or add ona (like PCI backend) written by entity C (or you) and if the final FPGA system has to pass all interoperability and compliance testing, then this is a potential case where FPGA probing may come handy. Even if initial simulations did not show any problems.

Yes exactly, its generically, if s*** happens (and it does happen!) then probing can narrow down the issue and greatly helps to enhance the testbench (to catch the problem and verify that the core does not behave badly under the conditions that caused the trouble seen using FPGA capture).

More for PCI debugging - Gaisler Research free open source GPL licensed GRLIB SoC design environment includes a PCI target/initiatior and also a PCI Trace Buffer! So it provides the PCI core and meand to debug it, and the monitor application is available for Linux too :)

Similarly ChipScope has special bus monitor cores for the Xilinx SoC onchip busses (PLB/OPB) to help troubleshooting bus access specially in case of debugging custom EDK IP-Cores.

Reply to
Antti Lukats

Has anyone had experience using the chipscope VIO core? Does it work well? Is it viable to replace unfinished blocks with chipscope VIO core?

Thanks,

p.s. on a side note, when using synchronous vio inputs i get the signals coming in to be interpreted as clocks from xilinx ise, is this normal???

Reply to
John

Is it viable to replace unfinished blocks with chipscope VIO core?

hm, the async in and out works well at least! and as I am able to write my own VIO style cores that can be plugged into ICON thats sufficent for me:)

coming in to be interpreted as clocks from xilinx ise, is this normal???

I guess it is, hm that means if many clocks used you might need some manual glock buffer assignment to make sure all signal that need global clock buffers defenetly get them

Antti

Reply to
Antti Lukats

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.