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

Custom Search

Where did you read that REVSEL are non-volatile?? To my knowledge the XCFxxP can not be used to implement safe multiboot triggered by the FPGA without using external non-volatile logic kludge - Xilinx has some appnotes using coolrunner to control the REVSEL and reboot Antti

dal ha scritto: > Franco Tiratore wrote: > > I'm currently trying to understand whether or not it is possible to > > implement a 802.11a-compliant OFDM modulator/demodulator on an FPGA. > > Yes it is possible, you need to choose an FPGA large enough. Wonderful! > The FFT is relatively easy, using fixed-point arithmetic. No reason to > use floating point. Can you explain this to me? This is a critical point! I had a look at a master thesis of a guy here at the university... He wrote that a floating point representation is required (but he didn't write why). It would be much easier to operate with fixed-point numbers, but I should understand why... > Other parts of the system are more challenging. Do you mean the Viterbi decoder? > > FFT block should perform this calculation in no more than 2.5 us. > > Easily achievable without requiring a high clock rate. I think you mean with fixed-point numbers... > The first thing you need to do is come up with an outline design for the > complete implementation, not just the FFT. Then estimate the size of > each block, and the total size of the design. Do this before you select > the FPGA, and work out what clock rate is required and how much memory > you need. > > You can break each part of the design into small blocks and learn as you > go. Start with the FFT if you want, but it will not be the most > difficult part. There are many papers on different FFT architectures, > google for 'r2sdf fft' for examples. Thank you for your suggestions! The problem is that my boss told me: "Ok, we want to have an FPGA implementation of an 802.11a modem. Before starting with VHDL, we need to understand which are the critical blocks and find an appropriate FPGA for our project. You have 1 week for this task." We will have a meeting during the next days, I will explain him the approach you suggested me. Ciao, Franco.

Marko S schrieb: > How do i calculate sqrt(a^2 + b^2) in synthesizable VHDL? > The signals a and b are 32 bit signed fix point numbers (std_logic_vector > (31 downto 0)). how accurate? how fast? latency? a table with 64 Bits input, 32 Bits output will not fit into an FPGA (but if you need the result with low latency, you might store some precomputed data in an external ram) or you could do something like max(a, b) + 0.5*min(a,b) ... and add a newton raphson stage? just for the sqrt(x) I once worked an idea to take len=ceil(log_2(x)) by counting the length of x (leading 0s) ... then you shift x>>(len/2) or something (+1?) ... this worked as a good approximation and I added only one or two stages of a newton-raphson The second approach was better in the first stage but uses more cycles/ressources ... I'm not sure if the ressources balance on an FPGA I did it for a TI-DSP - look at the thread "sqrt on C6414 DSP" on comp.dsp bye, Michael

Marko a cordic algorithim in vectroing mode will calcualtes sqrt(a^2 - b^2) which i am sure you can manipulate to get sqrt(a^2+b^2) by using signed numbers and making b the negative (-6 as opposed to 6) have a look at Ray Andrakas, survey of CORDIC algorithms for FPGA based computers for infor on cordics, opencore.org also have a the vhdl for a synthesisable cordic. I ve just finished writing a excel function that performs the function of a cordic if you want the vb for that then let me know and you can have it test out your application before coding it. good luck Adam

"Franco Tiratore" <trapule@googlemail.com> ha scritto nel messaggio news:1147266066.463679.95960@j73g2000cwa.googlegroups.com... > I'm currently trying to understand whether or not it is possible to > implement a 802.11a-compliant OFDM modulator/demodulator on an FPGA. > As far as I understand, the critical part of the project is the > 64-point complex FFT with 32 bit floating-point representation (each > real or complex number is represented in 32-bit floating-point). We have developed an 802.11b baseband and MAC in an FPGA, and we are trying to implement an 802.11g/a baseband processor as well. The FFT module is one of the most simplest part of the design and can be accomodated even in a small size FPGA. But you have to implement it using fixed point! Floating point will be an overkill... Other parts are far more challenging to implement then the simple FFT module, and much more resources-consuming! > I hope we can start a profitable discussion. :-) If you want, you can drop me an email (for replying remov the "h" from the address :-) ) Regards, Antonio

