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
2019JanFebMar2019

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 113250

Article: 113250
Subject: Re: FPGA application field
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 08 Dec 2006 22:41:05 -0800
Links: << >>  << T >>  << A >>
tenteric wrote:
(snip)

> I know that. But I'm interesting, is there any real-world cases when
> FPGA design was successfull in heavy scientific computation, where
> outcome compensating FPGA cost + design cost, etc.

There are some I know for searching DNA sequences.  I believe they
were reasonably successful at overcoming costs, etc.

Systolic array is my favorite for such processors.

-- glen


Article: 113251
Subject: Re: FPGA application field
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 08 Dec 2006 22:45:17 -0800
Links: << >>  << T >>  << A >>
tenteric wrote:

(snip)

> I need to be more precise - my passion is just very fast computation -
> I'm very interesting in implementing any math algorithm thus it will
> work as fast as it can.

My favorite architecture for such specialized processors is the
systolic array.  The ones I have seen used are for algorithms
using 16 bit fixed point, which is easy.  If you want 64 bit
floating point it takes a lot more cells, but may be just about
reasonable.   If you can do it in 64 bit fixed point that would
be somewhat easier (that is, more computation per device).

-- glen


Article: 113252
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: sp_mclaugh@yahoo.com
Date: 8 Dec 2006 22:54:22 -0800
Links: << >>  << T >>  << A >>
John_H wrote:

Regarding the frequency range of noise due to sample clock jitter
(sampling using an ADC much faster than required for a given
band-limited signal):

> Since the noise you'll see from the clock jitter will be spread across
> the full 25 MHz bandwidth of your 50 MS/s data stream

On a second reading, I was wondering if you could explain this a bit
further. In the worst-case scenario, we would have an input signal with
a purely 4.2 MHz frequency component (would never happen for video, but
just for the arguement). If two samples were taken, each experiencing
maximum sample clock jitter, but in opposite directions, then they
would be seperated by (sample time + 2 * jitter). However, we would
treat them as if they were seperated by only (sample time).

Wouldn't this only introduce noise up to a frequency of:
4.2 MHz * (sample time + 2 * jitter) / (sample time) ?

ie, for 250 ps of jitter on a 20 ns clock, with a 4.2 MHz signal being
sampled, I could expect to see noise up to 4.305 MHz...?

Or, instead of assuming an input with a purely 4.2 MHz component, go to
the other extreme. Assume the input is a constant DC signal. The jitter
on the sampling clock wouldn't cause any noise at all here, would it?

Please excuse the simple question, this is probably something
elementary, but it's new to me!

Sean


Article: 113253
Subject: Re: Avoiding meta stability?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 08 Dec 2006 23:09:24 -0800
Links: << >>  << T >>  << A >>
Symon wrote:

(snip on asynchronous (self timed) logic)

> I challenge you to design a metastability free traffic light controller from 
> 'metastability solved' asynchronous logic. The lights are at a crossroads 
> out in the sticks with low traffic volume. They are nomally both set RED 
> until a car comes along. The lights then go GREEN in the direction from 
> which a vehicle comes from. Make sure your logic doesn't go metastable when 
> two cars arrive simultaneously from two orthogonal directions. Your 
> controller must work no matter with whatever time difference the two cars 
> arrive, and must work on EVERY occasion for EVERY car arrival timing 
> scenario. Even one mistake in the lifetime of the universe is FAR, FAR too 
> often for this junction!

I went back to see what I wrote before.  I didn't say that it never went
metastable, only that it wasn't a problem.  I was told that sometimes 
one would see the console lights stop for a little while until the 
metastability was resolved.  For the traffic light I would expect a 
possible delay from when the cars arrived until one of the lights
turned green.  As long as both lights can't turn green at the same time,
you are still safe.

