From: Bo (firstname.lastname@example.org)
Date: Mon Nov 27 2000 - 08:16:40 PST
I do agree with you. What I tried to point out is not really how good/bad the
autorouters are but what can happen if you don't look at all the aspects of
board design. I made mistake for not realizing that someone didn't bother to
enter any constraints on the previous design that I was looking at in the lab.
What I forgot to do is to check the layout of this older design just because I
thought: "O it works this means layout was done properly". I was wrong. And I
learned from it. What I tried to do by writting the summary is to indicate
where I made my mistake so others don't do the same. It is these 'little'
mistakes that make people really frustrated and hopefully we can avoid them.
Thanks once again to everybody who replied to my post. You were great help.
--- "Willis, Ken" <Ken.Willis@sycamorenet.com> wrote:
> Hi Bo,
> Just my opinion, but I think autorouting gets a bad rap. I agree,
> if you let a machine randomly route your signals, who knows what
> you will get. I think a lot of people have had this experience in
> the past, and it sours them on autorouting. But just like a
> simulator, if you give it lousy input you will get garbage back.
> But if you provide detailed (and realistic) topology/constraints
> to the autorouter, it can be a great ally. I recently had a design
> I inherited that had been hand-routed (also with no topology rules,
> resulting in lousy SI results) over a period of several weeks. I
> basically started it over, set up how each of the major classes of
> signals should be routed, and our service bureau autorouted it from
> scratch in less than an hour. I simulated the whole board and it came
> out great. Soup to nuts we re-spun the board over about 2 days.
> Autorouters certainly aren't perfect, require some cleanup, and are
> NOT the answer for all classes of signals. But if you set 'em up
> right they can speed up your process a lot on certain types of designs.
> And setting up the constraints has the nice side benefit of letting you
> DRC your design forever, including after future ECOs.
> -----Original Message-----
> From: Bo [mailto:email@example.com]
> Sent: Friday, November 24, 2000 1:30 PM
> To: Michael Nudelman
> Cc: firstname.lastname@example.org
> Subject: Re: [SI-LIST] : PCI Bus problem (an interesting one) Thanks!
> Hi Everybody,
> I would like to thank Scott McMorrow, Tony Dunba r(thanks for the offer you
> have made), Michael Nudelman, George Borkowicz, Andrew Ingraham, John Medina
> and others for the replies that they have sent to my post. All the replies
> have helped me to resolve my problem. Here is how it went:
> Few of you have clearly pointed out that there should be a problem with the
> models itself. I went and checked them once again after people indicated
> could be a problem. So I looked and looked and looked. And found nothing.
> I read all the emails I received regarding this problem and still couldn't
> think what else should I do. It was getting to be very, very frustrating.
> After running X number of simulations I still could not find the
> Well believe it or not I got a break. The break came in the view of
> pointing out to me something that I didn't think of. But let me go back to
> explain what I did that caused this mistake. What I simulated was the
> topology that was to be implemented on new board. What I looked at in the
> was a board that implemented a PCI bus using same components and similar
> placement (positioning of the components of the board relative to each
> and same board stickup. Somebody reading this will probably guess my
> in advance before reading next few sentences. Well the break came when
> complained to me that reset line used in PCI bus for the card was 34 inches
> long! My comment to that was: "Wait a second, the placement of components
> make that bus no longer that 8-10 inches!" So I went to look at the layout
> the PCI bus on the lab card and I found that bus was 18-25 inches long
> than 8-10 that I thought. What I had was a "o so popular" case of auto
> doing routing when no constraint was put on the bus. I was comparing apples
> (my simulations) with oranges (lab measurements). So I went and extracted
> topology from the lab and made simulations on it. So I went in to great
> to model the lab topology. That paid off because I finally got simulations
> look similar to the measurements in the lab. So I then went back to the
> topology for the new board and made sure that all things are carefully
> And guess what? It gave good results. What is left now is to make sure that
> someone to make sure that auto router doesn't do poor job on the topology.
> In all I will summarize what I have found out while solving this problem:
> - Do NOT trust Auto router. Just because a net is not critical one it
> mean that it you can let Auto router do with it whatever it likes. This was
> mistake for believing that placements are the same for both topologies.
> - This was purely my mistake: Assuming just because a bus is slower in
> (than the ones I typically analyze) I can model it with little less detail.
> big mistake on my part. I had to go through whole lot of detail to get
> - Whenever you compare anything watch what you are comparing. The "similar"
> word should be used very carefully. Just because somebody claims that the
> something is similar to something else that may not be true.
> - It is very hard to beat statement "It works in the lab". Very hard. Some
> people are very hard on convincing that what you see on one board may not be
> the case on the next board.
> Thanks once again for all the help. It is greatly appreciated (especially
> someone is really frustrated).
> --- Michael Nudelman <email@example.com> wrote:
> > Bo,
> > I am not a Virtex specialist, but I inquired our own Virtex specialist,
> > she
> > told me, that there is the slew rate control for all FPGAs.
> > I also looked at the XILINX APPLINX CDROM, and it did not specifically
> > mentioned
> > slew rate control just for LVTTL - it mentioned it referring to all
> > I hope I'm not misleading you.
> > Mike.
> > Bo wrote:
> > > Hi Micheal,
> > >
> > > Thanks for the reply.
> > >
> > > What I am using is a PCI "compliant" devices. At least according to the
> > vendor
> > > specs say. I am using PCI I/O buffers provided with each device(and
> > is
> > > what I am using in the simulations). I asked someone to look at the
> > for
> > > the devices, and guess which one was the only one that meet PCI specs
> > fully?
> > > Intel of course since it was Intel who designed initial PCI spec.
> > > I didn't see either simulations or lab measurments to be below 1 ns for
> > > rise/fall times and I do not expect to see either to be faster than 1ns.
> > With
> > > respect to the slew rates, I can limit slew rate on Altera's Apex 20k
> > can't
> > > do the same on Xilinx Virtexe FPGA. Virtexe allows slew rate limiting
> > for
> > > LVTTL devices (here is quote from the data sheet for virtex-e devices:
> > >
> > > "...As mentioned above, a variety of symbol names provide the option of
> > > choosing the desired slew rate for the output buff-ers. In the case of
> > > LVTTL output buffers (OBUF, OBUFT, and IOBUF), slew rate control can be
> > > alternatively programed with the SLEW= property. By default, the slew
> > for
> > > each output buffer is reduced to minimize power bus transients when
> > switching
> > > non-critical signals. The SLEW= property has one of the two following
> > values.
> > > SLEW=SLOW
> > > SLEW=FAST
> > > ...."
> > >
> > > If I can slew rate limit PCI output buffers on Virtexe please tell me.
> > might
> > > be misunderstanding specs I am reading. I hope I am.
> > >
> > > Regards,
> > > Bo
> > >
> > > --- Michael Nudelman <firstname.lastname@example.org> wrote:
> > > > Bo,
> > > >
> > > > As I understand, your problem stems from using non-PCI devices on the
> > > > bus.
> > > > However, it may not be a problem, since both Xilinx and Altera do
> > > > PCI-core
> > > > designs for their devices (or at least that's what they told me 3
> > ago,
> > > > when I
> > > > was making a PCI bus) and thus should (at least in theory) guarantee,
> > that
=== message truncated ===
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
**** To unsubscribe from si-list or si-list-digest: send e-mail to
email@example.com. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
This archive was generated by hypermail 2b29 : Tue May 08 2001 - 14:30:15 PDT