Custom Search
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 Feb 26, 5:54=A0pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote: > Scott Lurndal wrote: > > "(see below)" <yaldni...@blueyonder.co.uk> writes: > >> On 24/02/2010 20:37, in article hm6fbd6...@news6.newsguy.com, "Michael > >> Wojcik" <mwoj...@newsguy.com> wrote: > > >>> (see below) wrote: > >>>> Just the usual red tape: return address, frame pointer of caller; an= d either > >>>> a static pointer or some housekeeping for 'display' registers (if us= ed) to > >>>> access non-locals. But bear in mind that in decent languages arrays = are > >>>> storable values, so a value array parameter gets copied in toto, unl= ike C. > >>> It will be in C if the array is wrapped in a struct. Letting array > >> That is passing a struct, not an array. > > >>> parameters decay to pointers was a feature of early C that couldn't b= e > >>> changed for historical reasons, but when the standardization committe= e > >>> added support for struct parameters, they made them first-class. > >>> struct (and not the misnamed "typedef") is C's mechanism for creating > >>> new types and ADTs, so if you want a pass-by-value array in C, the > >>> correct thing to do is to put it in a struct. > >> Yes. Preposterous, isn't it? > > > Q? =A0Why would anyone want to pass an array by value? > > Because you can? In Perl there is the 'shift' statement, which allows access to an array by value.Article: 145951
On Feb 28, 8:06=A0pm, "jimwu88NOOOS...@yahoo.com" <jimw...@gmail.com> wrote: > 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> wrot= e: > > > > > > 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, rev= iews, > > > > > and presentations. > > > > > >http://www.timing-diagrams.com/dokuwiki/doku.php?id=3Ddocs:vcd_fil= es > > > > > > Dan > > > > > > On Feb 5, 5:29=A0pm, "M.Randelzhofer" <techsel...@gmx.de> wrote: > > > > > > > "Serkan" <ok...@su.sabanciuniv.edu> schrieb im Newsbeitragnews:= 382d6281-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 progra= m. > > > > 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 o= f > > > > replacing registers with latches in designs with tight timing. =A0I= t > > > > 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 prog= ram > > > is now freeware and I'm the only developer at this time. =A0I work fu= ll > > > 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 o= n new > > > features and bug fixes. =A0I'm focusing the next few releases on bug > > > fixes and improvements and better documentation.. =A0I did at one tim= e > > > have a user forum, so I will add that back again. =A0There is also a = new > > > 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 diag= ram > > > 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 wil= l > > > 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!- Hide quoted text - > > - Show quoted text - You have to add a Delay and include the uncertainty in the values for min, typ, and max. 1) select the source edge ( click in edge) from a clock or other signal 2) select the destination edge (click in edge with shft key down) in the bus 3) add Menu - Delay (ctrl 7). That brings up the Delay Panel and the User Delay and Constraints Panel on the left 4) select User Delays and Constraints Panel. (click in tab). 5) make a User delay that contains the min, typ, and max delay values with the uncertainties. Add the User Delay 6) select the User Delay Panel(click in tab). select that User Delay in the Delay Panel. Add the delay. Once a User Delay has been added, it can be used in other Delays and steps 4 and 5 in the procedure above are not needed. I hope this helps. DanArticle: 145952
Michael Wojcik <mwojcik@newsguy.com> writes: >Scott Lurndal wrote: >> >> I've never promoted or suggested that one put an array in a struct >> and pass it by value, I frankly think it would be a stupid thing to >> do in a C program. > >Is it a stupid idea, or a good one, in all the languages that support >it? Is this just a special attribute of C? Perhaps stupid was a bit strong. As an OS designer/implementer, I find the copy to be a problem; perhaps for other applications, it would make some sense (although most the apps I can think of that process arrays are probably better off in FORTRAN or R or Mathematica. > >> I was curious if anyone thought passing an array by value was a >> _good_ idea. > >It might be if you want the callee to be able to modify its copy of >the array without affecting the caller's. Just like any other >pass-by-value object. > >If the callee would have had to make a copy of the array anyway, why >not let the compiler do the work? Yes, a point. However, I'd be concerned about the adverse affect on performance if used for subtantially large arrays. scottArticle: 145953
Charles Richmond <frizzle@tx.rr.com> writes:
> Joe Pfeiffer wrote:
>>
>> Since C99, you can allocate an array with a variable number of elements
>> like this:
>>
>> printf(" array size >> ");
>> scanf("%d", &size);
>>
>> int awry[size];
>
> But how about the second dimension, Joe??? Can you allocate:
>
> int awry2[size][size];
Yes (just tried it)
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Article: 145954
Joe Pfeiffer wrote:
> Charles Richmond <frizzle@tx.rr.com> writes:
>> Joe Pfeiffer wrote:
>>> Since C99, you can allocate an array with a variable number of elements
>>> like this:
>>>
>>> printf(" array size >> ");
>>> scanf("%d", &size);
>>>
>>> int awry[size];
>> But how about the second dimension, Joe??? Can you allocate:
>>
>> int awry2[size][size];
>
> Yes (just tried it)
Hey! C's finally caught up to PL/I. Only took them 50 years, and then
of course all the features are just tacked-on in true C fashion, instead
of thought-through.
Article: 145955On Mar 1, 5:38=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > I really have to say that paying for Hyperlynx once is a lot cheaper > > than fixing board, after board, with bad SI. =A0In 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 = =A316K > > GHz (GHz version) line and board sim ~ GBP =A338K > > 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. Even so, I have *never* had to respin a board because of SI issues. A full blown simulation tool is not the only way to analyze this sort of stuff, regardless of what you will hear. Heck how often do you even have the full details of your loading to use with a high end tool? You have to extract that data from the layout program and they don't pull if from a universal Gerber file. You have to be using a compatible layout program... more big bucks, otherwise needlessly spent. RickArticle: 145956
On Mar 1, 4:30=A0am, 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 I can attest to the fact that there are things going on that are very different from the static conditions. I ran an IBIS simulation on the file provided by the vendor... actually, I don't thin it was a simulation as much as just a display of the waveform shown in the IBIS file. It clearly shows a quick rise time (~1 ns) to a level lower than Vdd because of the 100 ohm load to ground. But after about 2-3 ns the voltage drops off and remains constant for the duration of the 20 ns data sample. I am pretty sure you can't generate this waveform with a simple RLC model. It also makes me suspicious of the entire IBIS file thing. It just seems like this is a very poor way to model an I/O, but then I haven't looked at it in detail. I do know that the one time I used a simulator, it did not give results so much like what we measured. It predicted severe overshoot on the bus lines and we observed very little. RickArticle: 145957
On Mar 2, 12:56=A0pm, rickman <gnu...@gmail.com> wrote: >=A0It clearly shows a quick rise time (~1 ns) to a level lower > than Vdd because of the 100 ohm load to ground. =A0But after about 2-3 > ns the voltage drops off and remains constant for the duration of the > 20 ns data sample. =A0I am pretty sure you can't generate this waveform > with a simple RLC model. =A0It also makes me suspicious of the entire > IBIS file thing. =A0 Yes, that sounds simply broken. Like the sim-engine, and the model got out of step. Did your scope 'reality check' look anything like that? > It just seems like this is a very poor way to model > an I/O, but then I haven't looked at it in detail. IBIS is simplified output from the 'real spice'. So they just have single numbers for ramp rates, and a table plot for I-V. Given the limits of the information in the IBIS, you should still be able to get useful spice data points. Certainly more than enough, to correlate with bench measurements, and for clock ringing (which is what you were looking for). Tho I'm not sure I'd try and get Eye patterns from it ;) It's best to use Hyperlynx for that level of analysis. Those spice examples look quite plausible to me. Both show ringing, but with (expected) quite different amplitudes and phases.Article: 145958
On Mar 1, 7:11=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Mar 2, 12:56=A0pm, rickman <gnu...@gmail.com> wrote: > > >=A0It clearly shows a quick rise time (~1 ns) to a level lower > > than Vdd because of the 100 ohm load to ground. =A0But after about 2-3 > > ns the voltage drops off and remains constant for the duration of the > > 20 ns data sample. =A0I am pretty sure you can't generate this waveform > > with a simple RLC model. =A0It also makes me suspicious of the entire > > IBIS file thing. =A0 > > Yes, that sounds simply broken. Like the sim-engine, > and the model got out of step. > Did your scope 'reality check' look anything like that? The "sim-engine" is just a display of the contents of the V-t curve given in the model. I found it in the file and the data is exactly like the curve drawn. > > It just seems like this is a very poor way to model > > an I/O, but then I haven't looked at it in detail. > > IBIS is simplified output from the 'real spice'. > So they just have single numbers for ramp rates, and > a table plot for I-V. > > =A0Given the limits of the information in the IBIS, you should still be > able to get useful spice data points. > =A0Certainly more than enough, to correlate with bench measurements, and > for clock ringing (which is what you were looking for). > > Tho I'm not sure I'd try and get Eye patterns from it ;) > It's =A0best to use Hyperlynx for that level of analysis. What the heck do you feed into Hyperlynx? That is what the IBIS models are supposed to be for from what I have read. Hyperlynx is not spice, it uses the IBIS models for the drivers and inputs and it gets info on your pcb from your layout package. All in all, it is a *very* expensive way to design high speed PCBs and like I said, I didn't find it produced very good results. > =A0Those spice examples look quite plausible to me. > Both show ringing, but with (expected) quite different amplitudes and > phases. In the end we picked a 12 mA, FAST output which gives a 6 ns rise time with a small wiggle in the rising edge at around 2.6 volts pretty well above the typical threshold. With an 8 mA drive the rise time is slower and the wiggle shows up further down in the curve near the threshold. The common factor is a ~4 ns time delay which matches the end of the initial pulse in the V-t curve data. I don't think any of this is ringing due to reflections in the trace. A 6 ns rise time would require a trace a foot or more long to create any noticeable reflection. The trace on this board is maybe 3 inches long total. I don't know what the IBIS data is about. RickArticle: 145959
I need to instantiate LVDS interfaces in my top-level. I am planning to use SV interface blocks. Altera's documentation suggests that LVDS i/os should only be instantiated using a megafunction. But the interface blocks do not allow hierarchy so I cannot instantiate a megafunction inside the interface block. Any thoughts on this?Article: 145960
On Mar 2, 1:44=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 1, 7:11=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > What the heck do you feed into Hyperlynx? =A0That is what the IBIS > models are supposed to be for from what I have read. =A0Hyperlynx is not > spice, it uses the IBIS models for the drivers and inputs and it gets > info on your pcb from your layout package. =A0All in all, it is a *very* > expensive way to design high speed PCBs and like I said, I didn't find > it produced very good results. The top end Hyperlynx products, include the trace parasitics, and lossy transmission line models. So if you are serious about eye patterns, they are a good idea. If you just want ringing/drive selector, then yes, they could be an overkill. Hence the spice alternative. > > In the end we picked a 12 mA, FAST output which gives a 6 ns rise time > with a small wiggle in the rising edge at around 2.6 volts pretty well > above the typical threshold. =A0With an 8 mA drive the rise time is > slower and the wiggle shows up further down in the curve near the > threshold. =A0The common factor is a ~4 ns time delay which matches the > end of the initial pulse in the V-t curve data. =A0I don't think any of > this is ringing due to reflections in the trace. =A0A 6 ns rise time > would require a trace a foot or more long to create any noticeable > reflection. =A0The trace on this board is maybe 3 inches long total. =A0I > don't know what the IBIS data is about. I used 22nH, and 5pF as the load, and got noticable ringing effects, with fast-ish edges. That ~3 inch trace will be 30-40nH, and rather more than 5pF, so your slower edges should give similar results. Try it and see :) -jgArticle: 145961
Hi all, I'm designing an LPDDR2 SDRAM memory interface controller for a Virtex-6 FPGA based on the DDR3 interface controller provided by MIG 3.3. The memory interface signals need a 1.2V IOStandard. For the single- ended signals, either LVCMOS12 or HSTL_I_12 IOStandard can be used. The problem is on the differential (CK and DQS) signals, there is no differential 1.2V IOStandard supported. Is there any workaround for this issue? Is it possible to configure the logic to a 1.5V IOStandard (for example DIFF_SSTL15) and tweak VCCO and VREF in such a way to get the IOB lines within the desired 1.2V swing? Regards, ShantArticle: 145962
On Mar 1, 8:37=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Mar 2, 1:44=A0pm, rickman <gnu...@gmail.com> wrote: > > > On Mar 1, 7:11=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > What the heck do you feed into Hyperlynx? =A0That is what the IBIS > > models are supposed to be for from what I have read. =A0Hyperlynx is no= t > > spice, it uses the IBIS models for the drivers and inputs and it gets > > info on your pcb from your layout package. =A0All in all, it is a *very= * > > expensive way to design high speed PCBs and like I said, I didn't find > > it produced very good results. > > =A0The top end Hyperlynx products, include the trace parasitics, and > lossy transmission line models. So if you are serious about eye > patterns, they are a good idea. > =A0If you just want ringing/drive selector, then yes, they could be an > overkill. > > =A0Hence the spice alternative. > > > > > In the end we picked a 12 mA, FAST output which gives a 6 ns rise time > > with a small wiggle in the rising edge at around 2.6 volts pretty well > > above the typical threshold. =A0With an 8 mA drive the rise time is > > slower and the wiggle shows up further down in the curve near the > > threshold. =A0The common factor is a ~4 ns time delay which matches the > > end of the initial pulse in the V-t curve data. =A0I don't think any of > > this is ringing due to reflections in the trace. =A0A 6 ns rise time > > would require a trace a foot or more long to create any noticeable > > reflection. =A0The trace on this board is maybe 3 inches long total. = =A0I > > don't know what the IBIS data is about. > > =A0I used 22nH, and 5pF as the load, and got noticable ringing effects, > with fast-ish edges. > > =A0That ~3 inch trace will be 30-40nH, and rather more than 5pF, so your > slower edges should give similar results. > > =A0Try it and see :) > > =A0-jg I'm talking about the boards. I get virtually no ringing with the slower edge rates. The fastest, 20 mA/FAST, setting gives pronounced ringing and 16 mA has some as well. They are both 2 ns or less rise times. At 12 ns the ringing is gone and I only see the tiny notch in the rising edge that I am convinced is not ringing or reflection. BTW, a transmission line does not ring. You can get reflections, but unless there is some sort of feedback in your IO driver that is oscillating, you won't see true ringing with a transmission line... unless there is something with transmission lines that I didn't learn. It is often that reflections look like ringing because they echo several times at lower amplitude each time around. No? RickArticle: 145963
On Mar 2, 6:15=A0pm, rickman <gnu...@gmail.com> wrote: > > I'm talking about the boards. =A0I get virtually no ringing with the > slower edge rates. =A0The fastest, 20 mA/FAST, setting gives pronounced > ringing and 16 mA has some as well. =A0They are both 2 ns or less rise > times. =A0At 12 ns the ringing is gone and I only see the tiny notch in > the rising edge that I am convinced is not ringing or reflection. It depends on your terminology. The notch I mention below, I would call ringing, as it comes from a LCR+Slope model. It is effectively ringing summed onto the slowish rise time, and is not huge, but large enough to see a slight reverse in voltage. > BTW, a transmission line does not ring. =A0You can get reflections, but > unless there is some sort of feedback in your IO driver that is > oscillating, you won't see true ringing with a transmission line... > unless there is something with transmission lines that I didn't > learn. =A0It is often that reflections look like ringing because they > echo several times at lower amplitude each time around. =A0No? > > Rick Just for fun, I added some guestimate numbers from what you said, and added a probe to the driving end, and voila, guess what? A small notch appears, on the driving end ;) Which end were you probing, your end, or connector, or the customers FPGA pin ? -jgArticle: 145964
On Mon, 1 Mar 2010 17:28:38 -0800 (PST), fpgabuilder wrote: >I need to instantiate LVDS interfaces in my top-level. I am planning >to use SV interface blocks. Altera's documentation suggests that LVDS >i/os should only be instantiated using a megafunction. But the >interface blocks do not allow hierarchy so I cannot instantiate a >megafunction inside the interface block. > >Any thoughts on this? This sounds to me like an inappropriate use of SV interfaces. When you say "I am planning to use SV interface blocks", what exactly do you intend? Interfaces are useful in certain situations, but you definitely would not want to use them everywhere in your design. In particular, you should avoid using interfaces for the design's top-level I/O because it will inevitably cause trouble with other tools in the flow. It is not quite true that "interfaces do not allow hierarchy". You cannot create a *module* instance inside an interface, but you certainly can have an *interface* instance inside another. However, nested interface instances are not necessarily synthesizable. -- Jonathan BromleyArticle: 145965
> Even so, I have *never* had to respin a board because of SI issues. Neither have I, but I haven't exactly been pushing the boundaries for the last couple of years. > A > full blown simulation tool is not the only way to analyze this sort of > stuff, regardless of what you will hear. Heck how often do you even > have the full details of your loading to use with a high end tool? > You have to extract that data from the layout program and they don't > pull if from a universal Gerber file. I think Hyperlynx will pull in Gerbers OK. At least it should for what it costs. NialArticle: 145966
All, Apologies for the cross-post, I know a lot of people who deal with FPGAs are also experts with PCBs, stack-ups, high-speed layout, hoping for some good ideas from both groups. I'm not an expert on board design or electronics, but I'm trying to do things right from the start... My issue in a nut shell: How can I properly prevent ground-loops from external connections that interface to my board? I receive several digital signals streams from two to four external boards, single- ended, ~5 Mbps, almost zero-balanced. My board has sensitive analog and audio/video and I'd like to avoid the possibility of ground-loops, 60 Hz hum, etc. I know of three methods to isolate and I list the methods and my thoughts. 1. I can use a capacitor in-series with each input signal and level- shift it back so my digital ICs will properly trigger and keep the ext_GND isolated from my sys_GND. I have tested this and it's reliable for my configuration. But! I'm very worried about EMI and return currents. If I use a capacitor to couple the external signal in AND I don't connect ext_GND(s) to my sys_GND, I fear that the return current from the input signal will see an impedance discontinuity and cause me MORE EMI headaches. I reason that the current should flow in a loop and while the capacitor isolates my two systems, the return current will still have to go back to the original source and since my GNDs are discontiguous, I have a high-impedance return (maybe through free space) and this will couple more noise into my system. 2. I can use an isolation transformer (1:1) and a capacitor on the input side to avoid saturating the core (strip DC) and use a cap on the output & restore the DC. I wonder if the capacitance between windings, other parasitics and EM "leakage" however won't end up defeating the purpose of isolation and will end up coupling noise from the external circuits into my system. Since my signals are single-ended I don't have a differential receiver to reject the common-mode noise either. I'm also uncertain if the return current has a path, but based on my recollection of transformers, the load impedance is reflected back to the source, so there is a "path" and both sides are coupled together. 3. I can use a digital isolator (NVE, ADI) and have it straddle the external input block and my digital system. The issue here is the need for power on the external input side that would have to be isolated from the digital side. I also wonder, since the NVE/ADI parts end up using magnetic isolation techniques, will they end up broadcasting any EM? Thank you! Sam.Article: 145967
rickman wrote: > On Mar 1, 5:38 am, "Nial Stewart" > Even so, I have *never* had to respin a board because of SI issues. A > full blown simulation tool is not the only way to analyze this sort of > stuff, regardless of what you will hear. Heck how often do you even > have the full details of your loading to use with a high end tool? I haven't seen a complex board without need for respin and SI is one of the reasons quite often. For me complex board is 15+ layers, high speed busses (600+MHz DDR), differential gigabit traces, board full of components and quite big boards. Even with simulation there are suprises, but the more time is spent on simulation the better quality the board usually is. Especially crosstalk is a real problem in complex boards, and without automatic batch simulation quite impossible to handle without very conservative design rules. And with too conservative rules the designs do not to fit to the boards. It quite normal in complex boards to have ibis models for most of the chips already in the component database, and some defaults for others and layout is extracted from the design databases. In the more expensive tools the flow has been automated in recent years. Next stage is power integrity simulation of the boards. With hundreds of amps of current the power distribution is a real problem and hard to analyze. --KimArticle: 145968
rickman wrote: > What the heck do you feed into Hyperlynx? That is what the IBIS > models are supposed to be for from what I have read. Hyperlynx is not > spice, it uses the IBIS models for the drivers and inputs and it gets > info on your pcb from your layout package. All in all, it is a *very* > expensive way to design high speed PCBs and like I said, I didn't find > it produced very good results. Hyperlynx also can use spice (hspice or eldo) models, so you can use a mixture of ibis and spice models for the simulation. And I think also AMS and IBIS-AMI is supported. And also the trace models do not have to come from the layout. I have used the tool often for design exploration. For example checking the termination schemes (ODT vs. separate resistors etc.) and the results have matched quite well to the real world. Altough the trace was only based on PCB stackup model, vias and trace lengths on different layers. --KimArticle: 145969
This lot seems to be revealing a bit more about their stuff. http://www.mercurynews.com/breaking-news/ci_14493616 http://www.tabula.comArticle: 145970
On Tue, 02 Mar 2010 11:22:07 +0000, Symon wrote: >This lot seems to be revealing a bit more about their stuff. >http://www.mercurynews.com/breaking-news/ci_14493616 >http://www.tabula.com Thanks for the heads-up. Any startup may simply vanish without trace in a puff of hot air, but this lot look as though they may have one of the few really innovative and potentially disruptive ideas to hit FPGAs in recent times. Commercial reality being what it is, it is unlikely that hobbyists and small design shops will be able to get their hands on real tools and devices at a sensible price for quite some time. But I reckon it's still worth watching. -- Jonathan BromleyArticle: 145971
On Mar 2, 5:14=A0am, digitaljanitor <b7grabn...@sneakemail.com> wrote: > All, > > Apologies for the cross-post, I know a lot of people who deal with > FPGAs are also experts with PCBs, stack-ups, high-speed layout, hoping > for some good ideas from both groups. =A0I'm not an expert on board > design or electronics, but I'm trying to do things right from the > start... > > My issue in a nut shell: =A0How can I properly prevent ground-loops from > external connections that interface to my board? =A0I receive several > digital signals streams from two to four external boards, single- > ended, ~5 Mbps, almost zero-balanced. =A0My board has sensitive analog > and audio/video and I'd like to avoid the possibility of ground-loops, > 60 Hz hum, etc. > > I know of three methods to isolate and I list the methods and my > thoughts. > > 1. =A0I can use a capacitor in-series with each input signal and level- > shift it back so my digital ICs will properly trigger and keep the > ext_GND isolated from my sys_GND. =A0I have tested this and it's > reliable for my configuration. > > But! =A0I'm very worried about EMI and return currents. =A0If I use a > capacitor to couple the external signal in AND I don't connect > ext_GND(s) to my sys_GND, I fear that the return current from the > input signal will see an impedance discontinuity and cause me MORE EMI > headaches. =A0I reason that the current should flow in a loop and while > the capacitor isolates my two systems, the return current will still > have to go back to the original source and since my GNDs are > discontiguous, I have a high-impedance return (maybe through free > space) and this will couple more noise into my system. > > 2. =A0I can use an isolation transformer (1:1) and a capacitor on the > input side to avoid saturating the core (strip DC) and use a cap on > the output & restore the DC. > > I wonder if the capacitance between windings, other parasitics and EM > "leakage" however won't end up defeating the purpose of isolation and > will end up coupling noise from the external circuits into my system. > Since my signals are single-ended I don't have a differential receiver > to reject the common-mode noise either. > > I'm also uncertain if the return current has a path, but based on my > recollection of transformers, the load impedance is reflected back to > the source, so there is a "path" and both sides are coupled together. > > 3. =A0I can use a digital isolator (NVE, ADI) and have it straddle the > external input block and my digital system. > > The issue here is the need for power on the external input side that > would have to be isolated from the digital side. =A0I also wonder, since > the NVE/ADI parts end up using magnetic isolation techniques, will > they end up broadcasting any EM? > > Thank you! > Sam. I guess my first question is to figure out if any of this is overkill. When you say you have signals coming from "external" boards, do you mean a separate chassis? If the boards are in the same case, then proper grounding techniques should do the job. If you are sure that you need this sort of isolation there is a third choice, optical isolation. 5 Mbps is not beyond the speed of optoisolators. A quick search turns up parts rated up to 50 Mbps. The input devices require no special circuitry and output devices simply require a power supply that is separate and isolated since this becomes the only path for conducted noise. I guess my real concern is that if you are so worried about the return current and coupled EMI from the external digital signals, why don't you put the digital electronics on a separate card? That is the best way to provide proper isolation from the digital noise... at least the best first step. RickArticle: 145972
On Mar 2, 1:08=A0am, -jg <jim.granvi...@gmail.com> wrote: > On Mar 2, 6:15=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > I'm talking about the boards. =A0I get virtually no ringing with the > > slower edge rates. =A0The fastest, 20 mA/FAST, setting gives pronounced > > ringing and 16 mA has some as well. =A0They are both 2 ns or less rise > > times. =A0At 12 ns the ringing is gone and I only see the tiny notch in > > the rising edge that I am convinced is not ringing or reflection. > > It depends on your terminology. > The notch I mention below, I would call ringing, as it > comes from a LCR+Slope model. It is effectively ringing summed onto > the slowish rise time, and is not huge, but large enough to see a > slight reverse in voltage. > > > BTW, a transmission line does not ring. =A0You can get reflections, but > > unless there is some sort of feedback in your IO driver that is > > oscillating, you won't see true ringing with a transmission line... > > unless there is something with transmission lines that I didn't > > learn. =A0It is often that reflections look like ringing because they > > echo several times at lower amplitude each time around. =A0No? > > > Rick > > Just for fun, I added some guestimate numbers from what you said, and > added a probe to the driving end, and voila, guess what? > > A small notch appears, on the driving end ;) > > Which end were you probing, your end, or connector, or the customers > FPGA pin ? > > -jg The driver. Does it show up at the same time for both 8 and 12 mA drive? RickArticle: 145973
Please clarify exactly what type of signals you wish to isolate. Analog Video? Digial Video? Analog - AC with DC component? just AC? Other There are many ways to isolate...for particular type of signals... so please clarify exactly what type of signals. Yes -for digital you might try some of the AD iCoupler isolators (some even pass power 50mA to the isolated side). JoeArticle: 145974
"digitaljanitor" <b7grabn98q@sneakemail.com> schreef in bericht news:5770b06c-0a2a-4000-9545-e68e179b9dea@b9g2000pri.googlegroups.com... > All, > > Apologies for the cross-post, I know a lot of people who deal with > FPGAs are also experts with PCBs, stack-ups, high-speed layout, hoping > for some good ideas from both groups. I'm not an expert on board > design or electronics, but I'm trying to do things right from the > start... > > My issue in a nut shell: How can I properly prevent ground-loops from > external connections that interface to my board? I receive several > digital signals streams from two to four external boards, single- > ended, ~5 Mbps, almost zero-balanced. My board has sensitive analog > and audio/video and I'd like to avoid the possibility of ground-loops, > 60 Hz hum, etc. > > I know of three methods to isolate and I list the methods and my > thoughts. > > 1. I can use a capacitor in-series with each input signal and level- > shift it back so my digital ICs will properly trigger and keep the > ext_GND isolated from my sys_GND. I have tested this and it's > reliable for my configuration. > > But! I'm very worried about EMI and return currents. If I use a > capacitor to couple the external signal in AND I don't connect > ext_GND(s) to my sys_GND, I fear that the return current from the > input signal will see an impedance discontinuity and cause me MORE EMI > headaches. I reason that the current should flow in a loop and while > the capacitor isolates my two systems, the return current will still > have to go back to the original source and since my GNDs are > discontiguous, I have a high-impedance return (maybe through free > space) and this will couple more noise into my system. > > 2. I can use an isolation transformer (1:1) and a capacitor on the > input side to avoid saturating the core (strip DC) and use a cap on > the output & restore the DC. > > I wonder if the capacitance between windings, other parasitics and EM > "leakage" however won't end up defeating the purpose of isolation and > will end up coupling noise from the external circuits into my system. > Since my signals are single-ended I don't have a differential receiver > to reject the common-mode noise either. > > I'm also uncertain if the return current has a path, but based on my > recollection of transformers, the load impedance is reflected back to > the source, so there is a "path" and both sides are coupled together. > > 3. I can use a digital isolator (NVE, ADI) and have it straddle the > external input block and my digital system. > > The issue here is the need for power on the external input side that > would have to be isolated from the digital side. I also wonder, since > the NVE/ADI parts end up using magnetic isolation techniques, will > they end up broadcasting any EM? > > Thank you! > Sam. I used to apply optocouplers. For real long lines I even switched to glassfiber. petrus bitbyter
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