Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Messages from 113275

Article: 113275
Subject: Re: Opencores DDR SDRAM controller
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 9 Dec 2006 22:44:01 -0800
Links: << >>  << T >>  << A >>
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).
> 
> Daniele


Article: 113276
Subject: Re: JTAG programming of Altera Cyclone and CONF_DONE
From: "alterauser" <fpgaengineerfrankfurt@arcor.de>
Date: 10 Dec 2006 02:44:47 -0800
Links: << >>  << T >>  << A >>
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
Subject: linking two fpga boards
From: "alterauser" <fpgaengineerfrankfurt@arcor.de>
Date: 10 Dec 2006 03:10:51 -0800
Links: << >>  << T >>  << A >>
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 ?

Thanks


Article: 113278
Subject: Re: Caching of external memory
From: "Rune D. Jørgensen" <RUNE_dahl@hotmailREMOVE_THIS.com>
Date: 10 Dec 2006 13:01:54 GMT
Links: << >>  << T >>  << A >>
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. Jorgensen

Article: 113279
Subject: Re: Some questions about FFT implementation
From: ---@--- (Robert Scott)
Date: Sun, 10 Dec 2006 14:27:11 GMT
Links: << >>  << T >>  << A >>
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, Michigan

Article: 113280
Subject: Re: Some questions about FFT implementation
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 10 Dec 2006 08:18:16 -0800
Links: << >>  << T >>  << A >>

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. 

Rune


Article: 113281
Subject: Re: impossible opb_emc hack?
From: "Anonymous" <someone@microsoft.com>
Date: Sun, 10 Dec 2006 17:36:13 GMT
Links: << >>  << T >>  << A >>

"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,
Clark



Article: 113282
Subject: Re: Writing output signals to text file (VHDL)?
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 10 Dec 2006 09:53:31 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: impossible opb_emc hack?
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 10 Dec 2006 18:58:10 +0100
Links: << >>  << T >>  << A >>

"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

Antti



Article: 113284
Subject: Re: Writing output signals to text file (VHDL)?
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 10 Dec 2006 18:06:30 GMT
Links: << >>  << T >>  << A >>

"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))

KJ 



Article: 113285
Subject: Re: Writing output signals to text file (VHDL)?
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 10 Dec 2006 11:32:38 -0800
Links: << >>  << T >>  << A >>
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))
> 
> KJ


Article: 113286
Subject: Re: Writing output signals to text file (VHDL)?
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 10 Dec 2006 11:45:55 -0800
Links: << >>  << T >>  << A >>
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))
> 
> KJ


Article: 113287
Subject: Re: Some questions about FFT implementation
From: ---@--- (Robert Scott)
Date: Sun, 10 Dec 2006 20:07:00 GMT
Links: << >>  << T >>  << A >>
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, Michigan

Article: 113288
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 10 Dec 2006 20:14:20 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 10 Dec 2006 20:16:43 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 10 Dec 2006 20:24:37 GMT
Links: << >>  << T >>  << A >>
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
Subject: approximation of an exponential ramp?
From: burn.sir@gmail.com
Date: 10 Dec 2006 13:15:40 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: approximation of an exponential ramp?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 11 Dec 2006 10:56:17 +1300
Links: << >>  << T >>  << A >>
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.


-jg


Article: 113293
Subject: How to perform a boundary scan test BEFORE configuration on Spartan-3 Starter Board ?
From: florent.peyrard@gmail.com
Date: 10 Dec 2006 14:12:03 -0800
Links: << >>  << T >>  << A >>
Hi all,

in other words, is there an easy way to avoid FPGA attempt to
configure?

thanks
florent


Article: 113294
Subject: Aurora v2.5
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Sun, 10 Dec 2006 23:02:10 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA+Ethernet
From: "kunil" <kunilkuda@gmail.com>
Date: 10 Dec 2006 16:38:36 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx MPMC2 "External Ports" question
From: "ed_h" <ehenciak@gmail.com>
Date: 10 Dec 2006 17:34:36 -0800
Links: << >>  << T >>  << A >>
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: 113297
Subject: Re: Some questions about FFT implementation
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 10 Dec 2006 18:18:08 -0800
Links: << >>  << T >>  << A >>
Thank 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,
Vitaliy


Article: 113298
Subject: Re: Some questions about FFT implementation
From: Ray Andraka <ray@andraka.com>
Date: Sun, 10 Dec 2006 22:39:35 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Some questions about FFT implementation
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 10 Dec 2006 19:41:58 -0800
Links: << >>  << T >>  << A >>

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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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