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
Ren,
There are quite a few texts on Verilog and/or VHDL based chip design.
Most discuss both ASIC and FPGA design. I would suggest a text on
HDL-based design (vs. a vendor-specific, schematic-based methodology,)
as this knowledge will be most portable. Also look for one which is
more than just a language reference (one which goes into the details
of synchronous designs methods and the differences between
sythesizable and none-synthesizable code.)
For reference, I often borrow a co-worker's copy of "HDL Chip Design:
A Practical Guide for Designing, Synthesizing and Simulating ASICs and
FPGAs Using VHDL or Verilog" by Douglas J. Smith, but couldn't comment
on this as a learning text.
For my customers, I generally recommend an in depth, week-long course
in Verilog or VHDL, if your schedule and budget permit. A few years
back, I took the Esperan (www.esperan.com) VHDL cousre, which I
thought was good. It teaches the language and tools. You choose the
simulation and synthesis tools with which you would like to work.
I've sent a couple customers to both the Esperan Verilog and VHDL
courses and heard nothing but positive responses.
As an Altera FAE, I should let you know about our on-line course
selection. There are basic Verilog and VHDL on-line courses for $95.
While these courses won't make you a power-user, they are a good
introduction to these languages.
Bill
--------------------------------------------------
I am an Altera FAE. I am participating in this
forum on my own time, so please direct all
techincal questions to http://mysupport.altera.com
--------------------------------------------------
Article: 42726Here 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. You have two choices: •Wait till September for the Industrial version (August for commercial) or •use the readily available XC2S150 ( i.e. the older, 2.5V version of the same architecture). Essentially the same price, but different pin-out. I asked why, and the answer is: different package construction, which flips the chip in the opposite direction. Done for cost reasons. I am sorry that you got jerked around, but Xilinx really is innocent. Send nasty comments to your distributor, they should have known better. Maybe I should have jumped in earlier, but I generally try to concentrate on technical questions, not distribution quirks. Greetings Peter Alfke, Xilinx Applications ============================= rickman wrote: > I heard back from the Rep today. Xilinx is giving everyone the same > story. No XC2S150E parts of any flavor until July. In fact, I received > an email from someone at Xilinx support saying that this is only an > estimated date and that they won't be setting firm dates until the end > of May. > > All this is after I received a quote from Insight back in March saying I > could have commercial temp parts in 5-6 weeks. Insight said that got > this info directly from Xilinx. So I don't understand what happened. > > We have slipped a month on our schedule already due to changes in the > design. Now we will have to slip another two months, maybe more due to > lack of availability of the Xilinx parts. > > roy wrote: > > > > Send an order to the rep. instead of the disti. he may be able to expedite. > > I've done this and it sometimes works. > > You also may get access to to the product manager in this way. > > Roy. > > > > 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. > > > > > > I have tried working with distis and they keep saying that Xilinx won't > > > give them parts until June no matter how much they beg. I have > > > contacted the rep and they keep talking about placing an order so that > > > it can be expedited. But what is the point of placing an order if I > > > can't get delivery when I need it? > > > > > > Anyone know how to get your hands on a small number of ES chips prior to > > > the official release? > > > > > > I was able to get some chips from the Coolrunner product manager under > > > these same conditions awhile back. But I don't have a way to contact > > > the SpartanIIE product manager. > > -- > > 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: 42727
Kevin Brace wrote > Anyhow, has anyone successfully duplicated output and OE FFs in > an HDL-based design when I/O buffers were not inserted? Instantiate the flops?Article: 42728
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: 42729
Hi, Thanks, Austin. It would be great verification to Peter's claim ;-) Regards, Austin "Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3CD017E1.CD1EB45@xilinx.com... > Austin, > > Working on it. > > I have to figure out how to simulate the 5V driving the 3.3 v part. It isn't > obvious to me how to do it. I will figure it out. It may be the version I have > is the IC Designers verfication version so it doesn't have that feature. I have > asked for someone who has the full version to get back to me. > > If the full version can't do that, I will have to complain to someone.....pretty > basic thing to simulate. > > The IBIS file was easy to find for the part, however, on the Micron website. > > Austin > > Austin Franklin wrote: > > > Hi Austin, > > Thanks for the offer! It would be great if you could give me a definite > > answer! > > > > Xilinx part is XCS30-4PQ240C and the DRAM is a Micron MT 4LC4M16R6TG-6. > > There is a 33.2 ohm resistor on the address, RAS and CAS pins. Data pins, OE > > and WE are hooked up directly. > > > > Any more info you need, please let me know. > > > > Regards, > > > > Austin > > > > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > > news:3CD002C4.F40E80B4@xilinx.com... > > > Austin, > > > > > > I don't suppose you would consider an IBIS simulation? > > > > > > Call the hotline, ask them to simulate your two chips talking to one > > another if > > > you do not have an IBIS simulator of your own. Or call the Xilinx FAE. > > They > > > all have copies of Hyperlynx. Or, post back here the part numbers of the > > two > > > parts that are talking to one another, and if I get a chance, I will > > simulate it > > > and post the result. > > > > > > Austin > > > > > > Austin Franklin wrote: > > > > > > > Well, I seem to keep answering my own questions... There is a paper on > > the > > > > Xilinx web site: > > > > > > > > http://www.xilinx.com/partinfo/3volt.pdf > > > > > > > > that claims the Spartan output can safely drive a 3.3V device...even > > without > > > > a series limiting resistor (if used in the default TTL mode). Hum. > > > > Comments? > > > > > > > > "Austin Franklin" <austin@dark87room.com> wrote in message > > > > news:ucv0nihlei4g2e@corp.supernews.com... > > > > > I did check the Spartan vs Spartan XL pinouts...and they are the same > > > > > (except for a few configuration pins), and obviously VCC has to > > change. I > > > > > measured the output of a Spartan to the DRAMs, and it was 4V+, so > > that's > > > > not > > > > > going to work...default is TTL, so I believe this is TTL output. > > Looks > > > > like > > > > > I have to change to an XL... My outputs have to be registered in the > > IOBs > > > > > too, so that probably precludes my using any I/O open collector type > > > > trick. > > > > > > > > > > Anyone know if the 5V PROMs will work fine with the SpartanXL part? > > > > > > > > > > "Austin Franklin" <austin@dark87room.com> wrote in message > > > > > news:ucutbb7if6khe3@corp.supernews.com... > > > > > > I have to update a board that has a Spartan on it that interfaces to > > > > > memory. > > > > > > The memory I have to use is 3.3V LVTT, changed from 5V TTL. From > > what > > > > the > > > > > > specs for the Spartan and memory say, the DRAM inputs to the Spartan > > > > > aren't > > > > > > a problem, but I am concerned about the outputs from the Spartan to > > the > > > > > > DRAM. The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and > > 15ns > > > > > of > > > > > > VCC + 1.6V). The TTL output from the Spartan is min 2.4V, with no > > max. > > > > > > > > > > > > Anyone have any experience interfacing a Spartan to a 3.3Vmemory? > > > > > Switching > > > > > > to an XL isn't a really good option, as I do not believe they are > > pin > > > > > > compatible with their non-XL counterpart (or are they, except for > > VCC > > > > > > obviously, which is an easy change?) and the PCB routing etc. from > > the > > > > old > > > > > > design can be used, except for the DRAM to Spartan interface, and > > 3.3V > > > > > > regulator, which are reasonably easy to re-do... > > > > > > > > > > > > Any experience/input (sic) would be greatly appreciated. > > > > > > > > > > > > Austin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Article: 42730
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. > You have two choices: > > •Wait till September for the Industrial version (August for commercial) or This is yet another set of dates I am being given. No one so far has said anything later than July for either part. > •use the readily available XC2S150 ( i.e. the older, 2.5V version of the same > architecture). Essentially the same price, but different pin-out. > I asked why, and the answer is: different package construction, which flips the > chip in the opposite direction. Done for cost reasons. There is no 2.5 volt power supply on this board. There is no room to add one either. This is a PC/104 board and is cramped enough with 3.3 volt and 1.8 volt power converters. That was the reason for selecting the E parts. In some ways the E parts are a step backwards. If I could use the standard SpartanII chips, they would be pin compatible with the Virtex parts and I could offer the same board with either family of chips. The SpartanIIE chips have no pin level compatibility with the Virtex E parts. > I am sorry that you got jerked around, but Xilinx really is innocent. > Send nasty comments to your distributor, they should have known better. > Maybe I should have jumped in earlier, but I generally try to concentrate on > technical questions, not distribution quirks. The blame has yet to be established, not that it will help. It took quite an effort to get a P&A quote from Insight. They say they had to go to Xilinx to get it and Xilinx took quite awhile to respond. So are you so sure that Xilinx was not the party that fouled this up? Just to make sure that I have covered all the bases, I put in the order today for the commercial parts. I will see if they confirm the ship date that I was quoted. I will say this, after making similar posts here about the availability of Coolrunner parts in a specific package and size, I was contacted by the product manager, Betsy Thibault. She ended up sending me prequal engineering samples that I can work with. But now they are pointless since I won't have the FPGA for another five months. But I guess the XC2S150E case is different since this is a new die and it must be run through qualification before there is any confidence in it. The Coolrunner was just a new size/package combination. Otherwise I would have hoped that I could have gotten chips in the XC2S150E prior to formal release. > Greetings > Peter Alfke, Xilinx Applications > ============================= > rickman wrote: > > > I heard back from the Rep today. Xilinx is giving everyone the same > > story. No XC2S150E parts of any flavor until July. In fact, I received > > an email from someone at Xilinx support saying that this is only an > > estimated date and that they won't be setting firm dates until the end > > of May. > > > > All this is after I received a quote from Insight back in March saying I > > could have commercial temp parts in 5-6 weeks. Insight said that got > > this info directly from Xilinx. So I don't understand what happened. > > > > We have slipped a month on our schedule already due to changes in the > > design. Now we will have to slip another two months, maybe more due to > > lack of availability of the Xilinx parts. > > > > roy wrote: > > > > > > Send an order to the rep. instead of the disti. he may be able to expedite. > > > I've done this and it sometimes works. > > > You also may get access to to the product manager in this way. > > > Roy. > > > > > > 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. > > > > > > > > I have tried working with distis and they keep saying that Xilinx won't > > > > give them parts until June no matter how much they beg. I have > > > > contacted the rep and they keep talking about placing an order so that > > > > it can be expedited. But what is the point of placing an order if I > > > > can't get delivery when I need it? > > > > > > > > Anyone know how to get your hands on a small number of ES chips prior to > > > > the official release? > > > > > > > > I was able to get some chips from the Coolrunner product manager under > > > > these same conditions awhile back. But I don't have a way to contact > > > > the SpartanIIE product manager. -- 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: 42731
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: 42732
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
Article: 42733
Tim wrote:
>
> Kevin Brace wrote
>
> > Anyhow, has anyone successfully duplicated output and OE FFs in
> > an HDL-based design when I/O buffers were not inserted?
>
> Instantiate the flops?
You mean I should instantiate FDP (D FF with asynchronous
preset) FDPE (D FF with clock enable and asynchronous preset) type FFs
in my code directly?
I hate to do so, because, in general, I don't like to use vendor
specific primitives, but if I have to, I will, however, the problem with
that is, I won't know the net name because I don't hand craft control
logic in my PCI IP core.
Here is an example of hard crafting the control logic.
________________________________________________________________
reg TRDY_n_Port;
wire TRDY_n_equ;
assign TRDY_n_equ = ((!T_Abort) & (Data_Transfer)) | ((Data_Ready) &
(Data_Transfer)));
always @ (posedge CLK or negedge RST_n) begin
if (RST_n == 1'b0)
TRDY_n_Port <= 1'b1;
else begin
TRDY_n_Port <= TRDY_n_equ;
end
end
________________________________________________________________
Note that the above TRDY# equation is meaningless (I don't do
mine this way.), and it is for illustrative purposes only, but this way
I know the net (wire) name, so I can easily duplicate a FF. (Actually
duplication is not necessary in this case because TRDY_n_Port doesn't
retain its value.)
However, I refuse to use assign statements to write out the equation for
TRDY# or other control logic (FRAME#, IRDY#, DEVSEL#, TRDY#, STOP#,
etc.) because I find it a lot harder and time consuming to do the logic
design.
Instead, I let the synthesis tool synthesize the control logic.
________________________________________________________________
reg DEVSEL_n_Port;
reg TRDY_n_Port;
reg STOP_n_Port;
assign TRDY_n = TRDY_n_OE_n ? 1'bz : TRDY_n_Port;
always @ (posedge CLK or negedge RST_n) begin
if (RST_n == 1'b0) begin
DEVSEL_n_Port <= 1'b1;
TRDY_n_Port <= 1'b1;
STOP_n_Port <= 1'b1;
State_Machine_State <= Target_Idle;
end
else begin
case (State_Machine_State)
Target_Idle: begin
if ((FRAME_n == 1'b0) && (IRDY_n == 1'b1)) begin
State_Machine_State <= Addr_Comp;
end
end
Addr_Comp: begin
if (Addr_Hit == 1'b1) begin
DEVSEL_n_Port <= 1'b0;
State_Machine_State <= Data_Transfer;
end
end
Data_Transfer: begin
if (T_Abort == 1'b1) begin
DEVSEL_n_Port <= 1'b1;
TRDY_n_Port <= 1'b1;
STOP_n_Port <= 1'b0;
end
else if (Disc_Req == 1'b1) begin
DEVSEL_n_Port <= 1'b0;
TRDY_n_Port <= 1'b1;
STOP_n_Port <= 1'b0;
end
else if (Data_Ready == 1'b1) begin
TRDY_n_Port <= 1'b1;
end
end
endcase
end
end
________________________________________________________________
Looking at the above sort of meaningless state machine, in
certain states, the value of FFs is retained, therefore, there is going
to be a value retention feedback fanout in addition to a fanout going
towards a tri-state buffer.
Yes, I tried to restrict the max. fanout to 1, but either XST will get
stuck during a netlist generation or XST will break my constraint, and
have 2 fanouts.
Because the synthesis tool synthesizes the logic, I don't know the net
(wire) name of the last level of LUT before being fed to a FF.
If I knew that, I can easily duplicate FFs.
However, some people may suggest I should manually duplicate FFs like
this.
________________________________________________________________
reg DEVSEL_n_Port;
reg TRDY_n_Port;
reg STOP_n_Port;
reg DEVSEL_n_Port_Dup;
reg TRDY_n_Port_Dup;
reg STOP_n_Port_Dup;
assign TRDY_n = TRDY_n_OE_n ? 1'bz : TRDY_n_Port;
always @ (posedge CLK or negedge RST_n) begin
if (RST_n == 1'b0) begin
DEVSEL_n_Port <= 1'b1;
TRDY_n_Port <= 1'b1;
STOP_n_Port <= 1'b1;
DEVSEL_n_Port_Dup <= 1'b1;
TRDY_n_Port_Dup <= 1'b1;
STOP_n_Port_Dup <= 1'b1;
State_Machine_State <= Target_Idle;
end
else begin
case (State_Machine_State)
Target_Idle: begin
if ((FRAME_n == 1'b0) && (IRDY_n == 1'b1)) begin
State_Machine_State <= Addr_Comp;
end
end
Addr_Comp: begin
if (Addr_Hit == 1'b1) begin
DEVSEL_n_Port <= 1'b0;
DEVSEL_n_Port_Dup <= 1'b0;
end
end
Data_Transfer: begin
if (T_Abort == 1'b1) begin
DEVSEL_n_Port <= 1'b1;
TRDY_n_Port <= 1'b1;
STOP_n_Port <= 1'b0;
DEVSEL_n_Port_Dup <= 1'b1;
TRDY_n_Port_Dup <= 1'b1;
STOP_n_Port_Dup <= 1'b0;
end
else if (Disc_Req == 1'b1) begin
DEVSEL_n_Port <= 1'b0;
TRDY_n_Port <= 1'b1;
STOP_n_Port <= 1'b0;
DEVSEL_n_Port_Dup <= 1'b0;
TRDY_n_Port_Dup <= 1'b1;
STOP_n_Port_Dup <= 1'b0;
end
else if (Data_Ready == 1'b1) begin
TRDY_n_Port <= 1'b1;
TRDY_n_Port_Dup <= 1'b1;
end
end
endcase
end
end
________________________________________________________________
Hopefully, the synthesis tool will be smart enough to notice
that xxxxxx_n_Port and xxxxxx_n_Port_Dup are the same, so it will use
the manually duplicated ones for value retention feedback loops, but it
didn't seem to work that way when I tried it.
Thanks,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 42734Alan Fitch <alan.fitch@doulos.com> wrote in message news:<h$Zd6gBPA7z8YBum@doulos.co.uk>... > The simplest way is to implement a reset pin. Your code above almost > looks like it is using "load" as a reset. > > Generally, if you use an asynchronous reset, you should write a process > in the style > > process(clk, reset) > begin > if reset = '1' then > > -- reset stuff, e.g. z := 63 > > elsif rising_edge(clk) then > > -- synchronous actions > > end if; > > end process; > > You should only have one clock edge per process. > > Also I would declare integers constrained, otherwise you are relying on > the synthesis tool to remove unused bits. You can do this like this > > variable z : integer range 0 to 63; -- unsigned 6 bit > variable z2 : integer -32 to 31; -- signed 6 bit > > Think hardware! > > regards > > Alan > > I still have the same error , is their any constrain that i must know about the range of an array ... i don't know what's wrong i've tried the tips that Mr. Alan gave , but nothing new sincerely HassanArticle: 42735
Hi Kevin, Allow me to re-post what Peter already posted, which is what I wrote on this originally. I looked at the datasheet myself, and it is confusing. So, ignoring the libraries guide and the datasheet, here is what I believe to be correct: From a primitive point of view, the IOB has a "T" input. All of the primitives in the library have "T" inputs. It really is a "T" (TRISTATE) signal, active high. 1. As far as I am aware, you cannot change the polarities by what you do in the design, short of using FPGA Editor. 2. If you are in schematics, all the library elements have a "T" pin on them, so you would probably just implement a tristate logic function to directly control the I/O. This is somewhat natural and obvious. But most people are not using schematics anymore... 3. If you are in HDL-land, here is one example of what a designer might do: assign bidir = my_oe ? my_value : 1'bz; In this case, the synthesis tool probably generates the following circuit: my_oe ---> inverter ---> T pin on I/O primitive Here, the inverter can be pushed forward into the IOB by the mapper, using the local inversion (instead of a separate lut). It is also possible that either the mapper or the synthesis tool could push the inverter backwards into the logic that was driving my_oe. If you are in HDL-land, here is another example of what a designer might do: assign bidir = my_t ? 1'bz: my_value; In this case, the synthesis tool probably generates the following circuit: my_t ---> T pin on I/O primitive Here, there is no need for inverters anywhere, so nothing special is done, and this logic is what gets implemented. I think the idea of those local inverters in the IOB is that the CAD tools can compensate for a designer who is not aware of the architecture. If the local inverters did not exist, the coding style of the HDL designer would impact the circuit performance (that extra "inverter" would cost something in terms of delay, because it would be in a LUT). EricArticle: 42736
Peter Alfke wrote:
>
> Hi, Kevin, I was not accusing you, I was just annoyed at the whole issue, which really
> is a non-issue:
>
> The Spartan-II shows correctly in Fig. 2 of its data sheet, that the internal OE
> control signal is active High. ( Anybody should be able to deduce that this imlies that
> the 3-state control is active Low).
>
I am getting confused, but I will try to explain what I am
trying to say here.
The Figure 2 of Virtex/Spartan-II datasheet show that T input of an
OBUFT doesn't have a bubble in front of it.
Doesn't that imply that OBUFT is active high? (T = 1 -> O = I. T = 0 ->
O = Z)
But ISE 3.1's Libraries Guide says that OBUFT is active low despite the
fact that the bubble isn't there in front of the T input.
Wouldn't the bubble imply that whatever is active low?
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 42737--------------F63926AB1D976285050C3172 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit 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. >Article: 42738
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
>
Article: 42739Kevin, I think you have at least two options that should work: 1. Include the I/O pads in the IP core. It is then completely self-contained, and the OE FF's will be in the IOB with the bus FF's. 2. Make a source module for only the I/O portion. Using generates, it should be straight forward to get exactly the I/O that you want. Regards, "Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:aapcfa$7ue$1@newsreader.mailgate.org... > Here is a problem I got in which I cannot seem to find an > answer. > Rather than synthesizing my PCI IP core over and over each time I make > modifications to the backend, I will like to instantiate a netlist > version of my PCI IP core from the backend design files to save time. > To do so, I will declare a blackbox on the backend side, and NGDBUILD > will automatically glue the necessary modules together. > The problem I found was, when I synthesize my PCI IP core separately > with "Add I/O Buffers" option of XST unchecked, XST will not duplicate > output and OE (Output Enable) FFs for my design which is expected. > So, to force XST to duplicate output and OE FFs, I decided to reduce > those FFs' max. fanout to 1, and turn on register duplication, which > should result in FFs getting duplicated with only 1 fanout. > A single fanout is a must for those FFs to get pushed into IOBs, but > when I try to restrict the max. fanout to 1, XST seems to get stuck > during a netlist generation part of the synthesis. (At the end.) > After some trials, I noticed that when the max. fanout is 1 for output > FFs, XST will get stuck, but when it is 2, it doesn't seem to get stuck. > For OE FFs, max. fanout of 1 doesn't seem to cause problems. > I can see the results at MAP, but when I check the fanout of those FFs > through Floorplanner (After P&R), the fanout of OE FFs is 2, one going > towards the pin and another one going towards a LUT for data retention > (A feedback path for data retention.), therefore, these OE FFs don't get > pushed into IOBs. > For output FFs, the max. fanout was 2, so they do have 2 fanouts, and > they won't make into IOBs even if IOB = TRUE attribute was added in a > .UCF file. > At least for OE FFs, what I expected was . . . , one of the duplicated > FFs to be used for data retention, and the one will have a single fanout > towards the pin, but it doesn't seem to happen. > Actually, the duplicated ones have a single fanout, so XST seems to be > following my synthesis constraints to some extent, but it is not totally > following it since I got OE FFs with 2 fanouts. > I wish I can force those duplicated single fanout FFs to go towards the > pin, but it is headed towards some LUT, and attaching IOB = TRUE doesn't > help either. > Anyhow, has anyone successfully duplicated output and OE FFs in > an HDL-based design when I/O buffers were not inserted? > I am sure what I described here can be done really easily in schematics, > but that is not an option in my case. > I read a posting at news:comp.arch.fpga sometime ago that in > LeonardoSpectrum (I hate that tool because the GUI is so buggy. I have > only tried an Altera OEM version, and not a full version.) to duplicate > a FF to be pushed into an IOB, the fanout has to be 1. > Going back to the motivation of what I am trying to do, the real > reason I will like to have my PCI IP core in a netlist is because I will > like to attach it to a VHDL-based design, and I hate to have to redo my > PCI IP core in VHDL. > > > > > Thanks, > > > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.)Article: 42740
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: 42741
Kevin Brace wrote:
>
>
> I am getting confused, but I will try to explain what I am
> trying to say here.
> The Figure 2 of Virtex/Spartan-II datasheet show that T input of an
> OBUFT doesn't have a bubble in front of it.
> Doesn't that imply that OBUFT is active high?
Yes:
• A High level on the T input tristates the output, a Low level makes the output active.
(The OE name inside the box is wrong, Kill it! Sorry.)
• A bubble is shorthand for an inverter.
• An overbar implies that the named signal is active Low.
• Tristate is the same as (OE with an overbar )
Pllease read Eric's explanation again, and it should be clear.
But we should never have put the "OE" inside fig 2. That was dead wrong..
Peter Alfke
Article: 42742Marc Randolph wrote: > My assumption when generating a deskewed clock is that you must count > everything. You have to count the on-chip routing delay from the > DLL/DCM, count the output IOB delay driving off chip, count the > routing delay on the PCB, and count the input IOB delay back on chip. > > The best (only?) way to get ALL of these values, that I'm aware of, > is to run timing analyzer. I agree you should look at the whole path, but even timing analyzer doesn't give you everything you might want to consider. If you're doing a timing analysis, you may want to include the min-max range of parameters, plus things like jitter added by the DCMs that timing analyzer doesn't mention. When I designed a QDR SRAM interface to go into a Virtex-E the hardest part was developing the timing analysis for the board clock loop and determining all the parameters that were relevant. Another thing to keep in mind is if any part of your clock path uses normal routing resources, it will probably have a different delay with every spin through the tools unless you lock the nets. The fortunate thing is you know that the reference and feedback are locked in a certain phase relationship, so you can start there and go "backwards" around the clock loop if you know the insertion delay and board trace delays. > But in looking at this a bit closer, I realized that I have a question > about this as well. Not that it will change my design - on the PCB, I > simply make the feedback net the same length as the net going to the > remote device, and that gets me close enough. > > My question arises from the output of timing analyzer, with respect to > using a normal `GCLK' pin vs. a `DLL' pin for the clock input to a > DLL: > > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tiodll 0.000 CLKIN1 > CLKIN1_ibuf > net (fanout=1) 0.000 CLKIN1_c > Tdllino -1.924 I14/I24/I0 > net (fanout=1) 0.000 I14/clk1_dll > Tgio 0.500 I14/I23/I0 > net (fanout=373) 0.729 clk1 > ---------------------------- ------------------------------ > Total -0.695ns (-1.424ns logic, 0.729ns route) > > But that can't be right, can it?! Tiodll is really zero? It is correct. When you use the special purpose feedback pin the DLL knows this and compensates for the insertion delay and route, making them effectively zero. I forget just where this is stated in the documentation, but it came in handy in our design. Pete -- Peter Young Hardware Designer AMIRIX Systems - Halifax, N.S. http://www.amirix.comArticle: 42743
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: 42744
Do any of the tools (either the synthesis or mapping stages) support this, or do you have to create instantiations yourself? BTW this would stack the OR inputs "vertically." if you need them horizontal, perhaps the SOP feature would work? -Stan "Peter Alfke" <palfke@earthlink.net> wrote in message news:3CCB9127.D10CAD92@earthlink.net... > Any one LUT takes 4 inputs (any function you want). > You can then concatenate LUTs through the carry chain at no extra cost in > area, and about 30 ps additional delay per LUT used. > > Peter Alfke, Xilinx Applications > ================================ > crackeur wrote: > > > In static logic, to implement a gigantic OR function, one may instead stack > > up multiple layers of OR gates in order to optimize for performance. How > > does > > LUT work, is it any different? If I want to implement an OR function with > > lots of inputs, does LUT do it better, or in otherwords, how does the FPGA > > compiler optimize this using LUTs? > > > > Jimmy >Article: 42745
I guess I am not to only one having IOB related problems. (See:
Duplicating
IOB FFs Without I/O Pads Being Inserted in XST.)
To get rid of FFs from inside an IOB, give it put the following code
inside a UCF file.
INST "instance name" IOB = FALSE;
You will have to find the "instance name" by using the floorplanner.
If you click on the I/O pad, and select 'Properties', that should tell
you the name.
When an IOB input FF is used, I believe the programmable delay
to prevent a positive hold time gets activated by MAP automatically, but
the delay can be disabled if the user wants to.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
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: 42746"Børge Strand" wrote: > Come to think of it, I have those files samba mounted too, from a > stand-alone linux file server. (So there's no vmware involved here.) > > A fast ls -ld xst says: > drwx------ 3 borges users 4096 May 1 12:39 xst/ > This is the same permission that all other files in the directory have. But > when I go back to W2K, select xst, and click properties->security, not a > single permission is marked. > > Do you think this could be a Samba problem? It sure makes me curious. > > Regards, > Børge Suggest that you check out support.xilinx.com. If you can't find anything matching in the Answer Database, file a Webcase. Make sure you mention your network setup and the fact that you are using Samba (we use it at Xilinx, too!). -Dennis McCrohan Speaking only for myself, not for Xilinx CPLD Software.Article: 42747
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 FAXArticle: 42748
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 ============================== 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 FAXArticle: 42749
Russell wrote: > > Hi, > > I can't get my spartan2 thing to program. Using impact in win2k, > i can get toggles on pin 4 (TMS_IN) of the pc parallel port, but > no other pins toggle (not even pin 3, CLK). I'm using a copy of > a parallel-III jtag dongle. Could it be anything to do with win2k? > I'm using impact in webpack-4.2. > > http://toolbox.xilinx.com/docsan/2_1i/data/common/jtg/fig26.htm > http://toolbox.xilinx.com/docsan/2_1i/data/common/jtg/jtg.htm It goes now. There was a short on TCLK fpga pin.
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