Marko S schrieb: > How do i calculate sqrt(a^2 + b^2) in synthesizable VHDL? If you really need the results in random order, use cordic. But often you can rearrange your computations to get away without the root. That is your application? Do you want to draw circles? Kolja Sulimma

On 10 May 2006 10:08:54 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >There is ABSOLUTELY NO truth to this rumor. XPLA3 aka CoolRunner is >alive and kicking and finds increasing acceptance in the market. >Disappearance from our website and poor availability data from Avnet or >DigiKey have nothing to do with the health of the product line and its >long-time future. Indirectly it does. If people have trouble getting a part, they will be less inclined to design it in, so demand drops....

corerction the sqrt(a^2 - b^2) is for gven during the hyperbolic extension, a normal cordic algorithim will provide sqrt(a^2 + b^2) sorry about that Ad

"Michael Schöberl" <MSchoeberl@mailtonne.de> wrote in message news:4462f354$1@news.fhg.de... > Marko S schrieb: >> How do i calculate sqrt(a^2 + b^2) in synthesizable VHDL? >> The signals a and b are 32 bit signed fix point numbers (std_logic_vector >> (31 downto 0)). > > how accurate? how fast? latency? > > just for the sqrt(x) I once worked an idea to take len=ceil(log_2(x)) by > counting the length of x (leading 0s) ... > then you shift x>>(len/2) or something (+1?) ... this worked as a good > approximation and I added only one or two stages of a newton-raphson > Hi Marko, For square root, you could use modified Dijkstra's square root. http://lib.tkk.fi/Diss/2005/isbn9512275279/article3.pdf One clock per output bit. No multipliers. HTH, Syms.

