Frustration with Vendors!
in [FPGA]
|
From: rickman on 1 Mar 2010 00:50 On Feb 28, 5:46 pm, Michael S <already5cho...(a)yahoo.com> wrote: > On Feb 28, 7:59 pm, rickman <gnu...(a)gmail.com> wrote: > > > > > On Feb 28, 11:09 am, Michael S <already5cho...(a)yahoo.com> wrote: > > > > Assuming you are talking about MAX-II: > > > > According to MAX-II device handbook (p.2.29) for any given I/O > > > standard there are only two levels of of programmable > > > drive strength control. So, 8mA and 12mA being the same is not > > > surprising. > > > W.r.t. slew rate control the handbook doesn't say how exactly it is > > > implemented but gives you a hint on p.2.30 - "The lower the voltage > > > standard (for example, 1.8-V LVTTL) the larger the output delay when > > > slow slew is enabled." Being EE from that phrase you could probably > > > figure out the topology of their slew control. Since I am not EE, nor > > > a specialist in CMOS circuit design I wouldn't say what my guess is. > > > > My personal advice, not from EE but from experienced Altera designer > > > nevertheless - unless you line has low-impedance parallel termination > > > resistor use minimal drive strength and fast slew rate. > > > I'm not sure why you are quoting the Altera device handbook. I guess > > that is the standard assumption if not using Xilinx. > > Exactly. > Sorry for misunderstanding on my part. After reading the whole thread > and realized that you are using Latice device. > So just ignore everything I wrote above. > > > The part I am > > using has 4, 8, 12, 16 and 20 mA drive strength and FAST vs. SLOW > > speeds. It does not appear that they are just linear extrapolations > > and in particular, in the IBIS "simulation" I see some very odd > > behavior which I am pretty sure has nothing to do with transmission > > line effects. BTW, the IBIS simulation I can access is not really a > > simulation at all, but just a curve that was provided for one set of > > conditions (and rather odd ones at that). > > > Are you sure the advice you got wasn't for low current drive and > > *slow* slew rate? A slow slew rate works well with longer lines than > > does a fast slew rate. > > > Rick > > My advice was for Altera. > In Altera case, applying slow slew rate to signal used as a clock is > not such a bright idea. Reducing drive strength is safer and, for a > given overshoot, would normally get you faster voltage change rate in > the threshold region (=good). > I don't know whether the same is true for your Lattice device. Yes, it can be important to get through the transition range quickly. This is exactly the issue we found. With a 40 ns rise time, the clock was multiple clocking and could even have been clocking on the falling edge as someone suggested. It didn't do that with my module plugged into the older board which used an older FPGA. With the newer part the assumption is that the newer, faster part is able to trigger on the clock noise. We haven't looked at this on the old chassis yet. It may be that there is less noise on the old chassis as well. I don't see how adjusting the drive strength would be better than adjusting the slew rate. It is the edge rate that causes the problems with the transmission line, no matter how it is generated. The drive strength will slow the edge if it can't supply the current during the transition the same as slowing the slew rate, no? Rick
From: Kim Enkovaara on 1 Mar 2010 02:03 -jg wrote: > There are plenty of free/cheap spice tools around, so there really > should be a 'simplest common denominator' offering from the IC > vendors, that allows usable 'quick checks' of port behavior, on all > drive conditions. The biggest problem with spice models is the compatibility. They would have to verify the models with multiple different spice implementations. And usually the vendors have spice models only for the high speed serial transceivers, not for regular IOs. For normal IOs IBIS is enough for the simulation, and even for the high speed transceivers IBIS-AMI (IBIS 5.0) seems to gain traction due to the difficulties of spice models. For professional settings SI tools are almost mandatory if the boards are in any way complex. And SI tools can easily use IBIS models. --Kim
From: -jg on 1 Mar 2010 03:02 On Mar 1, 8:03 pm, Kim Enkovaara <kim.enkova...(a)iki.fi> wrote: > -jg wrote: > > There are plenty of free/cheap spice tools around, so there really > > should be a 'simplest common denominator' offering from the IC > > vendors, that allows usable 'quick checks' of port behavior, on all > > drive conditions. > > The biggest problem with spice models is the compatibility. They would > have to verify the models with multiple different spice implementations. > > And usually the vendors have spice models only for the high speed serial > transceivers, not for regular IOs. For normal IOs IBIS is enough for > the simulation... ?? - you make a simple spice model, from the IBIS, IBISis fairly vanilla, in the details it provides. I'll start a new thread with an example.
From: Nial Stewart on 1 Mar 2010 05:38 > I really have to say that paying for Hyperlynx once is a lot cheaper > than fixing board, after board, with bad SI. In fact one re-spin of > the pcb is about what the tool costs. Austin, Out of interest I've asked about Hyperlynx pricing. There are many different pricing options, but the perpetual licences for Hyperlynx are... EXT (MHz version) line (schematic I presume) and board simulation ~ GPB �16K GHz (GHz version) line and board sim ~ GBP �38K This might be what it costs to re-spin a board if you're paying a large CEM to kit and build 20 Virtex boards, but for most of us a re-spin won't cost anything like that. We don't all work for large corporations. Nial.
From: Michael S on 1 Mar 2010 05:39
On Mar 1, 7:50 am, rickman <gnu...(a)gmail.com> wrote: > On Feb 28, 5:46 pm, Michael S <already5cho...(a)yahoo.com> wrote: > I don't see how adjusting the drive strength would be better than > adjusting the slew rate. It is the edge rate that causes the problems > with the transmission line, no matter how it is generated. The drive > strength will slow the edge if it can't supply the current during the > transition the same as slowing the slew rate, no? > > Rick The points is - we understand how drive strength control work. Or at least we think we do ;) As explained above in the thread, there are several drivers that are turned on or off statically at programming time (or at load time for SRAM-based devices). Minimal drive strength = only one driver active = the simplest possible topology = minimum of surprises. On the other hand, there are several way of implementing slow slew rate, we don't know which one is used by your vendor. Or at least I don't know. Most likely, slew rate control is implemented through some sort of feedback loop that is described by higher-than-first-order differential equations = unpleasant surprises are possible. |