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
We had to make a schematic get the edif file and then make a blackbox for VHDL. I'm not sure you still have to do that or not. Steve CArticle: 42776
"Tuomo Auer" <tuomo.auer@removethis.hut.fi> schrieb im Newsbeitrag news:FqcA8.1240$Su1.388973@reader1.news.jippii.net... > I think you should use IN5817 since it is a shottky diode. 1N4002 is a > regular silicon diode. Forward voltage drop over a shottky is around > 0.15..0.25 volts while it is 0.55..0.65 volts for a regular diode. And for > voltage detection there are two diodes in series in the programming cable... Why not just omit this more ore less useless stuff? Did that, worked fine (more than once). Just take a 74HC125, connect it according to the schematic (ommit those RC- stuff). Just add a 100nF cap. Go. -- MfG Falk P.S. Always remeber. Fool-proove things are only used by fools.Article: 42777
On 2 May 2002 02:28:34 -0700, point308@hotmail.com (Mark McMahon) wrote: >Hello all, > >I've been trying to make my own Xilinx parallel cable III using the >available schematics. My board is double sided, with a male parallel >connector so I can use any parallel cable. > >The differences between my PCB and the original xilinx one are: >(1) D6, Busy and PE are connected on the board, not at the computer >end of the cable. >(2) The tristate buffer is 74HC125A >(3) The diode are 1N4002, not 1N5817. > >I've tried two different board layouts, both of which work sometimes, >depending on which direction the wind is blowing. >I've tried both linear and switch mode power supplies. >If anyone else has successfully implemented this design I would >appreciate some pointers in the right direction. > >Thanks for your help. >Mark. (sigh) This topic pops up on a fairly regular basis. IMHO, the design of the cable is flawed. They put noise filter caps on the buffer outputs, and they should be on the inputs. Also, any glitch on the clock will confuse the chain. There should be hysteresis on the clock buffer. I insert series-pairs of 74HCT14s in front of the TCK, TDI, and TMS buffers, and put a 68pf filter cap on the TCK connection to the parallel port connector (at the input of the first HCT14). Like you, I connect D6, Busy, and PE at my target. Use a schottky diode, not a 1N4002. My version of the download cable works first time, every time, even with long cables to the PC. =================================== Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 42778
rickman wrote: > > I have been trying to get my hands on some pieces of XC2S150E-6FG456I > for over a month. I am told that they will not be shipping until June > and I need to get about four pieces for prototypes in a month. I can > buy the commercial temp versions, but we need the industrial temp > versions for this version of the board. And why not take a bigger one for the prototypes ? cheersArticle: 42779
Falk Brunner wrote: > Arent the industrial temp. chips not just the same as the commercial ones, > exept that they are tested! > selected to run at higher tmeperatures (slower > transistors) at the same speed as the commercial ones? > > Yes, this is all a little bit experimental and not fully covered by the > datasheets. And not tested by the manufacturer ! Not all parameters scale the same way with temperature. The more we add clever compensation tricks, the less obvious becomes the behavior at elevated (or lower) temperature. So you should be aware that you stick your head out when you use commercial parts slightly downgraded for the industrial temp range. It will work most of the time, but not always... Peter Alfke, Xilinx ApplicationsArticle: 42781
Exactly how does this help if the commercial temp chips are not available? Falk Brunner wrote: > > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag > news:3CD16253.FD3CF44A@yahoo.com... > > > > Another way would be to use a more available commercial > > > temp chip, and test 10 boards at a time in an environment > > > chamber. > > > > That might be possible, but I am being told that the commercial temp > > chips that I expected to be receiving in a few weeks are also not > > available until August. > > Arent the industrial temp. chips not just the same as the commercial ones, > exept that they are selected to run at higher tmeperatures (slower > transistors) at the same speed as the commercial ones? > So IMHO there are ways to overcome the problem for the prototypes. If your > timing analyzer tells you, a commercial chip runs @ 120 Mhz, this can maybe > translated to 100MHz operation of a industrial version. You could also > tweeak the core voltage to the upper end (+5%) to do you test and "simulate" > the industrial versions. Or just test on lower temperatures, extrapolating > the (unfurunately not available) industrial speed grades. > Yes, this is all a little bit experimental and not fully covered by the > datasheets. > But as Peter said. > "No Guts, no glory" > > -- > MfG > Falk -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42782
Peter Alfke wrote: > > Rick, > I look at screw-ups as an opportunity to improve, and I will use this > unfortunate incident for that purpose. > Meanwhile, good luck with your project. > Let us know if you are still counting on the '150E part in I-grade, so we > can get you one at the earliest moment. > Peter Yes, I still need the 150E in both the commercial temp range and the industrial temp range. > ============================== > rickman wrote: > > > Peter, > > > > I apologize if you feel that I was "shooting the messenger". I was > > simply stating the case as I view it from this end. You may feel that > > Xilinx only has one story about available parts, but obviously there are > > many "views" or "snapshots" of this "one story". As I said, you are the > > first person of the 5 or 6 that I have had contact with in this matter > > that has said that parts will not be available until September. If > > there is only "one story", then where are the app engineer, the disti > > FAE and the disti inside sales person getting their info? > > > > I appreciate your help on the coolrunner parts. As it turned out, there > > was some internal confusion at Xilinx and the disti on the availability > > of that part based on changing plans that were not well communicated to > > the supply chain. Some members of the disti chain were using year old > > documentation when they were advising me to switch to the CS280 > > package. But this shows that there are some significant problems with > > disemination of info on new products from Xilinx. > > > > I would hope that in a company the size of Xilinx, there would be forces > > acting to build consistency and completeness to each development > > effort. My observation, after some 12 years of using Xilinx parts and > > using Xilinx software is that the company has many departments that > > march to different drummers. This is not meant to be a negative > > criticism, but rather a suggestion as to how to improve the company. > > Certainly Xilinx is not unique in this regard. But just like there are > > many, many burger joints that just sell burgers and there is only one > > McDonald's that is the same in every city in America - there are any > > number of semiconductor companies that sell silicon, but there are few > > that provide a consistant, reliable and complete program of sales and > > support. Certainly Xilinx has improved over the years in many > > respects. But new product introduction and dissemination of information > > to distribution still has a few significant wrinkles. This is evidenced > > by the problems I had getting correct information on both the Coolrunner > > and the SpartanII-E parts. > > > > Peter Alfke wrote: > > > > > > Well Rick, I just tried to be helpful, the same way I helped you with > > > the CoolRunner parts ( yes, that was me contacting CPLD marketing). > > > And you are right in saying that Xilinx has many employees, almost > > > 3000. > > > > > > But we have only one story about available parts, and only slight > > > differences in aggressive or conservative estimates about non-existent > > > parts. > > > > > > Unfortunately, you were mislead to order a non-existent part that > > > clearly was not even in our pricebook. If it isn't in the price book, > > > it does not exist! > > > > > > Somebody (not you, Rick) made a mistake, and I can only suggest the > > > alternatives I mentioned before ( plus of course a switch to > > > Virtex150. ) > > > Your power supply situation is unfortunate. > > > > > > I only jumped in when I sensed your frustration and anger. > > > Don't shoot the messenger! > > > I may already be in trouble with Marketing and Insight... > > > > > > Peter Alfke > > > =========================================== > > > rickman wrote: > > > > > > > Peter Alfke wrote: > > > > > > > > > > Here is the straight story: > > > > > > > > > > The XC2S150E has not even been released to production, and is not > > > > in any > > > > > pricebook. Your distributor made a big mistake in quoting you that > > > > part. > > > > > No wonder you are annoyed. > > > > > > > > I am not so sure that this is the "straight" story. I think that > > > > Xilinx > > > > has many employees and many different "straight" stories. > > > > > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42783
emanuel stiebler wrote: > > rickman wrote: > > > > I have been trying to get my hands on some pieces of XC2S150E-6FG456I > > for over a month. I am told that they will not be shipping until June > > and I need to get about four pieces for prototypes in a month. I can > > buy the commercial temp versions, but we need the industrial temp > > versions for this version of the board. > > And why not take a bigger one for the prototypes ? > cheers Because these are prototype units, not lab queens. We will be doing our initial testing and then ship the units to customers. Once in the field, we will have to support these chips until the end of the product life which I expect to be some 5 years or more. Since there will be many dozen bit files for the FPGA, I would hate to have to develop and test each bit file on two different chips! -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42784
Hal Murray wrote: > Ever since that day, "Can you get samples?" was our code word > for "Does it really exist?" If Steve could get samples, I > was happy using it in a design and he was happy too, knowing > that he wouldn't get stuck trying to locate an impossible part > while everybody was breathing down his neck. > > "Samples in hand" has been my rule of thumb ever since. Several > times I have passed it on to new people. If you required samples in hand before using a product, you would never design in a Xilinx part. Xilinx does not sample their FPGAs, according to my FAE. That is why I asked for and received a quote with both price and delivery. It is not often that a vendor will quote you delivery on a non-existent part. However, that was not good enough in this case. Someone made a mistake or there was a wire crossed somewhere, so I got bad information that said I could go ahead and design in the XC2S150E. > Obviously, if you have a good relationship with a vendor or > distributor you can sensibly stick your neck out farther. > But it takes a while to establish that trust. I have asked my vendor via email what happened. We will see about the response. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42785
I don't think that's an excuse for messing up the datasheet. How many people will actually read the library guide compared to the datasheet? Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) hamish@cloud.net.au wrote: > > Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: > > One problem I had a while ago with a Spartan-II datasheet was it didn't > > say that Spartan-II IOB tri-state buffers are active low or high. > > You should have read the libraries guide - it's the data sheet for > the primitives in the library. > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 42786
turn on IOBDELAY for the input delay in the IOB check up the constraint guide, there are more option NET "I_MBR_*_DATA[*]" IOBDELAY = BOTH; pyng kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0205011748.6a41a9e5@posting.google.com>... > Does anyone know how to get rid of the flops in the IOBs? The mapper > default is supposed to exclude them but low and behold, when I view > the floor plan, I see them being used. > > Another question- does anyone know how to turn on the programmable > delay on the input path of the IOB? I'm trying to solve a nasty clock > skew problem. > > Thanks!Article: 42787
Hi Manfred, My output frequency range is very small... between about 31.5MHz and 32.5Mhz, although I need mHz precision. It should use a 5MHz reference signal. Adrian > Hi Adrian, > I developed a digital PLL some years ago > and found some unknown tricks. > Maybe I can help you. > What is your desired output frequency range ? > > -Manfred > > > > "Noddy" <g9731642@campus.ru.ac.za> schrieb im Newsbeitrag > news:1019660268.49750@turtle.ru.ac.za... > > Hi, > > > > I am trying to design a high precision (30 bit) frequency synthesiser > inside > > a Spartan II. Of course, normal way to do this is with a charge pump, > > voltage controlled oscillator and a phase lock loop. > > > > Can anyone point me to some good references? I have a very high precision > > 5Mhz which is generated from a hydrogen maser and will be used as the > input > > clock signal. > > > > thanks > > adrian > > > > > > > >Article: 42788
Hello, The new website is http://www.timinganalyzer.net There is also a message board at http://www.timinganalyzer.net/wwwboard The new email is: support@timinganalyzer.net The next version beta 0.71 which will be released soon (within a week or so) includes the first release of a processor support package. With one click, you can draw any sequence of read and write cycles complete with manufacturer delays and constraints. I have started with MC68LC302 Microcontroller. There is an app note on the website which describes the code used in the script and shows users how to make their own models or extend an existing model. Check out the new website when you get a chance. Dan FabrizioArticle: 42789
Austin - On Thu, 02 May 2002 07:31:49 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >Bob, > >The emperor never really had clothes, did he? You've crossed the line from spirited argument to ad hominem attack. Shame on you. Bob Perlman ----- Cambrian Design Works http://www.cambriandesign.com >We never offered a silicon differential driver until Virtex II. > >The LVPECL is a clever use of two single ended drivers, with three external resistors, two >series 100 ohm, and one parallel 187 ohm. > >Looks like, smells like, and is two single ended drivers. Just that simple. If you want to >point out how the two single ended drivers are not a perfectly balanced, low bounce >differential driver, please do so without implying that someone here in IC design was doing a >lousy job. > >Other than that, sounds like we are in "violent agreement." > >Austin > > > >Bob Perlman wrote: > >> Austin - >> >> I give, I give! You've managed to convince me that Xilinx has >> designed a differential transmitter that has poor delay matching, lots >> of shoot-through current, high I/O capacitance, and requires three >> external resistors at the driver end. >> >> Nevertheless, I'm sure it's a wonderful driver. >> >> Bob Perlman >> ----- >> Cambrian Design Works >> http://www.cambriandesign.com >> >> On Wed, 01 May 2002 12:54:42 -0700, Austin Lesea >> <austin.lesea@xilinx.com> wrote: >> >> > http://www.support.xilinx.com/xapp/xapp133.pdf >> > >> >See page 32 of the pdf file. >> > >> >Austin >> > >> >Bob Perlman wrote: >> > >> >> Austin - >> >> >> >> On Wed, 01 May 2002 11:07:53 -0700, Austin Lesea >> >> <austin.lesea@xilinx.com> wrote: >> >> >> >> >Bob, >> >> > >> >> >Because the LVPECL uses a resitor network to set the levels (r's in series, r's in >> >> >parallel). >> >> >> >> What resistor networks? The Spartan IIE data sheet says that you >> >> connect 100 ohms across the rails. Where are the other resistors? >> >> >> >> Bob Perlman >> >> ----- >> >> Cambrian Design Works >> >> http://www.cambriandesign.com >> >> >> >> >Also, each IO has the capacitive load of the pin (~ 10 pF) so each IO must charge, and >> >> >discharge that capacitance. Charging lowers Vcco (Vcco bounce) and discharging raises >> >> >ground (ground bounce). They don't cancel either. >> >> >> >> >Austin >> >> > >> >> >Bob Perlman wrote: >> >> > >> >> >> Austin - >> >> >> >> >> >> I think we're going in circles here. I mentioned in my first post >> >> >> that the cancellation wouldn't be perfect, but that there would be >> >> >> some, and that I'd expect it to be significant. >> >> >> >> >> >> I can agree with your results if: >> >> >> >> >> >> (a) the true and complement transitions are significantly skewed (bad >> >> >> news for the receiver) >> >> >> >> >> >> (b) crossover current is a significant fraction of the current being >> >> >> sourced or sunk by the driver through the I/O pin, and lasts for a >> >> >> significant fraction of the rise/falltime. ( I thought that this >> >> >> wasn't the case for modern driver designs. Can you give more >> >> >> information on duration/amplitude?) >> >> >> >> >> >> (c) both. >> >> >> >> >> >> Can you clarify something? You've said that: >> >> >> - driver impedance is 7 ohms >> >> >> - drivers switch from rail to rail >> >> >> >> >> >> How do 7-ohm rail-to-rail drivers connected to 3.3V produce 0.85V >> >> >> across a 100 ohm load? >> >> >> >> >> >> Bob Perlman >> >> >> ----- >> >> >> Cambrian Design Works >> >> >> http://www.cambriandesign.com >> >> >> >> >> >> On Wed, 01 May 2002 07:55:38 -0700, Austin Lesea >> >> >> <austin.lesea@xilinx.com> wrote: >> >> >> >> >> >> >Bob, >> >> >> > >> >> >> >Simple. The outputs pull all the way to Vcc, and to ground. The switches are not >> >> >> >current sources at all, but on and off switches with ~ 7 ohms on resistance. The >> >> >> >current is going to flow through the IO pin, through to the ground connections, and >> >> >> >the Vcco connections. Just because one is going up when the other is going down >> >> >> >doesn't mean they will cancel: the delay from the pad to the package pin (25 ps to >> >> >> >125 ps), and to the external resistors is slightly different for each. The loading >> >> >> >is slightly different on each as a result. As well, there is a crossover current in >> >> >> >a CMOS output driver that flows from Vcco to ground when switching hi, or low, and >> >> >> >that is unaffected by this arrangement. >> >> >> > >> >> >> >So, the lab explains exactly what we expect to happen. >> >> >> > >> >> >> >I agree that mysteries are a bad thing, and we always drill down until we explain a >> >> >> >result completely. >> >> >> > >> >> >> >Austin >> >> >> > >> >> >> > >> >> >> >Bob Perlman wrote: >> >> >> > >> >> >> >> Austin - >> >> >> >> >> >> >> >> I know they're conventional single-ended I/Os; I thought I made that >> >> >> >> clear in my analysis (I assumed that the drivers both source and sink >> >> >> >> current; real PECL drivers only source current). I'm not sure why >> >> >> >> you mentioned LVDS drivers, but they also source and sink. >> >> >> >> >> >> >> >> If you're not seeing lower ground bounce for Spartan IIE >> >> >> >> differerential LVPECL in the lab, it would be useful to figure out >> >> >> >> why. If you're not seeing lower ground bounce, I have to wonder if >> >> >> >> the true and complementary transitions are simultaneous or >> >> >> >> near-simultaneous. If they're not, that could spell big trouble for >> >> >> >> the receiver. >> >> >> >> >> >> >> >> When lab results are counter-intuitive, it pays to find out why. >> >> >> >> >> >> >> >> Bob Perlman >> >> >> >> ----- >> >> >> >> Cambrian Design Works >> >> >> >> http://www.cambriandesign.com >> >> >> >> >> >> >> >> On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea >> >> >> >> <austin.lesea@xilinx.com> wrote: >> >> >> >> >> >> >> >> >Bob, >> >> >> >> > >> >> >> >> >These are still plain old single ended IOs, and as measured in the lab, there is >> >> >> >> >virtually no difference in ground bounce from a regular single ended IO. >> >> >> >> > >> >> >> >> >LVDS in Virtex II and Virtex II Pro are current sink and source differential >> >> >> >> >drivers, and there is actually a large benefit from such drivers. >> >> >> >> > >> >> >> >> >Austin >> >> >> >> > >> >> >> >> >Bob Perlman wrote: >> >> >> >> > >> >> >> >> >> Austin - >> >> >> >> >> >> >> >> >> >> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea >> >> >> >> >> <austin.lesea@xilinx.com> wrote: >> >> >> >> >> >> >> >> >> >> >Bob, >> >> >> >> >> > >> >> >> >> >> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there >> >> >> >> >> >is no benefit from differential switching as regards to ground bounce. Each >> >> >> >> >> >single ended IO is already switching rail to rail, and driving hard. Thus >> >> >> >> >> >even though some of the current flows out comes back in on the other pin, a >> >> >> >> >> >lot of current is flowing through power and ground. >> >> >> >> >> > >> >> >> >> >> >Austin >> >> >> >> >> >> >> >> >> >> The original poster wanted to use Spartan IIE which, if I'm reading >> >> >> >> >> the data sheet correctly, supports LVPECL differential outputs >> >> >> >> >> terminated with 100 ohms across the two signals. >> >> >> >> >> >> >> >> >> >> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is >> >> >> >> >> 1.06-1.43V, or~ 1.25V typical. This means that the current through >> >> >> >> >> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA. >> >> >> >> >> >> >> >> >> >> When the differential signal switches, one driver switches from source >> >> >> >> >> to sink, while the other switches from sink to source. On the ground >> >> >> >> >> side, one driver slews from sinking 8.5 mA to sinking nothing, while >> >> >> >> >> the other slews from sinking nothing to sinking 8.5mA. Similar things >> >> >> >> >> happen on the VCC side, except that current is being sourced rather >> >> >> >> >> than sunk. >> >> >> >> >> >> >> >> >> >> Beyond a certain point, the strength of the drivers is moot; the >> >> >> >> >> current into or out of the I/O pin will be limited by the transmission >> >> >> >> >> line impedance. If we think of the differential lines as two 50-ohm >> >> >> >> >> single-ended lines, the current needed to send a 0.85V delta V down >> >> >> >> >> each line is 17mA, which is exactly the delta you get when you stop >> >> >> >> >> sourcing 8.5mA and start sinking it, or vice versa. >> >> >> >> >> >> >> >> >> >> The balance isn't perfect, but the net di/dt on either the VCC or >> >> >> >> >> ground paths should be considerably less than for single-ended >> >> >> >> >> signals. >> >> >> >> >> >> >> >> >> >> Bob Perlman >> >> >> >> >> ----- >> >> >> >> >> Cambrian Design Works >> >> >> >> >> http://www.cambriandesign.com >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >Bob Perlman wrote: >> >> >> >> >> > >> >> >> >> >> >> Hi - >> >> >> >> >> >> >> >> >> >> >> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks >> >> >> >> >> >> <hicksthe@egr.msu.edu> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >Hi, >> >> >> >> >> >> > I am seriously considering using a spartan2e to serve as a clock >> >> >> >> >> >> >distribution generator for a lvpecl clock system. This clock system >> >> >> >> >> >> >will be driving a total of 17 differential clocks. When I price the >> >> >> >> >> >> >LVPECL chips the spartan2e looks very competetive. Also, it would give >> >> >> >> >> >> >me the clock DLL to clean up my system clock. The question is that I >> >> >> >> >> >> >have a total of 34 output lines that should be switching at the same >> >> >> >> >> >> >time. The spec says 12 power and ground pairs in the chip and 3 >> >> >> >> >> >> >simulatneous outputs per pair. Thus a total of 36 outputs. (one spare >> >> >> >> >> >> >pair for me.) How do I split these up over the 12 power/ground pairs? >> >> >> >> >> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E). Where do >> >> >> >> >> >> >I get 12 power/ground pairs from these 24 pins? >> >> >> >> >> >> >> >> >> >> >> >> If you're using differential outputs, the power and ground di/dt >> >> >> >> >> >> should be significantly less than what you'd see for single-ended >> >> >> >> >> >> signals. Assuming that the true and complementary transitions occur >> >> >> >> >> >> in unison, one driver should be increasing its ground or VCC current >> >> >> >> >> >> as the other driver's current is decreasing. The match isn't perfect, >> >> >> >> >> >> but it should be pretty good. >> >> >> >> >> >> >> >> >> >> >> >> Ask Xilinx for diff pair power/ground guidelines; they should be less >> >> >> >> >> >> stringent than the guidelines for single-ended signals. >> >> >> >> >> >> >> >> >> >> >> >> Bob Perlman >> >> >> >> >> >> ----- >> >> >> >> >> >> Cambrian Design Works >> >> >> >> >> >> http://www.cambriandesign.com >> >> >> >> >> >>Article: 42790
Bob, I was referring to the fact that Xilinx was using two single ended IO's to create a psuedo-differential output (it wasn't differential from the start - hence the emperor never had any clothes). What did you think I was referring to? An "attack on the person" was the furthest from my mind. Austin Bob Perlman wrote: > Austin - > > On Thu, 02 May 2002 07:31:49 -0700, Austin Lesea > <austin.lesea@xilinx.com> wrote: > > >Bob, > > > >The emperor never really had clothes, did he? > > You've crossed the line from spirited argument to ad hominem attack. > Shame on you. > > Bob Perlman > ----- > Cambrian Design Works > http://www.cambriandesign.com > > >We never offered a silicon differential driver until Virtex II. > > > >The LVPECL is a clever use of two single ended drivers, with three external resistors, two > >series 100 ohm, and one parallel 187 ohm. > > > >Looks like, smells like, and is two single ended drivers. Just that simple. If you want to > >point out how the two single ended drivers are not a perfectly balanced, low bounce > >differential driver, please do so without implying that someone here in IC design was doing a > >lousy job. > > > >Other than that, sounds like we are in "violent agreement." > > > >Austin > > > > > > > >Bob Perlman wrote: > > > >> Austin - > >> > >> I give, I give! You've managed to convince me that Xilinx has > >> designed a differential transmitter that has poor delay matching, lots > >> of shoot-through current, high I/O capacitance, and requires three > >> external resistors at the driver end. > >> > >> Nevertheless, I'm sure it's a wonderful driver. > >> > >> Bob Perlman > >> ----- > >> Cambrian Design Works > >> http://www.cambriandesign.com > >> > >> On Wed, 01 May 2002 12:54:42 -0700, Austin Lesea > >> <austin.lesea@xilinx.com> wrote: > >> > >> > http://www.support.xilinx.com/xapp/xapp133.pdf > >> > > >> >See page 32 of the pdf file. > >> > > >> >Austin > >> > > >> >Bob Perlman wrote: > >> > > >> >> Austin - > >> >> > >> >> On Wed, 01 May 2002 11:07:53 -0700, Austin Lesea > >> >> <austin.lesea@xilinx.com> wrote: > >> >> > >> >> >Bob, > >> >> > > >> >> >Because the LVPECL uses a resitor network to set the levels (r's in series, r's in > >> >> >parallel). > >> >> > >> >> What resistor networks? The Spartan IIE data sheet says that you > >> >> connect 100 ohms across the rails. Where are the other resistors? > >> >> > >> >> Bob Perlman > >> >> ----- > >> >> Cambrian Design Works > >> >> http://www.cambriandesign.com > >> >> > >> >> >Also, each IO has the capacitive load of the pin (~ 10 pF) so each IO must charge, and > >> >> >discharge that capacitance. Charging lowers Vcco (Vcco bounce) and discharging raises > >> >> >ground (ground bounce). They don't cancel either. > >> >> > >> >> >Austin > >> >> > > >> >> >Bob Perlman wrote: > >> >> > > >> >> >> Austin - > >> >> >> > >> >> >> I think we're going in circles here. I mentioned in my first post > >> >> >> that the cancellation wouldn't be perfect, but that there would be > >> >> >> some, and that I'd expect it to be significant. > >> >> >> > >> >> >> I can agree with your results if: > >> >> >> > >> >> >> (a) the true and complement transitions are significantly skewed (bad > >> >> >> news for the receiver) > >> >> >> > >> >> >> (b) crossover current is a significant fraction of the current being > >> >> >> sourced or sunk by the driver through the I/O pin, and lasts for a > >> >> >> significant fraction of the rise/falltime. ( I thought that this > >> >> >> wasn't the case for modern driver designs. Can you give more > >> >> >> information on duration/amplitude?) > >> >> >> > >> >> >> (c) both. > >> >> >> > >> >> >> Can you clarify something? You've said that: > >> >> >> - driver impedance is 7 ohms > >> >> >> - drivers switch from rail to rail > >> >> >> > >> >> >> How do 7-ohm rail-to-rail drivers connected to 3.3V produce 0.85V > >> >> >> across a 100 ohm load? > >> >> >> > >> >> >> Bob Perlman > >> >> >> ----- > >> >> >> Cambrian Design Works > >> >> >> http://www.cambriandesign.com > >> >> >> > >> >> >> On Wed, 01 May 2002 07:55:38 -0700, Austin Lesea > >> >> >> <austin.lesea@xilinx.com> wrote: > >> >> >> > >> >> >> >Bob, > >> >> >> > > >> >> >> >Simple. The outputs pull all the way to Vcc, and to ground. The switches are not > >> >> >> >current sources at all, but on and off switches with ~ 7 ohms on resistance. The > >> >> >> >current is going to flow through the IO pin, through to the ground connections, and > >> >> >> >the Vcco connections. Just because one is going up when the other is going down > >> >> >> >doesn't mean they will cancel: the delay from the pad to the package pin (25 ps to > >> >> >> >125 ps), and to the external resistors is slightly different for each. The loading > >> >> >> >is slightly different on each as a result. As well, there is a crossover current in > >> >> >> >a CMOS output driver that flows from Vcco to ground when switching hi, or low, and > >> >> >> >that is unaffected by this arrangement. > >> >> >> > > >> >> >> >So, the lab explains exactly what we expect to happen. > >> >> >> > > >> >> >> >I agree that mysteries are a bad thing, and we always drill down until we explain a > >> >> >> >result completely. > >> >> >> > > >> >> >> >Austin > >> >> >> > > >> >> >> > > >> >> >> >Bob Perlman wrote: > >> >> >> > > >> >> >> >> Austin - > >> >> >> >> > >> >> >> >> I know they're conventional single-ended I/Os; I thought I made that > >> >> >> >> clear in my analysis (I assumed that the drivers both source and sink > >> >> >> >> current; real PECL drivers only source current). I'm not sure why > >> >> >> >> you mentioned LVDS drivers, but they also source and sink. > >> >> >> >> > >> >> >> >> If you're not seeing lower ground bounce for Spartan IIE > >> >> >> >> differerential LVPECL in the lab, it would be useful to figure out > >> >> >> >> why. If you're not seeing lower ground bounce, I have to wonder if > >> >> >> >> the true and complementary transitions are simultaneous or > >> >> >> >> near-simultaneous. If they're not, that could spell big trouble for > >> >> >> >> the receiver. > >> >> >> >> > >> >> >> >> When lab results are counter-intuitive, it pays to find out why. > >> >> >> >> > >> >> >> >> Bob Perlman > >> >> >> >> ----- > >> >> >> >> Cambrian Design Works > >> >> >> >> http://www.cambriandesign.com > >> >> >> >> > >> >> >> >> On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea > >> >> >> >> <austin.lesea@xilinx.com> wrote: > >> >> >> >> > >> >> >> >> >Bob, > >> >> >> >> > > >> >> >> >> >These are still plain old single ended IOs, and as measured in the lab, there is > >> >> >> >> >virtually no difference in ground bounce from a regular single ended IO. > >> >> >> >> > > >> >> >> >> >LVDS in Virtex II and Virtex II Pro are current sink and source differential > >> >> >> >> >drivers, and there is actually a large benefit from such drivers. > >> >> >> >> > > >> >> >> >> >Austin > >> >> >> >> > > >> >> >> >> >Bob Perlman wrote: > >> >> >> >> > > >> >> >> >> >> Austin - > >> >> >> >> >> > >> >> >> >> >> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea > >> >> >> >> >> <austin.lesea@xilinx.com> wrote: > >> >> >> >> >> > >> >> >> >> >> >Bob, > >> >> >> >> >> > > >> >> >> >> >> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there > >> >> >> >> >> >is no benefit from differential switching as regards to ground bounce. Each > >> >> >> >> >> >single ended IO is already switching rail to rail, and driving hard. Thus > >> >> >> >> >> >even though some of the current flows out comes back in on the other pin, a > >> >> >> >> >> >lot of current is flowing through power and ground. > >> >> >> >> >> > > >> >> >> >> >> >Austin > >> >> >> >> >> > >> >> >> >> >> The original poster wanted to use Spartan IIE which, if I'm reading > >> >> >> >> >> the data sheet correctly, supports LVPECL differential outputs > >> >> >> >> >> terminated with 100 ohms across the two signals. > >> >> >> >> >> > >> >> >> >> >> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is > >> >> >> >> >> 1.06-1.43V, or~ 1.25V typical. This means that the current through > >> >> >> >> >> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA. > >> >> >> >> >> > >> >> >> >> >> When the differential signal switches, one driver switches from source > >> >> >> >> >> to sink, while the other switches from sink to source. On the ground > >> >> >> >> >> side, one driver slews from sinking 8.5 mA to sinking nothing, while > >> >> >> >> >> the other slews from sinking nothing to sinking 8.5mA. Similar things > >> >> >> >> >> happen on the VCC side, except that current is being sourced rather > >> >> >> >> >> than sunk. > >> >> >> >> >> > >> >> >> >> >> Beyond a certain point, the strength of the drivers is moot; the > >> >> >> >> >> current into or out of the I/O pin will be limited by the transmission > >> >> >> >> >> line impedance. If we think of the differential lines as two 50-ohm > >> >> >> >> >> single-ended lines, the current needed to send a 0.85V delta V down > >> >> >> >> >> each line is 17mA, which is exactly the delta you get when you stop > >> >> >> >> >> sourcing 8.5mA and start sinking it, or vice versa. > >> >> >> >> >> > >> >> >> >> >> The balance isn't perfect, but the net di/dt on either the VCC or > >> >> >> >> >> ground paths should be considerably less than for single-ended > >> >> >> >> >> signals. > >> >> >> >> >> > >> >> >> >> >> Bob Perlman > >> >> >> >> >> ----- > >> >> >> >> >> Cambrian Design Works > >> >> >> >> >> http://www.cambriandesign.com > >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> >Bob Perlman wrote: > >> >> >> >> >> > > >> >> >> >> >> >> Hi - > >> >> >> >> >> >> > >> >> >> >> >> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks > >> >> >> >> >> >> <hicksthe@egr.msu.edu> wrote: > >> >> >> >> >> >> > >> >> >> >> >> >> >Hi, > >> >> >> >> >> >> > I am seriously considering using a spartan2e to serve as a clock > >> >> >> >> >> >> >distribution generator for a lvpecl clock system. This clock system > >> >> >> >> >> >> >will be driving a total of 17 differential clocks. When I price the > >> >> >> >> >> >> >LVPECL chips the spartan2e looks very competetive. Also, it would give > >> >> >> >> >> >> >me the clock DLL to clean up my system clock. The question is that I > >> >> >> >> >> >> >have a total of 34 output lines that should be switching at the same > >> >> >> >> >> >> >time. The spec says 12 power and ground pairs in the chip and 3 > >> >> >> >> >> >> >simulatneous outputs per pair. Thus a total of 36 outputs. (one spare > >> >> >> >> >> >> >pair for me.) How do I split these up over the 12 power/ground pairs? > >> >> >> >> >> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E). Where do > >> >> >> >> >> >> >I get 12 power/ground pairs from these 24 pins? > >> >> >> >> >> >> > >> >> >> >> >> >> If you're using differential outputs, the power and ground di/dt > >> >> >> >> >> >> should be significantly less than what you'd see for single-ended > >> >> >> >> >> >> signals. Assuming that the true and complementary transitions occur > >> >> >> >> >> >> in unison, one driver should be increasing its ground or VCC current > >> >> >> >> >> >> as the other driver's current is decreasing. The match isn't perfect, > >> >> >> >> >> >> but it should be pretty good. > >> >> >> >> >> >> > >> >> >> >> >> >> Ask Xilinx for diff pair power/ground guidelines; they should be less > >> >> >> >> >> >> stringent than the guidelines for single-ended signals. > >> >> >> >> >> >> > >> >> >> >> >> >> Bob Perlman > >> >> >> >> >> >> ----- > >> >> >> >> >> >> Cambrian Design Works > >> >> >> >> >> >> http://www.cambriandesign.com > >> >> >> >> >> >>Article: 42791
You guys ( I know both of you personally, and like both of you ) call it quits ! Bob analyzed the circuit, and Austin explained that this is not a real PECL circuit but rather an applications fix, with certain limitations. Everything is understood. Now, Peace on Earth. Please. Peter ========================= Bob Perlman wrote: > Austin - > > On Thu, 02 May 2002 07:31:49 -0700, Austin Lesea > <austin.lesea@xilinx.com> wrote: > > >Bob, > > > >The emperor never really had clothes, did he? > > You've crossed the line from spirited argument to ad hominem attack. > Shame on you. > > Bob PerlmanArticle: 42792
The data sheet is not "messed up". It has one mistake in it: It should not have the "OE" inside the block, outside the buffer symbol. Dumb mistake. Except for that, the data sheet is clear: The input is called T, therefore it is an active High Tristate. Anybody is free to consider it an active Low OE ( i.e OEbar). Generations of engineers have grown up with this method. I have dealt with this very clear and straightforward nomenclature for over 30 years. Peter Alfke ================================================== Kevin Brace wrote: > I don't think that's an excuse for messing up the datasheet. > How many people will actually read the library guide compared to the > datasheet? > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) > > hamish@cloud.net.au wrote: > > > > Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: > > > One problem I had a while ago with a Spartan-II datasheet was it didn't > > > say that Spartan-II IOB tri-state buffers are active low or high. > > > > You should have read the libraries guide - it's the data sheet for > > the primitives in the library. > > > > Hamish > > -- > > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 42793
Okay, here is the answer... It was Synplify being overly helpful and annotating the EDIF netlist! ---------------------------------------------------------- Jay, Out of curiosity, are you using Synplify? If so, I suspect that it is adding an IOB property to some of your flip-flops in the EDF file with the value of TRUE. A simple search for IOB in the EDF file will confirm this. While I'm not sure how to turn it off, at least it explains why the flip-flops are being pulled into the I/O even though you are not using the -pr option in Map or the IOB=TRUE attribute in the UCF/NCF file. Craigr Jay wrote: > Does anyone know how to get rid of the flops in the IOBs? The mapper > default is supposed to exclude them but low and behold, when I view > the floor plan, I see them being used. > > Another question- does anyone know how to turn on the programmable > delay on the input path of the IOB? I'm trying to solve a nasty clock > skew problem. > > Thanks!Article: 42794
This was interesting, until it went off the rails a little.. I did not see numbers on just how good the delay-balance actually is ? There are two classes of gnd noise : Transistion, and Static Load. Local Transistion noise may not improve with two pins toggling, but the BUS-Line, EMC behaviour, and 'no change in static Icc' of a balanced drive should result in measurable spectral improvements. ie put any sort of real physical PCB route on the chip, and balanced should win. Did the lab checks include EMC effects ? -jg > >> >> >> <austin.lesea@xilinx.com> wrote: > >> >> >> > > >> >> >> >Simple. The outputs pull all the way to Vcc, and to ground. The switches are not > >> >> >> >current sources at all, but on and off switches with ~ 7 ohms on resistance. The > >> >> >> >current is going to flow through the IO pin, through to the ground connections, and > >> >> >> >the Vcco connections. Just because one is going up when the other is going down > >> >> >> >doesn't mean they will cancel: the delay from the pad to the package pin (25 ps to > >> >> >> >125 ps), and to the external resistors is slightly different for each. The loading > >> >> >> >is slightly different on each as a result. As well, there is a crossover current in > >> >> >> >a CMOS output driver that flows from Vcco to ground when switching hi, or low, and > >> >> >> >that is unaffected by this arrangement. > >> >> >> > > >> >> >> >So, the lab explains exactly what we expect to happen. > >> >> >> > > >> >> >> >I agree that mysteries are a bad thing, and we always drill down until we explain a > >> >> >> >result completely. > >> >> >> > > >> >> >> >Austin > >> >> >> > > >> >> >> > > >> >> >> >Bob Perlman wrote: > >> >> >> > > >> >> >> >> Austin - > >> >> >> >> > >> >> >> >> I know they're conventional single-ended I/Os; I thought I made that > >> >> >> >> clear in my analysis (I assumed that the drivers both source and sink > >> >> >> >> current; real PECL drivers only source current). I'm not sure why > >> >> >> >> you mentioned LVDS drivers, but they also source and sink. > >> >> >> >> > >> >> >> >> If you're not seeing lower ground bounce for Spartan IIE > >> >> >> >> differerential LVPECL in the lab, it would be useful to figure out > >> >> >> >> why. If you're not seeing lower ground bounce, I have to wonder if > >> >> >> >> the true and complementary transitions are simultaneous or > >> >> >> >> near-simultaneous. If they're not, that could spell big trouble for > >> >> >> >> the receiver. > >> >> >> >> > >> >> >> >> When lab results are counter-intuitive, it pays to find out why. > >> >> >> >> > >> >> >> >> Bob PerlmanArticle: 42795
Noddy wrote: > > Hi Manfred, > > My output frequency range is very small... between about 31.5MHz and > 32.5Mhz, although I need mHz precision. It should use a 5MHz reference > signal. You should specify also the step size, and phase noise tolerances. MilliHz precision is not going to be trivial, but I think the FPGA PLL/DLL can work to divide a cycle by 256. If you do not use fractional-cycle counting, the a std PLL has a step size equal to the Freq Compare sample rate. eg 10Hz compare rate will give you step size of 10Hz. Each 10Hz step, can have a sub-hz precision, limited by the phase noise in the system. 4% freq range is outside VCXO scope, and you will need very high Q inductance for lowest phase noise. Cavity oscillators, or similar, may be needed. -jgArticle: 42796
Jim, Package skew is +/- 25 to 125 ps, depending on the lengths of the runs from the pads to the pcb balls, and to the resistors. For test boards, we keep the skew of external differential pairs to less than +/- 2.5 ps, and the differential pairs are constructed to be 100 ohms differential, side by side, with an approximate 65 to 68 ohm impedance from a single rail to ground. The actual drive delay difference from one IOB to the next IOB is less than +/- 20 ps (using the clock tree to adjacent IOB FFs) in this family of parts. All Power rails have separate planes, with ground planes, and with reasonably good bypassing for all supplies (probably 20 to 40% of what is recommended for maximum SSO switching measurements -- we have special max SSO boards for those measurements where we turn on the max number of SSOs with the recommended bypassing). All measurements are done in 50 ohm transmission line environment (ie the pcb is fabricated with this in mind). Trace lengths confirmed with TDR. Impedances confirmed with TDR and Network Analyzer. All measurements made with 1 GHz fet/bipolar probes (no ground leads, 0.1" center pins) to a 4GS/s scope. If we suspect something else is going on, we can use the 20 GS/s sampling scope, or look at the ->26 GHz spectrum analyzer with near field probes, or with contact probes directly. Spice simulations and IBIS simulations are routinely checked against bench measurements to validate the models that we ship to customers. All simulations use transmission line modeling of the laminate package, and the pcb. AustinArticle: 42797
Austin Lesea wrote: > > Jim, > > Package skew is +/- 25 to 125 ps, depending on the lengths of the runs from the pads to the pcb > balls, and to the resistors. > > For test boards, we keep the skew of external differential pairs to less than +/- 2.5 ps, and the > differential pairs are constructed to be 100 ohms differential, side by side, with an approximate 65 > to 68 ohm impedance from a single rail to ground. > > The actual drive delay difference from one IOB to the next IOB is less than +/- 20 ps (using the > clock tree to adjacent IOB FFs) in this family of parts. So, given that balanced drive would be placed by the designer on adjacent IOB, does that need an additional package adder, or not ? QFP packages would by nature, give better delay-balance than BGA ? -jgArticle: 42798
Hi Christian, Thanks for your reply. I've been looking more closely at it,and am at the following state: In schematic capture, if I connect the readback inputs and outputs directly to pads, via IBUFs and OBUFs, it works properly. I look at it in the FPGA editor and the connections are correct (down in the bottom left and right corners of the chip). I had hoped this would be good enough, but because I'm trying to do this via the parallel port, my PC can't drive (or listen ) fast enough to get a valid bitstream. Next approach is to dump the readback stream at 1MHz onto the RAM on the XS40 board. I got the RAM working OK, and hooked up the readback to my memory driver. Now when I synthesise, the readback pins *don't* get connected! I tried surrounding the readback element (in the schematic) with BUFs and BUFGs and all that, but it never gets connected. Finally I tried connecting the outputs of the readback block to OBUFs, as well as the internal nets (memory driver). This time the readback was connected, but only to the OBUFs, not the internal nets! I've even hung "dummy logic" off the readback ports to force synthesis, but it's just not happening. Summary: the readback will only synthesise if driving directly to OBUFs, not internal nets. This is driving me mad. I understand that only a tiny percentage of users want to use readback, but surely Xilinx could provide better support for this facility. I've read all of the documentation they provide on readback, and am still none the wiser. Cheers, JohnArticle: 42799
Hi,
Forget it. A Synplicity person finally got back to me. It turns out
since my path was short, it didn't require the multicycle commands.
However, it still wrote out the constraints.
But to answer your question, they are in the top module. Just some
registers. Thanks.
With Regards,
Henry
Ken McElvain <ken@synplicity.com> wrote in message news:<3CD06C00.1070302@synplicity.com>...
> Are the names properly scoped? From your command
> I would expect that pre_data and filt are declared in the
> top level module. Is this true?
>
> - Ken
>
>
> Henry wrote:
>
> > Hi,
> >
> > I'm using Synplify Pro 7.0. I can't get the define_multicycle_path to
> > work.
> >
> > I have the following command in my .sdc file:
> > define_multicycle_path -from {pre_data[11:0]} -to {filt[13:0]} 2
> >
> > pre_data and filt are vectors declared as reg in my Verilog. And of
> > course, they are registered at positive edge of clock.
> >
> > After I run the synthesis on it. I scroll near the end of the log
> > file, it tells me that the timing constraint is never applied to the
> > design. And of course, the reports is still thinking that the paths
> > are running with a cycle of 1.
> >
> > What gives???? Mucho thanks in advance!
> >
> > I E-mailed Synplicity, but they are slow to react. :-(
> >
> > With Regards,
> > Henry
> >
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