> >> The FFT is relatively easy, using fixed-point arithmetic. No reason to >> use floating point. > > > Can you explain this to me? This is a critical point! > I had a look at a master thesis of a guy here at the university... > He wrote that a floating point representation is required (but he > didn't write why). > It would be much easier to operate with fixed-point numbers, but I > should understand why... > A floating point FFT is likely to produce more accurate results than a fixed point FFT. That said you can make a fixed point FFT as accurate as you wish. For 802.11a, which I believe uses a maximum of 64QAM, I find it hard to believe that floating point is necessary. Basically a less accurate fft will add a little extra noise to your system. If it's small enough its not worth worrying about. > >> Other parts of the system are more challenging. > > > Do you mean the Viterbi decoder? > Viterbi is not such a hard thing to implement but it can be tricky to get it performing properly. There's also the QAM/BPSK/QPSK modulator/demodulator and data formatting for the MAC. The real magic in these modems, however, is the front end processing required to equalize the channel. Issues such as AGC, alignment and equalization are a real swine to get right and have a huge bearing on the quality of results (at least thats my take from implementing a couple of wireline modem standards).

Hi Jens, Sorry for the late replay and tanks for your input. I was able to solve my problem by simulating my core directly in ISE, but my the problem remains. I'm using XPS 7.1, so if I understand correctly, I have to change to 8.1, to preform BFM simulation, since the wizard in XPS 7.1 doesn't allows me to do so, since I don't have the BFM toolkit installed. Regards jm

This problem have been solved I should force the signal in the module level. just like this "force uut.cnt", uut this the instance of design moduel. thank Srinivasan Venkataramanan

Falk Brunner <Falk.Brunner@gmx.de> writes: > Eli Hughes schrieb: > > > I guess my frustration goes beyond the Cool Runnerm. Take the > > Spartan 3e. Its been advertised on the website as the greast thing > > since sliced bread for *over* a year now. I am sure its a nice > > chip. I have been wanting to use it. Click on the online store > > and select say the > > What can a Spartan 3E do what a Spartan 3 can't? Configure itself from parallel flash... > Not much I guess. So > instead of wasting times with marketing battle, go for another > (available) IC. Don't forget. We are engineers. We make valuable > things out of AVAILABLE things. (At least, thats the myth ;-) > As Jerry Avins on comp.dsp says: "Engineering is the art of making stuff you want from stuff you can get" Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conekt

> We have developed an 802.11b baseband and MAC in an FPGA, and > we are trying to implement an 802.11g/a baseband processor as well. > The FFT module is one of the most simplest part of the design and can > be accomodated even in a small size FPGA. But you have to implement > it using fixed point! Floating point will be an overkill... Ok, you are the second person telling me to use a fixed-point representation, then it must be the way it has to be done... :o) Let's consider the problem from scratch. Let's suppose that I want to implement a 64-QAM symbol mapper. This means that every 6 input bits the mapper has to output the correspondent symbol, that consist af a real and an imaginary part. The problem is to choose the representation of each of these numbers. We know that each number can be one of the following: -7, -5, -3, -1, 1, 3, 5, 7. The 802.11a standard says that we must consider a correction factor of 1/sqrt(42) that is approximately 0.154. Then we have to multiply all the above mentioned numbers for this factor. Then, we are not dealing with integer numbers! After this, to make it simple, we have to apply the 64-point fft to 64 complex numbers (made up of two real numbers of the type described above). The problem is now to understand how to represent these numbers. I had a look at a master thesis (not so good thesis, I must say). It considers all these numbers represented in 32 floating-point format. That means, for example in the 64-QAM mapper, we have a ROM that outputs the correspondent 32 floating point symbols (32+32 for real and imaginary part) according to the 6 input bits. With a floating-point representation the ROM outputs exactly the calculated values. If I want to use a fixed-point representation, how should I convert the non-integer numbers to fixed-point numbers? And furthermore, what about the output of the IFFT block, how should I interpret the fixed-point output numbers? It's clear that I have few ideas but well-confused... :o) But that's why I started this post.... :o))) > Other parts are far more challenging to implement then the simple FFT > module, and much more resources-consuming! Can you go more in detail? I think the Viterbi decoder is another critical part. > If you want, you can drop me an email (for replying remov the "h" > from the address :-) ) > > Regards, > Antonio I WANT, I WANT! :o))))))) But probably other people are interested and can contribute on the newsgroup... Ciao, Franco

Dear all, I hope this isn't OT but I was wondering if anyone has any experience using the TPS75003 to power a Spartan 3? For my particular application I'm having to swap round the output voltages produced by one of the buck convertors and the LDO with respect to most of the app notes. The potential dividers which give the reference feedback in the app notes come out to give a voltage which is consistently about 40mV above spec for all three outputs. I was wondering if anyone knew why? Or is it just a bit of design headroom? TIA -- Peter

Hi Andy! Andy Ray ha scritto: > A floating point FFT is likely to produce more accurate results than a > fixed point FFT. That said you can make a fixed point FFT as accurate > as you wish. Perfect. Then it's only a matter of studying the FFT theory. The important thing is to understand that this block is not so critical as it appeared. And of course, if you can suggest some documentation it would be really useful. > For 802.11a, which I believe uses a maximum of 64QAM, I find it hard to > believe that floating point is necessary. Basically a less accurate fft > will add a little extra noise to your system. If it's small enough its > not worth worrying about. This is a really interesting point. Can you suggest some text/documentation in order to understand a systematic way to evaluate the noise due to the fixed-point representation? Of course this noise must be somehow affected by the number of bits we dedicate to the foxed-point representation. I think an in-depth theory must be available in some book... And another critical point... Even the DAC (after the ofdm modulator, before the RF part of the transmitter) introduces noise, due to the number of bits of its resolution. How can we quantify its effects? Also here, this problem must have been already studied. > There's also the QAM/BPSK/QPSK modulator/demodulator and data formatting > for the MAC. > > The real magic in these modems, however, is the front end processing > required to equalize the channel. Issues such as AGC, alignment and > equalization are a real swine to get right and have a huge bearing on > the quality of results (at least thats my take from implementing a > couple of wireline modem standards). I think we will consider these problems at a later stage. As you have probably understood, we are really at the beginning of this work and for the moment we are mostly acquiring information. The complete project (a 802.11a transceiver) will take several months (several years?). Unfortunately the people involved in my group lack of the necessary expertise (but we are of course working to build it up). Ciao, Franco