But current FPGAs are not very well designed for self timed logic.  All 
the flip-flops are completely useless!  It has been many years since I
thought about actual designs (when KA-10's were around).

-- glen


Article: 113254
Subject: Re: RTL Hardware design issue: Count Leading Zeros CLZ
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 09 Dec 2006 12:07:26 GMT
Links: << >>  << T >>  << A >>
davidc@ad-holdings.co.uk wrote:

>Hi,
>
>I'm trying to create a Count Leading Zero (CLZ) in VHDL for a project
>but i'm having difficulty in finding any information what so ever apart
>from an explanation as to what it does, can anyone help?

What you need is a priority encoder:

function priority8to3(inval : std_logic_vector(7 downto 0)) return
std_logic_vector is
variable ret : integer;
variable a: std_logic_vector(2 downto 0);
begin
	a := "000";

	--priority encoder. By looping from 7 downto 0, the priority
	--can be reversed.		
	prio_loop: for i in 0 to 7 loop
		if inval(i)='1' then
			ret := i;
			exit prio_loop;
		end if;
	end loop;

return a + ret;
end;


-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 113255
Subject: Re: Avoiding meta stability?
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 9 Dec 2006 12:45:38 -0000
Links: << >>  << T >>  << A >>
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:9KydnQ6z6aBF_efYnZ2dnUVZ_rKvnZ2d@comcast.com...
> Symon wrote:
>
> (snip on asynchronous (self timed) logic)
>
>> I challenge you to design a metastability free traffic light controller 
>> from 'metastability solved' asynchronous logic. The lights are at a 
>> crossroads out in the sticks with low traffic volume. They are nomally 
>> both set RED until a car comes along. The lights then go GREEN in the 
>> direction from which a vehicle comes from. Make sure your logic doesn't 
>> go metastable when two cars arrive simultaneously from two orthogonal 
>> directions. Your controller must work no matter with whatever time 
>> difference the two cars arrive, and must work on EVERY occasion for EVERY 
>> car arrival timing scenario. Even one mistake in the lifetime of the 
>> universe is FAR, FAR too often for this junction!
>
> I went back to see what I wrote before.  I didn't say that it never went
> metastable, only that it wasn't a problem.  I was told that sometimes one 
> would see the console lights stop for a little while until the 
> metastability was resolved.  For the traffic light I would expect a 
> possible delay from when the cars arrived until one of the lights
> turned green.  As long as both lights can't turn green at the same time,
> you are still safe.
>
Hi Glen,
Weeeelll, yes and no! I was just trying to make a point that there is a 
finite probability that the lights will stay red until the drivers drop dead 
of old age. Not exactly safe! Nearly, but not exactly. :-) Likewise, the 
PDP-10 console lights _could_ stop for months.
So, I would respectfully disagree with your statement that "The solution to 
metastability is asynchronous logic (also called self-timed logic).". 
Furthermore, the implication that synchronous design is any worse than 
asynchonous design I think is not true. As Mike said in his post, "The 
D-flop is also an asynchronous circuit.".
>
> But current FPGAs are not very well designed for self timed logic.  All 
> the flip-flops are completely useless!  It has been many years since I
> thought about actual designs (when KA-10's were around).
>
> -- glen
>
Right, I agree you make a good point that FPGAs are not the route to take 
for asynchronous logic circuits.
Best regards, Symon. 



Article: 113256
Subject: Using Jtag for general Communications
From: googlinggoogler@hotmail.com
Date: 9 Dec 2006 07:07:40 -0800
Links: << >>  << T >>  << A >>
Hi,

I would like to send some data back via my jtag cable from my spartan-3
board to the computer. I have read the article below, but it appears
that this method works only with modelsim.

http://www.xilinx.com/publications/xcellonline/xcell_53/xc_pdf/xc_jtag53.pdf

I'm to cheap to buy modelsim at present and would enjoy the exercise of
creating something of my own, I am currently using the Xilinx webpack
7.1

Can anyone propose a method in which i can send simple data back? will
it be a case of instansiating the JTAG within the spartan and doing it
this way? can I avoid reinventing by using some TCL and interact with
something within the ISE for doing this?

(is there a good tutorial on TCL aimed specifically at Xilinx tools, i
can find bits and pieces but nothing from the ground up, i've messed
with the shell but thats really as far as i got in terms of doing
anything productive)

Cheers

David


Article: 113257
Subject: JTAG programming of Altera Cyclone and CONF_DONE
From: "Nevo" <nevo_n@hotmail.com>
Date: Sat, 09 Dec 2006 17:28:18 GMT
Links: << >>  << T >>  << A >>
All,

I'm having an extraoridnarily difficult time with my first FPGA project and 
am very frustrated.

I have a board designed around the EP1C6 Cyclone device. The Quartus 
programmer is able to detect the EP1C6 on a JTAG boundary scan. I'm able to 
initiate programming the device over the JTAG port, but Quartus gives me an 
error CONF_DONE failed to go high on device 1.

I reviewed the Cyclone datasheet, and 13-19 in particular, "JTAG 
Configuration of Single Cyclone FPGA."

This diagram does not show CONF_DONE going to the programming header.

Why is Quartus complaining that CONF_DONE isn't going high when that signal 
isn't supposed to go to the programming header? More importantly, is there 
anything I can do to circumvent this problem?

Many thanks,

-Nevo 



Article: 113258
Subject: Current programming hardware does not support Active Serial programming mode
From: "Nevo" <nevo_n@hotmail.com>
Date: Sat, 09 Dec 2006 17:46:14 GMT
Links: << >>  << T >>  << A >>
I get this error trying to program a serial device using a homemade 
ByteBlaster II cable as described in Altera's "ByteBlaster II Download Cable 
User's Guide."

I thought this cable supports active serial programming.

What am I doing wrong?

Thanks,

-Nevo 



Article: 113259
Subject: Re: FPGA+Ethernet
From: "Jean Nicolle" <jean.nicolle@sbcglobal.net>
Date: Sat, 09 Dec 2006 17:53:32 GMT
Links: << >>  << T >>  << A >>
As long as you limit yourself to 10BASE-T, it is quite possible to implement 
the PHY in the FPGA, and for very low logic usage.
See an implementation example http://www.fpga4fun.com/10BASE-T0.html

"Steve" <eejju@polyu.edu.hk> wrote in message 
news:1165494117.52713@nsserver1.polyu.edu.hk...
> Hi all,
>
> I want to add an Ethernet interface to my FPGA board for data 
> transmission. But I'm not sure which scheme I should use.
>
> A) There's a PHY on the FPGA board, but I don't have much knowledge or 
> experience on MAC. The protocol seems complicated and not easy to 
> implement in a short time. Is it possible to develop a small and simple 
> MAC? My idea is packing data to form a standard TCP or UDP packet and 
> using the PHY to send out or receive it. Another reason I don't want using 
> a full MAC is it costs too much resources (~2000 slices). If I use 
> MicroBlaze+OPB MAC, I can't afford the license fee.
>
> B) Using another external Ethernet micro-controller, such as Rabbit 
> microprocessor. I can develop an interface between FPGA and uC for data 
> transmission. But I'm wondering how fast the speed is?
>
> C) Using micro-controller + (MAC+PHY Ethernet single chip). Then porting 
> uClinux or lwip to the uC and hanging FPGA to the address/data bus of the 
> uC.
>
> Any suggestions? Thank you.
>
> JJ
> 



