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
does anyone have an idea about the exact amount of onchip ram in a xilinx virtex XCV1000BG560. samArticle: 30301
On Mon, 2 Apr 2001 02:45:11 -0800, sam <> wrote: >does anyone have an idea about the exact amount of onchip ram in a xilinx virtex XCV1000BG560. My databook says 131,072 bits of BlockRAM and 393,218 bits of SelectRam (Max). ---- KeithArticle: 30302
Can anyone help me out - I am looking for a pinout in text format for the Virtex-E XCV200E-FG456 device. (or better still a symbol!!) I plan to import the text file into ORCAD using the 'Generate Part' command to create the symbol from the pin table file. I have asked 2 of Xilinx FAEs by email for this file last week and so far no reply! ThanksArticle: 30303
There are no random sources inherent in the FPGA, although you could conceivably use the phase difference between the internal oscillator in the 4Kparts and an external clock. I'd prefer to use the linear feedback shift register (LFSR) with a long enough sequence to make it random over a long interval. That can be done very compactly in the 4K using CLB ram (see the xilinx app note on LFSRs, I think it is XAPP152). Use only one bit at a time from the LFSR though, the other bits are time shifted copies of the first bit. A 129 bit LFSR only takes 13 LUTs to implement and at 40 MHz will take thousands of years before it repeats. Of course at start-up it will start out with the same value, so the sequence is always the same. That is good for debug, but may be bad for your system. In that case, you need to seed the 129 bits with a random value on startup (if you seed it serially, the LFSR is still the same size). The random seed has to be generated by something external to the FPGA since the FPGA is always the same on startup. One possibility, which I mentioned above is to use the random relationship of the internal oscillator and an external clock to seed the LFSR. I'd use the internal oscillator phase relationship to seed an LFSR rather than directly for two reasons: 1) The instantaneous phase relationship will be random, but a time series will be periodic, and 2) non-repeatability of the phase makes debug difficult. (The LFSR can be forced to a particular start state for debug). Jörg Ritter wrote: > > Hello, > > has someone expierience with generating (pseudo) random numbers in > FPGA's (XC4000XLA series) ? > > My first idea was to use maximal length sequences (shift registers > having maximum possible period for an r-stage shift register) > > Is there another source of randomness of the FPGA istself which can be > used ? > > thanks > Joerg -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30304
use ieee.numeric_std.all instead
c<=std_logic_vector( resize( unsigned(A) + unsigned(B) , c'length));
numeric_std is more cohesive, and although you need to be specifc for signed and
unsigned types, ther are no conflicts if you need both. the std_logic libraries
overload the same operators for signed and unsigned so mixing them can get
unexpected results.
Matt Billenstein wrote:
>
> All,
>
> I'm using synopsys with the Xilinx Foundation tools (3.3i I believe) and I'm
> seeing some strange behavior with a particular construct...
>
> I include IEEE.std_logic_unsigned.all so that I can add std_logic_vectors.
> When I do something like:
>
> SIGNAL
> A, B : std_logic_vector(7 downto 0);
>
> SIGNAL C : std_logic_vector(8 downto 0);
>
> and then later in the architecture in a registered process:
>
> C <= ('0' & A) + ('0' & B);
>
> I include the '0' here on vectors A and B so that the types on the LHS and
> RHS are the same (9 bit vectors), but the synthesis tool appears to trim off
> the top bit of the C vector... Thus, if I add a couple numbers like
> 10000001 and 10000001 I should get 100000010 (which is 9 bits), but I only
> get 00000010 (which is 8 bits)... I lose the MSb. It turns out that on the
> very next clock cycle I subtract a constant bias (decimal 127) from C so I
> never actually use the 8th bit of the C vector for any output. I could code
> it differently to take the bias out of either vector A or B before I add
> them, but it appears the synthesis tool isn't actually giving me what I
> asked for... Any ideas?
>
> thx
>
> Matt
>
> --
>
> Matt Billenstein
> mbillens (at) one (dot) net
> http://w3.one.net/~mbillens/
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
Article: 30305Hello everyone I need some information on the basic introduction of FPGA.Please give me some advise .Article: 30306
Hello Ray, > There are no random sources inherent in the FPGA, although you could co= nceivably > use the phase difference between the internal oscillator in the 4Kparts= and an > external clock. this is what I was looking for. Thanks for your detailed answer, especially for the 4k implementation met= hod's. ciao J=F6rgArticle: 30307
Hello Joerg... I've been looking into the same thing. Here's a clear paper with good coverage and references. http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Papers/D5_Chu_P.pdf As to other forms of built in randomness... I think that metastability and propagation delay are two factors avaliable which have some randomness to them. If a oscillator were made (3 inverters), then build a random number by sampling this output at a widely space interval, there should be a degree of randomness. The key problem would be guaranteed startup of the oscillator (help!), else the number wouldn't be very random. Eric Pearson Carde Systems Waterloo, Ontario YAFC Jörg Ritter <ritter@informatik.uni-halle.de> wrote in message news:3AC850A3.6E2A36B@informatik.uni-halle.de... > Hello, > > has someone expierience with generating (pseudo) random numbers in > FPGA's (XC4000XLA series) ? > > My first idea was to use maximal length sequences (shift registers > having maximum possible period for an r-stage shift register) > > Is there another source of randomness of the FPGA istself which can be > used ? > > thanks > Joerg >Article: 30308
Ray Andraka wrote: [...] > Use only one bit at a time from the LFSR though, the other bits > are time shifted copies of the first bit. What about shuffling the bits? Or using only some bits from a large LFSR? Just a thought but I find it interesting... -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/Article: 30309
Hi all We are actually working an a openhardware/opensource computer. If you have a good knwoledge in FPGA or VHDL, you can join us ! If you want to learn how to build your own eZ80 computer, too ! Our web site is http://cpcng.free.frArticle: 30310
On Mon, 2 Apr 2001 13:31:04 +0100, "Laurence McCotter" <mccotter@tality.com> wrote: >Can anyone help me out - I am looking for a pinout in text format for the >Virtex-E XCV200E-FG456 device. (or better still a symbol!!) >I plan to import the text file into ORCAD using the 'Generate Part' command >to create the symbol from the pin table file. I have asked 2 of Xilinx FAEs >by email for this file last week and so far no reply! >Thanks > If you can't find a better way, there is such a thing in the BSDL files in xilinx\virtexe\data\*.bsd - BrianArticle: 30311
try emailing mailto:info@anadigm.com They're bound to have a support desk. "Fredrik Theander" <fredrik.theander@mbox301.swipnet.se> wrote in message news:Oq5x6.1768$e04.5422@nntpserver.swip.net... > Hi > > My name is Fredrik Theander I'm working on my exam thesis. My topic is > programmable analog devices I currently evaluating Anadgims FPAA. I wonder > if anyone have had any experience with it? > I would be glad to find someone who i can swap ideas with. > > regards > Fredrik Theander > >Article: 30312
Ray Andraka wrote:
> c<=std_logic_vector( resize( unsigned(A) + unsigned(B) , c'length));
This does not yield the correct MSB (a potential carry-out is dropped
before the resizing). Try
C <= std_logic_vector (resize (unsigned (A), C'length) +
resize (unsigned (B), C'length));
instead.
Reto
Article: 30313yorams@hywire.com wrote: > Hi. > I have read xilinx application note xapp258 and I have the following > question: > > <snip> > the following might occur > > path between bit i of counter to its synchronizer is: epsilon; > path between bit j of counter to its synchronizer is: epsilon + Tcyc; > > under these condition the synchronizer can sample false value of the gray > counter and thus give false full or empty flag. > > > Is it possible ? > Can it be avoided ? > The idea behind using Grey counters is that they make the problem you mention disappear. If you transfer the Grey value from one clock domain to the other, and you do it at the most awkward moment, right as the Grey counter increments, you will not transfer garbage ( which might happen with a binary counter ), since adjacent Grey values only differ by one bit. So you transfer either the old or the new value. Either one is as good as the other at that particular moment. Peter Alfke, Xilinx ApplicationsArticle: 30314
Rick Filipkiewicz wrote: > > Simon Bacon wrote: > > > > > OTOH, you may be claiming that the band of brothers who work on > > FPGA designs are a tempermental bunch... > > No Simon you must not give the guy the wrong impression. We are of course > calm, rational, gentle citizens of the digital world who help people > across the road and are very kind to all fellow creatures of this lovely > planet. We only become temperamental, irrational, demented scary monster > types when faced with: > > o The imminent arrival of the design which we have been working on for > months, > > o The cancellation of the project ditto, > > o The sudden non-availability of parts we have designed into ditto, > > o The appearence on this NG of opinions contrary to our most deeply held > beliefs, > > ... > > o Yet another MAP/PAR bug. Or synthesis bug. -andyArticle: 30315
Nicolas Matringe wrote: > > Ray Andraka wrote: > [...] > > Use only one bit at a time from the LFSR though, the other bits > > are time shifted copies of the first bit. > > What about shuffling the bits? Or using only some bits from a large > LFSR? > Just a thought but I find it interesting... The problem with using more than one bit from an LFSR is that all the other bits are related by time (they are just time shifted copies), therefore, even if you space the selected bits out and/or shuffle them, you still get spectral coloring in your random number. The one way around that is to space the bits far enough apart that the correlation is not a factor within your sample interval. That, however requires a large number of bit delays, at which point it is usually more economical to use multiple LFSRs that are identical except the seeds (and the seeds are spaced far apart). Another solution involves clocking the LFSR n times to generate an n bit random value using successive outputs. For some applications, such as memory testing, the spectral coloring may not be a factor, so less care is needed. If you are trying to model noise however, then you'll want to be careful about correlations between bits. > -- > Nicolas MATRINGE IPricot European Headquarters > Conception electronique 10-12 Avenue de Verdun > Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE > Fax +33 1 46 52 53 01 http://www.IPricot.com/ -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30316
Eric Pearson wrote: > > Hello Joerg... > > I've been looking into the same thing. Here's a clear paper with > good coverage and references. > > http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Papers/D5_Chu_P.pdf > > As to other forms of built in randomness... > > I think that metastability and propagation delay are two factors avaliable > which > have some randomness to them. You might have a very difficult time hitting the metastability in an FPGA. The window is very small, and the only time you can seem to hit it consistently is when you don't want to :-( For sampling an oscillator, I mentioned before that if both your system clock and your oscillator are reasonably stable, then the results of sampling will be periodic. (the sum of a finite set of periodic signals is also periodic). You lose the random distribution. Also worth noting, is it seems an ring oscillator implemented in the FPGA might tend to lock to a system clock because of the changes in local supply voltage due to currents drawn on the clock edges elsewhere in the FPGA. These two reasons are why I suggested using the phase difference between an oscillator and the system clock just once on start-up to initialize an LFSR rather than attempting to use it all the time. If a oscillator were made (3 inverters), then > build a random number by sampling this output at a widely space interval, > there should > be a degree of randomness. > > The key problem would be guaranteed startup of the oscillator (help!), else > the number > wouldn't be very random. > > Eric Pearson > Carde Systems > Waterloo, Ontario > YAFC > > Jörg Ritter <ritter@informatik.uni-halle.de> wrote in message > news:3AC850A3.6E2A36B@informatik.uni-halle.de... > > Hello, > > > > has someone expierience with generating (pseudo) random numbers in > > FPGA's (XC4000XLA series) ? > > > > My first idea was to use maximal length sequences (shift registers > > having maximum possible period for an r-stage shift register) > > > > Is there another source of randomness of the FPGA istself which can be > > used ? > > > > thanks > > Joerg > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30317
This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C0BBC0.540802E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Austin,=20 SNIP=20 I also decided to use an FPGA for a fiber optic framer/codec. When we = had shipped the 10,000th unit, the customer came back and said "it won't = send all 0's." [ I kid you not.] All 0's is what the customer (secret = governement user) wanted to send. All day, all night. They needed to = know that the n-th 0 was really the n-th 0, and not the n-th plus 1 "0". = It seems that the codec saw all 0's, and substituted a keep alive code = instead. For some unknown reason, every 0 in its proper place and order = was critically important to the national security! They told me it was = encrypted. Wow, some encryption algorithm!=20 SNIP=20 =20 I believe that there are a couple of very good compression techniques = which can reduce a file from an infinite length down to a single bit.=20 These are so secret that if anybody found out then you would have a = national emergency.=20 Maybe your FPGA was used in this form of encryption.=20 I have heard it also rumored that the British hoofed animals got wind = of this and the government is secretly trying to cover it up.=20 Seriously though, Thanks all for your help =20 Dave ------=_NextPart_000_0044_01C0BBC0.540802E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.3017.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <P><FONT face=3DArial size=3D2>Austin,</FONT>=20 <P><FONT face=3DArial size=3D2>SNIP</FONT>=20 <P>I also decided to use an FPGA for a fiber optic framer/codec. = When we=20 had shipped the 10,000th unit, the customer came back and said "it = won't send=20 all 0's." <B>[ I kid you not.]</B> All 0's is what the customer = (secret=20 governement user) wanted to send. All day, all night. They = needed=20 to know that the n-th 0 was really the n-th 0, and not the n-th plus 1 = "0". It seems that the codec saw all 0's, and substituted a keep = alive=20 code instead. For some unknown reason, every 0 in its proper = place and=20 order was critically important to the national security! They = told me it=20 was encrypted. Wow, some encryption algorithm!=20 <P>SNIP=20 <P>=20 <P>I believe that there are a couple of very good compression = techniques=20 which can reduce a file from an infinite length down to a single = bit.=20 <P>These are so secret that if anybody found out then you would have a = national emergency.=20 <P>Maybe your FPGA was used in this form of encryption.=20 <P><FONT face=3DArial size=3D2>I have heard it also rumored that the=20 British hoofed animals got wind of this and the government = is=20 secretly trying to cover it up.</FONT>=20 <P><FONT face=3DArial size=3D2>Seriously though, Thanks all = for your=20 help</FONT> =20 <P><FONT face=3DArial = size=3D2>Dave</FONT></P></BLOCKQUOTE></DIV></BODY></HTML> ------=_NextPart_000_0044_01C0BBC0.540802E0--Article: 30318
Workshop on Cryptographic Hardware and Embedded Systems
Espace Saint Martin, Paris, France, May 13-16, 2001
http://www.chesworkshop.org
for registration information, check CHES web site above
-------------------------------------------------------
INVITED SPEAKERS
Ross Anderson, University of Cambridge, U.K.
Protecting Embedded Systems - the Next Ten Years.
Adi Shamir, Weizmann Institute, Israel.
TBA
-------------------------------------------------------
LIST OF ACCEPTED PAPERS FOR CHES 2001
(contributions are ordered by date submitted)
Leone Manuel.
A new low complexity fast parallel multiplier for a
class of finite fields.
Pierre-Yvan Liardet and Nigel Smart.
Preventing SPA/DPA in ECC systems using the Jacobi form.
Mike Bond.
Attacks on cryptoprocessor transaction sets.
Louis Goubin.
A sound method for switching between boolean and
arithmetic masking.
Helena Handschuh and Christophe Tymen.
Fast primitives for internal data scrambling in tamper
resistant hardware.
Marc Joye and Christophe Tymen.
Protections against differential analysis for elliptic
curve cryptography: An algebraic approach.
Adam Young and Moti Yung.
Bandwidth-optimal kleptographic attacks.
Nigel Smart.
The Hessian form of an elliptic curve.
Mehdi-Laurent Akkar and Christophe Giraud.
An implementation of DES and AES, secure against some
attacks.
Palash Sarkar and Subhamoy Maitra.
Efficient implementation of large stream cipher systems.
Karine Gandolfi, Christophe Mourtel, and Francis Olivier.
Electromagnetic analysis: Concrete results
Ocean Cheung, K. H. Tsoi, Philip Leong, and Norris Leong.
Tradeoffs in parallel and serial implementations of the
International Data Encryption Algorithm IDEA.
Thomas Pornin.
Transparent harddisk encryption.
Erkay Savas, Tom Schmidt, and Cetin K. Koc.
Generating elliptic curves of known order.
Hanae Nozaki, Masahiko Motoyama, Atsushi Shimbo, and
Shinichi Kawamura.
Implementation of RSA Algorithm based on RNS Montgomery
Multiplication.
Colin Walter.
Sliding windows succumbs to big mac attack.
Manfred Aigner and Elisabeth Oswald.
Randomized addition-subtraction chains as a countermeasure
against power attacks.
Maire McLoone and J. V. McCanny.
High performance single-chip FPGA Rijndael algorithm
implementations.
Katsuyuki Okeya and Kouichi Sakurai.
Efficient elliptic curve cryptosystems from a scalar
multiplication algorithm with recovering y-coordinate
on the Montgomery-form.
D. May, H. L. Muller, and Nigel Smart.
Random register renaming to foil DPA.
Viktor Fischer and Milos Drutarovsky.
Two methods of Rijndael implementation in reconfigurable
Hardware.
Christophe Clavier and Marc Joye.
Universal exponentiation algorithm: A first step towards
provable SPA-resistance.
Pradeep Dubey, Vijay Kumar, Atri Rudra, Charanjit Jutla,
Josyula R. Rao, and Pankaj Rohatgi.
Efficient implementations of Galois field arithmetic.
Henry Kuo and Ingrid Verbauwhede.
Architectural optimization for a 3Gbits/sec VLSI
Implementation of the AES Rijndael algorithm.
Nick Howgrave-Graham, Joan Dyer, and Rosario Gennaro.
Pseudo-random number generation on the IBM 4758 secure
crypto coprocessor.
Johann Groszschaedl.
A bit-serial unified multiplier architecture for finite
fields GF(p) and GF(2^m).
Gerardo Orlando and Christof Paar.
A scalable GF(p) elliptic curve processor architecture
for programmable hardware.
Marc Joye and Jean-Jacques Quisquater.
Hessian elliptic curves and side-channel attacks.
Werner Schindler.
Efficient online tests for true random number generators.
Alexandre F. Tenca, Georgi Todorov, and Cetin K. Koc.
High-radix design of a scalable modular multiplier.
Daniel V. Bailey, Daniel Coffin, Adam Elbirt,
Joseph H. Silverman, and Adam D. Woodbury.
NTRU in Constrained Devices.
-------------------------------------------------------
Workshop on Cryptographic Hardware and Embedded Systems
Web: http://www.chesworkshop.org
E-Mail: ches@ece.orst.edu
Program Chairs: Cetin Kaya Koc <koc@ece.orst.edu>
David Naccache <David.Naccache@gemplus.com>
Christof Paar <christof@ece.wpi.edu>
-------------------------------------------------------
Article: 30319This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C0BBC0.D3A51420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Austin,=20 SNIP=20 I also decided to use an FPGA for a fiber optic framer/codec. When we = had shipped the 10,000th unit, the customer came back and said "it won't = send all 0's." [ I kid you not.] All 0's is what the customer (secret = governement user) wanted to send. All day, all night. They needed to = know that the n-th 0 was really the n-th 0, and not the n-th plus 1 "0". = It seems that the codec saw all 0's, and substituted a keep alive code = instead. For some unknown reason, every 0 in its proper place and order = was critically important to the national security! They told me it was = encrypted. Wow, some encryption algorithm!=20 SNIP=20 I believe that there are a couple of very good compression techniques = which can reduce a file from an infinite length down to a single bit.=20 These are so secret that if anybody found out then you would have a = national emergency.=20 Maybe your FPGA was used in this form of encryption.=20 I have heard it also rumored that the British hoofed animals got wind = of this and the government is secretly trying to cover it up.=20 Seriously though, Thanks all for your help =20 Dave ------=_NextPart_000_004E_01C0BBC0.D3A51420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.3017.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <P><FONT face=3DArial size=3D2>Austin,</FONT>=20 <P><FONT face=3DArial size=3D2>SNIP</FONT>=20 <P>I also decided to use an FPGA for a fiber optic framer/codec. = When we=20 had shipped the 10,000th unit, the customer came back and said "it = won't send=20 all 0's." <B>[ I kid you not.]</B> All 0's is what the customer = (secret=20 governement user) wanted to send. All day, all night. They = needed=20 to know that the n-th 0 was really the n-th 0, and not the n-th plus 1 = "0". It seems that the codec saw all 0's, and substituted a keep = alive=20 code instead. For some unknown reason, every 0 in its proper = place and=20 order was critically important to the national security! They = told me it=20 was encrypted. Wow, some encryption algorithm!=20 <P>SNIP=20 <P> <P>I believe that there are a couple of very good compression = techniques=20 which can reduce a file from an infinite length down to a single = bit.=20 <P>These are so secret that if anybody found out then you would have a = national emergency.=20 <P>Maybe your FPGA was used in this form of encryption.=20 <P><FONT face=3DArial size=3D2>I have heard it also rumored that the=20 British hoofed animals got wind of this and the government = is=20 secretly trying to cover it up.</FONT>=20 <P><FONT face=3DArial size=3D2>Seriously though, Thanks all = for your=20 help</FONT> =20 <P><FONT face=3DArial = size=3D2>Dave</FONT></P></BLOCKQUOTE></DIV></BODY></HTML> ------=_NextPart_000_004E_01C0BBC0.D3A51420--Article: 30320
Ray Andraka wrote: > > Eric Pearson wrote: > > > > Hello Joerg... > > > > I've been looking into the same thing. Here's a clear paper with > > good coverage and references. > > > > http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Papers/D5_Chu_P.pdf > > > > As to other forms of built in randomness... > > > > I think that metastability and propagation delay are two factors avaliable > > which > > have some randomness to them. > > You might have a very difficult time hitting the metastability in an FPGA. The > window is very small, and the only time you can seem to hit it consistently is > when you don't want to :-( > > For sampling an oscillator, I mentioned before that if both your system clock > and your oscillator are reasonably stable, then the results of sampling will be > periodic. (the sum of a finite set of periodic signals is also periodic). You > lose the random distribution. Also worth noting, is it seems an ring oscillator > implemented in the FPGA might tend to lock to a system clock because of the > changes in local supply voltage due to currents drawn on the clock edges > elsewhere in the FPGA. Certainly true. The common mode layout inductances, plus CMOS currents combine to make very good 'lock' systems for simple oscillators. This lock band will be highly Vcc/Temp/Process dependant, as the simple osc sweeps. By using a LFSR, and a dynamically tapped delay line ( series of gates ) you could deliberately wobble the osc about, and thus reduce the chances of staying on a lock-point. Jim G.Article: 30321
"Simon Bacon" <simonb@tile.demon.co.cut_this.uk> wrote in message news:985907702.2172.0.nnrp-09.9e9832fa@news.demon.co.uk... > > OTOH, you may be claiming that the band of brothers who work on > FPGA designs are a tempermental bunch... Might be, you know... Most of the FPGA designers I know feel insulted if they have to work in a machine with less than 1Gig of RAM.Article: 30322
Hell Everyone, I am currently negotiating with vj_sananda@hotmail.com of New Hampshire to trade my two books Computer Architecture and Timing Verification for his Janick Bergeron's Writing test benches. Thanks. Looking for recommendations on Computer Arithmetics books. Thanks. "Compilit" <compilehr@yahoo.com> wrote in message news:99u33j$f7l$1@taliesin.netcom.net.uk... > I have some EE books for trade. I am in the San Francisco Area. > > These all are all in brand new, unnused condition. Some have CD-ROM's > included that are not yet opened. > I bought them for a project now currently on hold. > > Please search www.abebooks.com or www.powells.com or www.Amazon.com for good > deals on these, and get back to me. Please help me to get the books I need. > > The following list are what I currently have extra to be given away: > > 1/ Designer's Guide to VHDL by Peter Ashenden > http://www.amazon.com/exec/obidos/ASIN/1558602704/qid=985827963/sr=1-3/ref=s > c_b_4/002-1116465-7214451 > 2/ VHDL Analysis and Modeling of Digital systems 2ed by Navabi > > 3/ Computer Architechiture, and Quantitative Approach. > > 4/ Verilog Digital Computer Design. Algorithms into Hardware by Arnold > > 5/ Real World FPGA Design with Verilog by Ken Coffman > > 6/ VHDL Representation and Synthesis by Armstrong and Gary > > 7/ VHDL made easy by Tellering and Taylor > > 8/ Verilog HDL by Palnitkar > > 9/ Verilog Designer's Library by Zeidman > > 10/ Timing Verification (ASIC) by Farzd Nekoogar > http://www.amazon.com/exec/obidos/ASIN/0137943482/ref=sim_books/002-1116465- > 7214451 > > 11/ VHDL by Douglas Perry > > 12/ VHDL for programmable logic by Kevin Skahill > > 13/ Real Time Signal Processing John G. Ackenhusen > http://www.amazon.com/exec/obidos/ASIN/0136317715/qid=985827868/sr=1-2/ref=s > c_b_3/002-1116465-7214451 > > 14/ Object Oriented Perl by Conway > > 15/ Programming and Customizing PIC controller Predro > > 16/ PCI-X System Architecture Mindshare INC > > 17/ Application-Specific Integrated Circuits. By Smith > > 18/ VHDL for Logic Synthesis by Andrew Rushton > http://www.amazon.com/exec/obidos/search-handle-form/002-1116465-7214451 > > ===================================================================== > > > The following are what I am in desparate need for, I don't mind them in used > conditions: > > 1/ > http://www.amazon.com/exec/obidos/ASIN/0792377664/ref=ase_janickbergershom/0 > 02-1116465-7214451 > Writing Testbenches - Functional Verification of HDL Models > by Janick Bergeron > > 2/ System-on-a-Chip Verification - Methodology and Techniques > http://www.amazon.com/exec/obidos/ASIN/0792372794/qid=985827145/sr=1-4/ref=s > c_b_5/002-1116465-7214451 > > > 3/ Rajsuman, Rochit SYSTEM ON A CHIP DESIGN AND TEST > http://dogbert.abebooks.com/abe/BookDetails?bi=75782617 > > 4/Keating, Michael and Pierre Bricaud Reuse Methodology Manual For > System-On-A-Chip Designs > http://dogbert.abebooks.com/abe/BookDetails?bi=53348445 > > 5/HDL chip design :a practical guide for designing, synthesizing, and > simulating ASICs and FPGAs using VHDL or Verilog > > http://www.powells.com/cgi-bin/biblio?inkey=2-0965193438-0 > > 6/PRINCIPLES OF VERILOG PLI > by Swapnajit Mittra > http://www.powells.com/cgi-bin/biblio?inkey=4-0792384776-0 > > 7/VHDL Coding and Logic Synthesis with Synopsys by Weng Fook Lee > http://www.amazon.com/exec/obidos/ASIN/0124406513/qid=985827963/sr=1-6/ref=s > c_b_7/002-1116465-7214451 > > 8/Vhdl Coding Styles and Methodologies by Ben Cohen must be 2nd edition > http://dogbert.abebooks.com/abe/BookDetails?bi=52919198 > > 9/Cohen, Ben VHDL ANSWERS TO FREQUENTLY ASKED QUESTION 2nd edition > http://dogbert.abebooks.com/abe/BookDetails?bi=55220448 > > 10/Component Design by Example : a Step-by-Step Process Using VHDL with UART > as Vehicle > by Ben Cohen > > Thank you, > Peace. > > Please click reply to email me. > >Article: 30323
Meloun <meloun@miracle.cz> writes: > Near simple problem :-) Thanks for posting the RS encoder. I might find that useful in the future. The original request (by someone else) was just for the encoder, but is there any chance that you have a decoder to share as well? Best regards, EricArticle: 30324
prashanth wrote:
> Hallo sir.
> How to use the distributed ram in VERTEX_E for instantiation of memory
If you have a decent synth tool try this:
reg [M:0] rdaddr, wraddr;
reg [N:0] ram [2**M:0];
always @(posedge clk)
if (we)
ram[wraddr] <= din;
assign dout = ram[rdaddr];
OTOH If you have FPGA Express then you'll have to use CoreGen.
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