FPGA Central

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.

http://xilinx.openchip.org/ChipScope/

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

http://cgi.ebay.com/ws/eBayISAPI.dll...tem=3851381123

Antti wrote:

> Quating Mike Teseler: "use devices from vendors
> that supply full timing specs.."

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

> "ChipScope Pro is a *MUST* have thing"

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

-- Mike Treseler

"mike_treseler" <tres@fl_ke.com> wrote in message
news:[email protected] lkaboutelectronicequipment.com...
> Antti wrote:
>
> > Quating Mike Teseler: "use devices from vendors
> > that supply full timing specs.."
>
> 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
>
> > "ChipScope Pro is a *MUST* have thing"
>
> If I'm not driving nails, I don't use a hammer.
>
> -- 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

On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <[email protected]>
wrote:

>
>"mike_treseler" <tres@fl_ke.com> wrote in message
>news:[email protected] alkaboutelectronicequipment.com...
>> Antti wrote:
>>
>> > Quating Mike Teseler: "use devices from vendors
>> > that supply full timing specs.."
>>
>> 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
>>
>> > "ChipScope Pro is a *MUST* have thing"
>>
>> If I'm not driving nails, I don't use a hammer.
>>
>> -- 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.

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

Bob Perlman
Cambrian Design Works

"Bob Perlman" <[email protected]> wrote in message
news:[email protected]..
> On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <[email protected]>
> wrote:
>
> >
> >"mike_treseler" <tres@fl_ke.com> wrote in message
>
>news:[email protected] alkaboutelectronicequipmen
t.com...
> >> Antti wrote:
> >>
> >> > Quating Mike Teseler: "use devices from vendors
> >> > that supply full timing specs.."
> >>
> >> 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
> >>
> >> > "ChipScope Pro is a *MUST* have thing"
> >>
> >> If I'm not driving nails, I don't use a hammer.
> >>
> >> -- 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.
>
> I don't think there are that many. Could you provide us a list?
>
> Bob Perlman
> Cambrian Design Works

Hi Bob,

http://xilinx.openchip.org/ChipScope/

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

On Sun, 7 Nov 2004 21:42:40 +0100, "Antti Lukats" <[email protected]>
wrote:

>"Bob Perlman" <[email protected]> wrote in message
>news:[email protected]. .
>> On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <[email protected]>
>> wrote:
>>
>> >
>> >"mike_treseler" <tres@fl_ke.com> wrote in message
>>
>>news:e9aa82b10d77ca24d93eff53b2ae23d2@localhost. talkaboutelectronicequipmen
>t.com...
>> >> Antti wrote:
>> >>
>> >> > Quating Mike Teseler: "use devices from vendors
>> >> > that supply full timing specs.."
>> >>
>> >> 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
>> >>
>> >> > "ChipScope Pro is a *MUST* have thing"
>> >>
>> >> If I'm not driving nails, I don't use a hammer.
>> >>
>> >> -- 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.
>>
>> I don't think there are that many. Could you provide us a list?
>>
>> Bob Perlman
>> Cambrian Design Works
>
>Hi Bob,
>
>http://xilinx.openchip.org/ChipScope/
>
>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

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

"Bob Perlman" <[email protected]> wrote in message
news:[email protected]..
> On Sun, 7 Nov 2004 21:42:40 +0100, "Antti Lukats" <[email protected]>
> wrote:
>
> >"Bob Perlman" <[email protected]> wrote in message
> >news:[email protected]. .
> >> On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <[email protected]>
> >> wrote:
> >>
> >> >
> >> >"mike_treseler" <tres@fl_ke.com> wrote in message
> >>
>
>>news:e9aa82b10d77ca24d93eff53b2ae23d2@localhost. talkaboutelectronicequipme
n
> >t.com...
> >> >> Antti wrote:
> >> >>
> >> >> > Quating Mike Teseler: "use devices from vendors
> >> >> > that supply full timing specs.."
> >> >>
> >> >> 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
> >> >>
> >> >> > "ChipScope Pro is a *MUST* have thing"
> >> >>
> >> >> If I'm not driving nails, I don't use a hammer.
> >> >>
> >> >> -- 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.
> >>
> >> I don't think there are that many. Could you provide us a list?
> >>
> >> Bob Perlman
> >> Cambrian Design Works
> >
> >Hi Bob,
> >
> >http://xilinx.openchip.org/ChipScope/
> >
> >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
>
> 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.

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

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

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.

> Bob Perlman
> Cambrian Design Works
>
>

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.

"Symon" <[email protected]> wrote in message
news:[email protected]..
> Antti,
> Here's my list!
> 1) Simulate or die.

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.

> 2) That's it.

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

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

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.

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

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, Syms.

cheers
Antti

Comments included below!
"Antti Lukats" <[email protected]> wrote in message
news:cmoeif$ngr$03$[email protected]..
> "Symon" <[email protected]> wrote in message
> news:[email protected]..
> > Antti,
> > Here's my list!
> > 1) Simulate or die.
>
> sure Symon! - "sure" translated from my mother tong means "die!" - not
> kidding.
>
You want me dead? A little bit of an over reaction!! ;-)
>
> 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.
>
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.
>
> > 2) That's it.
>
> 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).
>
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.
>
<snip>
>
> 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!
>
Excellent! I wonder how much they'll bump the price? ;-)
Best, Syms.

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

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

"Duane Clark" <[email protected]> wrote in message
news:[email protected]..
> Symon wrote:
> > ...
> > 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.
> >
>
> 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).

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.

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

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.

> --
> My real email is akamail.com@dclark (or something like that).

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

<John> wrote in message news:[email protected]..
> Has anyone had experience using the chipscope VIO core? Does it work well?
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

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

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