Article: 113260
Subject: Re: testbench help
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 09 Dec 2006 10:41:19 -0800
Links: << >>  << T >>  << A >>
jim wrote:
> get the following error while trying to create a test bench.

If this is a vhdl testbench, post the code to comp.lang.vhdl

   -- Mike Treseler

Article: 113261
Subject: Re: About Unstable Operation of ACTEL(A3P1000)....
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Sat, 9 Dec 2006 19:58:35 +0100
Links: << >>  << T >>  << A >>
> The un-operated functions are not fixed !!! Malfunctions are
> irregular.....................
> Also, the source of VHDL had been verified in Altera device
> (EPF10K100ARC240)
> In Altera, all functions are operated correctly...........

Altera-devices power-up with all FFs set to 0, while Actel power-up random, 
I think. Do you have a proper reset-circuit?

Thomas

www.entner-electronics.com



Article: 113262
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 09 Dec 2006 19:28:21 GMT
Links: << >>  << T >>  << A >>
sp_mclaugh@yahoo.com wrote:
<snip>
> As did I ! I'm looking into the differential clock approach now, though
> I fear that it won't be do-able. I *think* the Spartan 3 can do
> differential output, using special features of the IOB's, but it seems
> that some external setup/calibration components (resistors) are
> required. It would be up to Digilent (producer of my starter board) to
> have properly implemented these. There appear to be quite a few
> "special" output modes (ie, LVPECL, etc) and I would be lucky for them
> to have implemented exactly the one I need. Building my own PCB for the
> Spartan is out of the question at this time (it would take me a year or
> more to learn all the necessary skills). I could be mistaken - maybe
> there is an easy way. That's just my current best-guess after a few
> hours of research.

