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
cippalippa wrote: > thanks for the answer; I downloaded the code an I try to sintetize it > with ISE Webpack 8.2i (Xilinx XST Compiler) but in my Spartan 3E > starter kit board don't work (ddr sdram Micron MT46V32M16TG-6T). I don't have the Xilinx Spartan 3E Start Kit, but David claimed it worked, and given that I got it running by simply supplying the correct .ucf I strongly suspect it works. (BTW the 1600E edition which I have has the same Micron DDR SDRAM you list above). If you want us to help you, you need to be more explict about what didn't work. Did it fail to syntesize? Place and Route? Program? When it works you should see the LEDs blinking. To interpret them you need to read the verilog. Tommy > I don't know how can I debug the core; maybe is possible to use the > chipscope, but I never use it before an I don't know if is the right > tools to use. > I guess wich is the things that I must to carefully syntetize to obtain > the goal (like the working simulation). > > DanieleArticle: 113276
I had similar problems with a cyclone II device. The problem was, that the CD came up to late according to the capacitve load caused by another device the micro controller doing passive serial mode configuration) listening to that pin.Article: 113277
I have a ready built design with a cyclone device offering nothing more than some (around 5 maybe) unconnected io pins showing up on a standard connector (pinhead, IDE-like) and like to transport out data as quickly as possible into another board for test purposes. I am thinking of just adding an eval board an linking them via a logical upload channel. The question is, how this could be done easily? I intend to use a kind of serial connection and wire it directly - could a differential pair be of some use here ? What data bit rates colud I expect? Different ideas ? ThanksArticle: 113278
Hi. Just an update for anybody reading this thread later. We found a work around. After updating from EDK 8.2 SP1 to SP2, we where able to connect to the memory through the PLB instead of the OPB bus. This change made the cache function correctly. It was a beautiful and sunny day when Rune Dahl Jorgensen wrote news:Xns988CA6BF53518runedahl23223@130.226.1.34 in comp.arch.fpga: > Hi. > > We are working on a Virtex4 FX12 PowerPC system. The code below is > stored in BRAM and so are the stack and heap. > > Using cache on the external memory crashes the program after approx. > 10000 checks. When only caching BRAM it works fine. > > The program below clears the memory, then it checks half the > memoryspace for zeros and writes the addresses of the zeros in the > other half. > -- Rune D. JorgensenArticle: 113279
On 9 Dec 2006 21:43:29 -0800, "Vitaliy" <m.vitaliy@gmail.com> wrote: >Hello, > >I am working with FFT v.3.2 from Xilinx. Some questions relate directly >to that core, some do not. > . . . >2. a) Is the output of A/D converter fixed point (generally)? b) Then >only division can introduce floating point, right? I don't know what you mean by "introduce floating point". AFAIK the main reason to use floating point (if it is available) is that it avoids the problems of overflow that must be handled explicitly in fixed-point implementations. Sure, the A/D converter output may be a nice integer, but it must be combined with sines and cosines in a way that requires some kind of real number handling (fixed or floating point). It also creates possible overflows of whatever fixed-point range you have established. >3. For the output ordering, the output data can be presented either in >natural order or in bit/digit reverse order. Presenting data in natural >order requires additional resources. a) Does it mean that the output of >radix-2 butterflies is in bit/digit reverse order? b) Also, isn't the >output the frequency spectrum, so what does bit/digit reverse order >represent? c) Why would anyone want the output data with the indexes >that are (binary number) reversed? Bit-reversed ordering is an unavoidable consequence of the FFT algorithm. Either you handle it within the FFT or else you handle it in the application that uses the FFT. The "additional resources" that you speak of to present a natural frequency order to the output is no more memory and only a little bit more processing time (as compared to the butterfly rounds). >4. In version 3.1, when using Pipelined I/O the data had to be scaled, >in version 3.2 user has a choice of scaled and unscaled data. Why would >someone want to use unscaled (unless you always know what your inputs >are)? I am not familiar with the specific package, but I suspect that the scaling is needed to optimize the range vs. resolution in the fixed-point implementation. It would not have any meaning in a floating-point FFT implementation. Robert Scott Ypsilanti, MichiganArticle: 113280
Robert Scott skrev: > On 9 Dec 2006 21:43:29 -0800, "Vitaliy" <m.vitaliy@gmail.com> wrote: > >3. For the output ordering, the output data can be presented either in > >natural order or in bit/digit reverse order. Presenting data in natural > >order requires additional resources. a) Does it mean that the output of > >radix-2 butterflies is in bit/digit reverse order? b) Also, isn't the > >output the frequency spectrum, so what does bit/digit reverse order > >represent? c) Why would anyone want the output data with the indexes > >that are (binary number) reversed? > > Bit-reversed ordering is an unavoidable consequence of the FFT algorithm. > Either you handle it within the FFT or else you handle it in the application > that uses the FFT. The "additional resources" that you speak of to present a > natural frequency order to the output is no more memory and only a little bit > more processing time (as compared to the butterfly rounds). To address question c) above: If you use the FFT + processing + IFFT as a "black box", ignoring the bit-reversal issue might save some processing time and complexity. Both the FFT and the IFFT include a bit-reversal step. So if one computes, say, the spectrum of a filter, bit-reverses this once in the design stage, one can save run-time or system complexity by using the FFT without bit-reversal and then let the missing bit-reversal of the IFFT undo the effect upon return to time domain. Bit-reversals are only important if a human being needs to inspect the results in frequency domain. RuneArticle: 113281
"Anonymous" <someone@microsoft.com> wrote in message news:NfIeh.6808$it.5653@tornado.southeast.rr.com... > I got my self stuck in that I have a V4 design with a 16-bit flash and a > 32-bit peripheral device on the same external bus. I am using a opb_emc with > two memory banks and datawidth matching to talk to them. The problem is I > connected the wrong 16 data lines to the 16-bit flash. If I swap the halves > in my .ucf the flash works fine but the peripheral regs are word swapped. If > I swap them back the peripheral device is fine but obviously flash no longer > works. > > The question: looks like the opb_emc VHDL is somewhere in the bowels of EDK. > Dare I try to hack that code to use the other 16 data lines when performing > a datawidth match for the 16-bit bank? Is there a cleaner solution? > > Thanks, > Clark > > Turns out the hack was pretty easy. Just two lines changed in mem_steer.vhd. But obviously I don't want to have to hack the EDK code to compile my design. Does anyone know if there is an easy way to Import the opb_emc peripheral into my project to create a "myopb_emc" that I can hack without messing up EDK? I guess I can manually copy all the files but then I'm not sure how I get EDK to recognize my version from the Xilinx version? Thanks, ClarkArticle: 113282
The writing is working now (I shrinked the input file too much, so there was nothing to be processed. Still have question about converting two's complement to integer. Vitaliy Vitaliy wrote: > Hello, > > I am using FFT v3.2 core from Xilinx. I have Xilinx ISE/Model Sim. The > outputs of the core are xk_re and xn_re. > 1) I am expanding Xilinx-provided test bench file. I am trying to write > the outputs to .out file. Below are the lines of the code I'm using for > that. > > if (done='1' and busy='1') then > i1<=1; > end if; > while (busy='1' and i1=1) loop > write(my_line, xk_re); > writeline(my_output, my_line); > wait until clk='1'; > end loop; > > Basically, I want to write new value each clock cycle. However, the > above procedure prevents the output produced (meaning xk_re and xn_re > stay at 0, however xk_index does incrementat each clock cycle after > done bit is issued by the core. > I have also tried the following just to see if writing anything (simple > counter in this case) during the time the data is supposed to be > produced will prevent the data to be output. And, inded, the data was > not produce (xk_im and xk_re remained at zero). > > if (done='1' and busy='1') then > i1<=1; > end if; > while (busy='1' and i1=1) loop > write(my_line, i2); > writeline(my_output, my_line); > i2<=i2+1; > wait until clk='1'; > end loop; > > Any suggestions? > > 2) The output of the core is two's complement. Is there a standard > procedure in VHDL to transform the data from two's complement to > integer? > > > > Thanks, > Vitaliy > Ryerson University > ---------------------------------------------------- > -- Input 9.375 MHz (period - 106.67ns) signal. > -- This should apper in bin 768 > -- Fs = 50 MHz (period - 20 ns) > -- FFT Points = 4096 > -- Bin Size = 50 MHz / 4096 points = 12.207 kHz > -- 9.375 MHz / 12.207 kHz = 768 Bin > ---------------------------------------------------- > > LIBRARY ieee; > USE ieee.std_logic_1164.ALL; > use ieee.std_logic_arith.all; > use ieee.numeric_std.all; > use std.textio.all; > use ieee.std_logic_textio.all; > > ENTITY design_top_tb IS > END design_top_tb; > > ARCHITECTURE behavior OF design_top_tb IS > > constant CLOCK_PERIOD : time := 20 ns; > constant HALF_CLOCK_PERIOD : time := CLOCK_PERIOD / 2; > > file DATA_FILE : text is in "Copy_of_sine_9_375mhz_1.dat"; > > COMPONENT design_top > PORT( > xn_re : IN std_logic_vector(23 downto 0); > xn_im : IN std_logic_vector(23 downto 0); > start : IN std_logic; > nfft : IN std_logic_vector(3 downto 0); > nfft_we : IN std_logic; > fwd_inv : IN std_logic; > fwd_inv_we : IN std_logic; > scale_sch : IN std_logic_vector(11 downto 0); > scale_sch_we : IN std_logic; > ce : IN std_logic; > clk : IN std_logic; > rst : IN std_logic; > xk_re : OUT std_logic_vector(23 downto 0); > xk_im : OUT std_logic_vector(23 downto 0); > xn_index : OUT std_logic_vector(11 downto 0); > xk_index : OUT std_logic_vector(11 downto 0); > rfd : OUT std_logic; > busy : OUT std_logic; > dv : OUT std_logic; > edone : OUT std_logic; > done : OUT std_logic; > ovflo : OUT std_logic; > locked : OUT std_logic > ); > END COMPONENT; > > SIGNAL i : integer; > SIGNAL i1 : integer:=2; --used for writing > SIGNAL i2 : integer:=1; > SIGNAL xn_re : std_logic_vector(23 downto 0) := > "000000000000000000000000"; > SIGNAL xn_im : std_logic_vector(23 downto 0) := > "000000000000000000000000"; > SIGNAL start : std_logic := '0'; > SIGNAL nfft : std_logic_vector(3 downto 0) := "1100"; -- for 4096 pt > fft > SIGNAL nfft_we : std_logic := '0'; > SIGNAL fwd_inv : std_logic := '1'; -- FFT=1 IFFT=0 > SIGNAL fwd_inv_we : std_logic := '0'; > SIGNAL scale_sch : std_logic_vector(11 downto 0) := "000000000000"; > SIGNAL scale_sch_we : std_logic; > SIGNAL ce : std_logic := '1'; -- FFT always enabled > SIGNAL clk : std_logic := '0'; > SIGNAL rst : std_logic := '1'; -- Start with DCM in reset > SIGNAL xk_re : std_logic_vector(23 downto 0); > SIGNAL xk_im : std_logic_vector(23 downto 0); > SIGNAL xn_index : std_logic_vector(11 downto 0); > SIGNAL xk_index : std_logic_vector(11 downto 0); > SIGNAL rfd : std_logic := '0'; > SIGNAL busy : std_logic := '0'; > SIGNAL dv : std_logic := '0'; > SIGNAL edone : std_logic := '0'; > SIGNAL done : std_logic := '0'; > SIGNAL ovflo : std_logic := '0'; > SIGNAL locked : std_logic := '0'; > > BEGIN > > uut: design_top PORT MAP( > xn_re => xn_re, > xn_im => xn_im, > start => start, > nfft => nfft, > nfft_we => nfft_we, > fwd_inv => fwd_inv, > fwd_inv_we => fwd_inv_we, > scale_sch => scale_sch, > scale_sch_we => scale_sch_we, > ce => ce, > clk => clk, > rst => rst, > xk_re => xk_re, > xk_im => xk_im, > xn_index => xn_index, > xk_index => xk_index, > rfd => rfd, > busy => busy, > dv => dv, > edone => edone, > done => done, > ovflo => ovflo, > locked => locked > ); > > -- Clock > clock_proc : process > begin > wait for HALF_CLOCK_PERIOD; > clk <= not clk; > end process; > > control : process > begin > wait for (100 ns+(CLOCK_PERIOD)); --wait for > GSR > rst <= '0'; --release DCM > reset > wait until (locked = '1' and locked'event); --wait for > DCM lock > wait for ((HALF_CLOCK_PERIOD)+(CLOCK_PERIOD*2)); > nfft_we <= '1'; > fwd_inv_we <= '1'; > scale_sch <= "010101010101"; > scale_sch_we <= '1'; > wait for CLOCK_PERIOD; > nfft_we <= '0'; > fwd_inv_we <= '0'; > scale_sch_we <= '0'; > wait for CLOCK_PERIOD; > start <= '1'; --start > loading and transform > wait for (CLOCK_PERIOD*8192); > wait; -- will wait forever > end process; > > > data_read : process > variable input_line : line; > variable input_data : integer; > file my_output : TEXT open WRITE_MODE is "file_io.out"; > -- above declaration should be in architecture declarations for > multiple > variable my_line : LINE; > variable my_output_line : LINE; > begin > i <= 0; > xn_re <= "000000000000000000000000"; > xn_im <= "000000000000000000000000"; > wait for CLOCK_PERIOD; -- push data > to negative edge transition > while not endfile(DATA_FILE) loop > readline(DATA_FILE, input_line); > read(input_line, input_data); > xn_re <= conv_std_logic_vector(input_data, 24); > i <= i + 1; --line index that returns the line number of the > input file > wait for CLOCK_PERIOD; > end loop; > > if (done='1' and busy='1') then > i1<=1; > -- if (i1=0) then > -- i2<=1; > end if; > while (busy='1' and i1=1) loop > write(my_line, xk_re); > writeline(my_output, my_line); > ---- i1 <= i1-1; > wait until clk='1'; > end loop; > -- if (i1=0) then > -- i2<=1; > -- end if; > -- wait for CLOCK_PERIOD * 12500; --12500 > -- ASSERT (FALSE) REPORT > -- "Simulation successful (not a failure). No problems detected." > -- SEVERITY FAILURE; > end process; > ---- > END;Article: 113283
"Anonymous" <someone@microsoft.com> schrieb im Newsbeitrag news:hAXeh.13390$it.10363@tornado.southeast.rr.com... > Turns out the hack was pretty easy. Just two lines changed in > mem_steer.vhd. > But obviously I don't want to have to hack the EDK code to compile my > design. Does anyone know if there is an easy way to Import the opb_emc > peripheral into my project to create a "myopb_emc" that I can hack without > messing up EDK? I guess I can manually copy all the files but then I'm not > sure how I get EDK to recognize my version from the Xilinx version? > > Thanks, > Clark > just copy into local \pcores and use that it will override the orginal one AnttiArticle: 113284
"Vitaliy" <m.vitaliy@gmail.com> wrote in message news:1165773211.677889.327250@73g2000cwn.googlegroups.com... > The writing is working now (I shrinked the input file too much, so > there was nothing to be processed. Still have question about converting > two's complement to integer. > >> >> 2) The output of the core is two's complement. Is there a standard >> procedure in VHDL to transform the data from two's complement to >> integer? >> To convert a std_logic_vector (ex. My_slv) that is being interpreted as 'twos complement' to an integer use... to_integer(signed(My_slv)) KJArticle: 113285
I'm getting this error in ModelSim: # ** Error: design_top_tb.vhd(165): (vcom-1137) Identifier 'signed' is not visible. Making two objects with the name 'signed' directly visible via use clauses results in a conflict; neither object is made directly visible. (LRM Section 10.4) Vitaliy KJ wrote: > "Vitaliy" <m.vitaliy@gmail.com> wrote in message > news:1165773211.677889.327250@73g2000cwn.googlegroups.com... > > The writing is working now (I shrinked the input file too much, so > > there was nothing to be processed. Still have question about converting > > two's complement to integer. > > > >> > >> 2) The output of the core is two's complement. Is there a standard > >> procedure in VHDL to transform the data from two's complement to > >> integer? > >> > To convert a std_logic_vector (ex. My_slv) that is being interpreted as > 'twos complement' to an integer use... > > to_integer(signed(My_slv)) > > KJArticle: 113286
In to_integer(signed(My_slv)), does signed relate to integer or to arithmetic (I think integer, but just checking)? Because there are two libraries: ieee.numeric_std.signed and ieee.std_logic_arith.signed So, when I specify the complete name of the library (i.e ieee.numeric_std.signed), the compiler is happy. Vitaliy KJ wrote: > "Vitaliy" <m.vitaliy@gmail.com> wrote in message > news:1165773211.677889.327250@73g2000cwn.googlegroups.com... > > The writing is working now (I shrinked the input file too much, so > > there was nothing to be processed. Still have question about converting > > two's complement to integer. > > > >> > >> 2) The output of the core is two's complement. Is there a standard > >> procedure in VHDL to transform the data from two's complement to > >> integer? > >> > To convert a std_logic_vector (ex. My_slv) that is being interpreted as > 'twos complement' to an integer use... > > to_integer(signed(My_slv)) > > KJArticle: 113287
On 10 Dec 2006 08:18:16 -0800, "Rune Allnor" <allnor@tele.ntnu.no> wrote: >Bit-reversals are only important if a human being needs to inspect the >results in frequency domain. What about an application that requires the software to inspect the frequency spectrum, looking for peaks, interpolating between adjacent bins, and finding patterns of harmonic-related peaks. It is hard to imagine that application being written without having the frequency spectrum in its natural order, even if no human interpretation is involved. Robert Scott Ypsilanti, MichiganArticle: 113288
sp_mclaugh@yahoo.com wrote: <snip> > Yes, but assume that we have a pure 4.2 MHz sine wave, and we sample > where the slew rate is fastest (at the zero crossings, if the sinusoid > goes from -1 to +1). Call the difference between two such samples > max_change. Then, with worst-case jitter, instead of seeing max_change > between two samples, we see max_change * (t_sample + 2*t_jitter) / > (t_sample). This assumes a first-order expansion around the fast-slew > area. In other words, treat that area as having a constant slope (good > approx for a sinusoid), so the amplitude between samples is linearly > related to the time between samples. But, once we read the values into > the FPGA, we treat them as if they were only seperated by t_sample. If > the change-per-unit-time increases, doesn't that directly translate to > a change in maximum frequency? So... is my 4.305 MHz cutoff above > correct? The 4.2 MHz cutoff is the right cutoff to design for because 1) these are based on ideal-time samples in your filter space and 2) you probably won't have a "brick wall" filter. You should have an analog filter on the front end if your input isn't guaranteed to be cleanly band-limited (such as the steps from a 27 MHz DAC) to help reduce any initial aliasing but the analog filter doesn't need to be extreme, just to have a good block between 45 and 55 MHz since that range would alias back down to your ~5 MHz range of interest. A digital filter can clean up what's left but you don't need to design for 4.305 MHz rather than your desired 4.2 MHz in the digital realm though the difference is rather minor. <snip> > So what happens between these two extremes (signal being either > completely DC or completely high frequency - 4.2 MHz)? Surely if the > signal was completely 1 Hz, we wouldn't expect to see jitter uniformly > distributed from 0 to 25 MHz, correct? Shouldn't the maximum frequency > of jitter-induced noise be a percent (>100%) of the maximum frequency > of the input signal? Again, the jitter has an effect on the 1 Hz measurement - a very small amount - but you will see a noise floor all the way out to 25 MHz from the jitter if the other system noise (including measurement noise) didn't swamp out those extremely small values. Imagine a .01% random noise source added to your signal. You will see that entire noise source in your spectrum. It's just very small and not worth worrying about in this application. You will have more jitter-induced error at higher frequencies than at lower frequencies. Happily, the higher frequencies for video produce less noticeable artifacts. If your noise floor for low frequencies was -40 dB, you might have objectionable results, especially if you're trying to process single frames. If the -40dB noise floor is at the higher frequencies, you have the perceived color getting off track a bit in a composite signal or loss of precision in fast intensity changes for component video. The main luminance content is still very clean. <snip> > Ah, now that does make sense to me. If my signal really *was* just a > sinusoid (ie, a single tone), then maybe I could even develop some > algorithm to pick out the min and max samples (where slew was lowest). > Of course, that's not possible with my (real) video signal. If you just picked out the min and max, you wouldn't gain any noise averaging from the other samples. If you have two independent jitter sources that individually induce 100 ps of RMS jitter, what would the two jitter sources do to your signal? You wouldn't end up with 200 ps RMS jitter; you'd end up with about 140 ps. Jitter is statistical in nature. If RMS jitter is based on 1 standard deviation, the chances of getting the jitter values to add hits at 2 standard deviations, not 1. If you average more samples with random distributions, your probability of getting less noise overall is reduced by the same reasoning even if the samples at the slower slew rates didn't reduce the jitter-induced noise on their own. <snip> > The source of the jitter is beyond my knowledge, but this is certainly > good to hear. I will definitely low-pass my signal as close as I can to > 4.2 MHz (depending on how steep my filter is, which depends on how much > FPGA real estate I have to spare). There's no need to over-design. A "clean" signal can still have some noise (or some alias) and meet all your needs. If you could experiment with different cutoff frequencies or steepness, you might gain better insight into what qualities deliver "better" results at what cost. Superb opportunity for learning experience. > One last question/comment. Wouldn't this be an ideal example of when to > use dithering? ie, my LSB isn't really significant, so I shouldn't > treat it as if it was. I've never used dithering before, but maybe I > can use an LFSR (linear feedback shift register) or some other > technique to add one LSB of randomness to the samples... ? Dithering is useful if you're trying to avoid frequency spurs typically related to the nonlinearity of the ADC you're using. If you want to get a 3 MHz sinewave and a 100 kHz sinewave superimposed without 2.9 and 3.1 MHz components 80 dB below the main sinewave, then yes - dithering is helpful. For video you shouldn't notice any problems from the slight non-linearity of today's converters. You'll already have noise in your system from the amplifiers, the converter, and the jitter-induced effects. This is another aspect that could add nicely to the learning experience but keep in mind that the added dither has to be kept out of the frequency range of interest, such as feeding it through a bandpass that has good bandstops up to 5 MHz and 45-55 MHz (for aliasing) as well as a good rolloff by the time you reach 95 MHz; I wouldn't recommend it because of the stringent analog filter design needs, but seeing the difference is informative.Article: 113289
Nico Coesel wrote: > "Gabor" <gabor@alacron.com> wrote: <snip> >> Quick calculation: >> using 4.2 MHz full scale (of the ADC input range) sine wave >> 4.2MHz is about 26 Mradians/s >> ADC input range corresponds to -1 to +1 of normalized sine >> 1 LSB of 8-bit ADC is therefore 1/128 (normalized). >> 1 / (26M * 128) is about 0.3 nS >> >> So for a 1 LSB sampling error, you could live with 300 pSec of >> sampling jitter. My guess is that the threads you looked at >> were concerned about significantly smaller acceptable jitter, >> as would be the case in most networking applications where >> the sampling rate and bandwidth are closer to the same >> frequency. > > Isn't this calculation a bit crude? I suppose the spectrum of the > jitter is also important. The calculation is crude, sure. But what DO we know about the jitter from the oscillator and the jitter induced by switching within an FPGA? Almost nothing. There's little chance to "count on" any kind of jitter spectrum for doing anything beyond a first order approximation. If the first order effects are considered, the secondary issues are... secondary.Article: 113290
One more thing: If you're doing your own ADC board (leaving the Spartan3 board to the "experts") you would do yourself the best service by including your oscillator there and supplying that clock to the FPGA. If you don't have a global clock pin on the ribbon cable header, you can still use a twisted pair (signal and ground) to route the clock independently to the unused DIP header on the Digilent board.Article: 113291
In an interview from 97, Bob Yannes the designer of MOS 6581 (aka "SID") said the following aboud the chips ASDR enveloper: "In order to more closely model the exponential decay of sounds, another look-up table on the output of the Envelope Generator would sequentially divide the clock to the Envelope Generator by two at specific counts in the Decay and Release cycles. This created a piece-wise linear approximation of an exponential. I was particularly happy how well this worked considering the simplicity of the circuitry. The Attack, however, was linear, but this sounded fine." In short, he was using an down-counter to count down from 255 down to some number, but he somehow made the counter to move pseudo-exponentially instead of linearly. Does anyone know how this works? burns (the whole interview is found at http://stud1.tuwien.ac.at/~e9426444/yannes.html)Article: 113292
burn.sir@gmail.com wrote: > In an interview from 97, Bob Yannes the designer of MOS 6581 (aka > "SID") said the following aboud the chips ASDR enveloper: > > "In order to more closely model the exponential decay of sounds, > another look-up table on the output of the Envelope Generator would > sequentially divide the clock to the Envelope Generator by two at > specific counts in the Decay and Release cycles. This created a > piece-wise linear approximation of an exponential. I was particularly > happy how well this worked considering the simplicity of the circuitry. > The Attack, however, was linear, but this sounded fine." > > In short, he was using an down-counter to count down from 255 down to > some number, but he somehow made the counter to move > pseudo-exponentially instead of linearly. > > Does anyone know how this works? You could use a table, but that's likely to get large, and you could use a simple binary shift 1/2^n, which will approximate decays, but that's likely to be a bit coarse, (even if very simple) as each change is 2:1. I'd imagine the best would be a mix of the two. handle the coarse side with binary shifting, /2, and the finer selection between the two with a table, which now only has to cover a 2:1 range, so can be smaller ? Think of this as a bit like a tiny floating point number format : exponent and mantissa. -jgArticle: 113293
Hi all, in other words, is there an easy way to avoid FPGA attempt to configure? thanks florentArticle: 113294
I've just used the Core Generator to customise an Aurora 16 bit streaming interface for a V2P. The resulting code has the core placed on the bottom edge of the device when I put it on the top edge during customisation. Has anyone else noticed this? TIA. Rog.Article: 113295
I'm using Picoblaze to emulate the MAC (still on early stage, I can't tell whether it works or not). Basically, the MAC interface (MII) is not so hard to understand and the PHY layer helps against the noise from CAT5 cables. Take a look at http://www.fpga4fun.com/10BASE-T.html, and the PHY's datasheet. The complete details about how should MAC work can be found in IEEE802.3 whitepaper (http://standards.ieee.org/getieee802/). But I think fpga4fun site's information is enough.Article: 113296
Mikhail,
Last year, I was three steps away from the funny farm when
implementing a desgin with the x4 PCI Express core in a Virtex 4 FX
(this used MGTs). What problems are you having?
Just to state the obvious, be sure that you are using the proper
silicon stepping in the UCF, make sure you have obeyed any Xilinx
reference clock specification (this changed from 125MHz to 150MHz for
PCI Express), and insure your board is electrically sound (we had minor
crosstalk issues on a early version of our custom board, but that was
easy to fix...fortunately for us, it was not on lane zero of
PCIe)...that's probably obvious to you, but these are some simple
suggestions that I have found that others overlook :)! Also, on V4 FX,
the MGT reference voltage is .1V lower than what the datasheet
specifies if I am not mistaken...that .1V seemed to really matter too
:) :) !!!! This might have changed now that V4FX is in (or close to)
production, but double check this with Xilinx.
Is there a thread where you are discussing this?
Ed
MM wrote:
> "ed_h" <ehenciak@gmail.com> wrote in message
> news:1165645305.866775.178560@16g2000cwy.googlegroups.com...
> >I got this working today using the following configuration :
>
> Congratulations! You should feel good now! :) I am now trying to get MGTs
> running and don't feel even half as good as you probably are :(
>
> /Mikhail
Article: 113297Thank You for the answers, they are all informative. Another question: For testing the algorithm I had to use version 2.1 from Xilinx, since their latest version, for which I can use core generator provides structural model rather than behavioral. The input to the core is converted from integer to 2's complement (in the test bench file). My input file is digital sine wave (file from Xilinx website). The output is two's complement (datasheet for version 2.1 doesn't specify whether it is in bit reversed or natural order). My input is only 42 numbers (or lines). However, the output size is ~100 times greater (and of course it is not 100x the same number, than 100x th other number, values do not seem to corellate to the expected output). Any ideas as to why and what to do about it? Thanks, VitaliyArticle: 113298
Vitaliy wrote: > Hello, > > I am working with FFT v.3.2 from Xilinx. Some questions relate directly > to that core, some do not. > > 1. Why is block floating point unavailable for Pipelined/streaming FFT? > Is it because the dynamic range is too hard to predict? Block floating point has a common exponent for the entire block of data. In order to do this, the entire data set must pass through a max function to determine the max value before a common exponent can be extracted. This is fine if you are going into memory, then through the FFT then back to memory. It doesn't work, of course, if you are doing the FFT on the data as it arrives. > 2. a) Is the output of A/D converter fixed point (generally)? b) Then > only division can introduce floating point, right? floating point is there to reduce the width of the operand by separating off an exponent. It is helpful for reducing hardware data path widths and for reducing memory. It generally becomes useful at widths greater than 14 bits; single precision ieee floats have 24 bit fixed point fields modified by an exponent. Most ADC's are 16 bits or less, so the overhead for floating point (all the logic to handle the exponents) is expensive compared to the hardware savings realized by using it. > 3. For the output ordering, the output data can be presented either in > natural order or in bit/digit reverse order. Presenting data in natural > order requires additional resources. a) Does it mean that the output of > radix-2 butterflies is in bit/digit reverse order? b) Also, isn't the > output the frequency spectrum, so what does bit/digit reverse order > represent? c) Why would anyone want the output data with the indexes > that are (binary number) reversed? Bit reversal is an artifact of the Cooley-Tukey FFT algorithm. Getting the data back into natural order requires an additional memory buffer which adds to the latency and increases the hardware complexity. The bit reversal refers to the address sequencing, which directly affects the order the samples are presented. The bit reversed addressing means the output frequency bins are not ordered in order of increasing freqency, rather they are ordered as though the address bits have been reversed. For a 16 point FFT, instead of bins 0,1,2,3,...,15 you get bins 0,8,4,12,2,...,7,15. The bit reorder might occur elsewhere in the system, or if you are doing an FFT followed by an IFT (e.g. for a fast convolution or fast correlation), the inverse FFT can accept data in bit-reversed order and output in natural order, and the frequency domain process is independent of the order as long as all inputs are ordered the same way. By skipping the reorder, you save both latency and hardware. > 4. In version 3.1, when using Pipelined I/O the data had to be scaled, > in version 3.2 user has a choice of scaled and unscaled data. Why would > someone want to use unscaled (unless you always know what your inputs > are)? > The FFT results vary depending on the nature of the input. An FFT is energy conserving, meaning the sum of the input energy is redistributed into the output bins. If your input is always fairly monochromatic (i.e. very narrowband), then most of the output energy will be focused in one FFT bin, and can be up to N times the input amplitude for an N point FFT. On the other hand, if your input is broadband noise, the output energy will be fairly evenly distributed among all the output bins, which means the outputs will have amplitudes close to the input amplitudes. For larger FFT sizes, this represents a sizeable dynamic range. If you know before-hand the typical and worst case characteristics of your input, you can use scaling to essentially ignore MSBs that are never anything but extended sign bits in your application. > Thanks, > Vitaliy >Article: 113299
Robert Scott skrev: > On 10 Dec 2006 08:18:16 -0800, "Rune Allnor" <allnor@tele.ntnu.no> wrote: > > >Bit-reversals are only important if a human being needs to inspect the > >results in frequency domain. > > What about an application that requires the software to inspect the frequency > spectrum, looking for peaks, interpolating between adjacent bins, and finding > patterns of harmonic-related peaks. It is hard to imagine that application > being written without having the frequency spectrum in its natural order, even > if no human interpretation is involved. So what? There is no reason why a computer system should not be able to handle the bit-reversed order. This boils down to a matter of convenience. If somebody -- either computer or human -- wants to inspect the spectrum, the frequency domain processing is no longer a black box, and it might be *safer* to use the natural (non-bit-reversed) order. The the natural order is only *nescessary* is a human user is involved. Rune
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