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?ViewItem&item=3851381123
Why Xilinx ChipScope (or similar FPGA OCI tool) is a *MUST* Have tool
Started by ●November 7, 2004
Reply by ●November 7, 20042004-11-07
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
Reply by ●November 7, 20042004-11-07
"mike_treseler" <tres@fl_ke.com> wrote in message news:e9aa82b10d77ca24d93eff53b2ae23d2@localhost.talkaboutelectronicequipment.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
Reply by ●November 7, 20042004-11-07
On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <antti@case2000.com> wrote:> >"mike_treseler" <tres@fl_ke.com> wrote in message >news:e9aa82b10d77ca24d93eff53b2ae23d2@localhost.talkaboutelectronicequipment.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
Reply by ●November 7, 20042004-11-07
"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message news:j4uso0l2k7n98if17s0bp03g7g57sijhdh@4ax.com...> On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <antti@case2000.com> > wrote: > > > > >"mike_treseler" <tres@fl_ke.com> wrote in message > >news:e9aa82b10d77ca24d93eff53b2ae23d2@localhost.talkaboutelectronicequipment.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 wherepure> >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 WorksHi 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
Reply by ●November 8, 20042004-11-08
On Sun, 7 Nov 2004 21:42:40 +0100, "Antti Lukats" <antti@case2000.com> wrote:>"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message >news:j4uso0l2k7n98if17s0bp03g7g57sijhdh@4ax.com... >> On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <antti@case2000.com> >> 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. :) > >AnttiI 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 by ●November 8, 20042004-11-08
"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message news:6evto0dq9l3f5c29eid4c8khbp3djbdgab@4ax.com...> On Sun, 7 Nov 2004 21:42:40 +0100, "Antti Lukats" <antti@case2000.com> > wrote: > > >"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message > >news:j4uso0l2k7n98if17s0bp03g7g57sijhdh@4ax.com... > >> On Sun, 7 Nov 2004 20:17:54 +0100, "Antti Lukats" <antti@case2000.com> > >> 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 learningproper> >> >simulations, and I also possible use ChipScope also in some caseswhere> >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 morecases> >where using ChipScope (or other OCI) is really required. And that wouldmake> >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 > >
Reply by ●November 8, 20042004-11-08
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 by ●November 8, 20042004-11-08
"Symon" <symon_brewer@hotmail.com> wrote in message news:2v9q51F2j8q2hU1@uni-berlin.de...> 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
Reply by ●November 8, 20042004-11-08
Comments included below! "Antti Lukats" <antti@case2000.com> wrote in message news:cmoeif$ngr$03$1@news.t-online.com...> "Symon" <symon_brewer@hotmail.com> wrote in message > news:2v9q51F2j8q2hU1@uni-berlin.de... > > 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 todetermine> if there is some burst or longer period of silence. Without capturing the > real data its not possible to implement the logic. Not possible tosimulate> 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 workwithout> 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.
