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 8/7/2014 5:35 PM, Frank Buss wrote: > Jon Elson wrote: >> >> 9500XL is a 3.3 V logic family that is safe for 5 V signal levels, >> if series resistance is provided, but it will not drive 5V to >> an output. So, don't expect anything to work right with 5V pull-ups >> to an output. > > Where did you read that it needs a series resistor? The famlily data > sheet says on page 12: > > | The I/Os on each XC9500XL device are fully 5V tolerant > | even though the core power supply is 3.3 volts. This allows > | 5V CMOS signals to connect directly to the XC9500XL > | inputs without damage. > > And I think it is safe to drive it as output with the pullup resistor. > The 3k3 pullup allows a current of max 1.5 mA for the 5V, which should > not cause any over voltage at the pin in output mode. > >> The 5 V tolerance is there only for connection of INPUTS to other >> circuitry. Anyway, it looks like the pull-up and pull-down >> transistors don't get cleanly off the pad when you tell it to go to >> Hi-Z. > > I changed the output slew rate from slow to fast and increased the main > clock frequency in the UCF file (someday I'll learn the timing analyzer > and how to setup proper timing constraints), now it looks like this: > > http://i.imgur.com/xtfL72j.png > > Not perfect, but should work for my project. > The effect of changing the slew rate seems to confirm the suspicion that the output switches low at the same time the tristate happens. Can you look at the fitter output to see if this is the case (look at the generated equations)? -- GaborArticle: 156976
What is the "recommended" way to do IP forking from Xilinx's repos? Not
for public distribution but to have a modified one for specific
purposes. The modifications are beyond the customisations offered by
generator.
Has anyone done it?
--
Stavros
Article: 156977
SP <sp@orbitalfox.com> wrote:
> Has anyone done it?
In case someone is wondering the same and no better answer comes I have
done the following in Vivado IDE.
* Created a new IP repo from "Manage IP"
* In the "project manager" window I clicked the "IP settings" button.
* Clicked "Add IP".
- Found the IP from Xilinx's repo (Xilinx/Vivado/201x.x/data/ip/)
* Then I could click "Edit in Packager"
Not sure if this is the best way. Kinda worked. I will write and article
about it, but I must know if there are any better ways before I do so.
--
Stavros
Article: 156978On 8/8/2014 12:09 PM, Tim Wescott wrote: > > I agree with Allan's recommendation -- get a book on logic design with > Verilog. A good book will devote at least half of the content to > language-independent issues, essentially telling you what you want to > get. The rest of the content will go into the differences between > simulation and synthesis, how to write the code for synthesis, and how to > structure your test bench to properly test the code that'll actually make > an FPGA. Most of my HDL background is with VHDL and I have only used Verilog when required. I have asked a number of times about a good Verilog reference and been repeatedly told there aren't any. Has that changed? Do you have one you like? -- RickArticle: 156979
On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote: > On 8/8/2014 12:09 PM, Tim Wescott wrote: >> >> I agree with Allan's recommendation -- get a book on logic design with >> Verilog. A good book will devote at least half of the content to >> language-independent issues, essentially telling you what you want to >> get. The rest of the content will go into the differences between >> simulation and synthesis, how to write the code for synthesis, and how >> to structure your test bench to properly test the code that'll actually >> make an FPGA. > > Most of my HDL background is with VHDL and I have only used Verilog when > required. I have asked a number of times about a good Verilog reference > and been repeatedly told there aren't any. Has that changed? Do you > have one you like? I'm not really qualified to answer that. By training I'm a designer of analog circuits, control systems, and low-level communications algorithms (i.e., detecting bits). By experience I'm all of those, but my actual customer deliverables have been primarily lines of C or C++ code; a GOOD project is one where I'm backing that up with control or comms design. I have done exactly one small job each with Verilog and VHDL, and the comment I got back from the (real) digital guys on my VHDL code was "you're a software guy, aren't you?" (well, no -- I'm an analog circuit designer who puts food on the table by writing C++ code, but I certainly LOOK like a software guy when the light is shining from a certain direction). The books that I have are "The Verilog Hardware Description Language" by Thomas & Moorby, and the IEEE Verilog Standard. Thomas & Moorby was selected because, out of the three books on the shelf at Powell's Technical Books that day in 2003, it was the one that seemed to be the most clear and informative. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156980
On 8/10/2014 3:19 PM, Tim Wescott wrote: > On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote: > >> On 8/8/2014 12:09 PM, Tim Wescott wrote: >>> >>> I agree with Allan's recommendation -- get a book on logic design with >>> Verilog. A good book will devote at least half of the content to >>> language-independent issues, essentially telling you what you want to >>> get. The rest of the content will go into the differences between >>> simulation and synthesis, how to write the code for synthesis, and how >>> to structure your test bench to properly test the code that'll actually >>> make an FPGA. >> >> Most of my HDL background is with VHDL and I have only used Verilog when >> required. I have asked a number of times about a good Verilog reference >> and been repeatedly told there aren't any. Has that changed? Do you >> have one you like? ...snip... > The books that I have are "The Verilog Hardware Description Language" by > Thomas & Moorby, and the IEEE Verilog Standard. Thomas & Moorby was > selected because, out of the three books on the shelf at Powell's > Technical Books that day in 2003, it was the one that seemed to be the > most clear and informative. The most important thing I would want from a Verilog book wasn't mentioned in your list of features of a good Verilog book, a description of the pitfalls of the Verilog language. The issues you cover are all language independent in my opinion. I once asked specifically about finding a book to cover the pitfalls and was told that none existed. I asked again a year or two ago and was told the same thing. Unfortunately I have become very accustomed to writing VHDL and have lost any strong desire to become as proficient in Verilog. If "the" book becomes available I might buy it and finish my education, but I'm not expecting that to happen. -- RickArticle: 156981
Tim Wescott <seemywebsite@myfooter.really> wrote: > On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote: (snip) >> Most of my HDL background is with VHDL and I have only used Verilog when >> required. I have asked a number of times about a good Verilog reference >> and been repeatedly told there aren't any. Has that changed? Do you >> have one you like? (snip) > I have done exactly one small job each with Verilog and VHDL, and the > comment I got back from the (real) digital guys on my VHDL code was > "you're a software guy, aren't you?" (well, no -- I'm an analog circuit > designer who puts food on the table by writing C++ code, but I certainly > LOOK like a software guy when the light is shining from a certain > direction). > The books that I have are "The Verilog Hardware Description Language" by > Thomas & Moorby, and the IEEE Verilog Standard. Thomas & Moorby was > selected because, out of the three books on the shelf at Powell's > Technical Books that day in 2003, it was the one that seemed to be the > most clear and informative. Yes, and I would recommend it, too. You want a nice reference that you can look something up in when you need to. Some will probably complain that it isn't up to date with the newer standards, but most of the time that isn't a problem. I like writing structural verilog, using continuous assignment and module references, except that registers are in behavioral verilog. I put the registers into a module, and just reference that when I need one. (Like reg8 for an 8 bit register.) Some people like behavioral verilog, as it is more similar to writing software, but to me that distracts from the fact that it isn't software. Like analog circuits and digital logic, you have to remember that everything happens all the time, not sequentially like in C. If you think sequentially, you will write poor and inefficient verilog (or VHDL). For those who grew up in the days of TTL (or MSI CMOS), thinking about wiring up gates, I believe it is fairly easy to learn to think in verilog. Think about wires and gates. (And it shouldn't be so hard for analog designers.) But people used to thinking sequentially, like writing a C program, will have a harder time. Now, consider the design of a digital clock. Years ago, you would wire up some 7490 and 7492 counters, some 7447 (or maybe 7441) decoders, and let them count away. A little more recently, it might be done with a microprocessor or microcontroller, probably multiplexing the display. (That is, for those that don't use an LSI clock chip.) In the case of a digital clock, you don't need anywhere near the 10's of MHz that TTL can run at, and there is plenty of time to update the display in a software loop. Both make inefficent use of the available hardware resources, but that is fine. -- glenArticle: 156982
> > What are you using for an LVDS receiver? (Any equalisation?) > It is a Cyclone IVGX SerDes. Yes, equalization is active (at a medium > setting). > I will play around a little bit with this settings (unfortunately > the compile-time is quite long). It turned out that the equalization was too high. When increasing the setting, things got worse. When setting it to "low", things work perfect without any errors... I think the great effects of touching the cable can be explained with the weak twisting of the pairs. Regards, ThomasArticle: 156983
In article <ls83nl$34c$1@dont-email.me>, SP <sp@orbitalfox.com> wrote: >What is the "recommended" way to do IP forking from Xilinx's repos? Not >for public distribution but to have a modified one for specific >purposes. The modifications are beyond the customisations offered by >generator. > We've had to do it. The general rule is to quickly throw away any use of Xilinx's "wizards" or other hold-your-hand GUIs. Get to the straight RTL and just use that. Most of Xilinx's current IP is unencrypted RTL - although buried deep within wrappers and other "wizardly" cruft. (This is generally good advise in any cases for any vendors IP, IMHO. Throw away the wizards, and GUIs that just get in the way. But I digress). Now, it's simple. Just edit the RTL as needed and continue. There's gotchas, and other things that you'll have to work through. But they're all solvable. Regards, MarkArticle: 156984
thomas.entner99@gmail.com wrote: > It turned out that the equalization was too high. When increasing the > setting, things got worse. When setting it to "low", things work perfect > without any errors... > > I think the great effects of touching the cable can be explained with the > weak twisting of the pairs. I suspect the cable looks more like a parallel ribbon cable than twisted pair. That means there could be other signals between the twisted pair and ground - eg if it turns out it goes: GND RXD D+ D- TXD VCC Any common mode currents, which there will be because your coding scheme is not DC balanced, will flow around a loop with RXD or TXD in the middle, so are likely to be inductively coupled with these wires (ie cause crosstalk). It's difficult to say what effect the inductance of this loop will have on the LVDS signal (I suspect not a huge amount, but have no numbers: it will depend on how quick the rise times are), but I wouldn't be surprised if you saw coupling into the RXD and TXD wires. Likewise, we'd have to know a bit more about the channel characteristics to predict what the likely frequency response of the channel might be (you'd model each part's LCR properties separately: hard numbers needed). I'd guess that the touching effect increases both the capacitance to ground and the inter-pair capacitance. It moves the frequency nulls around - I'm not familiar with the equalisation settings on that transceiver to know the effect of the different modes, but it's not implausible that equalisation could cope with one but not the other. In theory your transmission line should be correctly terminated so you don't need equalisation, but it very obviously isn't. TheoArticle: 156985
thomas.entner99@gmail.com wrote: > I have an LVDS related issue that drives me crazy: > There are two boards with a FPGA that are connected by a ca. > 30cm cable. Only 6 wirea are used: > GND + Power > LVDS (with embedded clock), 720Mbps > UART (Rxd + Txd) > (The cable is unshielded for flexibility reasons) > The cable is a "flat Ethernet cable" with 4 twisted pairs, > one pair is unused, one pair is LVDS, one pair is GND + Rxd > and the last is Power + TxD. Ethernet cables use pin pairs (1,2) (3,6) (4,5) and (7,8). With the usual cables, you can see the pairs, including the colors, in the connector. I have one, though, which I would call flat, and which the pairs are not visible. It is very thin and flexible, and seems to work fine for 100baseTX. I suspect the wire is much smaller than the normal Cat 5 wire. But otherwise, ethernet cables are normally rated to 100MHz. 1000baseT uses a complicated signal system on all four pairs (in both directions at the same time) to get the bits through. I wouldn't be surprised if you could get 720MHz through Cat 5 cable for 30cm, but your cable might not be quite that good. -- glenArticle: 156986
It is crucial to understand how synthesis works, but it is not necessary to= code a netlist of the HW you think will do what you want. In 20+ years of VHDL-based FPGA development, I have made behavioral mistake= s FAR more often than I have made HW design mistakes (in other words, the c= ircuit was viable and reliable, it just didn't do what I wanted it to). Writing the code such that the clock cycle behavior is at least as apparent= , if not moreso, than the HW circuit helps avoid the most common mistakes. Sure, there are cases where I have to code "closer to the HW" to get perfor= mance or utilization where I need it, but those are few and far between. To= o far to code that way all the time. Learn what behaviors infer latches (bad), registers and ram (good). Study t= he synthesis tool's examples for ram inference, but learn their behavior, n= ot so much about how they happened to code that behavior. This will let you= write portable code that will work for multiple target FPGAs. Describe the desired behavior on every clock cycle. Think in terms of behav= ior and clock cycles of latency, rather than gates and registers. The latte= r will go to pot as soon as you turn on retiming and pipelining optimizatio= ns anyway. AndyArticle: 156987
On Friday, 1 August 2014 13:53:42 UTC+2, Allan Herriman wrote: > On Thu, 31 Jul 2014 09:34:52 -0700, wabac0 wrote: >=20 >=20 >=20 > > Over the years I have taught myself Verilog and VHDL, and although I am >=20 > > quite comfortable with Verilog, I feel as though my VHDL designs are >=20 > > just not as tight as they should be. In pursuit of self-improvement, I >=20 > > am trying to find "real world" examples of professional VHDL designs >=20 > > that I can glean for hints on how to make my designs better. I have rea= d >=20 > > many, many books and analyzed some projects on opencores, but everythin= g >=20 > > that I have seen seems a bit lacking. I am hoping that the >=20 > > comp.arch.fpga community might share a few examples of solid VHDL >=20 > > designs that I can review. Incomplete designs are fine, as long as I ca= n >=20 > > get a feel for how you are accomplishing things. Bear in mind that I >=20 > > will not critique your design, and am not interested in participating i= n >=20 > > The Great HDL Debate MMXIV: Part XXIII. I need to continue to use both >=20 > > VHDL and Verilog. >=20 >=20 >=20 >=20 >=20 > Here's an example of mine from 2002 or so. >=20 >=20 >=20 > http://fractional-divider.tripod.com/fracn20.zip >=20 >=20 >=20 > It shows how to use VHDL in a way that would be difficult to mimic in=20 >=20 > Verilog, and may seem strange to Verilog coders. As such, it may be=20 >=20 > useful as a learning exercise. >=20 >=20 >=20 > I have a Verilog version on that same web page, but it uses a Perl script= =20 >=20 > to write the Verilog, customised by some command line parameters. The=20 >=20 > VHDL version customises itself from its generics at elaboration time. >=20 >=20 >=20 > Most of the code consists of functions that in many cases use floating=20 >=20 > point numbers to produce a bunch of constants that control the=20 >=20 > (relatively small) chunk of RTL at the bottom of the file. >=20 >=20 >=20 > BTW, it isn't representative of code I write now, but it is still useful= =20 >=20 > as a tool torture test. >=20 >=20 >=20 > Regards, >=20 > Allan I'm interested in looking at this, but when I click on the link I get the f= ollowing message: This file is hosted by Tripod, a Lycos=AENetwork Site, and is not available= for download. Please check out Tripod's Help system for more information a= bout Remote Loading and our Remote Loading policy.Article: 156988
On Wed, 13 Aug 2014 00:18:49 -0700, ajpkane wrote: > On Friday, 1 August 2014 13:53:42 UTC+2, Allan Herriman wrote: >> On Thu, 31 Jul 2014 09:34:52 -0700, wabac0 wrote: >> >> >> >> > Over the years I have taught myself Verilog and VHDL, and although I >> > am >> >> > quite comfortable with Verilog, I feel as though my VHDL designs are >> >> > just not as tight as they should be. In pursuit of self-improvement, >> > I >> >> > am trying to find "real world" examples of professional VHDL designs >> >> > that I can glean for hints on how to make my designs better. I have >> > read >> >> > many, many books and analyzed some projects on opencores, but >> > everything >> >> > that I have seen seems a bit lacking. I am hoping that the >> >> > comp.arch.fpga community might share a few examples of solid VHDL >> >> > designs that I can review. Incomplete designs are fine, as long as I >> > can >> >> > get a feel for how you are accomplishing things. Bear in mind that I >> >> > will not critique your design, and am not interested in participating >> > in >> >> > The Great HDL Debate MMXIV: Part XXIII. I need to continue to use >> > both >> >> > VHDL and Verilog. >> >> >> >> >> >> Here's an example of mine from 2002 or so. >> >> >> >> http://fractional-divider.tripod.com/fracn20.zip >> >> >> >> It shows how to use VHDL in a way that would be difficult to mimic in >> >> Verilog, and may seem strange to Verilog coders. As such, it may be >> >> useful as a learning exercise. >> >> >> >> I have a Verilog version on that same web page, but it uses a Perl >> script >> >> to write the Verilog, customised by some command line parameters. The >> >> VHDL version customises itself from its generics at elaboration time. >> >> >> >> Most of the code consists of functions that in many cases use floating >> >> point numbers to produce a bunch of constants that control the >> >> (relatively small) chunk of RTL at the bottom of the file. >> >> >> >> BTW, it isn't representative of code I write now, but it is still >> useful >> >> as a tool torture test. >> >> >> >> Regards, >> >> Allan > > I'm interested in looking at this, but when I click on the link I get > the following message: > > This file is hosted by Tripod, a Lycos®Network Site, and is not > available for download. Please check out Tripod's Help system for more > information about Remote Loading and our Remote Loading policy. I just tested it and it downloaded fine for me. It sounds like a problem at your end. I emailed a copy to the email address in the header of your post. Regards, AllanArticle: 156989
On 8/10/2014 3:33 PM, rickman wrote: > On 8/10/2014 3:19 PM, Tim Wescott wrote: >> On Sun, 10 Aug 2014 14:20:09 -0400, rickman wrote: >> >>> On 8/8/2014 12:09 PM, Tim Wescott wrote: >>>> >>>> I agree with Allan's recommendation -- get a book on logic design with >>>> Verilog. A good book will devote at least half of the content to >>>> language-independent issues, essentially telling you what you want to >>>> get. The rest of the content will go into the differences between >>>> simulation and synthesis, how to write the code for synthesis, and how >>>> to structure your test bench to properly test the code that'll actually >>>> make an FPGA. >>> >>> Most of my HDL background is with VHDL and I have only used Verilog when >>> required. I have asked a number of times about a good Verilog reference >>> and been repeatedly told there aren't any. Has that changed? Do you >>> have one you like? > > ...snip... > >> The books that I have are "The Verilog Hardware Description Language" by >> Thomas & Moorby, and the IEEE Verilog Standard. Thomas & Moorby was >> selected because, out of the three books on the shelf at Powell's >> Technical Books that day in 2003, it was the one that seemed to be the >> most clear and informative. > > The most important thing I would want from a Verilog book wasn't > mentioned in your list of features of a good Verilog book, a description > of the pitfalls of the Verilog language. The issues you cover are all > language independent in my opinion. I once asked specifically about > finding a book to cover the pitfalls and was told that none existed. I > asked again a year or two ago and was told the same thing. > A decent reference for this is Sutherland and Mills "Verilog and SystemVerilog Gotchas". Regards, ChrisArticle: 156990
thomas.entner99@gmail.com wrote: > The cable is a "flat Ethernet cable" with 4 twisted pairs, one pair is > unused, one pair is LVDS, one pair is GND + Rxd and the last is Power + > TxD. This is NOT LVDS! The D stands for Differential! You use one wire of the pair for the true signal, one wire for the complement signal. I don't even know how you do single-ended with LVDS receivers, but it won't work well, as you clearly have discovered. You can still use LVDS the right way with 3 pairs. One pair is power & ground, one is the Rxd true/compl pair, the other is the Txd true/compl pair. JonArticle: 156991
Den onsdag den 13. august 2014 23.02.24 UTC+2 skrev Jon Elson: > thomas.entner99@gmail.com wrote: > > > > > > > The cable is a "flat Ethernet cable" with 4 twisted pairs, one pair is > > > unused, one pair is LVDS, one pair is GND + Rxd and the last is Power + > > > TxD. > > This is NOT LVDS! The D stands for Differential! You use one wire of the > > pair for the true signal, one wire for the complement signal. I don't even > > know how you do single-ended with LVDS receivers, but it won't work well, > > as you clearly have discovered. > > > > You can still use LVDS the right way with 3 pairs. One pair is power & > > ground, one is the Rxd true/compl pair, the other is the Txd true/compl > > pair. > afaiu, he is using one pair for LDVS, the other rx/tx is single ended uart paired with gnd and power. So the wiring is ok -LasseArticle: 156992
Jon Elson <jmelson@wustl.edu> wrote: > This is NOT LVDS! The D stands for Differential! You use one wire of the > pair for the true signal, one wire for the complement signal. I don't even > know how you do single-ended with LVDS receivers, but it won't work well, > as you clearly have discovered. > > You can still use LVDS the right way with 3 pairs. One pair is power & > ground, one is the Rxd true/compl pair, the other is the Txd true/compl > pair. The OP stated he has one LVDS pair (D+ and D- twisted), and two UART signals (RXD and TXD). The UART signals aren't sent by LVDS, they're just other things down the same cable. I assume the OP's LVDS is unidirectional (or else there would be other issues). The OP's situation of having RXD+GND and TXD+VCC pairs, rather than RXD+TXD and GND+VCC, is probably slightly better but it's marginal at typical UART speeds (and as always depends on the setup - as we've discovered the 'twisted pair' isn't). You can connect single-ended into an LVDS receiver by grounding the negative input (if you have positive and negative voltage rails) or putting it mid-range via a resistive divider (on a single supply arrangement) but you've just halved your signal amplitude (and thus differential SNR) - and of course you have no protection from common-mode noise. TheoArticle: 156993
Mark Curry <gtwrek@sonic.net> wrote:
> We've had to do it. The general rule is to quickly throw away any use
> of Xilinx's "wizards" or other hold-your-hand GUIs. Get to the
> straight RTL and just use that. Most of Xilinx's current
> IP is unencrypted RTL - although buried deep within wrappers
> and other "wizardly" cruft.
Seems a good advice if one is headed towards in-depth understanding of
the IP they are using. But what about situations where this is not
needed?
Personally I tend to want to be in the fist group, but I am curious for
the other reasons.
I take it you didn't throw away the tcl templates?
> Now, it's simple. Just edit the RTL as needed and continue.
This is the juicy part -- where? How do you re-include these in the rest
of the design? What about keeping it flexible and future proof?
--
Stavros
Article: 156994In article <lsigti$lvp$1@dont-email.me>, SP <sp@orbitalfox.com> wrote: >Mark Curry <gtwrek@sonic.net> wrote: >> We've had to do it. The general rule is to quickly throw away any use >> of Xilinx's "wizards" or other hold-your-hand GUIs. Get to the >> straight RTL and just use that. Most of Xilinx's current >> IP is unencrypted RTL - although buried deep within wrappers >> and other "wizardly" cruft. > >Seems a good advice if one is headed towards in-depth understanding of >the IP they are using. But what about situations where this is not >needed? We only edit Xilinx IP when we're forced to. One case, was to fix a bug that we just couldn't convince them was indeed a bug. It was just easier to fix it ourselves. For another it was to add features that were not present. >Personally I tend to want to be in the fist group, but I am curious for >the other reasons. > >I take it you didn't throw away the tcl templates? "tcl templates"? Don't even know what you're referring to here. Perhaps something in Vivado? Either way, we don't use tcl templates. We run vivado in non-project mode with our own tcl scripts. >> Now, it's simple. Just edit the RTL as needed and continue. > >This is the juicy part -- where? How do you re-include these in the rest >of the design? What about keeping it flexible and future proof? We copy over all IP into our revision control repository (regardless of whether we're editting it or not). This future proofs it against random updates from the vendor (oh pcore version x.x.x is no longer supported/ available by tool z.z.z...) RTL is RTL. Regards, MarkArticle: 156995
Theo Markettos wrote: > The OP stated he has one LVDS pair (D+ and D- twisted), and two UART > signals > (RXD and TXD). The UART signals aren't sent by LVDS, they're just other > things down the same cable. OK, he confused me with the UART data signals. Well, one other thing, is he terminating the LVDS with a resistor matching the characteristic impedance of the cable? I'll bet he isn't, his results would VERY likely match what he describes. We use 100 Ohm resistors, they are close enough. For best results, tune between 110 and 120 Ohms for minimum reflection. JonArticle: 156996
hi Jon, Jon Elson <jmelson@wustl.edu> Wrote in message: > Well, one other thing, is he terminating the LVDS with a resistor matching > the characteristic impedance of the cable? I'll bet he isn't, his results > would VERY likely match what he describes. We use 100 Ohm resistors, they > are close enough. For best results, tune between 110 and 120 Ohms for > minimum reflection. from the OP: I tried changing and even removing the termination resistors, this did not change the behavior at all. I have changed both boards, it is really the cable that makes the difference. BTW, removing the terminators on an LVDS - single drop - line is *never* a good idea. LVDS drivers are current sources and the receiver may simply not tolerate the differential swing on it's big input impedance. I did not understand how the op solved his problem changing receiver equalization, he clearly mentioned some cables did work ok without the need to change equalization... AlArticle: 156997
Wow, quite some discussion going on here... (I have considered this myself = "solved" and working on other stuff again.) To give some comments: Yes, we use 100 ohm termination, in fact on both sides of the cable. I trie= d to remove the termination on both sides (but I don't think I have removed= both sides at the same time - would not really make sense...). I have also= checked with a multimeter and got the correct values (e.g. 50 ohm, when bo= th are mounted and cable connected.) My conclusion was, that with the original (quite strong) equalizer setting = things were barely working (even with "good" cables I got an transmission e= rror here and then while "bad" cables resulted in errors all over). I think= it was simply to strong for the short cable distance. With the lowest poss= ible equalizer setting we have not seen any transmission errors anymore wit= h any combination of boards and cables. I had dismantled one cable and found that the (while they were really twist= ed) the turn rate was very low, about 1 to 2 full turns about the complete = length. This might be good enough for long ethernet cables, but I can imagi= ne that this short length make some of them almost behave like untwisted c= ables with quite some cross talk. This is my explanation why touching the u= ntwisted wires had some influence although I am still surprised that the ef= fect was such a drastic improvement. What I still cannot understand is why the (in my opinion) much more dramati= c change of removing the termination resistors had no influence (not good n= or bad) on this obviously barely working system while the touching had. Regards, ThomasArticle: 156998
Hi Thomas, thomas.entner99@gmail.com wrote: [] > To give some comments: Yes, we use 100 ohm termination, in fact on both > sides of the cable. I tried to remove the termination on both sides (but I > don't think I have removed both sides at the same time - would not really > make sense...). I have also checked with a multimeter and got the correct > values (e.g. 50 ohm, when both are mounted and cable connected.) I do not understand why you need termination at both ends. There are two aspects when terminating an LVDS line: 1. line impedence matching. 2. provide a load for a current source. In both cases it does not make too much sense to have a termination at the source. > My conclusion was, that with the original (quite strong) equalizer setting > things were barely working (even with "good" cables I got an transmission > error here and then while "bad" cables resulted in errors all over). I think > it was simply to strong for the short cable distance. With the lowest > possible equalizer setting we have not seen any transmission errors anymore > with any combination of boards and cables. Did you see your signal on the scope *after* the receiver for both a /good/ and /bad/ cable? Do you have an eye diagram? > > I had dismantled one cable and found that the (while they were really > twisted) the turn rate was very low, about 1 to 2 full turns about the > complete length. This might be good enough for long ethernet cables, but I > can imagine that this short length make some of them almost behave like > untwisted cables with quite some cross talk. twist per meter is usually specified in the cable datasheet; considering the rate you're working at I'd seriously consider the cable as a fundamental part to be analyzed. > This is my explanation why > touching the untwisted wires had some influence although I am still > surprised that the effect was such a drastic improvement. I would not call 'improvement' something that you cannot justify or explain. Since you do not know what is going on, it is *very* possible the problem is simply hidden for a various combination of causes and will likely reappear later on. > What I still cannot understand is why the (in my opinion) much more dramatic > change of removing the termination resistors had no influence (not good nor > bad) on this obviously barely working system while the touching had. IMO your connection is far from being a proper one, with serious matching issues and a very scattered amount of information to analyze. With these basis any conclusion on 'working' or 'not working' are pointless at best. If you don't have a model to explain why it works and why it doesn't, your likely exposed to see the issue again later and thanks to Murphy's law it would be right two days before shipping! If you want to seriously remove your issues you need to be able to explain every detail, spot the cause and remove it. Otherwise it would just be another piece of guesswork. AlArticle: 156999
On 17/08/14 17:57, alb wrote: > Hi Thomas, > > thomas.entner99@gmail.com wrote: > [] >> To give some comments: Yes, we use 100 ohm termination, in fact on both >> sides of the cable. I tried to remove the termination on both sides (but I >> don't think I have removed both sides at the same time - would not really >> make sense...). I have also checked with a multimeter and got the correct >> values (e.g. 50 ohm, when both are mounted and cable connected.) > > I do not understand why you need termination at both ends. There are two > aspects when terminating an LVDS line: > > 1. line impedence matching. > 2. provide a load for a current source. > > In both cases it does not make too much sense to have a termination at the > source. See "LVDS Owner's Manual Design Guide , 4th Edition" http://www.ti.com/lit/ml/snla187/snla187.pdf > Did you see your signal on the scope *after* the receiver for both a /good/ > and /bad/ cable? Do you have an eye diagram? Ensure the probes don't disturb the signal - which is easier said than done.
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