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
Delivery time is the problem! When a promised delivery is being postponed to a later date, it results in two things: 1) Irritation 2) Lack of faith in new delivery time -which again causes you to realize your planning goes down the toilet unless you do something about it. /Younès Lars <Lotzen@intersci.com> wrote in message news:ee6cced.1@WebX.sUN8CHnE... > HI Younes ! > > Whats about the Xilinx distributors? > You will find you chip on http://www.nuhorizons.com > But I don't know the delivery time. > > BYE LarsArticle: 23301
I got this quote from eetimes.com. Is this technically feasible? <<START QUOTE>> Panelist Steve Young, an architect of the Virtex FPGA family of Xilinx (San Jose, Calif.), advocated FPGAs in his presentation. But he surprised many when he said he expects the number of transistors on a single FPGA to hit 500 million in 2001, with the Xilinx Virtex-II family. Engineers designing FPGA silicon for companies such as Xilinx are coping with some of the most difficult deep-sub-micron devices around, Young said. "We face a number of problems so you don't have to," he said. These include simultaneous switching, deep-submicron parasitics, fault coverage, and clock skew management. "Like all chip designers, we are customers of EDA tools," said Young. "And we are challenging them." He said commercial EDA tools just aren't designed for the size of devices Xilinx engineers are building. Panel presentations will be available at the DAC Web site (www.dac.com) in a few weeks. http://www.eetimes.com/ Copyright c 2000 CMP Media Inc. <<END QUOTE>>Article: 23302
In article <8ir406$oi5$1@titan.bt.es>, "Juan-Luis Lopez" <jl.lopez@REMOVETHIS.ieee.org> wrote: > > There is an example of this within my final thesis at ( ... ) > The configuration was in slave serial mode. The asynchronous parallel mode > did not had any speed advantage, complicated the design and it did not allow > to verify the bitstream loading with a CRC Juan-Luis, Thank you very much for this information. It's interesting that asynch parallel has no speed advantage. I see you clocked CCLK by toggling one of the parallel port data pins. This requires instructions inserted to toggle CCLK. I had not thought that this would still be the fastest method. I have not yet found a resource that gives me timing specs on the parallel port (i.e. how fast can a bit be made to toggle under program control?). Thanks to you and all the others in this thread who have helped accelerate this beginning portion of my design project. Hopefully I'll be wiring it up soon and will report success. s.o. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23303
Sure. Steve might have been conservative, for we ship chips with >100 million transistors in volume today. Yes, we are facing and solving all these problems, so that the user can -to a large extent- be isolated from them. Xilinx can afford the work and cost to overcome these difficulties , since we design only a few different devices, but then manufacture them in high volume. The deep submicron geometries and associated mask-making and electrical difficulties ( and associated costs ) will become a real headache for ASICs and, directly or indirectly, for the ASIC user, since costs per mask set and design cannot be amortized over such high production volumes. Peter Alfke EKC wrote: > I got this quote from eetimes.com. Is this technically feasible? > > <<START QUOTE>> > Panelist Steve Young, an architect of the Virtex FPGA family of Xilinx (San > Jose, Calif.), advocated FPGAs in his presentation. But he surprised many > when he said he expects the number of transistors on a single FPGA to hit > 500 million in 2001, with the Xilinx Virtex-II family. > > Engineers designing FPGA silicon for companies such as Xilinx are coping > with some of the most difficult deep-sub-micron devices around, Young said. > "We face a number of problems so you don't have to," he said. These include > simultaneous switching, deep-submicron parasitics, fault coverage, and clock > skew management. > > "Like all chip designers, we are customers of EDA tools," said Young. "And > we are challenging them." He said commercial EDA tools just aren't designed > for the size of devices Xilinx engineers are building. > > Panel presentations will be available at the DAC Web site (www.dac.com) in a > few weeks. > > http://www.eetimes.com/ > > Copyright c 2000 CMP Media Inc. > <<END QUOTE>>Article: 23304
Does anyone have any experience in the use of FPGAs for accelerating DNA
sequencing algorithms? I'm particularly interested in the use of FPGAs for
accelerating the BLAST algorithm for DNA sequencing.
Most of these algorithms are like hybrid string-search algorithms which
must parse a large database representing a DNA sequence for various
variations of the search string. Such algorithms look like they could easily
benefit from the use of mulit-processor systems or computer clusters.
However, I think that the cost-performance ratio would be lower if I could
implement the algorithm as a parallel process in some FPGAs (each iteration
of the search would ideally take one clock cycle).
I'm looking at either building my own board (several Xilinx FPGA's
linked to a PCI bus) or buying a board from a vendor. Does anyone have any
favorite FPGA boards with PCI interfaces?
---
---
EKC
If you would like to e-mail me, remove the string 'NOSPAM'
from my e-mail address.
Article: 23305sceloporus occidentalis wrote: > > In article <8ir406$oi5$1@titan.bt.es>, > "Juan-Luis Lopez" <jl.lopez@REMOVETHIS.ieee.org> wrote: > > > > There is an example of this within my final thesis at > ( ... ) > > The configuration was in slave serial mode. The asynchronous parallel > > mode did not had any speed advantage, complicated the design and it did > > not allow to verify the bitstream loading with a CRC > > Juan-Luis, > Thank you very much for this information. It's interesting that asynch > parallel has no speed advantage. I see you clocked CCLK by toggling > one of the parallel port data pins. This requires instructions > inserted to toggle CCLK. I had not thought that this would still be the > fastest method. I have not yet found a resource that gives me timing > specs on the parallel port (i.e. how fast can a bit be made to toggle > under program control?). > > Thanks to you and all the others in this thread who have helped > accelerate this beginning portion of my design project. Hopefully I'll > be wiring it up soon and will report success. > > s.o. > > Sent via Deja.com http://www.deja.com/ > Before you buy. Ah yes, controlling timing on the parallel port. That is the tough part. The PP hardware will run as fast as you write to it. If I remember the timing spec on the old XC4000 famiily, you have a max of around 10 MHz CCLK rate. So if you run your port too fast, you might not meet timing on the part. If you are on an ISA bus, then you don't have that problem since it runs at a maximum rate of some 4 MHz, best case. If the PP is directly on the PCI bus, then it may be possible to reach some multi MHz speeds with a fast processor. But I don't think timing is a problem in Slave Serial mode. The PCI bus uses multiplexed address and data so each transaction is at least two clock cycles and there is one of overhead. So the fastest you can toggle a PP signal is 180 nS or 5.5 MHz. But it may be much slower depending on the operation of the computer. So if the interface is much slower than 5 MHz, then you can get faster performance by running in Asynch Parallel mode which lets the interface run 8 times slower than the serial bit stream. It also gives you positive feedback on the Ready status. Alternating writes to the data register and the control register will give you the required 100 nS minmum strobe times. In looking at the timing data on the XC4000E and XL, I see that the CCLK output (master mode) can be as fast as 80 nS, but the input requirement is 100 nS at best. According to this spec, you can't daisy chain the chips and expect them to work reliably in Fast mode!!! Am I missing something here? -- Rick 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: 23306
This could turn into a long debate, but I found this issue (along with a whole bunch of much more serious ones) when I had to use three different compiliers to get a job completed. I am embarrased to say that I originally started with the Orcad tools (I fell for their marketing approach of targeting multiple vendors with a single tool) only to switch to the Xilinx tools when the Orcad tools didn't even perform the basic function of producing an EDIF file most of the time (along with a pretty poor showing from their tech support). So when I switched to the Xilinx tools (I believe it was the Model Tech compiler) I had to rewrite the VHDL I had produced to get a workable implementation. Then as I was about half the way done the project, Xilinx updated us to the FPGA Express compiler. I then had to rewrite my code a second time. Many of the issues were the same, the biggest was the way you had to code a OneHot FSM. I kept getting logic with all 16 state variables as inputs. Anyway, enough of my griping. This was one of the last things I found that the compiler was doing very inefficiently. The VHDL below can be done in a single LUT and a single FF with a CE connected directly to the "enable" signal. That is what I got from the other two compilers. But FPGA Express gave me two LUTs and a FF. I don't consider a 4 input function to be a mess unless it is. The logic below can be done as the OR of three AND gates. D_input <= (condition and A) or (not condition and othercondition and B) or not condition and not othercondition and q), which is how I ended up coding it outside of the clocked process. The compiler produced an equally large and more obtuse bank of logic for the D input. It also produced logic for the CE which is the path that had the speed criticality. "enable" was a divided by N enable to allow the circuit to run at full or partial speed. Since it went to a large part of the chip with long routing delays, it could not be run through additional logic. All in all I was not impressed with the "labor saving" capabilities of VHDL. I am also not totally happy with the issues of maintaining large schematic designs. So I may be giving VHDL a try again soon. We will see. Andy Peters wrote: > > Rickman wrote in message <39505DA7.CBFD36CB@yahoo.com>... > > >It is not that I don't like the CE. But rather I don't want to see logic > >put in front of the CE that serves no purpose. I have written VHDL code > >and had the synthesizer take every IF in the clocked part of a process > >and turn it into a logic condition for the CE. Then it took these same > >logic conditions and used them to set or clear the D input. > > > > flop : process (clk, reset) is > > begin > > if reset = '1' then > > q <= '0'; > > elsif rising_edge(clk) then > > if enable = '1' then > > if condition = '1' then > > q <= A; > > else if othercondition = '1' then > > q <= B; > > end if; > > end if; > > end if; > > end process flop; > > > >This would have put a LUT in front of the CE ANDing enable with the OR > >of "condtion" and "othercondition". The D input would have gotten some > >real mess gating these same terms with A and B and "enable". I didn't > >write the synthesizer. But I had to use it! > > OK, I just ran that code through FPGA Express v3.3. It created two LUTs -- > one for the CE and one for D. CE is asserted when enable is asserted AND > either condition or othercondition is asserted. That is what you'd expect, > actually -- those are the conditions that would cause q to change. Now, > perhaps what you were expecting was for the enable signal to drive CE > directly; however, that would cause the logic for the D input to get > bigger -- slower -- because it's now a more-complicated four-input function. > A mess, as you say. > > Now, the D input equation is only a function of A, B and condition. D is > asserted when condition and A are true, or if condition is not true and B > is. > > If you consider your code carefully, you'll see that the > > if condition ... > elsif othercondition ... > > code builds a priority encoder. > > The synth knows that if condition is not true, then othercondition might be > true (and since CE would be asserted because othercondition true, then q > could be set), but if it's not, then the CE is killed, and q remains as is. > > -- a > ----------------------------------------- > Andy Peters > Sr Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) noao \dot\ edu > > "A sufficiently advanced technology is indistinguishable from magic" > --Arthur C. Clarke -- Rick 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: 23307
I think we are talking about different things. When I say clock enable or CE, I am referring to the CE input on the FF. Gating the clock in an FPGA is not practical since that will add delay to the clock path and cause problems with skewing. I do agree that clock enables (shutting off the clock to a function) will save power. But my question was very specific. I am asking if there is a "significant" power savings in an SRAM based FPGA by using the CE v. using an enable in the LUT. At this point I think the answer is not much. It does me no good to save a mW in a Watt design. I am looking for significant savings. But you are right that power can be reduced, sometimes dramatically, by gating the clocks to the FFs. But we just can't do that reliably in FPGAs at this point. Maybe they will add that at some other time. iglasner@my-deja.com wrote: > > hi, > > I'm not into the betting arena and even the single night I spend in > Vegas I prefered to walk arround than do gambling, but you might want > to know that most cellular phone asic DO close the clock for lot's of > FF's as well as mem and it DOES make a huge effect on the power > consumption. > > The point that more power might be somewhere else have nothing to do > with this point, as when you want to save power you save everywhere you > can. > > To your comment that : > > "The question is not does the FF use "any" power. But does the FF use > > less power? I would be willing to bet that most of the power in the > FPGA" > > than the answer is yes the FF will use less power even tho' the > capacitance look to you a small part, the amount of FF and the > frequnacy make this small to be not so small. > > and yes clock gateing is a "sience" for itself and have big difficult > of itself but it was done and will be done most likely in the future. > > have a nice day > > Illan > > In article <39505F5F.4A19D624@yahoo.com>, > Rickman <spamgoeshere4@yahoo.com> wrote: > > iglasner@my-deja.com wrote: > > > > > > Hi, > > > > > > A FF even if it "see" the same input level does consume power as > long > > > as there is a clock. > > > > > > The only way to reduce the power of a group of FF's is by shuting > down > > > their clock meaning using clock enable. > > > > > > One example for using clock enable is for stand by purpose in > cellualr > > > phone, where the power source (battery) is limited. > > > > > > have a nice day > > > > > > Illan > > > > The question is not does the FF use "any" power. But does the FF use > > less power? I would be willing to bet that most of the power in the > FPGA > > is burned in toggling the ouput of a "slice" or CLB or whatever the > > correct term is for an output from a FF or LUT. I would be willing to > > bet that much less power is used to toggle a LUT that is only driving > > the FF in the same CLB. Even less power is likely used by a FF that is > > clocked, but the output does not change. > > > > Certainly internal nodes in a FF are switching anytime the clock > > switches. But the power used is very small since the capacitance of > the > > internal nodes is very small. But to switch the output and the routed > > trace it connects to is likely the lion's share of where the power > goes. > > > > So I would bet (not heavily since I have most of my money in the stock > > market and that is the biggest bet I have ever made) that there is > very > > little power used by FFs which do not switch their outputs regardless > of > > how that is accomplished; D input not changed, CE held low or clock > > turned off. > > > > Anyone care to wager a pint of your faviorite beverage (or Haagen Das > in > > my case)? > > > > -- > > > > Rick 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.com > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- Rick 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: 23308
I'm surprised no one has yet mentioned the obvious synchronous detector. It's easy to build, since you know the frequency to good precision, and you can control it with a PLL. The problem with crystals is that they are hard to tune accurately as filters, and they are slow to react to input signal changes -- even of strong signals. A pair of synchronous detectors (analog gates) driven by a 1.5625Mhz I-Q square wave, followed by a pair of integrators, is easy to tune with a VCXO. You set up your PLL to keep the Q signal zeroed, and the I signal is therefore maximized. Depending upon how closely you can predict the frequency of the signal, and how stable the signal is, you can pull it out of noise up to and even beyond 60dB greater than your signal. Equivalently, you can get bandwidths to fractions of a Hz. It depends upon your integration time. You can generate a 1.5635 IQ square wave from a 3.1270 VCXO signal and two flip-flops. The output of each analog gate is the rectified synchronous signal. The more precisely you know the signal, the longer you can integrate the product from the analog gates' output, and the smaller signal you can detect, no matter what the noise level is. John Perry jperry@norfolk.infi.net Dominique SZYMIK wrote: > Hello, > > To your problem there might be two basic solutions: ...Article: 23309
Whenever I use Xilinx macros, I run CoreGen (get the latest patch) and then include the edf file when synthsising the design. It will include the macro and provide very close timing on it as well. Plus core gen generates templates that show all ports on the macro ... hope this helps, bkk In article <ee6c312.5@WebX.sUN8CHnE>, "Bryan Jones" <bryan@rice.edu> wrote: > Yall, > > I'm still trying to get the hang of instantiating Xilinx macros/primitives in my VHDL designs. I've gotting IBUF/OBUF/BUFG to work, but am now having trouble with ADSU16 on a Virtex part. Has anyone else gotten this to work? My code looks something like this: > > component adsu16 > port ( > a: in std_logic_vector(15 downto 0); > add: in std_logic; > b: in std_logic_vector(15 downto 0); > ci: in std_logic; > co: out std_logic; > ofl: out std_logic; > s: out std_logic_vector(15 downto 0) > ); > end component; > > Then, I instantiate it as usual: > > adsu16_1 : adsu16 port map ( > a, b, ci, co, ofl, s); > > However, when I Implement the design, ngdbuild complains that "logical block adsu16_1 of type adsu16 is unexapnded." Since this is a standard Virtex macro, and the virtex library is part of my project, shouldn't this work? > > Thanks for the help! > > Bryan Jones > bryan@rice.edu > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23310
Sorry havn't used Leonardo ... but am wondering if you guys looked at FPGA Compiler from Synopsys and what you guys thought of it ? bkk In article <Xs945.126351$uw6.2292218@news20.bellglobal.com>, "Xanatos" <deletemeaoe_londonfog@hotmail.com> wrote: > Hey all, > > My company is interested in purchasing Leonardo Spectrum (2000 version with > TimeCloser technology). Has anyone had a chance to use this (Beta, etc) > tool, and can offer any comments (good, bad or otherwise) about it? The > TimeCloser feature has caught our eye.... > > We have primarily used Synplify for FPGA synthesis (we have ver 5.3.1), and > so I'm also looking for any other comments from people who are familiar with > both the above version of Leonardo and how it compares feature wise and > performance wise to Synplify. > > Thanks for your replies, > Dave > (email aoe_londonfog@hotmail.com or post here) > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23311
Steven, In VHDL you need not declare xc4000 library. Its not a valid library declarations. When you specify the target architecture i.e, like xc4000, the corresponding library is automatically mapped. You also need not add xc4000 library in Foundation Project manager. You must include standard VHDL libraries like "Library IEEE" ,"Library Synopsys" etc. If you want to go for functional simulation include unisim library. Library Unisim; <br> use unisim.all; <br> Hope this helps. Vikram <br> Xilinx ApplicationsArticle: 23312
Steven, In VHDL you need not declare xc4000 library. Its not a valid library declaration. When you specify the target architecture i.e, like xc4000, the corresponding library is automatically mapped. You also need not add xc4000 library in Foundation Project manager. You must include standard VHDL libraries like "Library IEEE" ,"Library Synopsys" etc. If you want to go for functional simulation include unisim library. Library Unisim; <br> use unisim.all; <br> Hope this helps. Vikram <br> Xilinx ApplicationsArticle: 23313
Hi, Take a look at http://lslwww.epfl.ch/pages/publications/rcnt_theses/home.html There you find a recent thesis by E. Mosanya entiteled: "A Reconfigurable Processor for Biomolecular Sequence Processing" that may perhaps help you. Christof EKC wrote: > > Does anyone have any experience in the use of FPGAs for accelerating DNA > sequencing algorithms? I'm particularly interested in the use of FPGAs for > accelerating the BLAST algorithm for DNA sequencing. > [...] ________________________________________________________________________ Christof Teuscher Tel.: +41 21 693 67 14 Logic Systems Laboratory Fax: +41 21 693 37 05 Swiss Federal Institute of Technology christof@teuscher.ch EPFL-DI-LSL http://lslwww.epfl.ch CH - 1015 Lausanne http://www.teuschers.ch/christof ________________________________________________________________________Article: 23314
> I do agree that clock enables (shutting off the clock to a function) > will save power. But my question was very specific. I am asking if there > is a "significant" power savings in an SRAM based FPGA by using the CE > v. using an enable in the LUT. I'll bet the difference would be hard to measure. It might be a fun project to try though. The question is how big a capacitor is changing state. The CE pin is a simple mux. The LUT is a tree of muxes. Is your enable signal connected to the root of the tree or out at the leaves? In any case, I think that capacitor is small relative to wires going over to other CLBs. I think that "clock enable" has two meanings in the context of saving power. One is keeping a lot of logic from changing state when you don't need it, for example an adder that's only needed some of the time might flap around the other half if there is garbage on its input. A clock enable will avoid that. The other way to save power is to turn off parts of the clock tree. This saves the power in that branch of the clock tree as well as keeping that chunk of logic from changing state. Unfortunately, that style of clocking isn't supported in any of the FPGAs I've worked with. I'll bet it is important if you are serious about pushing battery life. The problem here is skew. I'll bet that's not a problem if you use 2-phase logic. -- These are my opinions, not necessarily my employers. I hate spam.Article: 23315
--------------3BFDA4C31C227C733F924944 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I'm currently working on such an accelerator on a FPGA board Spyder-Board to implement various versions (with or without gap) of the smith and waterman algorithm. The lab I'm working in alreday has some experience in such hardware accelerator for sequence comparison, beside I think tere have been quite a few publications on the topic : see SAMBA: Systolic Accelerator for Molecular Biological Applications and Spyder board Steven EKC wrote: > Does anyone have any experience in the use of FPGAs for accelerating DNA > sequencing algorithms? I'm particularly interested in the use of FPGAs for > accelerating the BLAST algorithm for DNA sequencing. > Most of these algorithms are like hybrid string-search algorithms which > must parse a large database representing a DNA sequence for various > variations of the search string. Such algorithms look like they could easily > benefit from the use of mulit-processor systems or computer clusters. > However, I think that the cost-performance ratio would be lower if I could > implement the algorithm as a parallel process in some FPGAs (each iteration > of the search would ideally take one clock cycle). > I'm looking at either building my own board (several Xilinx FPGA's > linked to a PCI bus) or buying a board from a vendor. Does anyone have any > favorite FPGA boards with PCI interfaces? > > --- > --- > EKC > > If you would like to e-mail me, remove the string 'NOSPAM' > from my e-mail address. --------------3BFDA4C31C227C733F924944 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hello, <p>I'm currently working on such an accelerator on a FPGA board Spyder-Board to implement various versions (with or without gap) <br>of the smith and waterman algorithm. The lab I'm working in alreday has some experience in such hardware accelerator for sequence comparison, beside I think tere have been quite a few publications on the topic : see <a href="http://www.irisa.fr/cosi/SAMBA/welcome.html">SAMBA: Systolic Accelerator for Molecular Biological Applications</a> and <a href="http://www.fzi.de/sim/people/spyder.html">Spyder board</a> <p>Steven <p>EKC wrote: <blockquote TYPE=CITE> Does anyone have any experience in the use of FPGAs for accelerating DNA <br>sequencing algorithms? I'm particularly interested in the use of FPGAs for <br>accelerating the BLAST algorithm for DNA sequencing. <br> Most of these algorithms are like hybrid string-search algorithms which <br>must parse a large database representing a DNA sequence for various <br>variations of the search string. Such algorithms look like they could easily <br>benefit from the use of mulit-processor systems or computer clusters. <br>However, I think that the cost-performance ratio would be lower if I could <br>implement the algorithm as a parallel process in some FPGAs (each iteration <br>of the search would ideally take one clock cycle). <br> I'm looking at either building my own board (several Xilinx FPGA's <br>linked to a PCI bus) or buying a board from a vendor. Does anyone have any <br>favorite FPGA boards with PCI interfaces? <p>--- <br>--- <br>EKC <p>If you would like to e-mail me, remove the string 'NOSPAM' <br>from my e-mail address.</blockquote> </html> --------------3BFDA4C31C227C733F924944--Article: 23316
This is a multi-part message in MIME format. --------------FA1E5A620253B8A37B018DF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I was wondering if you can use the JTAG interface on Xilinx devices (X4000XLA series) to debug your design. If so, how does it works? What are other good hardware methods or tools for debugging, knowing that almost all our FPGA pins are used and needed, so bringing out signal on pins and checking with analyzer is not useful to us. Thanx in advance!!! Steven. --------------FA1E5A620253B8A37B018DF7 Content-Type: text/x-vcard; charset=us-ascii; name="sanders.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steven Sanders Content-Disposition: attachment; filename="sanders.vcf" begin:vcard n:Sanders;Steven tel;cell:0476 582 612 tel;work:057 230 140 x-mozilla-html:FALSE org:imec adr:;;Flanders Language Valley 44;Ieper;;8900;Belgium version:2.1 email;internet:sanders@imec.be fn:Steven Sanders end:vcard --------------FA1E5A620253B8A37B018DF7--Article: 23317
Since one of the objectives of copying is to extract the pinouts, perhaps pinout tables could be provided on the web site in a plain text format. Robert Binkley wrote in message <39511274.41ED1204@hamxilinx.com>... > >Good news, Spartan/xl/II datasheets on our website were updated earlier today >(pretty quick huh?). You got what you asked for. I just downloaded it, and you >can highlight the text. Any other doc suggestions/complaints? :) > >Robert Binkley >Xilinx ApplicationsArticle: 23318
Hi Xilinx Experts, I've just added a second tristate driver to a bus in my design and suddenly the "generating PAR statistics" phase of PAR has gone from taking a few seconds to taking the best part of an hour :-(. Xilinx technical support say: The long PAR time, though a nuisance, does appear to be reasonable. Tristate delay calculations will always be more complicated as you have to consider the output capacitance of the drivers as additional loading on the bus (not just the usual input cap of receivers). ...which I don't like; it sounds to me like their algoirthm has gone from O(n) to O(n^2) or something like that. I'm worried that when I shortly add a third driver the time to do these delay calculations will exceed a week! So: has anyone else run into this problem? Is anyone using an on-chip tristate bus and still getting reasonable PAR times? Another consideration is that the bus goes into a synthesized ROM and so has lots (hundreds) of loads. Thanks for any advice. --Phil.Article: 23319
Hi Steven,
Steven Sanders wrote:
> I was wondering if you can use the JTAG interface on Xilinx devices
> (X4000XLA series) to debug your design. If so, how does it works?
One thing that can be done is a JTAG readback of the entire FPGA at
precise moments in time, then you simply need to look at the appropriate
bit(s) to find the value of any internal net or LUT content. Of course,
the design of the FPGA must be done to permit multiple (consecutive)
readbacks via JTAG, and some bitgen options have to be tweaked.
The biggest problem is that I am not aware of any software that would do
the entire job all by itself. The readback itself is fairly simple to do
(I guess it can be done easily with JTAG programmer/WEBPACK), but you'll
have to get scripts to read the resulting bitstream to get the nets/RAM
values you want.
You could also use JTAG to drive the inputs of your FPGA with test data
and look at the resulting outputs (using the EXTEST instruction). I've
done a few functional tests this way. Another possibility is to design
special test registers that record valuable data within your device and
those registers could be shifted out periodically (perhaps as fast as
possible) using the USER1/USER2 user-defined JTAG instructions.
There are a few possibilities, as you can see. Still, the best thing is
always to do proper simulation...
Regards,
Étienne.
--
______ ______
*****/ ____// _ \_\*************************************************
* / /_/_ / /_/ / / Etienne Racine, Hardware Designer *
* / ____// __ /_/ Visual Systems Engineering *
* / /_/_ / / /\ \ \ CAE Electronics Ltd. *
*/_____//_/_/**\_\_\*************************************************
Article: 23320
I have just started my first design in Virtex, and I suppose that it's
possible to use just a plain LUT to cut the clock off from some clock
branches and shape up the delay using DLL, am I right ??
Yesterday I've read somewhere that the best way to implement
clock gating is to use latch , what do you say about, fpga gurus ?
> The other way to save power is to turn off parts of the clock tree.
> This saves the power in that branch of the clock tree as well as
> keeping that chunk of logic from changing state.
> Unfortunately, that style of clocking isn't supported in any of
> the FPGAs I've worked with. I'll bet it is important if you are
> serious about pushing battery life.
> The problem here is skew. I'll bet that's not a problem if you
> use 2-phase logic.
regards,
-------------------------------------------
- Domagoj -
- Domagoj@engineer.com -
-------------------------------------------
Article: 23321Anyone out there using a dual processor PC for Xilinx? My last project takes about 1.5 hours to complie the single Xilinx chip if I do nothing else, and upwards of 3 hours if I try and do some work while the Xilinx s/w is running. Since my PC is only 350mhz (windows 95) its probably time for an upgrade. I'm wondering about dual processors, thinking one could run Xilinx while I use the other to get some real work done while the Xilinx s/w is running. Anyone got any insights or recomendations? Dual processors will force me into windows 2000 or NT. Any problems with that? Others where I work are interested from an Altera point of view also. Thanks DanArticle: 23322
Xilinx tools require lots of RAM, and many of the dual processor systems are using RDRAM which is astronomically expensive. The low end Dell dual processor boxes are limited to 512M, although the top of the line Dells can support 1G. You might want to buy a couple of fast desktop machines and put 768M of SDRAM into each, it will cost you less than a dual processor system with RDRAM. Dan Kuechle wrote: > > Anyone out there using a dual processor PC for Xilinx? > > My last project takes about 1.5 hours to complie the single > Xilinx chip if I do nothing else, and upwards of 3 hours if I > try and do some work while the Xilinx s/w is running. Since > my PC is only 350mhz (windows 95) its probably time for > an upgrade. I'm wondering about dual processors, thinking > one could run Xilinx while I use the other to get some real > work done while the Xilinx s/w is running. Anyone got > any insights or recomendations? > > Dual processors will force me into windows 2000 or NT. > Any problems with that? > > Others where I work are interested from an Altera point of > view also. > > Thanks > DanArticle: 23323
Wake up & smell the silicon, I couldn't resist responding to this. Steve is in the cube across from me, and we teased him on how conservative he was. Like Peter says, we have the time to do what is needed to make this scale of technology work: the ASIC/ASSP model is probably limited to less than 50 million devices. It is too expensive, too risky, takes too long, have inferior tools, and is unable to claim the advantages it once did. http://www.support.xilinx.com/xcell/xl30/xl30_10.pdf was written two years ago. It is so satisfying to see the team's vision realized. Thank you to all of our customers, and we will continue to provide you with the solutions you need to succeed. Austin Lesea, ICDES Group, Xilinx EKC wrote: > I got this quote from eetimes.com. Is this technically feasible? > > <<START QUOTE>> > Panelist Steve Young, an architect of the Virtex FPGA family of Xilinx (San > Jose, Calif.), advocated FPGAs in his presentation. But he surprised many > when he said he expects the number of transistors on a single FPGA to hit > 500 million in 2001, with the Xilinx Virtex-II family. > > Engineers designing FPGA silicon for companies such as Xilinx are coping > with some of the most difficult deep-sub-micron devices around, Young said. > "We face a number of problems so you don't have to," he said. These include > simultaneous switching, deep-submicron parasitics, fault coverage, and clock > skew management. > > "Like all chip designers, we are customers of EDA tools," said Young. "And > we are challenging them." He said commercial EDA tools just aren't designed > for the size of devices Xilinx engineers are building. > > Panel presentations will be available at the DAC Web site (www.dac.com) in a > few weeks. > > http://www.eetimes.com/ > > Copyright c 2000 CMP Media Inc. > <<END QUOTE>>Article: 23324
Domagoj wrote: > I have just started my first design in Virtex, and I suppose that it's > possible to use just a plain LUT to cut the clock off from some clock > branches and shape up the delay using DLL, am I right ?? No, you cannot do that, since the DLL must have a continuously running clock at its input. > > > Yesterday I've read somewhere that the best way to implement > clock gating is to use latch , what do you say about, fpga gurus ? Yes, you need a flip-flop or latch to prevent runt clock pulses or glitches. But you are still stuck with a delay, which means the gated clock is later than the ungated clock. That can lead to hold-time issues whenever these two clock domains meet. This is nothing for newcomers! If you use a relatively slow clock, you can be creative in using alternating clock edges, or at least use this trick at the interface between clock domains. All modern Xilinx FPGA permanently disable all "vertical" clock branches that are not used in the design. This saves power, but does not help you in changing things dynamically. Peter Alfke, Xilinx Applications > >
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