Driven differential signals don't need the resistor networks in the 
Spartan3.  You can generate an LVDS signal from pins marked as 
complementary pairs without any passives involved; a 100 ohm 
differential termination at the differential ADC clock is still 
important.  The ideal situation would have these signals routed next to 
each other with specific differential impedances but I expect your best 
bet will be to find the complementary signals that don't have anything 
else routed between and are roughly the same length.  There might not be 
a lot to choose from.

If I recall, the Digilent Spartan3 board has a 40-pin header with one 
power and one ground  (or similarly abysmal path for return currents. 
The header you connect to might be responsible for introducing most of 
your system jitter per Gabor's comments on return current.  If you have 
many unused signals on that connector, driving them to output logic low 
with a strong IOBSTANDARD will help.  Changing them to hard wired 
grounds would be better still.  I believe the ribbon cable helps add to 
the size of the crosstalk effects so keeping that short will also help. 
  But the differential clock is that much more attractive.

You might consider using a "dead bug" addition to your Digilent board. 
There are small differential drivers available.  If you tack the chip 
upside down by the oscillator (imagine a bug with its legs in the air) 
you can wire the oscillator output right to the discrete differential 
driver input.  Use a twisted pair to deliver this clock directly to a 
2-pin header on your ADC board.  If you're not designing the board and 
it already has only a single-ended input, you can tack a differential 
receiver to your ADC board in the same way.  If you use this approach to 
deliver a very clean clock (making up for a poorly designed signal 
header) consider hot-gluing or epoxying the twisted pair to the board so 
you have a mechanical strain relief that keeps the wires from ripping 
off your tacked-on chip.

<snip>
> That's good to know. I wonder if I should still worry about routing the
> clock through the FPGA's output header to drive the ADC. Perhaps there
> would be added jitter due to other reasons, such as active switching
> flip-flops near the driving IOB... ? I'm basically repeating this from
> another post I've read, I don't know what order of noise we're talking
> about here, and whether it's negligible compared to my poor oscillator.

If you're using "mild" I/O switching strengths, you'll be better off 
than using strong drives.  If you look at the data sheet for SSO 
recommendations, you'll see which standards tend to be nasty and which 
"play nice."  If you're dealing with inputs rather than outputs, things 
will be much better - it's the current surge from driving the outputs 
that cause the majority of the jitter-inducing crosstalk.

<snip>
<snip>
> Ah yes, a timing budget is something I will be doing. Of course, the
> rest of my design isn't finished yet, so I don't yet know what type of
> max setup times I'll need. I guess if I use input buffers (using
> IOB's), the setup time to get the data into the FPGA will be
> independent of the rest of my design, right? I've never touched any IOB
> features before, but it seems easy (just set a single attribute, I
> think...?).

If you arrange the design to register the ADC outputs directly in the 
FPGA's IOBs, you can find the setup and hold times in the Spartan3 data 
sheet without having to look at the Timing Analyzer report.  Even when I 
specify register packing in IOBs and use input registers, I still use 
OFFSET IN (BEFORE) constraints on my input signals to get a very big 
warning if something didn't end up in the IOB like I planned.

> On the other hand, couldn't I avoid the issue altogether by using a DCM
> to adjust my FPGA clock by the clock-to-out time of the ADC? That way,
> the data is ready right on the rising edge of my FPGA clock. It seems
> that I can make adjustments in increments of 1/256 of my clock
> frequency.

The DCM gives you flexibility.  But when you do your timing budget, you 
might find there's a better way to reduce the uncertainties rather than 
just shifting the clock by the reported delay.  The shift might be close 
to optimal but the delay is specified as a worst case, not typical. 
When you have a "best clock scheme" figured out and the DCM isn't 
*between* the oscillator and the ADC, you might get better results with 
the DCM but not necessarily withe any added phase shift.

<snip>
> So in essence, by sampling at 50 MSPS rather than the minimum of 8.4
> MSPS, and then applying a low pass with cutoff around 4.2 MHz, I'm
> getting rid of about (25-4.2)/25 * 100% = 83% of the noise to to jitter
> on the ADC clock (assuming the noise content is uniformly distributed
> from 0 to 25 MHz)... Does that calculation sound right (assumes ideal
> filters, etc)? If so, what a pleasant surprise!

It *sounds* right but I haven't been performing these calculations 
myself recently so my view from 20,000 feet says it's pretty reasonable.

>> You seem on target with knowing much of what to look for in the design.
>>  I hope it's fun.
> 
> I appreciate the kind words, though I think I'm right on the borderline
> capability-wise. Let's hope I'm not right below that line - close
> enough to waste a lot of time, but just too far to ever get it working!
> But yes, it should be a fun project.
> 
> The info you gave was very helpful, thanks!
> 
> Regards,
> 
> Sean

Article: 113263
Subject: Re: Opencores DDR SDRAM controller
From: "cippalippa" <menchinidaniele@tiscali.it>
Date: 9 Dec 2006 11:30:44 -0800
Links: << >>  << T >>  << A >>

Tommy Thorn ha scritto:


> > > Maybe I misunderstood, but it already does synthesize. David Ashley, as
> > > posted here earlier, did the needed modification to get it running on
> > > the Spartan 3E Start Kit. With just a .ucf adjustment, it worked on
> > > Digilent's Spartan 3E1600 board.

Hi,

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 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: 113264
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 09 Dec 2006 19:50:00 GMT
Links: << >>  << T >>  << A >>
sp_mclaugh@yahoo.com wrote:
> John_H wrote:
> 
> Regarding the frequency range of noise due to sample clock jitter
> (sampling using an ADC much faster than required for a given
> band-limited signal):
> 
>> Since the noise you'll see from the clock jitter will be spread across
>> the full 25 MHz bandwidth of your 50 MS/s data stream
> 
> On a second reading, I was wondering if you could explain this a bit
> further. In the worst-case scenario, we would have an input signal with
> a purely 4.2 MHz frequency component (would never happen for video, but
> just for the arguement). If two samples were taken, each experiencing
> maximum sample clock jitter, but in opposite directions, then they
> would be seperated by (sample time + 2 * jitter). However, we would
> treat them as if they were seperated by only (sample time).
> 
> Wouldn't this only introduce noise up to a frequency of:
> 4.2 MHz * (sample time + 2 * jitter) / (sample time) ?
> 
> ie, for 250 ps of jitter on a 20 ns clock, with a 4.2 MHz signal being
> sampled, I could expect to see noise up to 4.305 MHz...?

The jitter introduces amplitude errors, not frequency errors.  Any 
amplitude or frequency error can induce problems in the other domain 
(which is why the ADC frequency error - phase, actually - induces the 
amplitude error).  You're analyzing the signal as if it's in an ideal 
sampling domain so the errors will show up as amplitude noise.

> Or, instead of assuming an input with a purely 4.2 MHz component, go to
> the other extreme. Assume the input is a constant DC signal. The jitter
> on the sampling clock wouldn't cause any noise at all here, would it?

The jitter won't induce noise on the DC signal, correct.  Great 
observation.  You still get the benefit of the ADC noise being reduced 
at DC.

> Please excuse the simple question, this is probably something
> elementary, but it's new to me!
> 
> Sean

If you were to only sample at 8.4 MS/s, your 4.2 MHz sinewave would have 
maximum sample errors at the highest slew of the signal with maximum 
deviations that constructively add to produce the maximum error.  When 
you have a 50 MS/s stream looking at the 4.2 MHz signal, your maximum 
values are still the maximums but you throw many other samples in with 
that same period.  Each sample point will have similar noise power, but 
weighted by the signal slew rate; the top and bottom of the sinusoid are 
closer to DC for jitter analysis reasons so the noise power isn't 
constant for all sample points but significantly reduced in the slower 
slew regions.  Filtering over the wider bandwidth allows the worst 
sample errors to be filtered with the smallest sample errors leading to 
an overall reduction in jitter-induced noise.

I would expect most of your jitter to be high-frequency since you're 
coming from a crystal source with the induced noise coming from that 
"ideal" signal getting phase distortions through various buffer stages 
from the slight induced shifts of threshold point.  Higher frequency 
jitter is easier to remove from your overall system noise than low 
frequency jitter that induces real phase shifts in your observed data.

Article: 113265
Subject: Re: Xilinx MPMC2 "External Ports" question
From: "MM" <mbmsv@yahoo.com>
Date: Sat, 9 Dec 2006 15:05:51 -0500
Links: << >>  << T >>  << A >>
"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: 113266
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 09 Dec 2006 20:37:27 GMT
Links: << >>  << T >>  << A >>
"Gabor" <gabor@alacron.com> wrote:

>
>sp_mclaugh@yahoo.com wrote:
>> Hello,
>>
>> I'm in the middle of a project which involves digitizing and decoding
>> baseband NTSC composite video. Right off the top, I'll let everybody
>> know that this is part of an educational project (part of it for a
>> university project, though it's largely a hobbyist type project). I
>> realize that the project will be useless in a couple years, and that
>> there are pre-made devices out there, but I still want to do it.
>>
>> That being said, I think the hardest part of the whole project (for me)
>> is just getting the data into the FPGA (cleanly)! I know very little
>> about clock management, and I'm worried that I'm pushing the limits of
>> my setup. Let me briefly describe what I'm doing.
>>
>> The traditional way to sample NTSC video, as I understand it, is to use
>> dedicated chips to derive a "pixel clock" off of the hsync. This clock
>> then feeds the ADC, and perhaps the FPGA. I am not doing this. I am
>> using a fixed, free-running crystal oscillator clock (50 MHz Epson
>> SG-8002JF). For the record, that clock came on my Digilent Spartan 3
>> starter board, which I'm using for the project. I plan on sampling at
>> the full 50 MSPS, even though the video signal is band-limited to about
>> 4.2 MHz.
>>
>
>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.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 113267
Subject: Re: JTAG programming of Altera Cyclone and CONF_DONE
From: Marc Guardiani <news.guardiani@gmail.com>
Date: Sat, 09 Dec 2006 21:09:15 GMT
Links: << >>  << T >>  << A >>
Nevo wrote:
> Why is Quartus complaining that CONF_DONE isn't going high when that signal 
> isn't supposed to go to the programming header? More importantly, is there 
> anything I can do to circumvent this problem?

Quartus, using JTAG, can read the state of this pin without it having to 
be run to the header.

Break out the scope and connect it to CONF_DONE. Does it go high? If 
not, then the FPGA is not properly configured. This can be caused by a 
faulty JTAG connection, something holding CONF_DONE low, etc.

Marc

Article: 113268
Subject: Re: 50 MSPS ADC with Spartan 3 FPGA - clock issues
From: sp_mclaugh@yahoo.com
Date: 9 Dec 2006 15:23:29 -0800
Links: << >>  << T >>  << A >>
As for your previous post, I've got it printed up and sitting on my
workbench area. Lots of good info in there. I'll just respond to this
one for now.

John_H wrote:

> sp_mclaugh@yahoo.com wrote:

> > In the worst-case scenario, we would have an input signal with
> > a purely 4.2 MHz frequency component (would never happen for video, but
> > just for the arguement). If two samples were taken, each experiencing
> > maximum sample clock jitter, but in opposite directions, then they
> > would be seperated by (sample time + 2 * jitter). However, we would
> > treat them as if they were seperated by only (sample time).
> >
> > Wouldn't this only introduce noise up to a frequency of:
> > 4.2 MHz * (sample time + 2 * jitter) / (sample time) ?
> >
> > ie, for 250 ps of jitter on a 20 ns clock, with a 4.2 MHz signal being
> > sampled, I could expect to see noise up to 4.305 MHz...?
>
> The jitter introduces amplitude errors, not frequency errors.  Any
> amplitude or frequency error can induce problems in the other domain
> (which is why the ADC frequency error - phase, actually - induces the
> amplitude error).  You're analyzing the signal as if it's in an ideal
> sampling domain so the errors will show up as amplitude noise.

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?

> > Or, instead of assuming an input with a purely 4.2 MHz component, go to
> > the other extreme. Assume the input is a constant DC signal. The jitter
> > on the sampling clock wouldn't cause any noise at all here, would it?
>
> The jitter won't induce noise on the DC signal, correct.  Great
> observation.  You still get the benefit of the ADC noise being reduced
> at DC.

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?

> If you were to only sample at 8.4 MS/s, your 4.2 MHz sinewave would have
> maximum sample errors at the highest slew of the signal with maximum
> deviations that constructively add to produce the maximum error.

Yes, I think we are talking about the same thing (compare to what I
mentioned above). ie, the first sample is jittered so that it occurs
too early, while the second occurs too late -- and all of this
happening where slew is the highest.

> When
> you have a 50 MS/s stream looking at the 4.2 MHz signal, your maximum
> values are still the maximums but you throw many other samples in with
> that same period.  Each sample point will have similar noise power, but
> weighted by the signal slew rate; the top and bottom of the sinusoid are
> closer to DC for jitter analysis reasons so the noise power isn't
> constant for all sample points but significantly reduced in the slower
> slew regions.  Filtering over the wider bandwidth allows the worst
> sample errors to be filtered with the smallest sample errors leading to
> an overall reduction in jitter-induced noise.

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.

> I would expect most of your jitter to be high-frequency since you're
> coming from a crystal source with the induced noise coming from that
> "ideal" signal getting phase distortions through various buffer stages
> from the slight induced shifts of threshold point.  Higher frequency
> jitter is easier to remove from your overall system noise than low
> frequency jitter that induces real phase shifts in your observed data.

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

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... ?


Article: 113269
Subject: impossible opb_emc hack?
From: "Anonymous" <someone@microsoft.com>
Date: Sun, 10 Dec 2006 00:10:21 GMT
Links: << >>  << T >>  << A >>
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



Article: 113270
Subject: Re: How to develop custom opb devices for Microblaze?
From: Ben Jackson <ben@ben.com>
Date: Sat, 09 Dec 2006 19:01:14 -0600
Links: << >>  << T >>  << A >>
On 2006-12-09, beagle197@hotmail.com <beagle197@hotmail.com> wrote:
> to develop a custom data encoder(*3) Verilog module that can be
> accessed via C, and I am trying to determine if developing the module
> as device that attaches to the OPB would be a good choice of

There's a Xilinx IP block called opb_ipif (IP interface) specifically
for this.  If you're using XPS there's a wizard to make IP blocks and
one of the steps will offer to drag one of these in for you.

The OBP BRAM block is just a thin layer between a BRAM and an opb_ipif,
for example.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 113271
Subject: Re: impossible opb_emc hack?
From: Ben Jackson <ben@ben.com>
Date: Sat, 09 Dec 2006 19:07:57 -0600
Links: << >>  << T >>  << A >>
On 2006-12-10, Anonymous <someone@microsoft.com> wrote:
> 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.

Write a wrapper that muxes your data bus by looking at the chip enable
lines from the EMC.  You'll need to connect to the Mem_DQ_I/O/T (at
least in Verilog, maybe VHDL can mux an inout?) rather than the Mem_DQ_IO.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 113272
Subject: Re: JTAG programming of Altera Cyclone and CONF_DONE
From: "Rob" <robnstef@frontiernet.net>
Date: Sun, 10 Dec 2006 02:46:31 GMT
Links: << >>  << T >>  << A >>
Nevo,

I'm not sure if you're using a development board or a board designed by you, 
but the CONF_DONE needs to have an external pull-up on the board.

What is the mode of configuration? What are you using for your configuration 
device?

Rob

"Nevo" <nevo_n@hotmail.com> wrote in message 
news:SmCeh.122$495.9@trnddc06...
> All,
>
> I'm having an extraoridnarily difficult time with my first FPGA project 
> and am very frustrated.
>
> I have a board designed around the EP1C6 Cyclone device. The Quartus 
> programmer is able to detect the EP1C6 on a JTAG boundary scan. I'm able 
> to initiate programming the device over the JTAG port, but Quartus gives 
> me an error CONF_DONE failed to go high on device 1.
>
> I reviewed the Cyclone datasheet, and 13-19 in particular, "JTAG 
> Configuration of Single Cyclone FPGA."
>
> This diagram does not show CONF_DONE going to the programming header.
>
> Why is Quartus complaining that CONF_DONE isn't going high when that 
> signal isn't supposed to go to the programming header? More importantly, 
> is there anything I can do to circumvent this problem?
>
> Many thanks,
>
> -Nevo
> 



Article: 113273
Subject: Some questions about FFT implementation
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 9 Dec 2006 21:43:29 -0800
Links: << >>  << T >>  << A >>
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?
2.	a) Is the output of A/D converter fixed point (generally)? b) Then
only division can introduce floating point, right?
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?
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)?


Thanks,
Vitaliy


Article: 113274
Subject: Writing output signals to text file (VHDL)?
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 9 Dec 2006 21:52:06 -0800
Links: << >>  << T >>  << A >>
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;




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
2019JanFebMar2019

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