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
"Peter Alfke" <palfke@earthlink.net> wrote in message news:3CCD6747.8421B78A@earthlink.net > Phil, you have read too many conspiracy stories. > > Peter Alfke > Sorry Peter, it was mischevious of me to stoke the debate. Apologies, Phil -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 42651
On Mon, 29 Apr 2002 17:48:12 -0700, Mark Ng <mark.ng@xilinx.com> wrote: >Hi Len, > >It is definitely possible to disable the bus-hold circuitry in all 9500XL >devices. > Thanks Mark, That is definitely the right answer ! I guess I've got to go and see the guy with the F4.2 license and get him to do me a test JED file to see what happens to the I/Os. Len Chisholm.Article: 42652
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: 42653
I am searching an EDIF parser for automatic documentation generation. where can I get some scripts? Thanks Laurent - AmontecArticle: 42654
Bob, thanks, for your suggestion, that's what I am looking for actually! (the from to constraint) I know the clock delay does not really affect the operating freq, and the delay is working fine for me, just that when they show up as an un-constraint path, I feel un-easy about it. They should not have appear as un-constraint path, clock delay should have been included in the STA of the normal path. you show the clock delay+skew and the data delay then get the slack. anyway, I got a feel back from a xilinx support as. >I was not talking about the IOB registers. I was talking about the CLK in to any FF in the device. 90% coverage is very good, and you do not need to increase this more. It is completely normal to have these clock delays listed as unconstrained paths for reasons mentioned in my last email. We will have a better way of handling these unconstrained clock paths in our next major release, but for now you do not need to worry about them. They are constrained by the OFFSET IN constraint even though it doesn't mention it. >I see what you are saying! This is normal. The path from the CLK pad to the CLK input on the FF is "analyzed" by the OFFSET constraint. However, it is not actually constrained, so it will not show up as a constrained path. The reason it is not constrained, is because it is on global routing, it can not be any faster. The only way to improve a time it takes to get FROM the CLK pad to the FF's CLK input is constrain the data path to the FF so that the path is shorter, and this is done by the OFFSET. >You can add a FROM TO constraint on the CLK net (FROM clk_pad TO clk_FF), however this is not going to improve timing, and it will lengthen your run time slightly. The number that is reported for the max speed of the clock is based on all of your constraints, and reflects the affect those constraints have on the routing of the CLK net even though the clock net is not directly being constrained. thanks and have a nice day pyng Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<dtrqcuorukmvnum6usf9perpe0rqg3mat6@4ax.com>... > On 29 Apr 2002 08:03:18 -0700, ospyng@yahoo.com (spyng) wrote: > > >hi, > >does anyone have experience these? > > > >CLK pad input to FF show up as unconstraint path during timing > >analysis. and reduce coverage of timing constraint (90.5%). These > >un-constraint paths are the clock delay from the clk pad to the clk > >pin of the FFS > > > >Clk Pad input goes through a DCM and generate a internal clk to most > >of the ffs in the design. there is currently a period constraint on > >the clk pad input and during translate, there is message that show > >that the period constraint have been push through the DCM and new > >period constraint had been generated for the internal clock. The > >internal clock period constraint is working fine. > > > >Why are all paths from Clk pad input to all ffs clk pin show up as an > >unconstraint path? > > Because they're not constrained. > > The delay from the input pin to an internal flip-flop or RAM has no > effect on the speed at which the device can be clocked internally. If > you have a 50 MHz period constraint, the internal paths do not care > if the delay from the clock pin to the internal FFs and RAMs is 0.5ns > or 500ns, as long as that delay is common to all devices; in either > case, you'll still be able to run at 50 MHz. (Of course, there is the > issue of whether a 500ns path could actually pass a 10ns pulse, but > that's a topic for another day.) > > I always add constraints for the pads-to-internal-devices clock paths, > because I don't want my unconstrained paths report to be cluttered > with stuff that's actually OK. And it's also a good way to confirm > that the delay is what I expect it to be. For example, I added the > following constraint in the ucf file to a 100 MHz clock passing > through a DCM in a 2V3000: > > TIMESPEC TSCLK04 = FROM PADS(ext_clk100) TO FFS : 0.5; > > Bob Perlman > ----- > Cambrian Design Works > http://www.cambriandesign.comArticle: 42655
Hi. I try to send data into the flash memory of the excalibur kit by the nios, but the example programs (C program files) of the kit don't work, i have changed code and now i can enrase sector of flash but i can't write data. I'm student and i have basic knowledges of C programmation. Thanks; VincentArticle: 42656
All, I think everyone is missing the beauty of the EasyPath program. We run lots of silicon to a specific customer test program, and the yield for just that functionality is good so that we can offer the parts at a price competitive with the price of an ASIC. Thus, no reason to redesign your IP into an ASIC for cost reduction, just make the exact same decisions you would make anyway: freeze the program, stop making changes, and sign up for a big order, with some NRE for the test program. The absolutely fabulous part is that there is no risk. With the ASIC who knows what will happen? How it will yield? What interesting little quirks it may have that will make it just a little less useful than the FPGA was. Even better, is if you do suddenly have to make a change, can the ASIC supplier take back all parts, retest to a new program, and re-issue them? EasyPath offers opportunities for corrective actions that will make any manager able to sleep better at night. Yes, it will cost money to retest. Yes, it will cost moneyy and take time to test product already shipped. And yes, there will be some fallout, depending on the change that was made. But look at the bright side: you will not be stuck with a lot of scrap that people will be making jewely with. Do we care where the non-functional parts and pieces are? No. Do we want to spend anytime trying to identify what is broken? No. Do we want to fill experimenter bags with bogus parts that could be remarked, and sold on the grey market and cause untold grief for our real paying customers? Absolutely not. (anyone remember the grief on bad EPROMs that were re-marked as good, and resold about twenty years ago?). This is a revolutionary concept, one that will change the face of the use of programmable logic. If you want to experiment, you can go back to University, where we have an active program for supporting experimental work. Fill out the request forms for a grant, and see what happens. If we like the project, our R&D group may work with the school and support it. As someone who once upon a time reviewed all Masters and PhD projects for their contribution to the state of the art and present technology at one of the top three Universtities, I can tell you that many projects do not qualify: they have been done better by someone else, most often in industry. Hopefully today with the internet, it is a lot easier to perform the same search that I used to do so long ago (i.e. 1975). Austin Hal Murray wrote: > >Aw, come on. Be serious for a moment. > > > >Is 2 Mbytes enough for video, or is that just not even close for > >something like a high performance MPEG4 coder? Is 1 Mbyte enough for a > >packet processor? What if you are using a 405PPC? How much code space > >do you need for a control program? For a DSP support program (with all > >of the hard stuff in the FPGA like the FFT cores, etc.)? > > > >If you look at SDRAM prices, are you willing to pay twice the commodity > >price in an FPGA? Three times? How much is it worth to you? > > > >I already know that programs grow to fit the available memory space, and > >that data grows to fill the disk..... > > There is obviously an chicken and egg problem. If you put X bytes > of RAM on the chip, then people will dream up ideas to use it. Some > of them won't fit so there will be a market for chips with more RAM. > > I remember a story about Motorola... Nothing firm, just a rumor, > but it seems reasonable. > > They had a good collection of "cores" for their small micro family. > If you would sign up to purchase enough of them, they would build > whatever you wanted from their collection of cores and make it into > a standard product - n A/D, y counters, x ROM, y RAM... Whatever > you wanted from their chinese menu. > > You got normal product type support and documentation. They got > a guaranteed order to cover (some of?) the NRE. > > That sort of chinese menu approach might make sense for something > like Easypath. For example, you could take chips with broken RAM, > zap a few links, and sell them as no-RAM (or smaller RAM) versions. > If volume gets high enough you can make a special/cheaper die. > Same for multipliers, and maybe PowerPC cores. > > -- > These are my opinions, not necessarily my employer's. I hate spam.Article: 42657
Thanks Paul. I will try the .vec approach. You are right Kevin. And I'm in the process of making a transition to the Modelsim OEM version provided by Altera. Hopefully that should be an improvement. Thanks, Prashant "Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in message news:<3cce43b7$0$8510$cc9e4d1f@news.dial.pipex.com>... > You can use a .vec or .vwf file which is just a text representation of the > signal transitions. Edit this and use it as stimulus to your simulation. > Results will still get displayed. > (You can start by saving your current waveform as a .vec/.vwf and looking at > the results/modifying it. > > IMHO however you might want to consider using another simulator that > supports more functions of a testbench. You write a test bench in your HDL > which provides the waveforms and/may even check the results of the Device > Under Test. > > I used to exclusively use waveform entry, but it really becomes limiting for > larger designs and almost impossible to do hierarchical testing. > > Paul > > "Prashant" <prashantj@usa.net> wrote in message > news:ea62e09.0204291455.4f95879@posting.google.com... > > hi, > > I'm using the Quartus II simulator to simulate my design. My design > > has grown and reached a point where I need to load up a thousands of > > different input vectors for a specific input. It would be a waste of > > time to try and do this manually. > > > > Is there a smart way to load many input vector values on a single > > input in the waveform editor of Quartus II waveform editor ? > > > > Thanks, > > PrashantArticle: 42658
YD, Texas Instruments has a web page devoted to powering Virtex and Virtex E. National Semi, Linear Tech, Elantec, and many others all make either low dropout linear regulators, and/or switchers that can be used (and we use ourselves). Read app note 158, 450, and 451. http://www.support.xilinx.com/apps/appsweb.htm Look up 158 under Virtex, and 450 and 451 under Spartan II. Avoid parts that trip, foldback, or shut off. It is OK to trip, foldback, or shutoff only after a time delay (say 20 ms) in order to meet UL or VDE safety requirements. Many regulator parts today will start turning on, sense the current, and if the current exceeds some threshold, they will turn off, and then start up again. This is exactly the kind of behavior you must avoid. It will terminally confuse the startup logic of the Virtex, Virtex E, Spartan II, Spartan IIE, and they will not power ON. The regulator parts which have thermal shutdowns, and are linear current limiting all work fine. Avoid parts that say things like "high speed" as the FPGA is not an Intel chip, and doesn't require 20 amperes in 100 ns. Read the data sheet and be sure you can supply at least the minimum required current for power ON (ie 500 mA for most Virtex C grade parts). Austin Deville wrote: > Hi all, > > For Virtex, are there any issues regarding powering up the different > voltage supplies in different orders? > What sort of component can be use for supplying the Virtex? > > best regards, > > YDArticle: 42659
Any idea why the ISE software would insist on inserting a clock
buffer
on the master reset line for a spartan2E? I checked for edge
requirements on the signal and found none.
Also, probably related, why does it not recognize a startup. Here
is
the code snippet I used.
u0_startup: startup_virtex PORT MAP
(gsr=>master_reset
);
Note Master_reset is a declared port on the top level of the chip.
Is
this the problem?
Also, I have a second input port that is serving as a clock (low
frequency ~100KHz) that also gets a forced clock buffer. Can I
eliminate this? (Or should I do so?) How? Please be specific as I
can
be a little dense sometimes.
Thanks,
Theron Hicks
Article: 42660"Theron Hicks" <hicksthe@egr.msu.edu> schrieb im Newsbeitrag news:3CCEB6D4.62126C0@egr.msu.edu... > Also, I have a second input port that is serving as a clock (low > frequency ~100KHz) that also gets a forced clock buffer. Can I WARNING!!! Dont be fooled by the low frequency!!! If you drive clock onto non-clock nets with heavy loads, skew can (and most probably WILL) kill your design. The clock frequency doesnt matter, since the FlipFlops ALWAYS run at full speed. > eliminate this? (Or should I do so?) How? Please be specific as I > can > be a little dense sometimes. If you have a high speed clock (here >1 MHz), sample this clock (and its related inputs) and work everything on the fast clock net using clock enables (derived from the sampled clock) -- MfG FalkArticle: 42661
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.comArticle: 42662
I had a problem with the DLL locking in one recent design. I've used the DLL many times without problem, so I suspect it had something to do with our strange clocking scheme. But it was never solved due to project time constraints. We did the following, which worked quite well. I ran the DLL reset (the "RST" pin on the DLL component if you're instantiating it in your code) to both a counter and a register bit. The counter performed an automatic reset of the DLL after device reset went away. If software ever wanted to, they could force a DLL reset via register bit. Of course, the host interface in the chip ran from a different clock domain so I had the luxery of doing this. If your host interface clock comes from the DLL then you won't be able to do this (unless you can still access the CCLK as you could back in the XC4000 days). Regards, Dave Matthews Dave Matthews V-Integration - FPGA and ASIC Design Services www.V-Integration.com 978-371-4940 "Barry Brown" <barry_brown@agilent.com> wrote in message news:<1020115122.72002@cswreg.cos.agilent.com>... > My design uses a Spartan-II configured from a PROM, and I'm using a clock > DLL in the FPGA. I have had some problems that I believe are due to > power-up initialization, so I'm trying to come up with a fool-proof scheme > to handle power-on config and reset. Here's my plan: > > 1. My board has a power-supply supervisor, which I will connect to the > PROGRAM input. This will hold off loading configuration until well after > the supply is stable, and in case the power ever glitches, the FPGA should > re-load itself. > > 2. In BitGen, I will set LCK_cycle to 1, so that the startup after > configuration will wait until the DLL is locked. > > 3. I will connect the DONE signal to an input, where I will invert it and > synchronize it and use it as the internal reset for my circuits in the FPGA. > > 4. I will set GTS_cycle = 2, GSR_cycle =3, and GWE_cycle = 3. I will set > DONE_cycle = 6. Therefore, my internal reset will be asserted until a short > while after the DLL is locked and the GSR is released. > > Anyone see a problem here? > > Thanks, > Barry BrownArticle: 42663
I am looking at the timing on the memory bus for the C6711B DSP when driven from the FPGA and I don't see any data in the SpartanIIE data sheet for output hold timing. Am I missing something or is the output hold time not specified? How can you interface to external SDRAM or SBSRAM, both of which have input hold times greater than zero, if the FPGA output hold time is not specified? Do I have to design the full hold time as routing delay on the PCB? I hate doing timing design with FR4! :( -- 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: 42664
I belive there are minimum numbers on the datasheet, I'd look for minimum clock to out (with or without DLL, based on your design). I didn't check, but you may want to. Eric rickman wrote: > > I am looking at the timing on the memory bus for the C6711B DSP when > driven from the FPGA and I don't see any data in the SpartanIIE data > sheet for output hold timing. Am I missing something or is the output > hold time not specified? > > How can you interface to external SDRAM or SBSRAM, both of which have > input hold times greater than zero, if the FPGA output hold time is not > specified? > > Do I have to design the full hold time as routing delay on the PCB? I > hate doing timing design with FR4! :( > > -- > > 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: 42665
Input hold times are ugly, that's why all Xilinx FPGAs have had extra input delays since the XC3000 days, in order to guarantee a "negative hold time". When you have to drive a (dumb) chip with a positive hold time requirement, you need to guarantee a min delay on the driving output ( some people call that an output hold time). Such a min delay is usually not specified, since it is very difficult to measure, and, if guaranteed, would preclude "down-binning" i.e. branding fast chips as slow. Here are a few suggestions: •You can rely on the speed of light, >150 ps per inch on a pc-board. •For the fastest speed grade, you can assume the min parameter to be >25% of the specified max value ( for clock-to-out) •You can deliberately delay the internal clock that drives the output in question. •In Virtex-II you can do that with the precision phase-shift in the DCM. •In slow applications you can use the opposite clock edge. Positive input hold times are a real pain in the ***. They are an indication that the chip manufacturer cares more about fancy performance specifications than about reliable operation in a real system... Peter Alfke, Xilinx Applications ========================================== rickman wrote: > I am looking at the timing on the memory bus for the C6711B DSP when > driven from the FPGA and I don't see any data in the SpartanIIE data > sheet for output hold timing. Am I missing something or is the output > hold time not specified? > > How can you interface to external SDRAM or SBSRAM, both of which have > input hold times greater than zero, if the FPGA output hold time is not > specified? > > Do I have to design the full hold time as routing delay on the PCB? I > hate doing timing design with FR4! :( > > -- > > 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: 42667
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 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: 42668
Barry, If the feedback comes from an external source, then there is the possibility that the DLL is trying to start up before the feedback signal is present on the DLL CLKFB pin. Then there are the usual suspects: the CLKIN signal isn't really stable immediately after configuration, when all the design wakes up and starts switching, the power supplies suddenly sag (bad power regulation) and the DLL can't accomodate such a large supply shift, or the cross talk induced delay when things start switching or the jitter pops the DLL out of LOCK. Austin Barry Brown wrote: > My design uses a Spartan-II configured from a PROM, and I'm using a clock > DLL in the FPGA. I have had some problems that I believe are due to > power-up initialization, so I'm trying to come up with a fool-proof scheme > to handle power-on config and reset. Here's my plan: > > 1. My board has a power-supply supervisor, which I will connect to the > PROGRAM input. This will hold off loading configuration until well after > the supply is stable, and in case the power ever glitches, the FPGA should > re-load itself. > > 2. In BitGen, I will set LCK_cycle to 1, so that the startup after > configuration will wait until the DLL is locked. > > 3. I will connect the DONE signal to an input, where I will invert it and > synchronize it and use it as the internal reset for my circuits in the FPGA. > > 4. I will set GTS_cycle = 2, GSR_cycle =3, and GWE_cycle = 3. I will set > DONE_cycle = 6. Therefore, my internal reset will be asserted until a short > while after the DLL is locked and the GSR is released. > > Anyone see a problem here? > > Thanks, > Barry BrownArticle: 42669
Try setting the port to all 'Z'. You can still use the input side of the port. I'm assuming the port is defined as "inout" in the port map? - Pete Koziar Principle Engineer, VLU-120 Orbital Sciences/TMS (http://www.orbtrac.com) creon100@yahoo.com (Sean) wrote in message news:<b97bab2f.0204251138.12476582@posting.google.com>... > It's me again, in my ongoing saga and struggle with this ISA bus > implementation. > > I am communicating over the bus fine now, but am having problem with > my synthesizable VHDL. > > The way it is working is that we have VHDL modules describing an input > (as seen by the PC) port and an output ISA port. We're going to have > about four input ports and one or two output ports in the description > of the chip (meaning it will respond to about six I/O address, some > for read, some for write). > > The input port description synthesizes with a tristate data bus. > However, the output port synthesizes with only an input bus since it > will only be reading the bus, and only doing that when it's address is > present (hence, no bus contention). When I do a top-level design > using one input port and one output port it creates the data bus fine > and creates iobufs on the bus. However, for some reason when I have > one ouput port and two input ports the synthesis tool gives a warning > saying there is no port type for the data bus and automatically gives > it only output buffers. > > This results in the following problem. Once the chip is programmed by > the PC the data bus automatically causes contention on the bus and so > the PC goes crazy. > > I just don't understand why it would suddenly not be able to determine > the my bus needs to be a tristated iobuf instead of just an output > buffer.Article: 42670
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: 42671
Peter Alfke wrote: > > Input hold times are ugly, that's why all Xilinx FPGAs have had extra input > delays since the XC3000 days, in order to guarantee a "negative hold time". > When you have to drive a (dumb) chip with a positive hold time requirement, you > need to guarantee a min delay on the driving output ( some people call that an > output hold time). > > Such a min delay is usually not specified, since it is very difficult to > measure, and, if guaranteed, would preclude "down-binning" i.e. branding fast > chips as slow. I guess I am a little confused. I had the impression that the SpartanIIE devices (I am not working with VirtexII devices) were compatible with SDRAM and SBSRAM interfaces. These interfaces specify hold times of 0.8/0.5 nS respectively. How does the SpartanIIE FPGAs work with these devices if you don't spec a minimum output hold time? Do you require the user to add 5 inches of board routing to the data path? Because of the problem caused by the long hold time of the C6711B DSP, there will likely be an additional route delay of 1 nS to the SBSRAM which will add to the output hold time requirement of the FPGA unless we are very careful about clock vs. data routing. I had hoped that by keeping the board small and all routing very short, I would minimize the SI issues involved. However it is looking like TI is going to torpedo my efforts in this regard. I don't see how spec'ing a min hold time would preclude downbinning. For example if you spec'ed 0.8 nS hold time on all of your speed grades, then you if a chip tested faster in the max clock to out, but met the min, it could still be used for the slow. Just because you have a min spec does not mean it has to change with speed grade. The max value of clock to output with the DLL in use is 3.1 nS on the Spartan-IIE -6 grade. 25% of this is just a hair under 0.8 nS. Couldn't this be spec'ed at 0.8 nS and easily tested? IIRC, the 25% estimate is intended to include the fabrication of faster parts over the forseeable lifetime of the chip. Can't Xilinx sign up to this estimate by spec'ing it in the data sheet? > Here are a few suggestions: > •You can rely on the speed of light, >150 ps per inch on a pc-board. That would require 5 inches of routing on a 3.6" sq board. Not an easy solution without adding a delay line layer. > •For the fastest speed grade, you can assume the min parameter to be >25% of the > specified max value ( for clock-to-out) This is useful. But is there a reason that this can not be spec'd in the data sheet? How can you work with standard memory parts without this specification? > •You can deliberately delay the internal clock that drives the output in > question. Can you give details on this? Does it require the use of a DLL? Can the DLL be used independantly of the clock routing, that is, if I already am using all four clock buffers, can I use the DLL as a fifth, or do I need to delete one of the other clocks? > •In Virtex-II you can do that with the precision phase-shift in the DCM. We are not using the Virtex-II parts. We are using the SpartanIIE to try to make an economical board. > •In slow applications you can use the opposite clock edge. This is a 100 MHz memory interface. I think that would prevent meeting the setup times. > Positive input hold times are a real pain in the ***. They are an indication > that the chip manufacturer cares more about fancy performance specifications > than about reliable operation in a real system... Positive input hold times may be a PITA, but they are a part of high speed digital design in the 21st century. I don't make the rules, I just have to design by them. If Xilinx does not like positive input hold times, then they should get on the memory interface spec committees and change them. But in the meantime we all have to design with positive input hold times. > Peter Alfke, Xilinx Applications > ========================================== > rickman wrote: > > > I am looking at the timing on the memory bus for the C6711B DSP when > > driven from the FPGA and I don't see any data in the SpartanIIE data > > sheet for output hold timing. Am I missing something or is the output > > hold time not specified? > > > > How can you interface to external SDRAM or SBSRAM, both of which have > > input hold times greater than zero, if the FPGA output hold time is not > > specified? > > > > Do I have to design the full hold time as routing delay on the PCB? I > > hate doing timing design with FR4! :( > > > > -- > > > > 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: 42672
Austin Lesea wrote: > > All, <snip> > Do we care where the non-functional parts and pieces are? No. Do we > want to spend anytime trying to identify what is broken? No. Do we > want to fill experimenter bags with bogus parts that could be > remarked, and sold on the grey market and cause untold grief for our > real paying customers? Absolutely not. (anyone remember the grief on > bad EPROMs that were re-marked as good, and resold about twenty years > ago?). I had seen this as a risk exposure, and since you have now mentioned it, what actually stops these devices comming back to bite users ? > This is a revolutionary concept, one that will change the face of the > use of programmable logic. Sorry, but not at the MOQ and NRE's.... As to revolutionary ? - I've heard stories about russian programmers being given chips with an errata tagged to each device. They had to work around the errata on a batch basis ! -jgArticle: 42673
In article <3CCEEE48.1B6EA5BA@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: > >> •You can deliberately delay the internal clock that drives the output in >> question. > >Can you give details on this? Does it require the use of a DLL? Can >the DLL be used independantly of the clock routing, that is, if I >already am using all four clock buffers, can I use the DLL as a fifth, >or do I need to delete one of the other clocks? Ick, if you are using all the clock buffers, this would be problematic. Otherwise, you drive the I/O output flip-flops with a 90 degree phase offset from the bus clock, asuming you would still meet other timing constraints. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42674
Austin Lesea wrote: > > YD, > > Texas Instruments has a web page devoted to powering Virtex and Virtex > E. > > National Semi, Linear Tech, Elantec, and many others all make either low > dropout linear regulators, and/or switchers that can be used (and we use > ourselves). > > Read app note 158, 450, and 451. > > http://www.support.xilinx.com/apps/appsweb.htm > > Look up 158 under Virtex, and 450 and 451 under Spartan II. > > Avoid parts that trip, foldback, or shut off. It is OK to trip, > foldback, or shutoff only after a time delay (say 20 ms) in order to > meet UL or VDE safety requirements. > > Many regulator parts today will start turning on, sense the current, and > if the current exceeds some threshold, they will turn off, and then > start up again. This is exactly the kind of behavior you must avoid. > It will terminally confuse the startup logic of the Virtex, Virtex E, > Spartan II, Spartan IIE, and they will not power ON. > > The regulator parts which have thermal shutdowns, and are linear current > limiting all work fine. > > Avoid parts that say things like "high speed" as the FPGA is not an > Intel chip, and doesn't require 20 amperes in 100 ns. > > Read the data sheet and be sure you can supply at least the minimum > required current for power ON (ie 500 mA for most Virtex C grade parts). > > Austin What about the so called snap-action regulators ? -jg
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