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
Hi, I am using Xilinx Foundation F1.5i. After mapping my design I got the following warning: WARNING:x4kma:59 - The clock buffer BUFGP symbol "$I33" (output signal=LCLK) (constrained to site BUFGP_TR) has been connected to pins that it cannot access directly. Route-throughs must be used to route its global net completely, resulting in increased skew. Please note that BUFGPs (primary global buffers) can only connect directly to K (clock) pins and EC (clock enable) pins on CLBs and IOBs. If increased skew is unacceptable, please check your original design to see if the global net associated with this clock buffer is connected to generic (non-CLK and non-CE) logic. I cannot understand this, because my clock net is definetly not connected to any signal but CLKs ! My clock path lock like this: SpartanPAD160 -> BUFGP -> LCLK net -> many FF-clocks Where is my mistake ? THX for any advise ! MatthiasArticle: 17101
Hi, after mapping my design I got some of the following warnings: WARNING:baste:267 - The OPTIMIZE attribute located on ACCESS symbol "U37" does not have a corresponding OPT_EFFORT property. The default effort (NORMAL) will be used. How can I access this OPTIMIZE attribute ? I didn't found any advise in the online help and munuals ! THX for advice MatthiasArticle: 17102
We are pleased to announce the following papers will appear at
the Workshop on Cryptographic Hardware and Embedded Systems.
Information about the conference is found at
http://ece.wpi.edu/Research/crypt/ches.
-------------------------------------------------------
Workshop on Cryptographic Hardware and Embedded Systems
Worcester, Massachusetts, August 12-13, 1999
-------------------------------------------------------
Accepted Papers:
----------------
A. Shamir
Factoring large numbers with the TWINKLE device
J. H. Silverman.
Fast multiplication in finite fields GF(2^n)
B. Kaliski and M. Liskov
Efficient finite field basis conversion involving dual bases
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
K. Itoh, M. Takenaka, N. Torii, S. Temma, and Y. Kurihara
Fast implementation of public-key cryptography
P. J. Lee, E. J. Lee, and Y. D. Kim
How to implement cost-effective and secure public key cryptosystems
J. Lopez and R. Dahab
Fast multiplication on elliptic curves over GF(2^m) without
precomputation
L. Gao, S. Shrivastava, and G. E. Sobelman
Elliptic curve scalar multiplier design using FPGAs
Y. Han, J. Zhang, and P.-C. Tan
Direct computation for elliptic curve cryptosystems
J.-S. Coron
Resistance against differential power analysis attacks for
elliptic curve cryptosystems
L. Goubin and J. Patarin
DES and differential power analysis
P. Fahn and P. Pearson
IPA: A new class of power attacks
T. S. Messerges, E. A. Dabbish, and R. H. Sloan
Power analysis attacks of modular exponentiation in smartcards
H. Handschuh, P. Paillier, and J. Stern
Probing attacks on tamper-resistant devices
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
W. P. Choi and L. M. Cheng
Modelling the crypto-processor from design to synthesis
R. R. Taylor and S. C. Goldsteiny
A high-performance flexible architecture for cryptography
A. F. Tenca and C. K. Koc
A scalable architecture for Montgomery multiplication
E. Mosanya, C. Teuscher, H. F. Restrepo, P. Galley, and E. Sanchez
CryptoBooster: A reconfigurable and modular cryptographic coprocessor
I. Hamer and P. Chow
DES cracking on the Transmogrifier 2a
M. Hartmann, S. Paulus, and T. Takagi
NICE - New Ideal Coset Encryption -
D. C. Wilcox, L. G. Pierson, P. J. Robertson, and E. L. Witzke
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
T. Horvath
Arithmetic design for permutation groups
O. Jung and C. Ruland
Encryption with statistical self-synchronization in synchronous
broadband networks
Invited Talks:
--------------
Brian Snow, National Security Agency, USA
We Need Assurance
Eberhard von Faber, Debis IT Security Services, Germany
Security Evaluation Schemes for the Public and Private
Market with a Focus on Smart Card Systems
Dale Hopkins, Compaq - Atalla, USA
Design of Hardware Encryption Systems for e-Commerce Applications
Colin D. Walter, Computation Department - UMIST, U.K.
An Overview of Montgomery's Multiplication Technique:
How to make it Smaller and Faster
David Naccache, Gemplus, France
Significance Tests and Hardware Leakage
-------------------------------------------------------
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: 17103Andy, usa a CPLD they are much faster !!! Regards Aurel Andy Peters wrote: > Is it reasonable to assume that I can build a 12-bit counter in VHDL using > FPGA Express and make it run faster than 50 MHz in the -09 part? > > given: > > counter : process (clk, reset) > begin > if reset = '1' then > cnt <= (others => '0'); > elsif clk'event and clk = '1' then > if load = '1' then > cnt <= initreg; > elsif cnten = '1' then > cnt <= cnt + '1'; > end if; > end if; > end process counter; > > load and cnten are both synchronous with the clock. FPGA Express tells me > that it's barely over 20 ns for some of it. > > Seems sorta silly that this can't work. Looks like it's time to do it by > hand or use a logicore adder for the counters. > > Time to go home and watch the knicks lose. > > -- a > ------------------------------------------ > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters@noao.edu > > NY Knicks in '99: > "Ya gotta believe!" -- ################################################################ Aurelius Wosylus Lattice_Vantis GmbH Einsteinstr. 10 D-85716 Unterschleissheim tel: +49-89-317 87-813 fax: +49-89-317 87-830 email: aurel_wosylus@latticesemi.com http://www.latticesemi.comArticle: 17104
Allan Herriman wrote: >Rickman, > >The reference is ITU-T Recommendation G.711 "PULSE CODE MODULATION >(PCM) OF VOICE FREQUENCIES" >(1988 vintage, I think). > >http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.html >This is copyright, so you shouldn't be able to get any free copies >from the web, unfortunately. > >I notice this web site also has a *free* reference G.711 >implementation in C from Sun. > >Regards, >Allan. > > >On Tue, 29 Jun 1999 23:13:22 -0400, Rickman <spamgoeshere4@yahoo.com> >wrote: > >>I may need to do uLaw and ALaw conversion in an FPGA since the newer >>AC97 codecs don't seem to support that internally. I could dig out >>copies of the specs and figure out how to implement the conversion >>myself, but I really just don't feel like doing all that thinking >>tonight. I got beat at indoor badminton by little old ladies and they >>wore me out! You wouldn't think that badminton would be such a strenuous >>sport, would you? >> >>Is there a simple way to perform this conversion one bit at a time? I >>did a little brain work and decided that a direct table lookup would be >>too expensive in terms of LUTs. If I remember correctly, one of the two, >>uLaw or ALaw, could be done with a table lookup for part of the word and >>an interpolation for the rest. And, of course, I need to convert in both >>directions. >> >>If I can't get anyone to do my thinking for me tonight, can someone at >>least point me to the specs for these two codes? Are they available >>online? Or are there any good references online? >> >>And yes, I agree that the conversion not only could, but should be done >>in software, but my customer has put it in the spec that the codec >>should provide this function. It is not a MIPS issue since I have been >>told that they don't need all the MIPS I am providing anyway. It is a >>"customer is always right" issue. >> >>-- >> >>Rick Collins >> >>rick.collins@XYarius.com >> >>remove the XY to email me. >> >> >> >>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 > All you need to know - you can find in codec datasheet (for ex. MC145480 from Motorola). Last year I had to do something similar - pcm conferencing bridge. Simple: first a-law (or u-law) to linear, then linear to u-law (a-law). Regards, PawelArticle: 17105
"Steven J. Ackerman" wrote: > On Fri, 18 Jun 1999 14:59:42 -0400, Brian Boorman > <XZY.bboorman@harris.com> wrote: > > Bye bye Coolrunner... > Just the oppopsite: Welcome Coolrunner, now you will be supported by a company that understands Programmable Logic. Peter AlfkeArticle: 17106
Aurel Wosylus wrote in message <377A1423.82DB59A5@latticesemi.com>... >Andy, >usa a CPLD they are much faster !!! Unfortunately, the chip has to do much more than simply a 12-bit adder. Hence, the 4013. best, -- andy ------------------------------------------ Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters@noao.eduArticle: 17107
>From what I know (could be wrong ! ) - DSPs ( TI, ARM ...etc ) form the programmable components in cell phones - why aren't FPGA's used instead ( or are they ???? ). Any comments would be welcome ! Thanks..........Article: 17108
Rickman wrote: > > I may need to do uLaw and ALaw conversion in an FPGA since the newer > AC97 codecs don't seem to support that internally. I could dig out > copies of the specs and figure out how to implement the conversion > myself, but I really just don't feel like doing all that thinking > tonight. I got beat at indoor badminton by little old ladies and they > wore me out! You wouldn't think that badminton would be such a strenuous > sport, would you? > > Is there a simple way to perform this conversion one bit at a time? I > did a little brain work and decided that a direct table lookup would be > too expensive in terms of LUTs. If I remember correctly, one of the two, > uLaw or ALaw, could be done with a table lookup for part of the word and > an interpolation for the rest. And, of course, I need to convert in both > directions. > > If I can't get anyone to do my thinking for me tonight, can someone at > least point me to the specs for these two codes? Are they available > online? Or are there any good references online? > > And yes, I agree that the conversion not only could, but should be done > in software, but my customer has put it in the spec that the codec > should provide this function. It is not a MIPS issue since I have been > told that they don't need all the MIPS I am providing anyway. It is a > "customer is always right" issue. > > -- mu-law looks alot like a sign,4 fractional bits and 3 exponent bits floating point number, so it is linear in segments If you have Matlab have a look at mu2lin.m or have look at: http://192.107.38.102/java/sun_au/B/INDEXB.HTM I think especially the tables at: http://192.107.38.102/java/sun_au/B/ACODI.HTM --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: 17109
Volume is high enough to make ASICs cheaper, and the static power in most FPGAs is a killer for handheld stuff. Where the FPGA would pay off is if they take advantage of the reconfigurability. I know of folks out there looking at this. Anurag wrote: > From what I know (could be wrong ! ) - DSPs ( TI, ARM ...etc ) > form the programmable components in cell phones - why aren't > FPGA's used instead ( or are they ???? ). > > Any comments would be welcome ! > 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: 17110
Lasse, what are you doing over here in comp.arch.fpga??? To do it in an FPGA you can use an architecture similar to the one I described in my DSPGURU post entitled 'quick and dirty logarithms' This is basically normalizing the fixed point input to get a mantissa and exponent, then passing them separately through small look-up tables and adding the results. The look up tables turn out to be only 4 or 5 bits address. You can find a link to the quick and dirty logs post at grant griffin's www.dspguru.com site. Lasse Langwadt Christensen wrote: > Rickman wrote: > > > > I may need to do uLaw and ALaw conversion in an FPGA since the newer > > AC97 codecs don't seem to support that internally. I could dig out > > copies of the specs and figure out how to implement the conversion > > myself, but I really just don't feel like doing all that thinking > > tonight. I got beat at indoor badminton by little old ladies and they > > wore me out! You wouldn't think that badminton would be such a strenuous > > sport, would you? > > > > Is there a simple way to perform this conversion one bit at a time? I > > did a little brain work and decided that a direct table lookup would be > > too expensive in terms of LUTs. If I remember correctly, one of the two, > > uLaw or ALaw, could be done with a table lookup for part of the word and > > an interpolation for the rest. And, of course, I need to convert in both > > directions. > > > > If I can't get anyone to do my thinking for me tonight, can someone at > > least point me to the specs for these two codes? Are they available > > online? Or are there any good references online? > > > > And yes, I agree that the conversion not only could, but should be done > > in software, but my customer has put it in the spec that the codec > > should provide this function. It is not a MIPS issue since I have been > > told that they don't need all the MIPS I am providing anyway. It is a > > "customer is always right" issue. > > > > -- > > mu-law looks alot like a sign,4 fractional bits and 3 exponent bits > floating point number, so it is linear in segments > If you have Matlab have a look at mu2lin.m > > or have look at: http://192.107.38.102/java/sun_au/B/INDEXB.HTM > I think especially the tables at: > http://192.107.38.102/java/sun_au/B/ACODI.HTM > > --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.org -- -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: 17111
On Sat, 26 Jun 1999 17:00:39 GMT, adamjone@purdue.edu wrote: David Albano's suggestion for pulsing PRGM low worked. Thanks a lot. I'm still looking for help with the readback functionality however. Anyone know how this is done? >I'm using a Virtex XCV300 and I'm having trouble finding documentation >on how to perform readback with the JTAG/boundary-scan interface. The >configuration and readback document (xapp138.pdf) references only the >SelectMAP method of readback. It says to reference xapp139 for >information on readback and configuration with the JTAG. After >calling tech support, I found that this document has not yet been >written. I've tried simply entering the CFG_OUT instruction into the >TAP instruction register and then clocking out data, but that doesn't >do it. Does anyone know what the proper method for readback using the >JTAG on Virtex parts is? > Also, I have been able to configure the Virtex device after >startup using the JTAG, but I haven't been able to reconfigure the >device after the first configuration. Is the sequence of commands >different for a second configuration?Article: 17112
>Just the oppopsite: >Welcome Coolrunner, now you will be supported by a company that understands >Programmable Logic. > >Peter Alfke > So, a PLD family designed by people who don't "understand programmable logic", bought by people who were silly enough to purchase something designed by (claimed) incompentents, and supported by people that don't know how to spell. Sorry, couldn't resist :-), you left yourself too open.Article: 17113
Ray Andraka wrote: > > Lasse, what are you doing over here in comp.arch.fpga??? To do it in an FPGA > you can use an architecture similar to the one I described in my DSPGURU post > entitled 'quick and dirty logarithms' This is basically normalizing the fixed > point input to get a mantissa and exponent, then passing them separately > through small look-up tables and adding the results. The look up tables turn > out to be only 4 or 5 bits address. You can find a link to the quick and > dirty logs post at grant griffin's www.dspguru.com site. ...snip... I found that by the definition, muLaw and ALaw are even simpler than that. For muLaw you add 33 first to bring all of the break points up to a power of two, then you do the shift for normallization that you mention. But you don't need the table lookup since they just grab the remaining four MSBs ignoring the nomalized '1' and use that as the LSBs of the companded word. The 3 bit shift count is inverted (or subtracted from 7, or just start with 7 and count down) and stuck between the sign bit and the four mantissa bits. A-Law is very similar, but you don't add anything first. In both modes, you limit the number of shifts to 7. This should be pretty simple to implement with a shift register, a 3 bit counter and a bit of control logic. I have 512 clock cycles to convert each frame at the fastest rate, so I can mux one compander circuit with multiple data sources. The inverse operation is similar which will allow me to possibly share the same circuit again. No worries! -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 17114
WARNING: Marketing / sales stuff ahead.
So it took a little longer than I planned, but
here I am announcing my software tools for FPGA
design, only 15 months later than the planned
schedule.
For those of you who don't use Xilinx chips, unless
you think that neat tools could make you change,
there will be nothing of interest here for you.
There are many screen shots and much more detail
available on my web site at www.fliptronics.com
as well as a downloadable copy of the online help
which accounts for the last 6 months of schedule slip.
The web site also has a feedback form on it, and even
if you think these tools are not for you, the feedback
form may help point me in a direction that would better
support your needs.
As some of you know, I am a consultant and have done a
few hundred FPGA designs. Most are high speed image
processing, DSP, satellite communications, medical
electronics, and a few other things. These programs
are the result of 5 years of evolutionary improvement
and automation of techniques that I use in my designs.
I believe that these programs will help beginning
users get better results, and will help expert users
be more productive.
Anyway, here is my press announcement.
I am looking forward to your comments (and orders)
Philip Freidin
=============================================
Press Release - 6/29/1999
Company: Fliptronics
Editorial contact phone: (408) 737-0295 Philip Freidin
Editorial contact email: philip@fliptronics.com
Products: FlibGen A module generator for Xilinx FPGA design
FlibTime A static timing reporter add-on to FlibGen
ChipView An FPGA viewer that shows floorplans and
critical timing paths.
FPGA tools helps Xilinx users get expert results.
-----------------------------------------------------
Fliptronics is announcing three new programs that can help
designers get expert results with Xilinx FPGAs, and can make
expert users more productive.
FlibGen is a module generator that has an easy to use menu
interface for building over 35000 modules. Module types
include arithmetic, counter, multiplexer and register
functions. Unlike other module generators, FlibGen links
directly into Viewlogic's ViewDraw schematic system and
actually draws a complete and detailed schematic of the
module being generated. This make simulation and design
debug far easier, as well as allowing the user to make
custom changes to the modules. All modules types can be
generated with data path widths from 2 to 32 bits. The
modules are typically used in data path and DSP
applications. FlibGen can do in seconds what could take
hours to do manually. All modules include detailed
floorplanning, and are optimal designs.
FlibTime is an extension to FlibGen. It reports to the user
the performance that the module being specified can achieve,
given the target FPGA, and its speed grade. Conversely, the
user can find out what speed grade device should be chosen,
given a module type and a performance goal. The performance
impact of selecting various options (i.e. an up-counter vs.
an up/down counter) or changing the size of the module
(i.e. a 13 bit vs. a 16 bit accumulator) can be seen
immediately. All FlibTime information is available without
having to run place and route software, or even generate
the module.
ChipView is an FPGA viewer for placed and routed designs.
Using color coding, it displays a detailed resources map
of your FPGA design, showing logic, flip-flops, RAM, ROM,
I/O, and carry-logic. The display includes information about
which resources have been floorplanned, and which have not,
as well as graphically showing how much room remains in the
FPGA for further additions. ChipView is able to overlay the
main display with information about the critical performance
paths in your design, assisting in resolving system timing
issues.
All three programs run on Windows NT4.0 systems.
FlibGen provides support for Xilinx XC4000E, XC4000EX, XC4000XL,
XC4000XLA, XC4000XV, Spartan and SpartanXL product families.
FlibGen and FlibTime work with Viewlogic's ViewDraw schematic
capture system.
ChipView supports the same FPGA families as FlibGen and can be
used with schematic- and HDL-based design flows.
Fliptronics is based in Silicon Valley California, and provides
consulting services for high speed FPGA and CPU design. Developed
over several years, these new programs encapsulate much of the
experience gained from doing hundreds of FPGA designs for image
processing, satellite communications applications, and medical
electronics.
Additional information and screen shots of the software are
available at www.fliptronics.com
Product Price: FlibGen $500
(includes 1 year of FlibTime $500
support and updates) ChipView $500
All 3 products as a kit $1400
Reader contact phone: (408) 737-0295 Philip Freidin
Reader contact email: philip@fliptronics.com
Web URL for more info: www.fliptronics.com
===================================================
Article: 17115I'd like the same if anybody can identify useful sources ! <channing@my-deja.com> wrote in message news:7l865v$khc$1@nnrp1.deja.com... > Hi, All, > > I want to apply a FPGA to build a Net Bridge. Is there anybody advise > how I can find the reference designs or get the technical document > related to this? > > > Thanks a lot. > > > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't.Article: 17116
Cost ! Anurag <anurag@earthling.net> wrote in message news:7ldo93$rru@fox.almaden.ibm.com... > From what I know (could be wrong ! ) - DSPs ( TI, ARM ...etc ) > form the programmable components in cell phones - why aren't > FPGA's used instead ( or are they ???? ). > > Any comments would be welcome ! > Thanks.......... > >Article: 17117
Hi, Just a naive question about the operating conditions limits on huge FPGA like the Xilinx Virtex. Some annoucement says that this device can operate at frequencies in the 100Mhz range. So let's say that that I want to implement a design within a XCV1000 wich can work at 100Mhz and has 80% of its Flip flop changing state at each clock cycle (heavily pipelined design)... In term of heat dissipation, such a design seems fairly unrealistic to me ... Am i right ? If so does anybody knows what kind of trade-off should I expect between operating frequency and DFF/CLB's activity ? Thanks StevenArticle: 17118
Hi, I'm looking for the prices of the Altera Flex 10K (10K40 .. 10K130E). Has somebody an idea ? Thanks. kerim el imemArticle: 17119
Good forced airflow is a must! Interestingly, Xilinx is strangely quiet everytime this is brought up. I think alot of that has to do with the difficulty in accurately estimating the power dissipation. I don't know where the limit is, but I can tell you that several years ago I let the magic smoke out of a plastic 4013 that had over 95% of the flip-flops toggling near the max toggle rate. Granted, that was a 5v design in older technology, but the spectre of exceeding the power dissipation limits of the package is very real. The solution in that case was to go to the HQ240 package, tie unused CLB inputs, put copper directly under it, and blow lots of air across it. Steven Derrien wrote: > Hi, > > Just a naive question about the operating conditions limits on huge FPGA > like the Xilinx Virtex. > Some annoucement says that this device can operate at frequencies in the > 100Mhz range. > > So let's say that that I want to implement a design within a XCV1000 > wich can work at 100Mhz and has 80% of its Flip flop changing state at > each clock cycle (heavily pipelined design)... > > In term of heat dissipation, such a design seems fairly unrealistic to > me ... Am i right ? > If so does anybody knows what kind of trade-off should I expect between > operating frequency and DFF/CLB's activity ? > > Thanks > > Steven -- -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: 17120
Ray Andraka wrote: > > Lasse, what are you doing over here in comp.arch.fpga??? hehe, I'm supposed to know about this stuff too, so I hang out here where I migth learn something :) --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: 17121
Steven Derrien <sderrien@irisa.fr> wrote in message news:377B5F7F.3D0FD6D5@irisa.fr... > Hi, > > Just a naive question about the operating conditions limits on huge FPGA > like the Xilinx Virtex. > Some annoucement says that this device can operate at frequencies in the > 100Mhz range. > > So let's say that that I want to implement a design within a XCV1000 > wich can work at 100Mhz and has 80% of its Flip flop changing state at > each clock cycle (heavily pipelined design)... > > In term of heat dissipation, such a design seems fairly unrealistic to > me ... Am i right ? > If so does anybody knows what kind of trade-off should I expect between > operating frequency and DFF/CLB's activity ? > You are probably on the limits with such a high toggle factor, but 80% seems *very* high, even for pipelined design. Probably looking at something like ~10W (++). With ~10C/W package termal resistance, the die will reach ~100C above ambient, so you probably need some cooling. But not totally unrealistic..... You can get a power estimate spreadsheet for the Virtex at http://www.xilinx.com/support/techsup/powerest/index.htm - OlafArticle: 17122
I need documentation about 82XX INTEL as soon as possible
Article: 17123I don't think it is possible with altera maxplusII. After finishing the VHDL files, I'm using Orcad Capture for creating the top level block diagram and VHDL file. Regards, Jaya Rajesh. "Asher C. Martin" wrote: > Greetings, > > I am doing some undergraduate research this summer at Beckman Institute > and I am working on some VHDL code to control an analog to digital > converter for various sensors on a robot. > > I am fairly new to ALTERA's MAX+PLUS II software and have a question > regarding how to convert GDF files to straight VHDL. I would like to > know if it is possible to tern a GDF file into a VHDL file. > > Any suggestions...? > > Best regards, > > >Asher< > (Undergraduate students @ UIUC) > > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>> > Asher C. Martin > 805 West Oregon Street > Urbana, IL 61801-3825 > (217) 367-3877 > E-MAIL: martin2@acm.uiuc.edu > http://fermi.isdn.uiuc.edu > telnet://fermi.isdn.uiuc.edu > ftp://feynman.isdn.uiuc.edu > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>Article: 17124
WildBeach wrote: > > > So, a PLD family designed by people who don't "understand programmable logic", > bought by people who were silly enough to purchase something designed by > (claimed) incompentents, and supported by people that don't know how to spell. > > Sorry, couldn't resist :-), you left yourself too open. So some person who is ashamed to use his own name tries to be funny. I was serious. There never was anything technically wrong with CoolRunner. I remember meeting the Philips FAE and asking him: "If you are as good as your data sheet claims, why haven't you "killed" all the other CPLD vendors?" And his answer had something to do with pricing. Philips is just the latest in a long string of main-stream IC companies who cannot ( or do not want to ) put in the energy and the smarts that the PLD market requires. Here are the other big companies that have thrown in the towel: Intel, TI, Motorola, AMD, National Semi, and now Philips. Except for Lucent, all PLD suppliers are now "pure players", with nothing else to distract their attention and no other product lines to subsidize or be subsidized by. I know how to spell, even if the finger sometimes slips on the keyboard :-) Peter Alfke
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