Thank you all. I will have a look at "Dijkstra's square root". I have 2000 clock cycles at 40 Mhz to complete the calculation (It should be enough). It is used for calculating the AM envelop after demodulating the signal with a coherent detector You can se the principle of the detector at http://www.cycom.co.uk/art1.html. "Symon" <symon_brewer@hotmail.com> wrote in message news:4462fbb4$0$15793$14726298@news.sunsite.dk... > "Michael Schöberl" <MSchoeberl@mailtonne.de> wrote in message > news:4462f354$1@news.fhg.de... >> Marko S schrieb: >>> How do i calculate sqrt(a^2 + b^2) in synthesizable VHDL? >>> The signals a and b are 32 bit signed fix point numbers >>> (std_logic_vector (31 downto 0)). >> >> how accurate? how fast? latency? >> >> just for the sqrt(x) I once worked an idea to take len=ceil(log_2(x)) by >> counting the length of x (leading 0s) ... >> then you shift x>>(len/2) or something (+1?) ... this worked as a good >> approximation and I added only one or two stages of a newton-raphson >> > Hi Marko, > For square root, you could use modified Dijkstra's square root. > > http://lib.tkk.fi/Diss/2005/isbn9512275279/article3.pdf > > One clock per output bit. No multipliers. > > HTH, Syms. >

I get this error when synthesising: ERROR:HDLParsers:3338 - "H:\Projektmapp\DENEX_LCS90_R2_V2\VHDL\TEST\fisa_vhdl.prj" Line 1. Bad file name in project file: And i found a solution at XILINX: Problem Description: Keywords: XST, HDL, Parser During synthesis, the following error occurs: "ERROR:HDLParsers:3338 - "<...>" Line 1. Bad file name in project file: Env Variable <...> not defined." Solution 1: The reason is that the project path contains a "$" character, which is read as an environment variable. To work around this error, remove the "$" character from the path name. This issue will be fixed in ISE 8.2i. But where do i find this path??

Hi, I had a strange experience with the Synplify Pro 8.4. I used the re-timing option thinking that it will help to improve the timing performance of the design as they have claimed in their docs. But my design's timing performance has gone down by about 5 Mz and I ended up not meeting my timing constraints. Why is it so? Can anyone tell me about this? Thanks & Regards, Srini.

take a look in the file H:\Projektmapp\DENEX_LCS90_R2_V2\VHDL\TEST\fisa_vhdl.prj on line number 1 that line very likely has a $ sign in the path/filename Aurash Marko S wrote: > I get this error when synthesising: > > ERROR:HDLParsers:3338 - > "H:\Projektmapp\DENEX_LCS90_R2_V2\VHDL\TEST\fisa_vhdl.prj" Line 1. Bad file > name in project file: > > And i found a solution at XILINX: > > Problem Description: > > Keywords: XST, HDL, Parser > > During synthesis, the following error occurs: > > "ERROR:HDLParsers:3338 - "<...>" Line 1. Bad file name in project file: Env > Variable <...> not defined." > > > > Solution 1: > The reason is that the project path contains a "$" character, which is read > as an environment variable. > > To work around this error, remove the "$" character from the path name. > > This issue will be fixed in ISE 8.2i. > > > > But where do i find this path?? > >

