Frustration with Vendors!
in [FPGA]
|
From: rickman on 28 Feb 2010 12:59 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. 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
From: rickman on 28 Feb 2010 13:09 On Feb 28, 11:31 am, "Nial Stewart" <nial*REMOVE_TH...(a)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? 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. 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... Rick
From: KJ on 28 Feb 2010 13:18 On Feb 27, 9:59 pm, rickman <gnu...(a)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 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. KJ
From: rickman on 28 Feb 2010 13:24 On Feb 28, 1:18 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > On Feb 27, 9:59 pm, rickman <gnu...(a)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. > > 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. Rick
From: Muzaffer Kal on 28 Feb 2010 14:46
On Sun, 28 Feb 2010 10:24:20 -0800 (PST), rickman <gnuarm(a)gmail.com> wrote: >On Feb 28, 1:18�pm, KJ <kkjenni...(a)sbcglobal.net> wrote: >> On Feb 27, 9:59�pm, rickman <gnu...(a)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.com |