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
Not forgetting of course the Elite Edition. Don't know what they'll call the version needed for the next range of huge parts - Annointed ? Maybe, following Douglas Adams, ``The Edition that is to come after me whose very command line flags I am unworthy to enumerate''Article: 26126
Jens Konig wrote: > > Hey, I know those spikes on signals simply routed 1to 1 through XC9572. They're coming from (that's what I think) crosstalk on the chip from other signals. This is fact since Xilinx changed from ASJ9745 to AEM9917 (new Mask+Manuf). Seems like having many bad sideeffects also. Can you clarify this some more ? Is it just visible, or causing actual downstream disturbance ? It is not uncommon for LOGIC devices to have light Voh pullups, and thus visible cross talk/ Vcc common mode noise effect 'grass' on the HI levels, but they should be well clear of the LOGIC thresholds. The edges, and Vol levels should be much cleaner. -jgArticle: 26127
Hi, Gabriel, > The question is for Boundary Scan Test. Each pin of an LVDS Signal > is connected to an independant BS cell. So It seems like it will be > a problem to read or drive an LVDS Signals in Boundary Scan mode > since the datasheet says that "Boundary-scan operation is > independent of individual IOB configurations". Note that we aim at > develloping extended test and that the FPGA will be connected to a > LVDS to LVTTL buffer which is not JTAG compliant. > So Is it possible to perform a Boundary Scan Test with LVDS Signals > ? And if yes how ? As I understand it, it *is* possible . . . you simply set your pair of output pins such that one of the is logic '1', and the other one is logic '0'. And then you invert them both. This gives you two differential logic levels. If I'm not mistaken, LVDS is 2.5v logic; I beleive that during the JTAG test the LVDS outputs will be the same as the Vccio pins for that I/O bank, so you should be safe there, too. Warning: You are going to run into a problem if your LVDS signals are AC-coupled. JTAG is inherently slow; I find that our JTAG clock is between 1 MHz and 5MHz maximum. Consider that you have to shift in data for each pin of the FPGA every time you change the JTAG output pins, then you can only toggle the output pins at a frequency less than (1~5MHz / Pin Count). I'm guessing 15 KHz maximum. Hope this helps. -KentArticle: 26128
Allan,
It sounds as if you are operating at the limits of the speed-power
curve on the device.
Concerning the DLL losing lock but the LOCKED output not being
deasserted, I remember a while back when I started using Virtex parts and
DLLs that a Xilinx person (perdaughter? :) ) told me that the LOCKED output
was only deasserted when the RESET input was asserted. I didn't use LOCKED
and I didn't have the problem that you're having or similar problems, so I
never investigated this further. But I couldn't help but wonder why the
LOCKED signal couldn't represent the true status of the DLL. Maybe they
have changed this function, maybe not, but you might want to ask your
favorite Xilinx person if you have to assert the RESET input to deassert the
LOCKED signal.
-Simon Ramirez, Consultant
Synchronous Design, Inc.
> Has anyone else seen this phenomenon, or have some idea as to the cause?
> I can understand that the DLL might lose lock due to noise, but why
> wouldn't the locked output be deasserted?
>
> Thanks,
> Allan.
>
Article: 26129I guess it's safe to say then that nobody can help explain hings to me? That's an excellent idea to have a Product selection Matrix. For each device, include Packages, Max IO's, Compatable ROMs (see below), and software license features. But if we end up with an "annointed" version, you do now that it' sonly a matter of time until you can get the "annointed professional" version. when "Annointed Pro" comes out, they're preoaobly re-release "Annointed" as "Annointed Student Edition". (Would that be "Accolade Edition"?) Isn't this Time Based License scheme still shiny new? And they're discarding it already? On a related note (in that it's something else from Xilinx that I don't understand), can anyone guide me as to PROMs? The XCV-150 and the XC2S-150 are bitstream-compatable, right? Does this imply that they can use the same PROMs? This is the information that I have from the xilinx website. Note the conflicts. Document # Device Required Size Suggested PROM PROM Size ds030.pdf XC2S150 1'040'128 XC17S150XL ? ds073.pdf XCV150 1'040'096 XC17V01 1'679'360 ds027.pdf XCV150 1'041'128 XC1701L 1'048'576 fpga5b.htm XCV150 1'038'944 XC1701L Does anyone know the size of the Spartan-II ROM listed above, and whether or not I can use it with the Virtex? Thanks. -KentArticle: 26130
Xilinx 3.1i service pack 3 mentions a problem where the clamp diodes are enabled for LVCMOS2 and LVDS when they should not be. http://support.xilinx.com/techdocs/9922.htm This might be your problem. Alan Nishioka alann@accom.com In article <ee6e2e2.-1@WebX.sUN8CHnE>, "Pauric Hennessy" <pauric.hennessy@ashling.com> wrote: > I'm currently using a virtex e device with bank 2 VCCO= 3.3V and all other banks connected to 2.5V. > I've got LVDS receivers powered off 3.3V connected to banks 4 and 5. 3.3V levels are thus supplied on these banks. > After configuration I see that the 3.3V rail is supplying a portion of the power to the 2.5V rail throuht some unknown path.Currently I'm powering the 3.3V rail and 2.5V rail off a current limited bench supply. Eventually the current drawn from the 2.5v bench supply reaches 0mA and can be removed from the equation- 2.5V being maintained by the 3.3V supply through some unknown path. > With my LVDS bank disabled and all outputs <0.8V then the 2.5V rail is ok. However enabling the 32 outputs of the LVDS sets them to 3.3V and this gets passed on to the LVCMOS2 i/ps on the FPGA. In this scenario the 2.5V rail rises to 2.8V. > The FPGA's are still functioning and performing as designed- but I need to know what is going on here- are my devices damaged? Are there clamp diodes on LVCMOS2 i/ps that allow 3.3V to migrate onto the 2.5V rail!! > Has anyone else haqd a similar experience. > rgds > Pauric > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26131
Upon further investigation, it looks like this bug/fix applies only to virtex and not to virtex-E. Alan Nishioka Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26132
I am doing a project using hardware encryption and am looking for 3DES VHDL open source. If anyone knows where this is available, please advise. Thank you. Michael Fluet mfluet@wpi.eduArticle: 26133
Hi Austin, > >The subject of bypass gets re-hashed on a fairly regular basis. This article is useful as it is accurate as far as it goes. > Indeed it does! For those who haven't found it and are interested in these areas, I find the signal integrity reflector talked about earlier in this thread very helpful. >In an FPGA, where we don't have a clue what you, the customer, are going to do, bypassing takes on a much more difficult task. > Yep! >One approach is to concern yourself with the determination of how much current is required at each possible frequency, and the resulting bypass reactance vs. >frequency, and then design a series of capacitance networks (capacitors of differring values and types) to cover the reactance vs frequency desired. >i.e. less than 2 ohms from 0 to 1 GHz. You are still guessing at the peak current with this method, as you note in your comments. > >The "switched capacitance approach" used by me and others is another solution. For example, if the amount of capacitance switched by the IO's is X pF, then if I >want less than 4% dV/dt (~150mV noise), I need to have 25 times X pF to bypass that one IO. Still a guess as to the peak currents, but perhaps an >overly conservative guess. > Interesting, I haad pondered using this approach also. Do the results not end up the same though as they are both estimating a worst case peak current? >Now IO's don't actually switch capacitance (the loads may be inductive, resistive, or capacitive due to the transmission line and its length on the PCB). As such, >the switched C approach is an estimate of a worst case. Add up the residual C of the points driven, not including the t-lines (t-lines are NOT >capacitors at the edge rate, nor the data rates). T-lines transform the impedance at one end to the other end. A capacitive load may look inductive if the length is >1/4 wave for the frequency dominant in the edge. > >This may still be a 10X over estimate, as package C includes the t-line of the package (again not a capacitor). Driving a bank of parallel connected IC's (RAM's) >does look like a big C. > Agreed! <Core bypassing> >Often forgotten is that the die has capacitance itself in the structures (self-bypassed) for both the core and the IO's. So does the multi-layer laminate packaging. >That is why a 0.1uF cap still works after all these years. The local capacitance is small, but highly effective at the edge rates of the logic >or IO. It is the 'refilling' of this internal capacitance that the external capacitors must accomplish. > This was somethig I was going to bring up. Is there any way that we can get useful information on this to aid our calculations? <snip - but agreed!> >Simultaneous switching outputs are to be floor-planned because if all of the outputs of a bank all go from a 1 to a 0 on a a clock edge, you will most definitely >collapse the on-chip Vcco! See the SSO guidelines which define the most outputs allowed in the best bypassing case. > Unfortuanatly I am in Altera land, and I haven;t seen any app notes yet from them. If only they could be persuaded to contribute in this forum! I am getting increasingly fristrated with the lack of support I feel from Altera at times! >In our appnote 158 (re-write due to be released perhaps this week), we make a point of recommending a number of large capacitors precisely because we don't >know what the frequency distribution is, and you probably are not sure either. > If you do know the frequency distribution - as I do to a large extent in my application - there are even more sums to be done! Or I can play safe and whack a number of large caps down :-) Martin TRW Automotive Advanced Product Development, Stratford Road, Solihull, B90 4GW. UK Tel: +44 (0)121-627-3569 mailto:martin.j.thompson@trw.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26134
des core at www.free-ip.com Mike Johnson Michael Fluet <mfluet@wpi.edu> wrote in message news:39DBF0F0.DC4D32F3@wpi.edu... > I am doing a project using hardware encryption and am looking for 3DES > VHDL open source. If anyone knows where this is available, please > advise. Thank you. > > Michael Fluet > mfluet@wpi.eduArticle: 26135
On Wed, 04 Oct 2000 23:09:36 -0400, Michael Fluet <mfluet@wpi.edu> wrote: >I am doing a project using hardware encryption and am looking for 3DES >VHDL open source. If anyone knows where this is available, please >advise. Thank you. > >Michael Fluet >mfluet@wpi.edu Hmmm... guess it beats traffic lights. David Kessner has done a VHDL DES core at www.free-ip.com/DES/index.html. A colleague of mine had a go at putting it on an ORCA, and came to the conclusion that it was much bigger than it needed to be, though he may have been wrong (I wasn't allowed to look at it). It's not 3DES, and the work necessary in selecting and implementing a 3DES mode is more or less as much as doing the basic DES algorithm. David has a simulation on the site, but you'll need something heavier-duty if you want to prove that it's actually DES (get the FIPS test suite). EvanArticle: 26136
On Thu, 05 Oct 2000 01:04:24 GMT, "S. Ramirez" <sramirez@deleet.cfl.rr.com> wrote: >Allan, > It sounds as if you are operating at the limits of the speed-power >curve on the device. > Concerning the DLL losing lock but the LOCKED output not being >deasserted, I remember a while back when I started using Virtex parts and >DLLs that a Xilinx person (perdaughter? :) ) told me that the LOCKED output >was only deasserted when the RESET input was asserted. I didn't use LOCKED >and I didn't have the problem that you're having or similar problems, so I >never investigated this further. But I couldn't help but wonder why the >LOCKED signal couldn't represent the true status of the DLL. Maybe they >have changed this function, maybe not, but you might want to ask your >favorite Xilinx person if you have to assert the RESET input to deassert the >LOCKED signal. I'd be very surprised if this was the case. It's not how the simulation model works (for Virtex, don't know about Virtex-E), so it wasn't the intention. Allan: > Has anyone else seen this phenomenon, or have some idea as to the cause? > I can understand that the DLL might lose lock due to noise, but why > wouldn't the locked output be deasserted? The only gotcha I can think of is that the lock output will remain asserted if the input clock stops, but this doesn't seem to be your problem. Are you sure the input clock is still running? I'd be inclined to check the DLL connections on FPGA Editor to make sure that it's wired up the way you think it is. EvanArticle: 26137
I could not run Boardscope with the -board parameter except -Demo The command line of Boardscope is "java RunBoardScope -<Board>" For -board parameter, there are several options: Demo, PametteVDC, pamettevdc800, rc1000pp, Custom,etc. But I only could run Boardscope with -Demo. When I selected other options, I got the following error message: "Could not load librar PVDCStubs UnsatisfiedLinkException: java.lang.UnsatisfiedLinkErro: no PvdcStubs in java.library.path" How can I solve it? Thanks!Article: 26138
In article <39DB4538.BBE59824@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > If I understand you right, you are suggesting you use an IOB to generate the > logic 0 or logic 1 signal? If that is the case, then I am assuming you are > doing so by either externally tying the pin, or internally using the pad pull-up > and leaving the pin floating. In either case, you tie up the pin so it can't be > used for something else. Where many designs are already pin limited, I don't > think it makes sense to use an IOB for a function that can be accomplished > better by a core cell. I then mentioned an exception might be if you used an > unbonded pin as the generator, since those IOBs are otherwise unusable anyway. Thanks Ray for the reply This what i meant.I don't see that "sacrifying" two IOBs will cause a problem, especially for one input data - one output design as is the case for most of (my)applications. Actually, I am working in modular design, I always wonder how times i have to duplicated the VCC and GND. This has really an effect if i want to generated a high level description for my deisgn. so i told let's connect the VCC and GND to the IOB. doing so, my high level description could be written easier... any comment from the xilinx people... Regards --Erika > > erika_uk@my-deja.com wrote: > > > > any more explanation,ray, i don't see really what do you mean > > > > In article <39DA4D27.D380F6E8@andraka.com>, > > Ray Andraka <ray@andraka.com> wrote: > > > SO you are using up a pin to get your fixed logic '1' or '0' ???? > > Perhaps from > > > an unbonded pin... > > > > > > erika_uk@my-deja.com wrote: > > > > > > > > hey, > > > > > > > > Sourcing a GND and VCC was an issue weeks ago in this news group. > > > > > > > > Xilinx claims that the Virtex is rich in terms of routing > > ressources, > > > > so why not source the Pwr and Gnd wires from the IOB? > > > > > > > > I know a friend who does so in the xc4k, is it not possible in > > virtex ? > > > > > > > > --Erika > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > > Before you buy. > > > > > > -- > > > -Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email ray@andraka.com > > > http://www.andraka.com or http://www.fpga-guru.com > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.com > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26139
bob elkind <eteam@aracnet.com> wrote: : In any case, this is a real quick check which gives unambiguous results. : Regardless of which way the test ends up, you've learned something about : the problem. I agree it's a quick test, but I'm not so sure about "unambiguous". The problem I was having, which turned out to be nothing to do with timing (it was caused by crosstalk into the JTAG inputs), also went away (or was substantially reduced) by freezing the chip. I assume the temperature change affected logic thresholds. Richard. http://www.rtrussell.co.uk/Article: 26140
Ray Andraka writes: > ... doesn't require my customer to have the extras to support the design. Is it principally due to $$$, or training & tool familiarity? Specifically, if there was a really good GPL synthesis tool (no license fee + you have the source), and the tool suited your style of work, would you use it for customer project? Or would there still be a significant non-technical barrier for use of a new tool? I was talking to an Altera FAE who felt that going into competition with Synplicity on synthesis via the GPL route would be no good because customers are far too reluctant to switch tools. I suspect $$$ may have something to do with this though. Any well put together tool should do its best to fit in with the customer's existing tools. (The Altera connection was because the FAE thought Synplicity had access to low-level FPGA data that even he did not have, and despite saying that Altera are 100% a hardware company they still won't be making it easy for third parties to develop good bitstream-level optimisers). -- JamieArticle: 26141
You normally shouldn't have to be defining vcc and ground. putting a '1' or '0' on the right side of your assignments should let the tools do it. For example: std_logic_signal<='1'; slv_signal<="1000111"; or in a component instantiation: u1:fdc port map( C=> clk, D=> flip_flop_d, CLR=>'0', Q=> flip_flop_Q); In this way, the tools will automatically create at least 1, and probably several each of '1' and '0' generators in the interior of the array. The reason, again, this was a topic of discussion a while back was that there was a bug in the xilinx mapper that assigned all the SRL 16 address inputs to one set of generators, which for designs using a large number of these could put too many loads on one generator (a real problem for the '0' generators since each lut has a weak pullup on it. It also can have the effedt ocongesting routing. Speficially instantiating a single '1' or '0' source carries with it the potential for ovrlaoding the source and congesting routing as well. There can never be too many IO pins. If you have some unused, it makes sense to make judicious connections with those to facilitate an easier debug, or to make your board more flexible so that it might be used in othr applications. Also, be aware that using a bonded IO and it's internal pullup for this leaves an avenue to introduce emi into your design, as you have a fairly high impedance antenna. erika_uk@my-deja.com wrote: > > In article <39DB4538.BBE59824@andraka.com>, > Ray Andraka <ray@andraka.com> wrote: > > If I understand you right, you are suggesting you use an IOB to > generate the > > logic 0 or logic 1 signal? If that is the case, then I am assuming > you are > > doing so by either externally tying the pin, or internally using the > pad pull-up > > and leaving the pin floating. In either case, you tie up the pin so > it can't be > > used for something else. Where many designs are already pin limited, > I don't > > think it makes sense to use an IOB for a function that can be > accomplished > > better by a core cell. I then mentioned an exception might be if you > used an > > unbonded pin as the generator, since those IOBs are otherwise > unusable anyway. > > Thanks Ray for the reply > > This what i meant.I don't see that "sacrifying" two IOBs will cause a > problem, especially for one input data - one output design as is the > case for most of (my)applications. > > Actually, I am working in modular design, I always wonder how times i > have to duplicated the VCC and GND. This has really an effect if i > want to generated a high level description for my deisgn. so i told > let's connect the VCC and GND to the IOB. doing so, my high level > description could be written easier... > > any comment from the xilinx people... > > Regards > > --Erika > > > > > erika_uk@my-deja.com wrote: > > > > > > any more explanation,ray, i don't see really what do you mean > > > > > > In article <39DA4D27.D380F6E8@andraka.com>, > > > Ray Andraka <ray@andraka.com> wrote: > > > > SO you are using up a pin to get your fixed logic '1' or '0' ???? > > > Perhaps from > > > > an unbonded pin... > > > > > > > > erika_uk@my-deja.com wrote: > > > > > > > > > > hey, > > > > > > > > > > Sourcing a GND and VCC was an issue weeks ago in this news > group. > > > > > > > > > > Xilinx claims that the Virtex is rich in terms of routing > > > ressources, > > > > > so why not source the Pwr and Gnd wires from the IOB? > > > > > > > > > > I know a friend who does so in the xc4k, is it not possible in > > > virtex ? > > > > > > > > > > --Erika > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > > > Before you buy. > > > > > > > > -- > > > > -Ray Andraka, P.E. > > > > President, the Andraka Consulting Group, Inc. > > > > 401/884-7930 Fax 401/884-7950 > > > > email ray@andraka.com > > > > http://www.andraka.com or http://www.fpga-guru.com > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > Before you buy. > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com or http://www.fpga-guru.com > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26142
>>>>> "AB" == Anders Boström <anders@sid.netinsight.se> writes: AB> I've been running the win32-version of Xilinx P&R tools successfully AB> under wine for quite some time. Unfortunately , the latest version, 3.2i AB> (aka. 3.1i sp3), seem to trigger a bug in wine. AB> I'm running Debian potato, and have tried both the standard potato AB> version of wine, 20000109, and the current woody version, AB> 20000909. Both crashes repeatably at the same place, see below for AB> details. I can happily announce that this issue is solved, mostly thanks to Andreas Mohr and James Abbatiello! Wine release 20001002 includes a fix for the heap-bug that Xilinx P&R tools trigger in older versions. Everybody running Xilinx P&R tools under wine should upgrade to release 20001002. / AndersArticle: 26143
Was this the super computer talking? Or Marvin the paranoid android? Rick Filipkiewicz wrote: > > Not forgetting of course the Elite Edition. Don't know what they'll call the version needed for the next > range of huge parts - Annointed ? Maybe, following Douglas Adams, > > ``The Edition that is to come after me whose very command line flags I am unworthy > to enumerate'' -- 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26144
Hchen wrote: > > I could not run Boardscope with the -board parameter except -Demo The command line of Boardscope is "java RunBoardScope -<Board>" For -board parameter, there are several options: Demo, PametteVDC, pamettevdc800, rc1000pp, Custom,etc. > > But I only could run Boardscope with -Demo. When I selected other options, I got the following error message: > > "Could not load librar PVDCStubs UnsatisfiedLinkException: java.lang.UnsatisfiedLinkErro: no PvdcStubs in java.library.path" > > How can I solve it? Thanks! Do you have one of these other boards? If not, you will get the error, unless you run BoardScope in demo mode. I admit, its not like the worlds most graceful failure, or clearest error message. But note, once you are in 'demo' mode, you can then load up the simulator, and emulate the device you eventually want to target. In general, you are better to write to jbits@xilinx.com with problems like this. Phil -- --------------------------------------------------------------------- __ / /\/ Dr Phil James-Roxby Direct Dial: 303-544-5545 \ \ Staff Software Engineer Fax: Unreliable use email :-) / / Loki/DARPA Email: phil.james-roxby@xilinx.com \_\/\ Xilinx Boulder ---------------------------------------------------------------------Article: 26145
bob elkind wrote: > <snip> > Would anyone in X-land care to alpha-test a software product selection > matrix chart to this newsgroup ? Guaranteed we are a friendly and > technologically sophisticated test group! (does the smiley face go here?) > > -- Bob Elkind > Good suggestion, and I will try to collect ( or, better yet, get somebody to collect ) this information. I published a chip overview in the recent edition of our XCell magazine, and I want to publish a similar overview of our software poducts. Please hang in there... Peter Alfke, Xilinx ApplicationArticle: 26146
Daniel Nilsson wrote: > > Hi. I wonder what it would take to make a sharc dsp to pci controller (I > only need very basic pci functionality, enough to control a pci ethernet > card, with dma). PLX or AMCC make the stuff you need... http://www.plxtech.com/ http://www.amcc.com/ Regards, IwoArticle: 26147
Allan, The LOCKED output may transition LOW on losing LOCK, and then anomolously go HIGH again, even though the DLL is not in the LOCK state anymore. This is a known behavior that has been addressed in future devices. It will not be addressed in the present devices, as this can be worked around by logic that latches a LOW if LOCKED is ever LOW. Causes of this are that the input jitters more than about 700 ps from one edge to the next. To determine that your input is 'clean' may require careful jitter analysis. It is also true that if the clock is lost for any reason, or an input clock edge is missing, the DLL will behave as you state. We recommend that the DLL be reset once the clock input signal is known to be stable. As to the influence of other nodes switching, if the input jitter is already marginal, and internal switching occurs, there is some small amount of added jitter do to all of the logic bouncing around. This may be sufficient to then break lock more frequently. Observation of SSO guidelines, proper SI engineering, proper bypass capacitor selection, etc. are all required to keep the logic clean and working. We have switched entire banks of IO's from 1's to 0's, and switched all other global clock resources at unrelated rates to analyze the self jitter contributions of the device. Please send me an email at austin@xilinx.com if you are interested in a particular case, Austin Allan Herriman wrote: > Hi, > > I have a problem with a Virtex-e part that has symptoms very similar to > those described in the recent thread "Virtex 'shutdown' phenomenon" > initiated by Richard Russell. > > In my case however, a DLL stops producing a clock after a few seconds to > a few minutes. The "locked" output of that DLL remains high, even > though the input clock is still present. > Other DLLs (running at lower rates) on the same chip continue to produce > clocks. > > This problem doesn't happen if the clock is less than 130MHz, and > happens regularly above 150MHz. > It seems to happen more often if data signals on the fpga are toggling. > > Once the DLL stops, the part has to be reloaded to get it to work again. > > The connections are basically identical to XAPP 132 Figure 9 "Standard > DLL Implementation" (except that a DLLHF has been used, and that the > reset input of the DLL is connected to gnd). > > The clock input is HSTL_I, and is clean. The reference voltage is > correct and is also clean. > > Has anyone else seen this phenomenon, or have some idea as to the cause? > I can understand that the DLL might lose lock due to noise, but why > wouldn't the locked output be deasserted? > > Thanks, > Allan.Article: 26148
This is a multi-part message in MIME format. --------------4E3D14C6D0CA5B341159C5B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jens, Are you reasonably sure it is not ground bounce, or very high frequency junk on input? Got a good ground plane, good vias to it, and well placed de-coupling caps? How large (how much energy is in) are the spikes you are seeing? I am annoyed with 9500 parts (I'd like them a lot if they didn't have these mysterious time-wasting problems), would like to see some note from Xilinx on what may be any issue with them. Otherwise, they're outta here for all new designs (and possibly some older ones). Unfortunately, we are not a mega-purchaser of these. If you've got their attention on this, could you forward any response from them to the group? Mistakes happen, properly one owns up to them. I think Xilinx continues to have the most advanced FPGA parts, wish they would devote such caring expertise to the CPLD side. Jens Konig wrote: > > Hey, I know those spikes on signals simply routed 1to 1 > through XC9572. They're coming from (that's what I think) > crosstalk on the chip from other signals. This is fact > since Xilinx changed from ASJ9745 to AEM9917 > (new Mask+Manuf). Seems like having many bad sideeffects also. --------------4E3D14C6D0CA5B341159C5B3 Content-Type: text/x-vcard; charset=us-ascii; name="jsmith.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John L. Smith Content-Disposition: attachment; filename="jsmith.vcf" begin:vcard n:Smith;John L. tel;fax:858-457-0888 tel;work:858-320-4102 x-mozilla-html:FALSE url:http://www.visicom.com org:Visicom;Imaging Products adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA version:2.1 email;internet:jsmith@visicom.com title:Principal Engineer x-mozilla-cpt:;11776 fn:John L. Smith end:vcard --------------4E3D14C6D0CA5B341159C5B3--Article: 26149
It turns out that there's no falling-edge triggered write-clock RAM in the Spartan/XL libraries, and it seems as if the synthesis tools know that and are unable to come up with a reasonable workaround. A Xilinx tech-support guy has just informed me he has requested that a RAM16X1D_1 (falling-edge triggered clock) element will be added to the Spartan libraries. When that will occur is anyone's guess, but it's progress! Hopefully, the synthesis tools will realize that such a library element exists and use it! The suggested work-around was to do a black-box instantiation of the RAM and clock inverter, and the map and P&R tools should do the right thing. Turns out that my workaround was somewhat easier: this clock signal comes from another board via differential drivers/receivers. I simply swapped the hot and cold wires where they come into the board via the backplane. :) Oh, yeah, I bit the bullet and will be ordering Synplicity. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u
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