Thanks :-) I found it myself also. "Aurelian Lazarut" <aurash@xilinx.com> wrote in message news:e3v6me$1b12@cliff.xsj.xilinx.com... > take a look in the file > H:\Projektmapp\DENEX_LCS90_R2_V2\VHDL\TEST\fisa_vhdl.prj > on line number 1 > that line very likely has a $ sign in the path/filename > Aurash > > Marko S wrote: >> I get this error when synthesising: >> >> ERROR:HDLParsers:3338 - >> "H:\Projektmapp\DENEX_LCS90_R2_V2\VHDL\TEST\fisa_vhdl.prj" Line 1. Bad >> file >> name in project file: >> >> And i found a solution at XILINX: >> >> Problem Description: >> >> Keywords: XST, HDL, Parser >> >> During synthesis, the following error occurs: >> >> "ERROR:HDLParsers:3338 - "<...>" Line 1. Bad file name in project file: >> Env >> Variable <...> not defined." >> >> >> >> Solution 1: >> The reason is that the project path contains a "$" character, which is >> read >> as an environment variable. >> >> To work around this error, remove the "$" character from the path name. >> >> This issue will be fixed in ISE 8.2i. >> >> >> >> But where do i find this path?? >>

Mark McDougall wrote: > Alan Nishioka wrote: > > > I haven't used any of the revsel features, so I can't answer that > > part, but I have used the config command to re-config an fpga (where > > I forgot to connect the prog line) and it works just fine. > > CONFIG was sent from/via the FPGA itself? Yes. I always connect the jtag lines back to io lines for true field programability. Usually, I rely on power cycling to reload the configuration. But this app required reconfig without user intervention. So I wrote a little state machine to send the jtag config command to the prom. I also considered sending the jtag sequence to the fpga to toggle the prog pin, but I figured config was easier. But in my next design, I am going to connect the prog pin to an io line. Alan Nishioka

I got good results with 8.4, but 8.5 produced a terrible result. But 8.5.1 produces the best of the other two versions. Give it a try if you can. -- Amal

