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
You can use guide if the instance names remain the same in the entire design. Means everything has to be labeled, and it probably won't work under synthesis with FPGA express. Another possibility is to add a write path to the ROMs in your design if you have a host that can do the writing. A third alternative is to ask xilinx if you can get a hold of a program (jbits) that will twiddle the needed bits in the bitstream (yes, they will do that). Walt Bax wrote: > Hello, > > Software: Xilinx Alliance v1.5i on Sun Solaris > Hardware: Xilinx XC4036XLA FPGA > > I'm using Xilinx logiblox ROM's in a design and wonder if > it is possible to reconfigure the ROM contents AFTER successfully > routing the design. > > e.g. changing the tap weights in a FIR filter implemented > using ROMs. > > The routing phase takes a long time so I'd like to avoid rerouting > if possible. > > Thanks, > > Walt -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14701
20 bits in from AMCC 1.5gb Rx to 20 bit parallel. Anybody want to sell me a design? I need it quick.Article: 14702
Hi, Is it 'alright' to implement an asynchronous FSM on an FPGA (providing of course, I take care of all hazards, race conditions, etc)? Moreover, are the power saving gains of async FSMs vs sync FSMs observable on an FPGA? ThanksArticle: 14703
I think it is a good board too. Bill wrote in message <79rptr$aff$1@dvorak.ednet.co.uk>... >Try RC1000 at www.embedded-solutions.ltd.uk > >Sanjeev wrote in message ... >>I am looking for a good project board that will take a Xilinx XC4085XL (PGA >>559) FPGA. Anyone have any good suggestions? >> >>Thanks >> >> > >Article: 14704
David Kessner <davidk@peakaudio.com> writes:
> I've read this too, but I question it greatly. I question it for several
> reasons:
>
> 1. I doubt that the "FPGA based supercomputer"
> (http://www.starbridgesystems.com/release.html)
> uses Xilinx place/route/bitstream software. For a
> computer like that to be remotely useful, they would need
> something more integrated into their development tools.
They claim to use libraries, not compile on-the-fly.
> 2. Someone (I forget who) used a genetic algorithm to "program"
> a Xilinx FPGA to detect two tones. This program basically
> randomly generated xilinx bitstreams in a "genetic
> permutation" way. But, before actually programming the
> xilinx, the bitstream was checked for faults that would
> have fried the chip (bus contention, etc.). So, this guy
> would have had to know what the bitstream file did.
That was done on XC6000 (R.I.P), which has a completely documented
bitstream format. You can't fry the chip with a bogus bitstream on
XC6000, BTW.
> 3. Xilinx has a "warning" on their web site about companies
> that are doing some "rescreening" of their chips. Basically
> they are retesting and sorting the FPGA's to upgrade them
> from Commercial to Industrial or Military temperature/voltage
> range. This warning didn't outright say it, but it implied
> that these guys are playing around with the bitstream files.
Dunno about that one.
> While, this isn't hard evidence, it passes at least a
> casual definition of "reasonable doubt", IMHO.
You can still get past the stage of reasonable doubt, just not by your
arguments. NeoCAD had reverse engineered the Bitstream before they
were bought by Xilinx. What is unclear is if they only figured out
how to produce a bitstream or if they also figured out how to reverse
engineer one (two very different things). There was also a report
here in this group (I think) that it is straightforward to figure out
where RAM bits are in the bitstream, so you might patch different RAM
content in.
> If the original poster really wants to protect his design,
> I'd recommend using an antifuse based FPGA (I.E., Quicklogic)
> or a CPLD. Once programed, it would be very difficult to
> read back the program from the chip. Most of the time, you'd
> have to open the chip up and inspect it visually-- way beyond
> what almost everyone are capable of.
The cost of having a chip analysed is not that great either. The only
bummer is that you have to pay for each chip you want to crack.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
Article: 14705We have used several small-storage dual port RAMs in XC40150XV devices. Write Enable signals for these dual port RAMs are intended to be active for a very long time, like 1 day. Is it dangerous to keep this signal active for such a long period in the real life? UtkuArticle: 14706
In article <796uds$cb3@news.rsc.raytheon.com>, rjmyers@ti.com wrote: > As some/many of you may know, Minc/Synario closed their > doors and had turn over their assets to be liquidated > (see EETimes article, dated around Dec 18, 1998). By now evrybody knows that Minc/Synario has been sold to Xilinx. Or better said, Xilinx aquired what they thought was worth in Minc. > I am trying to determine what people/other organizations > are doing to support the programming of PLDs (and possibly > CPLDs) now that the company that supplied ABEL has shut down. > It appears that Logical Devices may be the only "non-biased" > vendor out their, with their CUPL system that targets > multiple PLD vendor devices. The original company that invented Abel, was Data I/O. Since they are more focused on doing HW programmers, they already "sold" Abel to Synario (Synario beeing a spin off company of DataIO. In turn, Synario was bought by Minc, wich at the time was doing well, and needed a front end (entry) to complete their raw PLS compiler. On the other hand other front end were used for Abel. Xilinx used the Synario tool in a reduced version for their XAbel tools. Similar at Viewlogic. Minc was selling the PLS compiler and doing wery strong with the Minc tools for CPLDs. Lattice used to sell an adapted Synario too. > Any thoughts/insights on this matter are welcomed. From the announces from Xilinx, it is clear that Xilinx is not interested in maintaning Synario a vendor indipendent tool. They seem to be only after the PLS compiler and the rights to Abel, that will be used in their Foundation tools. The foundation tool is now based on a Aldec entry and the Synopsys compiler. The options for a vendor indipendent tools now seem to revert to the usual tools for entry like Mentor, Viewlogic, Veribest. We bought Synario because at the time was a better tool than the mentioned tools and had one front end with at least two compilers (Synopsys and Metamor). But now we see a great fragmentaion in the vendor tools. Most vendors prefer to have their own (as usual icompatible) tools. Vendor indipendent tools seem to be disapearing or are monolitic and pricy tools. Moving from Synario to Mentor, ViewLogic, Veribest, Cadence or OrCad can be quiet a step. Few of them offer a so nice envirnment as Synario, even if all of them offer the same capability. Whats next. I think for a while I suggest to stay with the version of Synario that you have right now. In the mean time look arround and let me know.... Bye Matija > -Bob -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14707
Hi all, Ray Andraka wrote: > A third alternative is to ask xilinx if you can get a hold of > a program (jbits) that will twiddle the needed bits in the bitstream > (yes, they will do that). Can jbits also be used for the 6200 series of FPGA's? Jamie MorkenArticle: 14708
Hi all, Does anyone have any 6200 series chips that they want to sell? I am also looking for XACT6200 development software. Jamie Morken Fourth Year CompSci University of VictoriaArticle: 14709
Write enable is just a control signal. Writes occur when it is asserted, and the clock makes the appropriate transition. You can leave Write Enable asserted forever, if that is what your design needs. Philip. In article <36C3D9FA.B910954F@netas.com.tr> Utku Ozcan <ozcan@netas.com.tr> writes: >We have used several small-storage dual port RAMs in XC40150XV devices. >Write Enable signals for these dual port RAMs are intended to be active >for a very long time, like 1 day. Is it dangerous to keep this signal >active for such a long period in the real life? > >UtkuArticle: 14710
No, it's dangerous to keep Write Clock signal low for a long time. Write Enable is safe. -----Original Message----- From: Utku Ozcan [mailto:ozcan@netas.com.tr] Posted At: Friday, February 12, 1999 10:36 AM Posted To: comp.arch.fpga Conversation: Very Long Write Enable in Xilinx Dual Port RAMs Subject: Very Long Write Enable in Xilinx Dual Port RAMs We have used several small-storage dual port RAMs in XC40150XV devices. Write Enable signals for these dual port RAMs are intended to be active for a very long time, like 1 day. Is it dangerous to keep this signal active for such a long period in the real life? UtkuArticle: 14711
Can somebody help me out with the following error message from M1.4's NGDBUILD? Running Logical Design DRC... ERROR:basnu:93 - logical block "cell_dln/overview/I$5576" of type "DFF" is unexpanded. I have approximately 400 of these :-) My design flow is: pld_men2edif (mentor -> edif), then ngdbuild. Is there another tool to be run in between? I did the same thing on another design a few days ago and it worked. (I'm new to M1 though.) thanks Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14712
Yes, but in addition to the regular hazards, you need to be aware of delays in the interconnect. For it to work, you will need to explicitly define the LUT contents and placement. Verification is a larger task than the design, implementation and placement For a small async FSM, the power savings will be lost in the noise. For larger ones, you are looking at a huge task making it work and verifying it. mathai@ecf.toronto.edu wrote: > Hi, > > Is it 'alright' to implement an asynchronous FSM on an FPGA (providing of > course, I take care of all hazards, race conditions, etc)? > > Moreover, are the power saving gains of async FSMs vs sync FSMs observable > on an FPGA? > > Thanks -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14713
No 4K only jamie morken wrote: > Hi all, > > Ray Andraka wrote: > > > A third alternative is to ask xilinx if you can get a hold of > > a program (jbits) that will twiddle the needed bits in the bitstream > > (yes, they will do that). > > Can jbits also be used for the 6200 series of FPGA's? > > Jamie Morken -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14714
Hamish Moffatt <hamish@rising.com.au> wrote: > Can somebody help me out with the following error message from M1.4's > NGDBUILD? > Running Logical Design DRC... > ERROR:basnu:93 - logical block "cell_dln/overview/I$5576" of type "DFF" is > unexpanded. > I have approximately 400 of these :-) So Xilinx's web site explains that this could be due to pin contention (nothing in the bld file about that) or missing library files (no complaints about that either). $XACT is set to the top of our M1.4 installation; $LCA is set to $XACT/mentor/data off the top of my head. Is there something else I need to set? I get this error about DFFs, AND3s, all sorts of stuff. Having just spent about 7 hours porting a design from XACT 5.2 and XC4010 (obselete libraries) to M1 and XC4028EX (unified libraries) (completely by hand) I am a bit frustrated! thanks Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14715
I may be wrong, but I believe that Orcad Express has a function to read an XNF file in, and generate VHDL from it. It's been awhile since I had that package loaded, but that's what I seem to remember. Don't know how complex a design it can handle. I do know that Orcad Express can import ABEl and turn it into VHDL. Tim Olmstead email : timolmst@cyberramp.net Visit the unofficial CP/M web site. MAIN SITE AT : http://www.devili.iki.fi/cpm PRIMARY US MIRROR AT : http://www.mathcs.emory.edu/~cfs/cpm SECONDARY US MIRROR AT : http://CPM.INTERFUN.NETArticle: 14716
>>>>>>>> Job posting deleted by archive ownerArticle: 14717
Hello my name is Jeff George, and I am contacting professionals with FPGA experience hoping to find one of you available for an open position with my client. The client I represent is a discretionary Commercial Aerospace contractor working on both US Commerical Aerospace and US DoD contracts. Title: Digital Flight Unit Design Engineer - f/Encrypted/Decrypted Voice & Data Communications Location: Torrance, CA Term: 2 - Contracts: 2 - 2 1/2 years and 1 - Perm/Full-Time Start date: Immediately/2 weeks notice Details: We are looking for a qualified candidate with extensive digital and analog hardware and high level software design experience. Specifically individuals will be responsible for understanding requirements as they apply to SPACE RADIATION HARDENING FLIGHT PRODUCTS DESIGNS. Capabilities must include; TTL, CMOS, ECL and FPGA design, implementation, integration and test. Product layout and digital/analog design to support data rates >600 Mbits desired. Knowledge of RS/422 & RS/232 and high speed interfaces. Secured embedded processor and computer designs with full or partial redundancy. Knowledge of NSA product endorsement including; TEMPEST, Cryptographic Verification, EMI/EMC, PCA and MRR a plus. Design analysis for Single Point Failures, MTBF requirements as well as worst case analysis. Presentation for customers, marketing and design reviews will be required. Qualified candidates will also demonstrate exceptional written and verbal communication, documentation and presentation skills. Please forward your resume in Word.DOC form promptly for immediate consideration! We look forward to hearing from you soon! US Citizenship required! Must have active or previous clearance. If you feel that you may fit this position and would like to proceed with an interview, will you please forward a copy of your resume to me at jgeorge@govjobs.com. If you are not interested and can refer someone who knows this technology, can you please forward my e-mail address to them. Thanks in advance Jeffrey George <*)))>< Senior Technology Specialist GOVJOBS.COM V: 714 928· 9797 / F: 714 444· 3513 JGeorge@GOVJOBS.COM http://GOVJOBS.COMArticle: 14718
Hello my name is Jeff George, and I am contacting professionals with FPGA experience hoping to find one of you available for an open position with my client. The client I represent is a discretionary Commercial Aerospace contractor working on both US Commerical Aerospace and US DoD contracts. Title: Digital Flight Unit Design Engineer - f/Encrypted/Decrypted Voice & Data Communications Location: Torrance, CA Term: 2 - Contracts: 2 - 2 1/2 years and 1 - Perm/Full-Time Start date: Immediately/2 weeks notice Details: We are looking for a qualified candidate with extensive digital and analog hardware and high level software design experience. Specifically individuals will be responsible for understanding requirements as they apply to SPACE RADIATION HARDENING FLIGHT PRODUCTS DESIGNS. Capabilities must include; TTL, CMOS, ECL and FPGA design, implementation, integration and test. Product layout and digital/analog design to support data rates >600 Mbits desired. Knowledge of RS/422 & RS/232 and high speed interfaces. Secured embedded processor and computer designs with full or partial redundancy. Knowledge of NSA product endorsement including; TEMPEST, Cryptographic Verification, EMI/EMC, PCA and MRR a plus. Design analysis for Single Point Failures, MTBF requirements as well as worst case analysis. Presentation for customers, marketing and design reviews will be required. Qualified candidates will also demonstrate exceptional written and verbal communication, documentation and presentation skills. Please forward your resume in Word.DOC form promptly for immediate consideration! We look forward to hearing from you soon! US Citizenship required! Must have active or previous clearance. If you feel that you may fit this position and would like to proceed with an interview, will you please forward a copy of your resume to me at jgeorge@govjobs.com. If you are not interested and can refer someone who knows this technology, can you please forward my e-mail address to them. Thanks in advance Jeffrey George <*)))>< Senior Technology Specialist GOVJOBS.COM V: 714 928· 9797 / F: 714 444· 3513 JGeorge@GOVJOBS.COM http://GOVJOBS.COMArticle: 14719
Hello my name is Jeff George, and I am contacting professionals with embedded processor development experience hoping to find one of you available for an open position with my client. The client I represent is a discretionary Commercial Aerospace contractor working on both US Commerical Aerospace and US DoD contracts. Title: Communications Systems Engineer - f/Encrypted/Decrypted Voice & Data Communications Location: Torrance, CA Term: 1 - Contracts: 2 - 2 1/2 years and 1 - Perm/Full-Time Start date: Immediately/2 weeks notice Details: Communications Systems Engineer Specific experience required in real-time embedded systems, which are based on ARM/6 and ARM/7 processors. Must be well versed in communication protocols for wireless systems. Also versed in communication protocols for LAN technologies as well as BUS structures in desktop PCs, portable PCs, palmtop units and workstations. Must be able to synthesize system solution to complex problems. Experience in cryptologic systems a plus. Developments including PCMCIA applications are a plus. Experience with ASIC technology is essential. Should have a strong analog background and possess and ability to quickly assess problematic situations and reach root causes. Experience with network communication standards is ideal. Experience with compliance requirements such as UL, BCC Part 15, CE Mark is MANDATORY! Must have active clearance or previous clearance of 5 years or less, clearable to Top Secret. Qualified candidates will also demonstrate exceptional written and verbal communication, documentation and presentation skills. Please forward your resume promptly in Word.DOC form for immediate consideration! If you feel that you may fit this position and would like to proceed with an interview, will you please forward a copy of your resume to me at jgeorge@govjobs.com. If you are not interested and can refer someone who knows this technology, can you please forward my e-mail address to them. Thanks in advance Jeffrey George <*)))>< Senior Technology Specialist GOVJOBS.COM V: 714 928· 9797 / F: 714 444· 3513 JGeorge@GOVJOBS.COM http://GOVJOBS.COMArticle: 14720
Utku Ozcan wrote: > > We have used several small-storage dual port RAMs in XC40150XV devices. > Write Enable signals for these dual port RAMs are intended to be active > for a very long time, like 1 day. Is it dangerous to keep this signal > active for such a long period in the real life? > > Utku Only for E parts if the clock stops during write. Here's what it says in the Xilinx answers database: http://www.xilinx.com/support/searchtd.htm Record #3423 Product Family: Documentation Product Line: Other Problem Title: 96/98 DATA BOOK: RAM: Write enable pulse width following active edge of WCLK. Problem Description: Keywords: Data, book, Single port, Dual port, edge triggered, RAM, NOTE, Twps, WCLK, write clock, WE, write enable Urgency: Standard General Description: The notes on pages 4-16 and 4-17 of the 9/96 Data Book and pages 4-13 and 4-15 of the 1/98 Data Book say: "The pulse following the active edge of WCLK (Twps in Figure <#>) must be less than one millisecond wide. For most applications, this requirement is not overly restrictive; however, it must not be forgotten. Stopping WCLK at this point in the write cycle could result in excessive current and even damage to the large devices if many CLBs are configured as edge-triggered RAM." These notes are misleading. They apply only the XC4000E devices. In the 4000EX, 4000XL, 4000XV, and subsequent families, this problem has been resolved. Solution 1: Ignore this warning if you are using 4000X parts. -- Tom Burgess -- Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 14721
Hi all,
I'm trying to synthesize in an XC4010E the module shown below, but F1.5
gives me next message:
Error: Sequential mapping has detected that the cell
'/ver1-Optimized/load_reg' uses both asynchronous
'set' and 'clear' pins. The target architecture does not support both on
the same sequential device (FE-SEQMAP-2)
After a lot of tests, if sentences with "-- ******" are commented, the
error dissappears, and from time to time I get next warning:
Warning: Latch inferred in design 'generar_stuff_bis' read with
'hdlin_check_no_latch' (HDL-307)
My problems are that I am not using any latch, I don't know how to
access 'hdlin_check_no_latch' variable, and I don't know
the use of the inferred latch.
Suggestions and ideas are welcome. Thanks in advance
My e-mail: jgracia@disca.upv.es
-- CODE:
library IEEE;
use IEEE.std_logic_1164.all;
entity generar_stuff_bis is
port (clock, reset, generar, trxon, error_contienda, bus_libre : in
STD_LOGIC;
linea_bus, parar : out std_logic
);
end generar_stuff_bis;
architecture generar_stuff_bis_arch of generar_stuff_bis is
component contador1
port (load, clock, reset : in std_logic;
c_in : in std_logic_vector(3 DOWNTO 0);
c_out : out std_logic_vector(3 DOWNTO 0));
end component;
signal dato_ant, load, linea_bus_int : std_logic;
signal c_in, c_out : std_logic_vector(3 DOWNTO 0);
begin
linea_bus <= linea_bus_int or error_contienda;
cnt : contador1 port map (
load => load,
clock => clock,
reset => reset,
c_in => c_in,
c_out => c_out);
process (clock, reset)
begin
if reset='1' or bus_libre='1'
then
dato_ant <= '1';
c_in <= "0000";
linea_bus_int <= '1';
parar <= '0';
if reset='1' then
load <= '0';
elsif bus_libre='1' then
load <= '1';
end if;
elsif clock='0' and clock'event then
if generar='1' and error_contienda='0' then
load <= '1';
if c_out /= "0101" then
parar <= '0'; -- ******
linea_bus_int <= trxon; -- ******
if dato_ant /= trxon then
c_in <= "0000";
dato_ant <= trxon;
else c_in <= c_out;
end if;
elsif c_out = "0101" then
parar <= '1'; -- ******
c_in <= "1111";
if dato_ant /= trxon then linea_bus_int <= trxon; --
******
else linea_bus_int <= not trxon; -- ******
end if;
end if;
end if;
end if;
end process;
end generar_stuff_bis_arch;
Article: 14722Achim Gratz wrote: > Reality check: how do they get 50ns max. latency on 8-100GB of memory > (SRAM? the power consumption would indicate otherwise). Even so, the > machine needs a bandwith of 20TB/s to sustain 3.8T 16bit adds per > second (what's with those tiny disk and memory sizes?). When you give > each of the 280 Xilinx chips 4GB/s to play with (and that would be > spectacular) you're still short of that figure by a factor of 20. not to mention how quickly a 16-bit adder tree will overflow when you have 3.8e12 of them! guyArticle: 14723
Ray Andraka wrote: > > Well, there are several ways to do parity in Altera. First is using the > ripple form, in which each bit is XOR'd to the sum of the previous bits. > Terribly slow for 36 bits unless you take advantage of the carry chain to > do it (and since the carry chain is implemented as a 3-LUT, this can be > done. In fact, each 3 lut takes care of two bits, so you only need 18 > LE's in the chain. It is a little faster if you break the chain into 8 LE > (1 LAB) segments and combine them in a single XOR (each LAB is then a 17 > input XOR). Second way is to combine the sums in a tree of XORs. For > this, you use the LEs as 4-LUTs, so the first layer reduces the 36 bits to > 9, the second to 3 and the third to a single bit. is well suited to > pipelining (pipeline it and it will synthesize the way you wanted). Third > way is to use the EABs to realize 8 input XORs; arrange those in the tree. > > The tree of XORs, even without pipelining should get you to around 100MHz > in a -3 part. This is slightly faster than using 8 LE carry chains > combined in an XOR and is a little more space efficient. To get this > performance, you'll want to use 5 LE's in a LAB to build a 16 input XOR. > Use Cliques to keep them together. This forms the first 2 layers. > Combine two 16:1 trees and a four input XOR with an additional 3 input > XOR. Again use cliques to keep these in the same row. Regardless of the > method used, you will want to use cliques to keep the logic in the same > row. i switched from 10K parts to 6000 parts for wide XOR stuff as soon as the latter became available. a flex6000 part is much better for wide XOR trees. you can use the shared LAB structure to keep all connections local, without ever going to row-level interconnect. i have a 64-bit ECC circuit for the mipsR4400 that performed immensely better in the 6000 than the 10K (something like >100MHz vs barely 50MHz). altera's p&r was even able to automatically generate a good layout for the XOR trees in the 6000 and use all local connections, without any cliques or floorplanning. in contrast, i had to use floorplanning to barely get the 50MHz from the 10K part. (incidentally... i was using the slowest speed grade chips available at the time -- had to be cost conscious) guyArticle: 14724
Utku Ozcan wrote: > We have used several small-storage dual port RAMs in > XC40150XV devices. > Write Enable signals for these dual port RAMs are intended > to be active > for a very long time, like 1 day. Is it dangerous to keep > this signal > active for such a long period in the real life? > > Utku There is no problem, and here is why:The circuitry in all Xilinx FPGA is static, and you can keep any signal at any level as long as you want. There are two exceptions to this broad statement: In the XC3000/3100 families, the configuration clocking ( CCLK ) is partly dynamic, and CCLK may, therefore, not be held Low for more than a few microseconds ( but it can be held High for an unlimited time. In XC4000E ( and only in this particular family ) the Write Clock signal to the RAM in the CLB must not have a long High time for a rising edge clock ( or a long Low time for a falling-edge clock). Certain nodes are not driven during that half-period and might thus drift into and through the threshold region, resulting in milliamps of temporary current. The "damage" described on page 4-15 in the note below table 7 is a figment of over-cautious imagination. XC4000EX, CL, XL, XLA, XV and other possible alphabet-soup families do not have and never had this restriction. 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