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
michel.lemer@ago.fr (Le mer Michel) wrote: > > So, I'm wondering if there's an easy way to embed the jedec file and > > programming algorithm into a DOS program. This would provide the > > simplest > > possible way of programming an on-board device via the PC printer port > > programmer. > > You can just install the software part for downloading. If the > parameters > are saved, they will only need to open the icon and click the run > button. Yeah, I did that, but when I say that our production dept are pc-illiterate, I mean /seriously/ pc illiterate. However, as brianp pointed out there's a dos programmer, so I can set up a batch file and they can just type the name of it in. No more "what's an icon again?" -- /Mel/ (at work)Article: 17201
I'm looking after a firewire (IEEE1394) core for a xilinx virtex and a speed of 400Mbps. Xilinx only offers one with a speed of 200Mbps. Is there someone with experience on that stuff? ThanksArticle: 17202
This is a multi-part message in MIME format. --------------7E5AB6FB5A578287925C9999 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Austin Franklin wrote: > > > "Modern reconfigurable computing could not begin > > untill Ross Freeman invented the FPGA." With the > > thought that "Modren" distinguishes the current > > type (FPGA based) of reconfigurable computers from > > projects that came before the FPGA. > > I even disagree with that. We were doing re-configurable computing in the > early and mid 70's with bit-slice processors, that had writeable control > stores. We even used the term 'reconfigurable compute engine'. > Specifically, we were developing systems for vision processing. > ...and if you want to be argue even more 'FPGA' was a term that was invented by Actel's marketing people as far as I know. Ross Freeman used the term 'configurable logic array' in his patent. But 'reconfigurable computing' is the term most people use *today* for computing with FPGA's even though it has other meanings as well and 'FPGA' is the accepted term *today* for the kind of chip that Ross Freeman invented so I think Steve is correct in what he says. > The IBM 370 had a writeable control store...and, was also a > 'reconfigurable' computer. > > Using a writeable 'memory' (RAM) as generic loadable/programmable logic has > been a standard hardware technique since I started in Engineering in the > mid 70's. Using ROMs as PLDs has been too. > There is a difference between microprogramming and 'reconfigurable computing as the term is used *today*. Xilinx FPGA's may use Look Up Tables but that is not what Ross Freeman claims to have invented in his patent. As a general point lots of engineers get excited too fast with statements like "Mr. X has patented Y", when in fact they mean "Mr. X has a patent in field Y". What Mr. X has actually patented is what is stated in the claims of that patent and is usually a lot smaller than the whole field. Just because Mr. Gilson or Intel or whoever has a patent about reconfigurable computing does not mean to say they own the whole field. Tom. --------------7E5AB6FB5A578287925C9999 Content-Type: text/x-vcard; charset=us-ascii; name="tom.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Kean Content-Disposition: attachment; filename="tom.vcf" begin:vcard n:Kean;Tom tel;fax:UK +44 131 556 9247 tel;work:UK +44 131 556 9242 x-mozilla-html:TRUE org:Algotronix Ltd. adr:;;P.O. Box 23116;Edinburgh;;EH8 8YB;Scotland version:2.1 email;internet:tom@algotronix.com title:Director note:Web Site: www.algotronix.com x-mozilla-cpt:;4768 fn:Tom Kean end:vcard --------------7E5AB6FB5A578287925C9999--Article: 17203
In article <01bec8d4$d6b3c480$3bab15d1@drt4> , "Austin Franklin" <austin@dark88room.com> wrote: > >> "Modern reconfigurable computing could not begin >> untill Ross Freeman invented the FPGA." With the >> thought that "Modren" distinguishes the current >> type (FPGA based) of reconfigurable computers from >> projects that came before the FPGA. > >I even disagree with that. We were doing re-configurable computing in the >early and mid 70's with bit-slice processors, that had writeable control >stores. We even used the term 'reconfigurable compute engine'. >Specifically, we were developing systems for vision processing. > >The IBM 370 had a writeable control store...and, was also a >'reconfigurable' computer. > >Using a writeable 'memory' (RAM) as generic loadable/programmable logic has >been a standard hardware technique since I started in Engineering in the >mid 70's. Using ROMs as PLDs has been too. > But there is something quite different about being able to *structurally* reconfigure something as opposed to updating a writeable control store (which does nothing to change the structure of a system). Although bit-slice devices and systems with writeable control stores have some interesting properties, they are not nearly as flexible as the FPGA-based systems we have today. I can take a single FPGA platform and turn it into a high-performance image-processing platform, and then use the exact same hardware to perform a completely different task (like sonar beamforming, for example). I would argue that systems with writeable control stores are not nearly so flexible. *Using the same hardware*, FPGA systems allow you to implement a completely custom datapath and control strategy for each new algorithm you are interested in, something that is only possible today with FPGA technology. This is enabling the production of reusable, generic hardware. The unprecedented flexibility of today's FPGA systems makes them fundamentally different than earlier flexible systems such as those based on writeable control stores (for example). Brad Hutchings Brigham Young UniversityArticle: 17204
Please find below the prelinarary program of the CHES workshop. For registration information, please see http://ece.wpi.edu/Research/crypt/ches ------------------------------------------------------- PRELIMINARY PROGRAM Workshop on Cryptographic Hardware and Embedded Systems Worcester, Massachusetts, August 12-13, 1999 ------------------------------------------------------- --- THURSDAY, AUGUST 12 --- Welcome by Ed Parrish (President, WPI) Introductory remarks by Cetin Koc and Christof Paar Invited Talk: Brian Snow, National Security Agency, USA We Need Assurance Session: CRYPTANALYTICAL HARDWARE A. Shamir Factoring large numbers with the TWINKLE device I. Hamer and P. Chow DES cracking on the Transmogrifier 2a --- break --- Session: HARDWARE ARCHITECTURES W.P. Choi and L.M. Cheng Modeling the crypto-processor from design to synthesis D.C. Wilcox, L.G. Pierson, P.J. Robertson, E.L. Witzke, and K. Gass A DES ASIC suitable for network encryption at 10 Gbps and beyond E. Hong, J.-H. Chung, and C.H. Lim Hardware design and performance estimation of the 128-bit block cipher CRYPTON Session: SMART CARDS AND EMBEDDED SYSTEMS K. Itoh, M. Takenaka, N. Torii, S. Temma, and Y. Kurihara Fast implementation of public-key cryptography on a DSP TMS320C6201 P.J. Lee, E.J. Lee, and Y.D. Kim How to implement cost-effective and secure public key cryptosystems --- lunch break --- Invited Talk: Colin D. Walter, Computation Department - UMIST, U.K. An Overview of Montgomery's Multiplication Technique: How to make it Smaller and Faster Session: ARITHMETIC ALGORITHMS A.F. Tenca and C.K. Koc A scalable architecture for Montgomery multiplication J.H. Silverman. Fast multiplication in finite fields GF(2^N) B. Kaliski and M. Liskov Efficient finite field basis conversion involving dual bases --- break --- Invited Talk: Eberhard von Faber, Debis IT Security Services, Germany Security Evaluation Schemes for the Public and Private Market with a Focus on Smart Card Systems Session: POWER ATTACKS I T.S. Messerges, E.A. Dabbish, and R.H. Sloan Power analysis attacks of modular exponentiation in smartcards L. Goubin and J. Patarin DES and differential power analysis P. Fahn and P. Pearson IPA: A new class of power attacks --- CHES Banquet on the WPI Campus, sponsored by Technical --- --- Communications Corporation, MA --- --- FRIDAY, AUGUST 13 --- Invited Talk: Dale Hopkins, Compaq - Atalla, USA Design of Hardware Encryption Systems for e-Commerce Applications Session: TRUE RANDOM GENERATORS V. Bagini and M. Bucci A design of reliable true random number generator for cryptographic applications D. Maher and B. Rance Random number generators founded on signal and information theory --- break --- Session: CRYPTOGRAPHIC ALGORITHMS ON FPGAS R.R. Taylor and S.C. Goldstein A high-performance flexible architecture for cryptography E. Mosanya, C. Teuscher, H.F. Restrepo, P. Galley, and E. Sanchez CryptoBooster: A reconfigurable and modular cryptographic coprocessor L. Gao, S. Shrivastava, and G.E. Sobelman Elliptic curve scalar multiplier design using FPGAs Session: GALOIS FIELD ARCHITECTURES H. Wu, M.A. Hasan, and I.F. Blake. Highly regular architectures for finite field computation using redundant basis H. Wu Low complexity bit-parallel finite field arithmetic using polynomial basis --- lunch break --- Invited Talk: David Naccache, Gemplus, France Significance Tests and Hardware Leakage Session: POWER ATTACKS II J.-S. Coron Resistance against differential power analysis attacks for elliptic curve cryptosystems H. Handschuh, P. Paillier, and J. Stern Probing attacks on tamper-resistant devices --- break --- Session: ELLIPTIC CURVE IMPLEMENTATIONS J. Lopez and R. Dahab Fast multiplication on elliptic curves over GF(2^m) without precomputation Y. Han, J. Zhang, and P.-C. Tan Direct computation for elliptic curve cryptosystems Session: NEW CRYPTOGRAPHIC SCHEMES AND MODES OF OPERATION M. Hartmann, S. Paulus, and T. Takagi NICE - New Ideal Coset Encryption - T. Horvath Arithmetic design for permutation groups O. Jung and C. Ruland Encryption with statistical self-synchronization in synchronous broadband networks ----------------------------------------------------------- Invited talks are 40 min, regular presentations 20 min long The Thursday program is from 9:00 am - 6:00 pm, the Friday program is from 8:30 am - 4:30 pm -------------------------------------------------------- Workshop on Cryptographic Hardware and Embedded Systems Worcester, Massachusetts, August 12-13, 1999 ------------------------------------------------------- Information: http://ece.wpi.edu/Research/crypt/ches E-Mail: ches@ece.orst.edu Program Chairs: Cetin Kaya Koc & Christof Paar koc@ece.orst.edu & christof@ece.wpi.edu -------------------------------------------------------Article: 17205
Hi I am looking for a prototype board with altera 10k50 and up, some memory, and 4 analog in (12b a/d 150 khz each) 2 analog out(12 b d/a), some interfacing vhdl/ahdl drivers. download with at least byteblaster.Article: 17206
<csoolan@dso.org.sg> wrote in message news:3781BA2A.74B1@dso.org.sg... > Hello, > > Does anyone have recommendations to find benchmark circuits for > FPGA - preferrably in VHDL ? > > Thanks in advance. > > email: csoolan@dso.org.sg I've been thinking about this for sometime myself. Gate counts and speed are two areas where it's hard to get *OBJECTIVE* data on FPGA devices. The problem with benchmarks is that most circuits seem to specialize in certain types of logic (gates, multiplexors, three-state buses, RAM, etc.). No matter what you use, somebody will complain that it doesn't represent what they're trying to benchmark. The same thing happens with computer benchmarks. I was talking to guy from the Bank of Boston about this at the DAC conference in New Orleans this month. They are also confused about FPGA gate counts and speed. We've got an 8-bit RISC processor (VHDL IP Core) that will run on most of the popular FPGA parts, and it occurs to me that would be an excellent benchmark circuit because it has a large variety of circuits inside of it (RAM, ROM, multiplexors, random logic, ALU, etc.). I suggested that the Bank of Boston develop a benchmark to compare FPGA gate counts and speeds, and offered him a core license to do that. It occurs to me that the same approach would work to benchmark VHDL synthesis tools too. -- Wade D. Peterson Silicore Corporation 3525 E. 27th St. No. 301, Minneapolis, MN USA 55406 TEL: (612) 722-3815, FAX: (612) 722-5841 URL: http://www.silicore.net/ E-MAIL: peter299@maroon.tc.umn.eduArticle: 17207
Austin Franklin wrote: > The PLX has the best DMA (burst master) system of the three. If you use > the Xilinx core, you will have to develop your own burst master, which is a > difficult task at best. The old AMCC chips were dogs, and I haven't tried > any of the new ones. Xilinx supplies with the LogiCORE PCI design a reference synthesizable bridge design that simplifies this task. The synthesizable bridge design gives you an example of how to do a DMA with R/W FIFOs, doorbells, mailboxes, target transaction ordering, etc. > Be careful with the latest PLX chip though (9054) if you need to use 5V > PCI. It does not provide any VCCIO pins, and that is in direct violation > with the PCI spec, especially since it is a 3.3V chip, used in a 5V PCI > system. If your PCI voltage is the same as the voltage of the chip, that > is fine. > > Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but at > least you can choose a technology part (3.3 or 5V) that meets your > application. Technically we do. Allow me to explain. The problem that is plaguing some universal PCI devices is the requirement for upper clamp diodes in the 3.3 V environment. If these clamps are missing, the device may not be compliant in a 3.3 V environment. If they are tied permanently to the 3.3 V rail, then they lose 5 V tolerance. In traditional ASIC thinking, since the devices aren't configurable, the solution is to bondout the upper clamp diode and the system designer then ties this to Vio. If Vio is at 5 V, the 5 V overshoot (as much as 11 V for 11 ns!) is clamped to something less than what would damage the device. If Vio is 3.3 V, the clamps for signal integrity are there as required by the spec. And the drive strength of the I/O buffer would be derived from this "Vccio". WIth FPGAs, we do thing differently, but still achieve compliance. From the PCI V2.2 Spec, page 114: > While the primary goal of the PCI 5V to 3.3V transition strategy is > to spare vendors the burden and expense of implementing 3.3V parts > that are "5V tolerant," such parts are not excluded. If a PCI > component of this type is used on the Universal board, its I/O buffers > may optionally be connected to the 3.3V rail rather than the "I/O" > designated power pins; but high clamp diodes must still be connected > to the "I/O" designated power pins. (Refer to the last paragraph of > Section 4.2.1.2. - "Clamping directly to the 3.3V rail with a simple > diode must never be used in the 5V signaling environment.") Since the > effective operation of these high clamp diodes may be critical to both > signal quality and device reliability, the designer must provide enough > extra "I/O" designated power pins on a component to handle the current > spikes associated with the 5V maximum AC waveforms (Section 4.2.1.3.). Several things to note here: 1. 3.3 V devices that are 5 V tolerant are allowed. This would include Xilinx FPGAs that supply 3.3 V to the I/O cells. The Xilinx XLA, SpartanXL, and Virtex families fall into this category. 2. Connecting the I/O cell to the 3.3 V rail is allowed. 3. The upper (high) clamp diode has to be tied to the I/O power. Xilinx handles this through a bitstream configuration; either the upper diode is tied to the 3.3 V rail, or it's floating. Since not using the upper clamps is allowed in a 5 V environment, this meets the PCI spec. We don't lose 5 V tolerance because the diode can be disconnected. 4. The overshoot for 5 V PCI has to be handled so that the device is not damaged. In 3.3 V devices, the thinner oxide layers can't withstand the 11 V overshoot. We handle this by a zener diode in the I/O structure that clamps the voltage to an acceptable level. So the real question here is how would one handle, in a compliant manner, the requirements for a universal PCI card with an FPGA? To do a universal PCI card, Xilinx requires loading of a different bitstream depending on the bus signaling level. When plugged into a 5 V PCI bus, a 5 V bitstream must be loaded. This will have the clamps disconnected and the 5 V drive strength enabled. This is fully 5 V PCI compliant. Likewise, when plugged into a 3.3 V PCI bus, a 3.3 V bitstream must be loaded. This will have the clamps enabled and the 3.3 V drive strength enabled. This is fully 3.3 V PCI compliant. While this is not a universal card in the usual sense of the term, it is completely compliant in either environment. The user does have the responsibility of insuring that his design loads appropriate bitstream. This is done by monitoring the PCI bus Vio pin with a comparator and some external logic. This could be as simple as using the comparator to drive an address line on a parallel PROM. And while we're discussing universal PCI cards, here is something to be aware of. As we go to smaller device geometries, specifically 0.18u, 5 V PCI tolerance will start to disappear. Since FPGAs tend to be produced for upwards of ten years and standard chips only 2-4 years, shortly the only way to do a 5 V or universal PCI card may be an FPGA (at 0.22u or larger). If you are planning on extended production of your 5 V or universal PCI card, this should be considered. Jim McManus Xilinx PCI Applications EngineerArticle: 17208
Hi, 10 x 10K40 10 x 10K50E 10 x 10K130E with almost 240 pin The country is France Thanks for the time. kerim el imem. lewis chen <lewis@galaxyfareast.com.tw> a écrit dans le message : 7lqj53$ro6@netnews.hinet.net... > How many quantity for your order and which your country > Lewis > Karim LIMAM ¼¶¼g©ó¤å³¹ <7lfnhf$oa1$1@arcturus.ciril.fr>... > >Hi, > > > >I'm looking for the prices of the Altera Flex 10K (10K40 .. 10K130E). Has > >somebody an idea ? > > > >Thanks. > > > > > >kerim el imem > > > > > >Article: 17209
Target is XC41050XV and has dedicated pins. Some new pins can be added, and we want the program to choose the free pads we want, not all the unused (free) pads. Is this possible in Design Manager? UtkuArticle: 17210
Wade D. Peterson wrote in message <7m39ct$e0i$1@news1.tc.umn.edu>... ><csoolan@dso.org.sg> wrote in message news:3781BA2A.74B1@dso.org.sg... >> Hello, >> >> Does anyone have recommendations to find benchmark circuits for >> FPGA - preferably in VHDL ? >> >> Thanks in advance. >> >> email: csoolan@dso.org.sg > >I've been thinking about this for sometime myself. Gate counts and speed are >two areas where it's hard to get *OBJECTIVE* data on FPGA devices. > snip... > >-- >Wade D. Peterson >Silicore Corporation >3525 E. 27th St. No. 301, Minneapolis, MN USA 55406 >TEL: (612) 722-3815, FAX: (612) 722-5841 >URL: http://www.silicore.net/ E-MAIL: peter299@maroon.tc.umn.edu > > > There used to be an organisation by the name of PREP (PRogrammable Electronics Performance Corporation) who published a set of benchmark circuits for FPGAs in VHDL on their web pages at http://www.prep.org/ , however the company and the web page both now appear to be defunct. Other contributors to the newsgroup will be able to fill in the details, but I believe a combination of vendors trying to bend the rules to suit their own marketing claims, combined with a lack of general acceptance eventually lead to PREP's failure. If you're interested, I have some of the benchmark circuits but if you want details on how the tests were performed, try to get hold of a copy of Actel's 1995 Data Book - it has a chapter devoted to the subject. -- Alasdair Alasdair MacLean, Senior Development Engineer, Marconi Electronic Systems, Electro Optic Systems Division, 4 Ferry Road, Silverknowes, Edinburgh EH4 4AD Telephone: 0131-343-5711, GNET: 709 5711 email: alasdair.maclean@gecm.comArticle: 17211
Using constraints, you can tell M1 to assign a set of signals to a set of pins. This is especially simple when the signals have a common prefix. For example, I once used the following constraint to assign all signals for an external memory interface to a set of pins. NET mem* LOC = Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15, Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12, U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8, W8, V8, Y7, W7, Y6, W6, V6, Y5 ; This would go into your ".ucf", or user constraints file. If your signals don't have the same prefix, you simply repeat the preceding command for each of the signals. Regards, Jamie Utku Ozcan wrote in message <3785D3E4.44731ACD@netas.com.tr>... >Target is XC41050XV and has dedicated pins. Some new pins can >be added, and we want the program to choose the free pads we want, >not all the unused (free) pads. Is this possible in Design Manager? > >UtkuArticle: 17212
"Semenov V.N." wrote: > > Hi, All! > > Today, I signed up for a membership at what > appears to be one of the most amazing sites on the Net. > It's basically a > vast consumer community service, which will soon be offering its members > substantial discounts on consumer merchandise as well as other various > community services (like forums, on-line shopping malls and a targeted > internet consumer index). They seem to be pretty serious! snip > > With best wishes, Mike. Mike, please read the rules ... 2. You will not use any method which could be viewed as 'SPAM' (unsolicited postings or e-mails) to refer people to TargetShop. Spamming is strictly prohibited by TargetShop, and you understand you may be subject to fines and/or imprisonment for disobeying laws or rules of certain network providers or jurisdictions regarding the use of 'SPAM' messages. The only acceptable methods of referring someone to Targetshop are sending e-mail to a friend, or posting a link to our main page (www.targetshop.com) on your own website. You will immediately lose your subscription to TargetShop, as well as any referral bonus you may have earned if this rule is disobeyed. --L2C --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- Lasse Langwadt Christensen, MSEE Aalborg University, Department of communication tech. Applied Signal Processing and Implementation (ASPI) http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 17213
Jamie Sanderson wrote: > > Using constraints, you can tell M1 to assign a set of signals to a set of > pins. This is especially simple when the signals have a common prefix. For > example, I once used the following constraint to assign all signals for an > external memory interface to a set of pins. > > NET mem* LOC = > Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15, > Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12, > U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8, > W8, V8, Y7, W7, Y6, W6, V6, Y5 ; > > This would go into your ".ucf", or user constraints file. If your signals > don't have the same prefix, you simply repeat the preceding command for each > of the signals. > > Regards, > Jamie I stated my problem inadequately. I have a design, it already has dedicated pins. Now when I add 4 pins, for example, normally, Design Manager will choose ANY of the unused pins. But I want to restrict the choose range of the Design Manager, for example, when I add a new pin, I want the Design Manager to choose not ANY of the unused pins but one among AA25, AA23, Y4, A26. Is this applicable? -- I feel better than James Brown.Article: 17214
Utku Ozcan wrote: > > I stated my problem inadequately. I have a design, it already has > dedicated pins. Now when I add 4 pins, for example, normally, > Design Manager will choose ANY of the unused pins. But I want to > restrict the choose range of the Design Manager, for example, when > I add a new pin, I want the Design Manager to choose not ANY of the > unused pins but one among AA25, AA23, Y4, A26. Is this applicable? > Why not just choose them yourself? It probably won't make a bit of difference in your routability. -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 17215
This is a multi-part message in MIME format. --------------4BA9E6687849D3D5C213C8C9 Content-Type: multipart/alternative; boundary="------------C56277CD46AE9EB76D74D356" --------------C56277CD46AE9EB76D74D356 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Unless I am mis-understanding what you are asking, Jamie explanation is essentially correct but I will try it a different way. You say you have added 4 new ports which you want to constrain to four specific pads but you don't care which one of the four pads the new port lands on. This can be done with one LOC constraint as Jamie pointed out if they have a common name that can be wild-carded but if not, it can be done in four LOC constarints within your UCF file as follows: NET port_1_name LOC = AA25, AA23, Y4, A26 ; NET port_2_name LOC = AA25, AA23, Y4, A26 ; NET port_3_name LOC = AA25, AA23, Y4, A26 ; NET port_4_name LOC = AA25, AA23, Y4, A26 ; You can overlap the port definitions as I have done so above as long as there is enough pads to go around to each port. If this sounds like what you are looking for, try it out. If this is not what you want to do or you have any other questions about Xilinx constraints, I suggest you look at the Timing and Contraints Journal on our website at http://support.xilinx.com/support/techsup/journals/timing/index.htm . It has concise information on ways to constrain your design. I also suggest looking through the docs (i.e. Libraries Guide) if you would like more detailed inormation on the constraint language. Good Luck, -- Brian Utku Ozcan wrote: > Jamie Sanderson wrote: > > > > Using constraints, you can tell M1 to assign a set of signals to a set of > > pins. This is especially simple when the signals have a common prefix. For > > example, I once used the following constraint to assign all signals for an > > external memory interface to a set of pins. > > > > NET mem* LOC = > > Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15, > > Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12, > > U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8, > > W8, V8, Y7, W7, Y6, W6, V6, Y5 ; > > > > This would go into your ".ucf", or user constraints file. If your signals > > don't have the same prefix, you simply repeat the preceding command for each > > of the signals. > > > > Regards, > > Jamie > > I stated my problem inadequately. I have a design, it already has > dedicated pins. Now when I add 4 pins, for example, normally, > Design Manager will choose ANY of the unused pins. But I want to > restrict the choose range of the Design Manager, for example, when > I add a new pin, I want the Design Manager to choose not ANY of the > unused pins but one among AA25, AA23, Y4, A26. Is this applicable? > > -- > I feel better than James Brown. -- ------------------------------------------------------------------- / 7\'7 Brian Philofsky (brian.philofsky@xilinx.com) \ \ ` Xilinx Applications Engineer hotline@xilinx.com / / 2100 Logic Drive 1-800-255-7778 \_\/.\ San Jose, California 95124-3450 1-408-879-5199 ------------------------------------------------------------------- --------------C56277CD46AE9EB76D74D356 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>Unless I am mis-understanding what you are asking, Jamie explanation is essentially correct but I will try it a different way. <p>You say you have added 4 new ports which you want to constrain to four specific pads but you don't care which one of the four pads the new port lands on. This can be done with one LOC constraint as Jamie pointed out if they have a common name that can be wild-carded but if not, it can be done in four LOC constarints within your UCF file as follows: <p>NET port_1_name LOC = AA25, AA23, Y4, A26 ; <br>NET port_2_name LOC = AA25, AA23, Y4, A26 ; <br>NET port_3_name LOC = AA25, AA23, Y4, A26 ; <br>NET port_4_name LOC = AA25, AA23, Y4, A26 ; <p>You can overlap the port definitions as I have done so above as long as there is enough pads to go around to each port. <p>If this sounds like what you are looking for, try it out. If this is not what you want to do or you have any other questions about Xilinx constraints, I suggest you look at the Timing and Contraints Journal on our website at <A HREF="http://support.xilinx.com/support/techsup/journals/timing/index.htm">http://support.xilinx.com/support/techsup/journals/timing/index.htm</A> . It has concise information on ways to constrain your design. I also suggest looking through the docs (i.e. Libraries Guide) if you would like more detailed inormation on the constraint language. <p>Good Luck, <p>-- Brian <br> <br> <br> <p>Utku Ozcan wrote: <blockquote TYPE=CITE>Jamie Sanderson wrote: <br>> <br>> Using constraints, you can tell M1 to assign a set of signals to a set of <br>> pins. This is especially simple when the signals have a common prefix. For <br>> example, I once used the following constraint to assign all signals for an <br>> external memory interface to a set of pins. <br>> <br>> NET mem* LOC = <br>> Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15, <br>> Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12, <br>> U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8, <br>> W8, V8, Y7, W7, Y6, W6, V6, Y5 ; <br>> <br>> This would go into your ".ucf", or user constraints file. If your signals <br>> don't have the same prefix, you simply repeat the preceding command for each <br>> of the signals. <br>> <br>> Regards, <br>> Jamie <p> I stated my problem inadequately. I have a design, it already has <br> dedicated pins. Now when I add 4 pins, for example, normally, <br> Design Manager will choose ANY of the unused pins. But I want to <br> restrict the choose range of the Design Manager, for example, when <br> I add a new pin, I want the Design Manager to choose not ANY of the <br> unused pins but one among AA25, AA23, Y4, A26. Is this applicable? <p>-- <br>I feel better than James Brown.</blockquote> <pre>-- ------------------------------------------------------------------- / 7\'7 Brian Philofsky (brian.philofsky@xilinx.com) \ \ ` Xilinx Applications Engineer hotline@xilinx.com / / 2100 Logic Drive 1-800-255-7778 \_\/.\ San Jose, California 95124-3450 1-408-879-5199 -------------------------------------------------------------------</pre> </html> --------------C56277CD46AE9EB76D74D356-- --------------4BA9E6687849D3D5C213C8C9 Content-Type: text/x-vcard; charset=us-ascii; name="brianp.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brianp.vcf" begin:vcard n:Philofsky;Brian tel;fax:(408) 879-4442 tel;work:1-800-255-7778 x-mozilla-html:TRUE org:<BR><H1 ALIGN="CENTER"><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx" ALIGN="CENTER"> Design Center version:2.1 email;internet:brianp@xilinx.com title:<H3 ALIGN="CENTER"><img src="http://bennyhills.fortunecity.com/deadparrot/108/homer.gif" alt="Homer" align="center"> Application Engineer adr;quoted-printable:;;2100 Logic Drive=0D=0ADept. 2510;San Jose;CA;95124-3450;USA x-mozilla-cpt:;15200 fn:<H3 ALIGN="CENTER">Brian Philofsky end:vcard --------------4BA9E6687849D3D5C213C8C9--Article: 17216
....sorry if this ends up being posted twice. My regular ISP has bad news service, so I tried posting it though DejaNews...which is convoluted at best...and it hasn't shown up yet... > > Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but at > > least you can choose a technology part (3.3 or 5V) that meets your > > application. > > Technically we do. Allow me to explain. This is from PCI-Spec 2.2: “While there are multible buffer implementations that can achieve this dual environment compliance, it is intended that they be dual voltage buffers; i.e., capable of operating from either power rail. They should be powered from “I/O” designated power pins on PCI connectors that will always be connected to the power rail associated with the signaling environment in use.” I'm not saying it wouldn't work just fine, but technically, according to this quote from the PCI spec, if you don't provide clamp diodes (under any voltage) and I/O designated power pins, I believe that would not meet this part of the spec. AustinArticle: 17217
Brian Boorman wrote: > > Utku Ozcan wrote: > > > > I stated my problem inadequately. I have a design, it already has > > dedicated pins. Now when I add 4 pins, for example, normally, > > Design Manager will choose ANY of the unused pins. But I want to > > restrict the choose range of the Design Manager, for example, when > > I add a new pin, I want the Design Manager to choose not ANY of the > > unused pins but one among AA25, AA23, Y4, A26. Is this applicable? > > > > Why not just choose them yourself? It probably won't make a bit of > difference in your routability. Pardon me for the misunderstanding. Thank you very much for the helpful answers. I had to pass test pins to board designers for the chip, but our P&R results missed the deadline. Therefore I had to pass some arbitrary unused pins. Now I have to choose them but not other pins. UtkuArticle: 17218
> Does anyone have a number for the Sales of Coolrunner - one press >release >mentioned $10M - sounded low ? Given that Philips Component Marketing could not sell a Mars Bar to a starving man, this might not be far off. I reckon Xilinx bought it because they could see competition coming up - the Philips PLDs are extremely low power. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 17219
The Portland, Oregon office of Oxford and Associates is helping a local client search for an FPGA designer with experience using Altera. Experience working with telephony applications is highly desirable. The work is to be done at the client's site. It's a 6+ month contract, with 40 hours a week plus overtime. Please respond to margaret@cyberhighway.net. Principals only, please.Article: 17220
alt.binaries.pictures.drag-racing alt.games.microsoft.cart-racing alt.sport.adv-racing alt.sport.adventure-racing alt.sport.dragracing alt.sport.horse-racing alt.sport.horse-racing.systems hk.rec.horse-racing msen.reuters.racing-results rec.autos.sport.nascar rec.gambling.racing .oval-racing uk.sport.horseracingArticle: 17221
Hi all. I just heard of a new standard for 1149.1-based in-system programming of programmable devices. And I was wondering why I hadn't noticed any discussion of this lately? Perhaps few parts use the TAP port for programming?? --al toda ########################################################### Alvin E. Toda aet@lava.net sr. engineer Phone: 1-808-455-1331 2-Sigma WEB: http://www.lava.net/~aet/2-sigma.html 1363-A Hoowali St. Pearl City, Hawaii, USAArticle: 17222
Austin Franklin wrote: > > > Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but > at > > > least you can choose a technology part (3.3 or 5V) that meets your > > > application. > > > > Technically we do. Allow me to explain. > > This is from PCI-Spec 2.2: > > “While there are multible buffer implementations that can achieve this dual > environment compliance, it is intended that they be dual voltage buffers; > i.e., capable of operating from either power rail. They should be powered > from “I/O” designated power pins on PCI connectors that will always be > connected to the power rail associated with the signaling environment in > use.” > > I'm not saying it wouldn't work just fine, but technically, according to > this quote from the PCI spec, if you don't provide clamp diodes (under any > voltage) and I/O designated power pins, I believe that would not meet this > part of the spec. Allow me to further elaborate on this subject. My PCI spec quotation from yesterday was the footnote to this section you just mentioned. But let's dig a little deeper into this: From the V2.2 PCI Spec, page 120 (5 V signaling): "Inputs are required to be clamped to ground. Clamps to the 5V rail are optional, but may be needed to protect 3.3V input devices." We don't need this upper clamp to protect our newer 3.3 V devices; the zener diode handles the protection aspect in XLA, SpartanXL, and Virtex families. We did need additional protection in older XL family since it lacked the zener diode. Xilinx's solution for this was the XLT family, which was an XL device with these upper clamps bonded out directly. The key issue here is to protect the device from the high overshoots seen on the unterminated 5 V PCI bus. We do this in every 3.3 V (and 2.5 V) family we support with PCI. Since upper clamps are optional, we can be compliant to the 5 V PCI spec without them. The complaint lodged against some of the PCI devices was the lack of a clamp diode in a 3.3 V environment, not the lack of a clamp in a 5 V environment. Remember the upper clamps serve a different purpose depending on the environment: 5 V - device protection 3.3 V - signal integrity Keep in mind that we are not a universal PCI device as most people think of universal PCI devices; we are either a 5 V PCI device or a 3.3 V PCI device, but not both at the same time. We will never need to be both at the same time, since we can only be plugged into one bus at a time. We are fully 5 V compliant when a 5 V bitstream is loaded and we are plugged into a 5 V PCI bus, and we are a fully compliant 3.3 V PCI device when a 3.3 V bitstream is loaded and we are plugged into a 3.3 V bus. As I mentioned, the user is responsible for loading the appropriate bitstream. If he does not do this (e.g. loads a 3.3 V bitstream while plugged into a 5 V PCI) then it will fall out of compliance. If the user does this as recommended, his board will be indistinguishable from a board that has a device that can be both 3.3 V and 5 V at the same time. If looked at from this point of view, the board really is universal, and will pass any tests that a universal device can pass. The signaling environment will never change on the fly; the card must be removed from the bus and plugged into another bus to change the environment. The card will always have the chance to load the correct bitstream. Jim McManus Xilinx PCI Applications EngineerArticle: 17223
Interested in enhancing your career or just curious to what the market could offer. CAll me....800.248.7020 x260 SEEKING: Jr & Sr. FPGA/Digital Design Engineers REF #: FPGA-610-99 ** Candidates MUST reside in the US or CN ** LOCATION: MA/TX/VA/MD/IL, other areas available too...call me to find out more. OTHER opportunities available...permanent hire positions. REQUIREMENTS: Design/develop products for a cutting edge product; communitions and computer. Extensive design exp in SCSI & RISC microprocessors, board level design, programmable logic design including FPGAs, PLDs, ASIC and analog design. Hands-on system architecture, board and chip level hardware design necessary. 5+ yrs exp. GREAT benefits + salary + Sign-on ___________________________________________________________ Call: Mike DeLaney 800-248-7020 x260 Fax 800-838-8789 ATTN: Mike Email: mdelaney@servtech.com National Engineering Search http://www.nesnet.com "Engineers placing Engineers" ____________________________________________________________ See what your skills are worth...CALL for a FREE salary survey. ____________________________________________________________ National Engineering Search (http://www.nesnet.com) is a technical recruiting firm, staffed with degreed engineers, dedicated exclusively to placing Engineers nationwide. If this position doesn't fit your requirements, call me with your specific search criteria. € NES can identify SELECT engineering opportunities based on your background, interests, and geographic requirements. € What makes us better...We are Engineers placing Engineers.Article: 17224
Utku Ozcan wrote: > Target is XC41050XV and has dedicated pins. Some new pins can > be added, and we want the program to choose the free pads we want, > not all the unused (free) pads. Is this possible in Design Manager? > > Utku Hello To prohibit IO pin, you can use this exemple : To prohibit pin P26: CONFIG PROHIBIT = P26 Hope this helps, Michel Le Mer Gerpi sa (Xilinx Xpert) 3, rue du Bosphore Alma city 35000 Rennes (France) (02 99 51 17 18) http://www.xilinx.com/company/consultants/partdatabase/europedatabase/gerpi.htm
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