Ron, I was cleaning out one of the labs yesterday and I came by a box topped with much dust. I brushed it off and came across some Xilinx devices. XC4005-5PG156C XCS40-3PQ208C I immediately thought of you, as this thread has been indelibly etched into my mind, due to all the colorful and enlightening dialogue. I have no use for these items, and if Xilinx doesn't see anything wrong with me giving a couple to you, I could then mail them. Rob Ron wrote: > Glory and riches are showered upon those who successfully factor one of > the RSA Challenge Numbers (see note [1]) ;-). I would like to be the > first to factor an RSA number using a standalone FPGA development > board(s) (ie; not connected to a conventional computer). > > The RSA Challenge numbers have traditionally been solved by networks of > supercomputers using a distributed Number Field Sieve (NFS) or similar > method. Sieving is unfortunately not suited to FPGA implementation, but > there is another integer factorization method called the Elliptic Curve > Method (ECM, see note [3]) that I think might stand a chance of cracking > RSA-704. I have therefore designed and tested a Verilog implementation > of ECM with a compile time bus-width specification (ie; `define L 704) > so that it's easy to determine how the LUT requirement increases as I > change the bus width. I've optimized the circuit for gate count to the > extent of multiplexing everything that is used more than once (multiply, > divide, modulo, etc) - a process that almost brought tears to my eyes at > one point, because I had to eliminate several areas that naturally lent > themselves to parallelization. > > Even so, the design requires far more LUTs than are currently available > from anyone as far as I know. I presently have Xilinx xc3s500e and Actel > ProASIC3E A3PE600 development boards, but I can't compile the design for > a 704 bit bus-width because I get the error message in Note [4] below (I > also get a similar message from the Actel synthesizer). I *can* compile > the design for a 384 bus-width however. Using a Xilinx 3s4000 as the > target device (even though I only have a 3s500) with a 384 bit > bus-width, I get the following Device utilization summary: > --------------------------- > Selected Device : 3s4000fg676-4 > Number of Slices: 49176 out of 27648 177% (*) > Number of Slice Flip Flops: 52253 out of 55296 94% > Number of 4 input LUTs: 83797 out of 55296 151% (*) > Number of bonded IOBs: 18 out of 489 3% > Number of GCLKs: 1 out of 8 12% > WARNING:Xst:1336 - (*) More than 100% of Device resources are used > --------------------------- > > > This would lead me to believe that my design would require at least > 101,376 LUTs, and probably more depending on how much of the FPGA is > consumed by routing. Since the Xilinx 3s4000 has 55296 LUTs and 27648 > slices, I imagine a part with twice that number of slices & LUTs (a > Xilinx 3s8000 perhaps?) would be needed to fit my design. Anyone care to > hazard a guess as to if/when such a monster might be available? > > Also, thus far the longest number that has been factored with ECM is > only 66 decimal digits (see Note [3]). If RSA-704 (212 decimal digits) > were factored, it would set a new record for ECM factoring also. > > If such a device did become available, my only hope for acquiring the > requisite hardware/software would be to work out a deal with the FPGA > vendor or someone to lend me the necessary development board and s/w > tools in exchange for the potential fame and glory, since I am but a > humble retired engineer/hobbyist. :-) > > Ron > > > _________________ > Notes: > > [1] RSA Challenge Numbers: > http://www.rsasecurity.com/rsalabs/node.asp?id=2093 > > [2] Factoring Methods: > http://mathworld.wolfram.com/PrimeFactorizationAlgorithms.html > > [3] Elliptic Curve Factorization Method > http://mathworld.wolfram.com/EllipticCurveFactorizationMethod.html > > [4] When synthesizing ECM with a 704 bit bus-width for the Xilinx > xc3s4000-4fg676, I get: > > ERROR: Portability:3 - This Xilinx application has run out of memory or > has encountered a memory conflict. Current memory usage is 2092148 kb. > Memory problems may require a simple increase in available system > memory, or possibly a fix to the software or a special workaround. To > troubleshoot or remedy the problem, first: Try increasing your system's > RAM. Alternatively, you may try increasing your system's virtual memory > or swap space. If this does not fix the problem, please try the > following: Search the Answers Database at support.xilinx.com to locate > information on this error message. If neither of the above resources > produces an available solution, please use Web Support to open a case > with Xilinx Technical Support off of support.xilinx.com. As it is > likely that this may be an unforeseen problem, please be prepared to > submit relevant design files if necessary. > ERROR: XST failed > Process "Synthesize" did not complete.

Martin Thompson <martin.j.thompson@trw.com> wrote: >As Jerry Avins on comp.dsp says: >"Engineering is the art of making stuff you want from stuff you can >get" And what is the art of knowing what stuff you can get when you need it? The electronic component distribution system is so fsked up. Yesterday I quoted 6 weeks delivery for a one off batch of a small electronic module. It needs a particular component which is part of the module specification so even if I can find a suitable alternative I have to jump through hoops getting customer approval of a revised specification. None of the manufacturer main distributors have stock they quote me 12-15 weeks with a 5000 part MOQ. Yesterday a catalogue supplier had the 600 parts I need in stock. No guarantee they will have them in stock today or in 1 month or 2 months if and when I get an order and actually need them. I will probably buy those 600 parts today and take the risk of being out of pocket if an order doesn't come through. This is the problem distributors are supposed to solve but since the bastards stopped holding stock they are just useless middle men taking a cut. Thankfully some semi suppliers are realising that they are in the best position to hold stock and can supply it efficiently with their 'on-line' shops. The Microchip online shops seems to have a wide range of parts available in useful quantities at acceptable prices for example. Sadly the Xilinx offering has a pitiful range and no commitment to holding stock. Actually I just looked and it seems Xilinx "buy online" no longer offers silicon instead directing you to Avnet. when I eventually got the Avnet site to do something browsing around showed the typical distributor crap lead times (frequently no-stock and call) and MOQs. I couldn't even see prices without having an account. If seems Xilinx is getting dumber not smarter. --

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

Custom Search