Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 2/28/2010 4:09 PM, Michael S wrote: > > 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. That's probably good advice. The lowest drive strength will probably have the greatest source impedance. This will likely get you closer to a proper source termination. OTOH, if you can get away with the slow rise time, then use it. With a longer rise time, you can have a longer trace without worrying about transmission line effects. Slower rise times have fewer ground bounce issues and associated crosstalk problems. Syms.Article: 145926
> Is there anyone who can explain why spice models that don't reveal > circuit details are not provided by the vendors? Is it a mindset that > they are providing IBIS models and that should be good enough? I get > the impression that when spice models are provided, little or no > effort is made to make them compatible with the free versions like > LTspice (which btw is an excellent tool!) Rick, If you were buying 10's of 1000's of devices a year and asked for spice models you'd get them. Although if you were buying 10's of 1000's of devices a year your company would probably have a hyperlynx license. It's catch 22 for those of us who are working for small companies (or ourselves). Unfortunately. Nial.Article: 145927
On Feb 28, 11:09=A0am, Michael S <already5cho...@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 =A0from 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. 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. RickArticle: 145928
On Feb 28, 11:31=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > Is there anyone who can explain why spice models that don't reveal > > circuit details are not provided by the vendors? =A0Is it a mindset tha= t > > they are providing IBIS models and that should be good enough? =A0I get > > the impression that when spice models are provided, little or no > > effort is made to make them compatible with the free versions like > > LTspice (which btw is an excellent tool!) > > Rick, > > If you were buying 10's of 1000's of devices a year and asked for spice m= odels > you'd get them. > > Although if you were buying 10's of 1000's of devices a year your company= would > probably have a hyperlynx license. > > It's catch 22 for those of us who are working for small companies (or our= selves). > > Unfortunately. > > Nial. Why would I buy a piece of software that I will use once per year, maybe, when its only purpose for me is to mitigate crappy support??? The original complaint was not about how I was stuck, not having a way to deal with the SI problem. It was about the fact that I asked a vendor for a very simple piece of information and instead of a simply answer I got a load of stuff that was not only not useful, it was very counter productive as I tried to make use of it? The end result was that I had to spend an afternoon programming up a bunch of boards with different configurations and test them all at my customer's facility. Having a multi-kilobuck tool would have only saved me the trouble of programming the 10 different combinations and instead have let me just test the two or three most likely choices. Clearly this is not worth the cost in time and money it would take to buy and ramp up on a tool like Hyperlynx. I appreciate everyone's input to this. I have learned significantly from this discussion, both about the models and tools as well as other people's attitudes about IO modeling, especially the vendors. BTW, we have already sold over 500 units and will likely be selling several thousand over the next few years. It has to do with IRIG time codes and if I can find a way to get into the general market this may lead to a standard product. Marketing is not my forte, but I am learning... RickArticle: 145929
On Feb 27, 9:45=A0am, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > On 02/27/2010 08:52 AM, John_H wrote: > > > > > On Feb 26, 4:52 pm, Jason Thibodeau<jason.p.thibod...@gmail.com> > > wrote: > >> Hello, > > >> I am using Xilinx ISE 11.1, and I need to place some components in > >> certain areas of the FPGA. I have never done manual PaR, so here are a > >> few questions: > >> 1) Do I need to manually place each and every net? > >> 2) Is it possible to just place 'blocks' of each component in a genera= l > >> area of CLB on the device, and let the PaR algorithms auto route any > >> connecting nets? > > >> Thanks in advance, > >> Jason > > > You can also use the User Constraints File to explicitly place > > individual elemens using a LOC constraint or associate many components > > into an AREA_GROUP constraint. > > > Check out the Constraints Guide athttp://bit.ly/8YkuR9for the > > details. > > Thanks for all the help, everyone. I have a lot to read up on. I'll be > working on this in the next few days, you'll probably hear from me if I > can't seen to get it working. > > Sincerely, > Jason Just be sure to have a final HDL design before you bother with the P&R issues. P&R can need to be redone anytime you make code changes. So reworking code after you've done manual P&R can be very expensive. RickArticle: 145930
On Feb 27, 9:59=A0pm, rickman <gnu...@gmail.com> wrote: > In fact, in an unrelated design, my customer told me he has an FPGA > design with 90 clocks and was having trouble with the tools making it > all work!!! =A0 Wow...what a shocker, couldn't get it to work with only 90 clocks?...maybe an even 100 would've done the trick. > I explained to him how to sample the slower clocks with a > single system clock to transport signals across clock domains and I > think he is going to do that. > Whilst good advice you gave them, I somehow think they will still have trouble with just one clock. KJArticle: 145931
On Feb 28, 1:18=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Feb 27, 9:59=A0pm, rickman <gnu...@gmail.com> wrote: > > > In fact, in an unrelated design, my customer told me he has an FPGA > > design with 90 clocks and was having trouble with the tools making it > > all work!!! =A0 > > Wow...what a shocker, couldn't get it to work with only 90 > clocks?...maybe an even 100 would've done the trick. I didn't ask for details, but I believe this is about a wide variety of interfaces. This is an IP network interface with all types of input/output. The trick is that clocks don't have to be treated as clocks. They can often be sampled and treated like enables. > > I explained to him how to sample the slower clocks with a > > single system clock to transport signals across clock domains and I > > think he is going to do that. > > Whilst good advice you gave them, I somehow think they will still have > trouble with just one clock. I'm curious why do you think that? If each clock domain crossing or async sampling is done properly, it should work just fine. RickArticle: 145932
On Feb 5, 10:19=A0am, Eric Chomko <pne.cho...@comcast.net> wrote: > Has anyone created a copy machine of an old system using an FPGA? I havent, but check out: applelogic.org (it's down right now as far as I can tell) http://www.mirrow.com/FPGApple/ http://mirrow.com/FPGApple/revisited.html http://members.iinet.net.au/~msmcdoug/pace/#Status http://www.applefritter.com/blog/12920 http://c64upgra.de/c-one/ looks like the mirrow.com links aren't working either...Article: 145933
On Sun, 28 Feb 2010 10:24:20 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >On Feb 28, 1:18 pm, KJ <kkjenni...@sbcglobal.net> wrote: >> On Feb 27, 9:59 pm, rickman <gnu...@gmail.com> wrote: >> >> > In fact, in an unrelated design, my customer told me he has an FPGA >> > design with 90 clocks and was having trouble with the tools making it >> > all work!!! >> >> Wow...what a shocker, couldn't get it to work with only 90 >> clocks?...maybe an even 100 would've done the trick. > >I didn't ask for details, but I believe this is about a wide variety >of interfaces. This is an IP network interface with all types of >input/output. The trick is that clocks don't have to be treated as >clocks. They can often be sampled and treated like enables. > This assumes the clock are all phase synchronous (even they maybe at different frequencies). If they are not you have to deal with constantly shifting sampling phase which might force you to do full phase recovery; which can be done but would be wasteful for so many clocks. > >> > I explained to him how to sample the slower clocks with a >> > single system clock to transport signals across clock domains and I >> > think he is going to do that. >> >> Whilst good advice you gave them, I somehow think they will still have >> trouble with just one clock. > > >I'm curious why do you think that? If each clock domain crossing or >async sampling is done properly, it should work just fine. That many clocks can be managed relatively easily in an ASIC as you have full control over the clock tree and each intra-clock domain tree can be synthesized properly. In an FPGA you only have a limited number of clock tree domains which means you have to push the intra-domain clocks to fabric routing which can be quite problematic. You also have the problem of bringing in that many clock through IO which can't connect to the clock tree (for similar reasons) if they're for external clocks. Being able to do proper clock domain crossing or async sampling suggests that you have good local clock management which you can't have in an FPGA with that many clocks. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 145934
> From what I see here, I would say that the best simulation is the one > I run on my board. =A0I am starting to think I have been wasting my time > pursuing any of this. =A0What good is a model that is totally incapable > of modeling my circuit even if I have the full blown multi-kilobuck > version of the software? I often find that the simulation tools are designed for optimization of ball park designs. Of course the ball park gets smaller when the clock speed max of a device goes up! Are mega bucks worth the investment? Not for me, I have not received the pennies yet, so why would I use anything other than the free design lead tools. I would have thought the later technology should have the adaptation (i.e. digital LPF) avoiding the need for re-engineering. But then again there may be some good work in it. Cheers Jacko hhtp://forum.nibzx.co.ukArticle: 145935
rich12345 wrote: > > I havent, but check out: > > applelogic.org (it's down right now as far as I can tell) > > http://www.mirrow.com/FPGApple/ > > http://mirrow.com/FPGApple/revisited.html > > looks like the mirrow.com links aren't working either... > It has changed to alexfreed.com So try http://alexfreed.com/FPGApple and http://alexfreed.com/FPGApple/revisited -Alex. --- news://freenews.netfront.net/ - complaints: news@netfront.net ---Article: 145936
On Feb 28, 7:59 pm, rickman <gnu...@gmail.com> wrote: > On Feb 28, 11:09 am, Michael S <already5cho...@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.Article: 145937
On Mar 1, 3:46=A0am, rickman <gnu...@gmail.com> wrote: > > You are missing the point. =A0No one has to give their "actual circuit" > in order to provide a spice model. =A0If they have characterized the > circuit to build the IBIS model, they can use that same data to > produce a spice model that does not reveal the circuit. =A0The more I > discuss this, the more I am ticked off about it. =A0The vendors all > understand what I am saying. =A0So why are they being so stubborn about > not providing characterized spice models? As a quick reality check, I grabbed a IBIS summary, and they store quite basic info : Ramp-Up, Ramp-Down, Cap, and the V-I plot of the pin drive. That can fairly easily give drive impedances, and for the simplest tests I ignored the Clamp pathways. Next, I used the Ramp values to make a PWL source, and then I split the typical impedances and use the N-fet ones, as they are lower, and added in some real world L, and voila : a Spice Circuit, that can be related to the key IBIS models. Because I like comparisons, I then copied/pasted to get TWO copies, and inserted two example Ramp times. Output is two ringing waveforms, with MUCH worse ringing on the 1ns ramp case than the 2ns ramp case. This should work in ANY spice that supports PWL sources. So, not sure WHY the vendors find that "too hard" ? [Took longer to type the post, than get the first plot] -jg ~~~~~~~~~~~~ Spice Netlist, IBIS napkin example ~~~~~~~~~~~~~ ***** main circuit L2 3 4 22n C6 2 0 5p C3 8 0 5p C2 7 0 5p C1 6 0 5p L1 7 8 22n R2 6 7 15 C5 3 0 5p IV2ns 8 0 0 R1 5 6 15 V1 5 0 PWL ( 0 0 + 50n 0 + 52n 3.3 + 100n 3.3 + 102n 0) C4 4 0 5p R3 2 3 15 IV1ns 4 0 0 R4 1 2 15 V2 1 0 PWL ( 0 0 + 50n 0 + 51n 3.3 + 100n 3.3 + 101n 0) .TRAN 1E-9 1.2E-7 3E-8 1E-9 .OPTIONS temp =3D 27 .endArticle: 145938
Here is the output Spice circuit, edited to make it easier to follow. ***** main circuit V1 1 0 PWL ( 0 0 + 50n 0 + 52n 3.3 + 100n 3.3 + 102n 0) R1 1 2 15 C1 2 0 5p R2 2 3 15 C2 3 0 5p L1 3 4 22n C3 4 0 5p IV2ns 4 0 0 V2 5 0 PWL ( 0 0 + 50n 0 + 51n 3.3 + 100n 3.3 + 101n 0) R3 5 6 15 C4 6 0 5p R4 6 7 15 C5 7 0 5p L2 7 8 22n C6 8 0 5p IV1ns 8 0 0 .TRAN 1E-9 1.2E-7 3E-8 1E-9 .OPTIONS temp = 27 .endArticle: 145939
On Feb 23, 10:43=A0pm, timinganalyzer <timinganaly...@gmail.com> wrote: > On Feb 23, 10:56=A0am, timinganalyzer <timinganaly...@gmail.com> wrote: > > > > > On Feb 14, 9:12=A0am, rickman <gnu...@gmail.com> wrote: > > > > On Feb 8, 7:51=A0pm, timinganalyzer <timinganaly...@gmail.com> wrote: > > > > > Hello serkan, > > > > > The latest version of the TimingAnalyzer now reads VCD files and > > > > automatically converts and saves it as a timing diagram. =A0This is > > > > useful for documenting simulation results for specifications, revie= ws, > > > > and presentations. > > > > >http://www.timing-diagrams.com/dokuwiki/doku.php?id=3Ddocs:vcd_files > > > > > Dan > > > > > On Feb 5, 5:29=A0pm, "M.Randelzhofer" <techsel...@gmx.de> wrote: > > > > > > "Serkan" <ok...@su.sabanciuniv.edu> schrieb im Newsbeitragnews:38= 2d6281-244f-48d7-a0ae-ff76e69316db@p24g2000yqm.googlegroups.com... > > > > > > > Any suggestions for a free waveform drawing tool? > > > > > > > inkscape or word alike tools take too much time for edition. > > > > > > some free tools does not let more than 10 clock cycles > > > > > > some free tools does not let more than 5 or 6 signals > > > > > > > kind regards > > > > > > serkan > > > > > >http://www.timing-diagrams.com/doku.php > > > > > > MIKE > > > > I am having trouble figuring out other aspects of using this program. > > > I noticed that the author's web site doesn't have a forum for users, > > > so I've started a Yahoo group for users to discuss this program and > > > hopefully provide support to one another. > > > >http://tech.groups.yahoo.com/group/TimingAnalyzer/ > > > > I am trying to draw a diagram to help me visualize the advantages of > > > replacing registers with latches in designs with tight timing. =A0It > > > seems like an uphill struggle given that I can't tell if the things I > > > try don't work because that isn't the way the tool works or if I'm > > > just not using it right. =A0I'm not finding this tool to be very > > > intuitive. =A0But then maybe I'm just not thinking along the right > > > vein. > > > > Rick- Hide quoted text - > > > > - Show quoted text - > > > Hi Rick, > > > I was away for week and didn't see your response. =A0Yes, =A0the progra= m > > is now freeware and I'm the only developer at this time. =A0I work full > > time as a design engineer so I don't get a lot of time to develop the > > program. =A0As a result, =A0progress is slow but I'm always working on = new > > features and bug fixes. =A0I'm focusing the next few releases on bug > > fixes and improvements and better documentation.. =A0I did at one time > > have a user forum, so I will add that back again. =A0There is also a ne= w > > code repository started for python scripts at: > > >http://code.google.com/p/timing-analyzer-plugins/ > > > Printing will be supported, =A0but for now, you have to save the diagra= m > > as an image and print the image. =A0 I realize the program is not as > > polished as some of the commercial quality alternatives, but that will > > change in time. > > > If you have any questions, =A0just let me know, my email is: > > > timinganaly...@gmail.com > > > Thanks, Dan > > Hi Rick, > > I added 3 new user forums on the website. =A0GUI HELP, =A0Script HELP, > and New Features and Improvement Request. > > www.timing-diagrams.com/forums/index.php > > -Dan I can't figure out how to add uncertainty window to a bus. Any trick? Thanks!Article: 145940
On Feb 28, 1:24=A0pm, rickman <gnu...@gmail.com> wrote: > > > Whilst good advice you gave them, I somehow think they will still have > > trouble with just one clock. > > I'm curious why do you think that? =A0If each clock domain crossing or > async sampling is done properly, it should work just fine. > I think that because based on your comments it sounded to me like they didn't quite knew what they were doing which is likely why they ended up with 90 clock domains...either that or you're talking about an ASIC design and not an FPGA. Low skew clock distribution resources and/or clock pins are generally not *that* prevalent in FPGAs...ASICs on the other hand can generate and control as many as the designer wants. KJArticle: 145941
On Feb 28, 5:46=A0pm, Michael S <already5cho...@yahoo.com> wrote: > On Feb 28, 7:59 pm, rickman <gnu...@gmail.com> wrote: > > > > > On Feb 28, 11:09 am, Michael S <already5cho...@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 =A0from that phrase you could probabl= y > > > 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. =A0I 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. =A0It 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. =A0BTW, 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? =A0A 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 (=3Dgood). > 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? RickArticle: 145942
-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. --KimArticle: 145943
On Mar 1, 8:03=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > -jg wrote: > > =A0There 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.Article: 145944
As a simple exercise, I looked at the info in a IBIS file, which is quite simple : V-I tables, and pF and nS values for ramps. So if you have a simple problem : What clock edge should I finally get ?, you can create a napkin Spice model, that can be used to track bench tests. The V-I tables can give the output impedance. For overshoot, use the N- CH values, and for min-slew checks, use the (usually slightly higher) P-CH values. Slew values are used to set the PWL source, and R/C values here I have split in two, and modeled, with a third C/2 for trace/load capacitance.. example for a 30 ohm, 10pF and 1ns or 2ns ramp values 22nH parasitic L. This has two instances to show slew-range effects on one plot. It is also small enough to easily fit inside most demo-mode Spice's [ Tested on B2spice / LTSpice / SpiceOpus. ] -jg ~~~~~~~~ Edited to be more human-understood ~~~~~~~ ***** main circuit V1 1 0 PWL ( 0 0 + 50n 0 + 52n 3.3 + 100n 3.3 + 102n 0) R1 1 2 15 C1 2 0 5p R2 2 3 15 C2 3 0 5p L1 3 4 22n C3 4 0 5p IV2ns 4 0 0 V2 5 0 PWL ( 0 0 + 50n 0 + 51n 3.3 + 100n 3.3 + 101n 0) R3 5 6 15 C4 6 0 5p R4 6 7 15 C5 7 0 5p L2 7 8 22n C6 8 0 5p IV1ns 8 0 0 .TRAN 1E-9 1.2E-7 3E-8 1E-9 .OPTIONS temp = 27 .end ~~~~~~~~~~~~~ LTSpice, B2Spice ~~~~~~~~~~ * IBIS_Check.cir for LTSpice * ***** main circuit V1 1 0 PWL ( 0 0 + 50n 0 + 52n 3.3 + 100n 3.3 + 102n 0) R1 1 2 15 C1 2 0 5p R2 2 3 15 C2 3 0 5p L1 3 4 22n C3 4 0 5p IV2ns 4 0 0 V2 5 0 PWL ( 0 0 + 50n 0 + 51n 3.3 + 100n 3.3 + 101n 0) R3 5 6 15 C4 6 0 5p R4 6 7 15 C5 7 0 5p L2 7 8 22n C6 8 0 5p IV1ns 8 0 0 .TRAN 1E-9 1.2E-7 3E-8 1E-9 * PickVisibleTraces V(8) V(4) then File.SavePlotSettings .end http://www.spiceopus.si/download/downloadw.html ~~~~~~~~~~~~~ SpiceOpus ~~~~~~~~~~~~~~~~ * IBIS_Check.cir for SpiceOpus * ***** main circuit V1 1 0 PWL ( 0 0 + 50n 0 + 52n 3.3 + 100n 3.3 + 102n 0) R1 1 2 15 C1 2 0 5p R2 2 3 15 C2 3 0 5p L1 3 4 22n C3 4 0 5p IV2ns 4 0 0 V2 5 0 PWL ( 0 0 + 50n 0 + 51n 3.3 + 100n 3.3 + 101n 0) R3 5 6 15 C4 6 0 5p R4 6 7 15 C5 7 0 5p L2 7 8 22n C6 8 0 5p IV1ns 8 0 0 * SpiceOpus script control section follows .control, this section is less spice portable .control destroy all tran 1E-9 1.2E-7 3E-8 1E-9 * was .TRAN 1E-9 1.2E-7 3E-8 1E-9 run rusage time setplot setplot tran plot v(8) v(4) xlabel t[s] ylabel '1nS Rise(r), 2nS Rise(g)' .endc .endArticle: 145945
On Fri, 26 Feb 2010 13:48:48 -0500 Michael Wojcik <mwojcik@newsguy.com> wrote: > Ahem A Rivet's Shot wrote: > > > > No, he's saying that C doesn't really implement an array type, > > the var[offset] syntax is just syntactic sugar for *(var + offset) > > which is why things like 3[x] work the same as x[3] in C. > > That's not quite correct. C does implement an array type (or, rather, > an array type qualifier which can be used to implement arrays of any > object type); it's just not first-class. This is saying the same thing as I did in different terms and with greater detail. -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/Article: 145946
On 03/01/2010 12:17 AM, -jg wrote: > The V-I tables can give the output impedance. For overshoot, use the N- > CH values, and for min-slew checks, use the (usually slightly higher) > P-CH values. > I'm not sure if it is that straight forward. From "The Development of Analog SPICE Behavioral Model Based on IBIS Model" Ying Wang and Han Ngee Tan, Proceedings of the Ninth Great Lakes Symposium on VLSI, (March 1999) http://www.cecs.uci.edu/~papers/compendium94-03/papers/1999/glsvlsi99/pdffiles/glsvlsi99_101.pdf > It must be cautioned that the IV tables of an IBIS > model are purely based on DC condition and should not > be used for transient simulation. ... > Thus, the approach of deriving switching signal only > based on static information, i.e., DC IV tables is not > valid. The dynamic information provided by IBIS model > must be adopted in the generation of analog SPICE > behavioral model. The model building principle is to map > all IBIS information of both static and dynamic into the > SPICE model. I would recommend a read through of that paper if you want to make a SPICE model based on IBIS data (it is only four pages long). This paper is built on the methodology presented in this paper, which gives a bit more info: "Extraction of Transient Behavioral Model of Digital I/O Buffers from IBIS" - by Peivand Tehrani, Yuzhe Chen and Jiayuan Fang, 46th IEEE Electronic Components & Technology Conference (May 28-31, 1996) http://www.sigrity.com/papers/ectc96/ectc96ibis.pdf Jared CasperArticle: 145947
On Mar 1, 10:30=A0pm, Jared Casper <jaredcas...@gmail.com> wrote: > On 03/01/2010 12:17 AM, -jg wrote: > > > The V-I tables can give the output impedance. For overshoot, use the N- > > CH values, and for min-slew checks, use the (usually slightly higher) > > P-CH values. > > I'm not sure if it is that straight forward. =A0From > > "The Development of Analog SPICE Behavioral Model Based on IBIS Model" > Ying Wang and Han Ngee Tan, Proceedings of the Ninth Great Lakes > Symposium on VLSI, (March 1999)http://www.cecs.uci.edu/~papers/compendium= 94-03/papers/1999/glsvlsi99... > > =A0> It must be cautioned that the IV tables of an IBIS > =A0> model are purely based on DC condition and should not > =A0> be used for transient simulation. > ... > =A0> Thus, the approach of deriving switching signal only > =A0> based on static information, i.e., DC IV tables is not > =A0> valid. The dynamic information provided by IBIS model > =A0> must be adopted in the generation of analog SPICE > =A0> behavioral model. The model building principle is to map > =A0> all IBIS information of both static and dynamic into the > =A0> SPICE model. > > I would recommend a read through of that paper if you want to make a > SPICE model based on IBIS data (it is only four pages long). > > This paper is built on the methodology presented in this paper, which > gives a bit more info: > > "Extraction of Transient Behavioral Model of Digital I/O Buffers from > IBIS" =A0- by Peivand Tehrani, Yuzhe Chen and Jiayuan Fang, 46th IEEE > Electronic Components & Technology Conference (May 28-31, 1996)http://www= .sigrity.com/papers/ectc96/ectc96ibis.pdf > > Jared Casper Yup, which is why the spice model I have, is not using just R. It also includes these AC parameters a) Slew rate value b) Capacitance c) Inductance -jgArticle: 145948
> 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.Article: 145949
On Mar 1, 7:50 am, rickman <gnu...@gmail.com> wrote: > On Feb 28, 5:46 pm, Michael S <already5cho...@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.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z