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 152050

Article: 152050
Subject: Delta-Sigma in an FPGA
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Tue, 28 Jun 2011 09:34:38 -0700
Links: << >>  << T >>  << A >>
Hey all --

So I've got yet another project making me say "Gosh it'd be nice to be 
able to implement a DAC/ADC directly in the FPGA."  And so I looked 
around and found all the same white papers I always find wherein a 
first-order delta-sigma modulated ADC or DAC is implemented using only 
an FPGA and an RC filter.

I've done the DAC one before, but only in closed loop situations where 
the actual accuracy doesn't matter much.  Has anyone actually tried 
doing either of these in a real quantitative sense and gotten a feel for 
what sorts of results can be accomplished?

Offhand, it seems like if you managed 12 bits it'd be a miracle.  Even 
if you stabilized the power supply voltages (and had zero ground bounce 
induced by the rest of the logic), it seems like you'd need rise/fall 
symmetry into the femtoseconds on the digital outputs in order to not 
shoot your linearity.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 152051
Subject: Re: Delta-Sigma in an FPGA
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 28 Jun 2011 11:01:05 -0700
Links: << >>  << T >>  << A >>
On 06/28/2011 09:34 AM, Rob Gaddi wrote:
> Hey all --
>
> So I've got yet another project making me say "Gosh it'd be nice to be
> able to implement a DAC/ADC directly in the FPGA." And so I looked
> around and found all the same white papers I always find wherein a
> first-order delta-sigma modulated ADC or DAC is implemented using only
> an FPGA and an RC filter.
>
> I've done the DAC one before, but only in closed loop situations where
> the actual accuracy doesn't matter much. Has anyone actually tried doing
> either of these in a real quantitative sense and gotten a feel for what
> sorts of results can be accomplished?
>
> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even if
> you stabilized the power supply voltages (and had zero ground bounce
> induced by the rest of the logic), it seems like you'd need rise/fall
> symmetry into the femtoseconds on the digital outputs in order to not
> shoot your linearity.

I've done this exactly once -- I implemented a DAC that fed the 
ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors) 
and a little speaker out of my junk box.  I needed it to listen in on 
digital phone signals that I was decoding, and I have to say, the dial 
tone was unambiguous every time.

I suspect that if you wanted to do this for real it would be essential 
to use an external part for the 1-bit DAC element.  Up to some point you 
could probably get away with a single-gate 74xx04 -- something like an 
AHC or similar way-fast, way-high-drive family, operating into a fairly 
high impedance, should give you decent symmetry.

Power that part off of its very own, very quiet supply, be very careful 
with grounds, and you may be able to do astonishing things.  I think 12 
bits would come easily, and I'm willing to bet that 16 bits wouldn't be 
at all unachievable.  In fact, you may even be able to do something 
perverted like compensating for the analog asymmetry in digital-land, 
and push the thing up to 20 bits -- assuming that all the surrounding 
circuitry were good for that.

I do think that you'd want to go to at least a 2nd-order sigma-delta, 
however.

Patent the approach when you're done, and sell the IP on Xilinx's and 
Altera's IP store.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 152052
Subject: Re: XST 13.1 explodes with generic of enum type with only one member
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 28 Jun 2011 11:44:49 -0700
Links: << >>  << T >>  << A >>
On 06/27/2011 03:36 PM, Jonathan Bromley wrote:
> It was all going so well until I asked XST to compile a
> VHDL entity with a generic of this type:
>     type video_modes_e is (vesa_1024x768_65Hz);
> I guess I'll have more modes later, but just now I
> need only the one.  But as soon as I put a generic
> of type video_modes_e on any entity, I get
>     INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
> followed by nice friendly suggestions about filing a WebCase.
>
> Anyone else met this?  I fixed it by adding a dummy value to
> the enumeration, but that's a bit rubbish, isn't it?
>
> I'll file the case, but thought y'all might be interested.

Yes, it's a bit rubbish.  You'd expect tools to be able to gracefully 
handle this sort of thing.

But the pain involved in defining an element 
vesa_abnormal_brain_do_not_use or vesa_xst_sucks is pretty low, and if 
you choose the name right there's not much chance folks will mistake it 
for the real deal.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 152053
Subject: Re: Delta-Sigma in an FPGA
From: "Andrew Holme" <ah@nospam.com>
Date: Tue, 28 Jun 2011 21:18:07 +0100
Links: << >>  << T >>  << A >>

"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com...
> On 06/28/2011 09:34 AM, Rob Gaddi wrote:
>> Hey all --
>>
>> So I've got yet another project making me say "Gosh it'd be nice to be
>> able to implement a DAC/ADC directly in the FPGA." And so I looked
>> around and found all the same white papers I always find wherein a
>> first-order delta-sigma modulated ADC or DAC is implemented using only
>> an FPGA and an RC filter.
>>
>> I've done the DAC one before, but only in closed loop situations where
>> the actual accuracy doesn't matter much. Has anyone actually tried doing
>> either of these in a real quantitative sense and gotten a feel for what
>> sorts of results can be accomplished?
>>
>> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even if
>> you stabilized the power supply voltages (and had zero ground bounce
>> induced by the rest of the logic), it seems like you'd need rise/fall
>> symmetry into the femtoseconds on the digital outputs in order to not
>> shoot your linearity.
>
> I've done this exactly once -- I implemented a DAC that fed the ever-hi-fi 
> LM386 (or maybe it was an LM358 and a couple of transistors) and a little 
> speaker out of my junk box.  I needed it to listen in on digital phone 
> signals that I was decoding, and I have to say, the dial tone was 
> unambiguous every time.
>
> I suspect that if you wanted to do this for real it would be essential to 
> use an external part for the 1-bit DAC element.  Up to some point you 
> could probably get away with a single-gate 74xx04 -- something like an AHC 
> or similar way-fast, way-high-drive family, operating into a fairly high 
> impedance, should give you decent symmetry.

Or an LVDS line receiver

> Power that part off of its very own, very quiet supply,

Yep

>be very careful with grounds, and you may be able to do astonishing things.

LVDS helps here



Article: 152054
Subject: Re: XST 13.1 explodes with generic of enum type with only one member
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Tue, 28 Jun 2011 22:47:58 +0100
Links: << >>  << T >>  << A >>
On Tue, 28 Jun 2011 05:33:42 -0500, "RCIngham" wrote:

>... it's the sort of degenerate case that I would not
>expect many parsers to handle well. Did you simulate it?

I'm only slightly insulted :-)

Yes, I did, and it does.

Clearly this is a slightly odd case, but actually the idea
of an enum with only one value is far from crazy.  In this
case, I'm using the enum to index into a table of constant
records.  Consequently, if I add a dummy enum, I'm obliged
to add a dummy record too.  Evidently this problem will go
away of its own accord as soon as I have a second useful
entry in the table, but the broken parser/elaborator is
nevertheless disappointing - and it cost me a wasted 
evening on my little playtime project, an excuse to start
using VHDL and Xilinx tools again after a long absence
(and my first brush with ISE 13, which on balance seems
to be A Good Thing).
--
Jonathan Bromley

Article: 152055
Subject: Re: XST 13.1 explodes with generic of enum type with only one member
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Tue, 28 Jun 2011 22:57:38 +0100
Links: << >>  << T >>  << A >>
On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote:

>  I've always told people 

including me; and yes, I did listen at the time :-)

>it was safest to stick to generics that are
>integer (and subtypes thereof). Recently, I'd changed my tune, as
>various tools coped fine with boolean, enum, etc.. Now I will change my
>tune back again :-)

Well, I thought to myself "that Alan Fitch isn't 
mentoring me any more, so I am free to do all manner 
of wild and wacky things", and look where it got me...

>Generally broken stuff in XST can be worked around by writing a wrapper
>round the top level - which is also a bit rubbish I suppose.

Ho hum.  At least it's about four orders of magnitude less 
horrible than the day job's current concern, which is all
about what is or isn't a constant in SystemVerilog
covergroups.  Never in the field of, etc, etc, have
so many different tools given so many different
"not yet implemented" errors...
-- 
Jonathan Bromley

Article: 152056
Subject: Re: Delta-Sigma in an FPGA
From: Tim <tim@seemywebsite.please>
Date: Wed, 29 Jun 2011 00:50:43 -0500
Links: << >>  << T >>  << A >>
On Tue, 28 Jun 2011 21:18:07 +0100, Andrew Holme wrote:

> "Tim Wescott" <tim@seemywebsite.com> wrote in message
> news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com...
>> On 06/28/2011 09:34 AM, Rob Gaddi wrote:
>>> Hey all --
>>>
>>> So I've got yet another project making me say "Gosh it'd be nice to be
>>> able to implement a DAC/ADC directly in the FPGA." And so I looked
>>> around and found all the same white papers I always find wherein a
>>> first-order delta-sigma modulated ADC or DAC is implemented using only
>>> an FPGA and an RC filter.
>>>
>>> I've done the DAC one before, but only in closed loop situations where
>>> the actual accuracy doesn't matter much. Has anyone actually tried
>>> doing either of these in a real quantitative sense and gotten a feel
>>> for what sorts of results can be accomplished?
>>>
>>> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even
>>> if you stabilized the power supply voltages (and had zero ground
>>> bounce induced by the rest of the logic), it seems like you'd need
>>> rise/fall symmetry into the femtoseconds on the digital outputs in
>>> order to not shoot your linearity.
>>
>> I've done this exactly once -- I implemented a DAC that fed the
>> ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors)
>> and a little speaker out of my junk box.  I needed it to listen in on
>> digital phone signals that I was decoding, and I have to say, the dial
>> tone was unambiguous every time.
>>
>> I suspect that if you wanted to do this for real it would be essential
>> to use an external part for the 1-bit DAC element.  Up to some point
>> you could probably get away with a single-gate 74xx04 -- something like
>> an AHC or similar way-fast, way-high-drive family, operating into a
>> fairly high impedance, should give you decent symmetry.
> 
> Or an LVDS line receiver
> 
>> Power that part off of its very own, very quiet supply,
> 
> Yep
> 
>>be very careful with grounds, and you may be able to do astonishing
>>things.
> 
> LVDS helps here

Wow -- I hadn't even thought about clock jitter.  I should have, but I 
didn't.

I suppose if you _really_ wanted to do a hot-stuff job you'd take the 
modulator output from the FPGA and regenerate it with a way-clean clock.  
You'll end up with delay in your loop, but lose some noise.

You'd have to sit back and do some math to figure out what sort of 
performance could be hoped for from an any-old-which-way implementation.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Article: 152057
Subject: Re: XST 13.1 explodes with generic of enum type with only one member
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Wed, 29 Jun 2011 12:42:40 +0100
Links: << >>  << T >>  << A >>
On Tue, 28 Jun 2011 11:44:49 -0700, Tim Wescott wrote:

>vesa_abnormal_brain_do_not_use

heh.  Best laugh for days.  Walk this way!
-- 
Jonathan Bromley

Article: 152058
Subject: Re: XST 13.1 explodes with generic of enum type with only one member
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Wed, 29 Jun 2011 13:15:02 +0100
Links: << >>  << T >>  << A >>
On Mon, 27 Jun 2011 23:36:49 +0100, Jonathan Bromley wrote:

>It was all going so well until I asked XST to compile a 
>VHDL entity with a generic of this type:
>   type video_modes_e is (vesa_1024x768_65Hz);
>I guess I'll have more modes later, but just now I 
>need only the one.  But as soon as I put a generic 
>of type video_modes_e on any entity, I get
>   INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
[...]
>I'll file the case, but thought y'all might be interested.

Wow.  Serious kudos to Xilinx's support team.  I got an
intelligent, courteous response overnight, and then a 
real working fix three hours later.

The fix is to add 

  -use_new_parser yes

to the XST command line (or, equivalently, put it in
Synthesis Process Properties/Other XST Command Line Options).

Apparently it's the default if you're using newer devices,
though I haven't investigated that in detail.  I'm using
a heritage Spartan-3.

Problem solved, job done, happy customer.
-- 
Jonathan Bromley

Article: 152059
Subject: JESD204A and Spartan-6 GTPs
From: "YH" <y.hubert@n_o_s_p_a_m.btesa.com>
Date: Wed, 29 Jun 2011 09:59:23 -0500
Links: << >>  << T >>  << A >>
Hi,

I read the application note “Virtex-5 FPGA Interface to JESD204A
Compliant ADC”.

I’m designing a pcb with a JESD204A NXP DAC linked to Spartan-6 GTP Dual
tiles.

I try to know If I’m actually going to be able to implement this
interface in Spartan-6.
For example, in the application note, the REFCLKOUT is used to feed some
FPGA Logic (in Virtex-5) but I can read from UG386 p93(for Spartan-6) that
I should not use this  output…

In general terms, Is there any important difference between Virtex-5 and
Spartan-6 that would prevent me from implementing the JESD204A interface in
Spartan-6?

Thanks a lot for any indication that could help,

YH

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152060
Subject: Virtex 5 Rocket IO design for reading in ADC data.
From: "jgk2004" <john.kauffman@n_o_s_p_a_m.uni-ulm.de>
Date: Wed, 29 Jun 2011 09:59:29 -0500
Links: << >>  << T >>  << A >>
Hello all,

I am presently working with a virtix 5 FPGA and trying to get the rocket
IOs to work with reading in the data generated from my ADC. The ADC is
clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my data
4 bits transitioning at 250Mhz. I am then configuring the FPGA to store the
data after it has been serial to parallel converted within the FPGA then I
read it out later after it has taken the data so I can process my FFT in
matlab. My problem is I know my ADC is working since I first took the data
over a scope, but I want to speed up the measuring process by using a cool
and fancy FPGA. My question is, can any help me in setting up the rocket
IOs so ensure it does not miss any bits or transitions? If 1 in just 1000
samples it wrong my FFT is completely crap and I cant use it!

My present setup, which I have no clue if I am correct, is I use the
rockets to sync to the incoming data (250MHz bits) only ( not the output
clock). I then use the same clock recovered for the data to then clock the
data into memory. My question is, is there a better way to do this? Cant i
use my 500MHz clock to just clock the other data rocket IOs or since the
rocket IOs work off of a PLL, I cant do that.....

I feel this must be a standard thing in using the rocket IOs... I just
don't have any clue on the proper setup.  If anyone could help that would
be great!



Jgk

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152061
Subject: What's the black and while round on FPGA slice?
From: "chifalcon" <eric.he@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com>
Date: Wed, 29 Jun 2011 10:46:50 -0500
Links: << >>  << T >>  << A >>
Hi, 
  I implemented a full combinatinal logic in Xilinx FPGA. A white and black
eye appears on each SLICE. What does it means??

  Thanks	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152062
Subject: Re: Delta-Sigma in an FPGA
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Wed, 29 Jun 2011 09:18:36 -0700
Links: << >>  << T >>  << A >>
On 6/28/2011 10:50 PM, Tim wrote:
> On Tue, 28 Jun 2011 21:18:07 +0100, Andrew Holme wrote:
>
>> "Tim Wescott"<tim@seemywebsite.com>  wrote in message
>> news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com...
>>> On 06/28/2011 09:34 AM, Rob Gaddi wrote:
>>>> Hey all --
>>>>
>>>> So I've got yet another project making me say "Gosh it'd be nice to be
>>>> able to implement a DAC/ADC directly in the FPGA." And so I looked
>>>> around and found all the same white papers I always find wherein a
>>>> first-order delta-sigma modulated ADC or DAC is implemented using only
>>>> an FPGA and an RC filter.
>>>>
>>>> I've done the DAC one before, but only in closed loop situations where
>>>> the actual accuracy doesn't matter much. Has anyone actually tried
>>>> doing either of these in a real quantitative sense and gotten a feel
>>>> for what sorts of results can be accomplished?
>>>>
>>>> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even
>>>> if you stabilized the power supply voltages (and had zero ground
>>>> bounce induced by the rest of the logic), it seems like you'd need
>>>> rise/fall symmetry into the femtoseconds on the digital outputs in
>>>> order to not shoot your linearity.
>>>
>>> I've done this exactly once -- I implemented a DAC that fed the
>>> ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors)
>>> and a little speaker out of my junk box.  I needed it to listen in on
>>> digital phone signals that I was decoding, and I have to say, the dial
>>> tone was unambiguous every time.
>>>
>>> I suspect that if you wanted to do this for real it would be essential
>>> to use an external part for the 1-bit DAC element.  Up to some point
>>> you could probably get away with a single-gate 74xx04 -- something like
>>> an AHC or similar way-fast, way-high-drive family, operating into a
>>> fairly high impedance, should give you decent symmetry.
>>
>> Or an LVDS line receiver
>>
>>> Power that part off of its very own, very quiet supply,
>>
>> Yep
>>
>>> be very careful with grounds, and you may be able to do astonishing
>>> things.
>>
>> LVDS helps here
>
> Wow -- I hadn't even thought about clock jitter.  I should have, but I
> didn't.
>
> I suppose if you _really_ wanted to do a hot-stuff job you'd take the
> modulator output from the FPGA and regenerate it with a way-clean clock.
> You'll end up with delay in your loop, but lose some noise.
>
> You'd have to sit back and do some math to figure out what sort of
> performance could be hoped for from an any-old-which-way implementation.
>

And of course, as you start adding more external parts to the solution, 
the advantages in board space and cost over just buying a chip vanish.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 152063
Subject: Re: Delta-Sigma in an FPGA
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 29 Jun 2011 10:20:06 -0700
Links: << >>  << T >>  << A >>
On 06/29/2011 09:18 AM, Rob Gaddi wrote:
> On 6/28/2011 10:50 PM, Tim wrote:
>> On Tue, 28 Jun 2011 21:18:07 +0100, Andrew Holme wrote:
>>
>>> "Tim Wescott"<tim@seemywebsite.com> wrote in message
>>> news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com...
>>>> On 06/28/2011 09:34 AM, Rob Gaddi wrote:
>>>>> Hey all --
>>>>>
>>>>> So I've got yet another project making me say "Gosh it'd be nice to be
>>>>> able to implement a DAC/ADC directly in the FPGA." And so I looked
>>>>> around and found all the same white papers I always find wherein a
>>>>> first-order delta-sigma modulated ADC or DAC is implemented using only
>>>>> an FPGA and an RC filter.
>>>>>
>>>>> I've done the DAC one before, but only in closed loop situations where
>>>>> the actual accuracy doesn't matter much. Has anyone actually tried
>>>>> doing either of these in a real quantitative sense and gotten a feel
>>>>> for what sorts of results can be accomplished?
>>>>>
>>>>> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even
>>>>> if you stabilized the power supply voltages (and had zero ground
>>>>> bounce induced by the rest of the logic), it seems like you'd need
>>>>> rise/fall symmetry into the femtoseconds on the digital outputs in
>>>>> order to not shoot your linearity.
>>>>
>>>> I've done this exactly once -- I implemented a DAC that fed the
>>>> ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors)
>>>> and a little speaker out of my junk box. I needed it to listen in on
>>>> digital phone signals that I was decoding, and I have to say, the dial
>>>> tone was unambiguous every time.
>>>>
>>>> I suspect that if you wanted to do this for real it would be essential
>>>> to use an external part for the 1-bit DAC element. Up to some point
>>>> you could probably get away with a single-gate 74xx04 -- something like
>>>> an AHC or similar way-fast, way-high-drive family, operating into a
>>>> fairly high impedance, should give you decent symmetry.
>>>
>>> Or an LVDS line receiver
>>>
>>>> Power that part off of its very own, very quiet supply,
>>>
>>> Yep
>>>
>>>> be very careful with grounds, and you may be able to do astonishing
>>>> things.
>>>
>>> LVDS helps here
>>
>> Wow -- I hadn't even thought about clock jitter. I should have, but I
>> didn't.
>>
>> I suppose if you _really_ wanted to do a hot-stuff job you'd take the
>> modulator output from the FPGA and regenerate it with a way-clean clock.
>> You'll end up with delay in your loop, but lose some noise.
>>
>> You'd have to sit back and do some math to figure out what sort of
>> performance could be hoped for from an any-old-which-way implementation.
>>
>
> And of course, as you start adding more external parts to the solution,
> the advantages in board space and cost over just buying a chip vanish.

True.  But when you get right down to it, for an ADC just implementing 
the necessary op-amp integrator and comparator is going to rival an 
external ADC chip.

So maybe the thing to do is to figure out the best DAC that you can do 
with FPGA only, and leave it at that...

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 152064
Subject: Re: Virtex 5 Rocket IO design for reading in ADC data.
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Wed, 29 Jun 2011 12:45:49 -0500
Links: << >>  << T >>  << A >>
>Hello all,
>
>I am presently working with a virtix 5 FPGA and trying to get the rocket
>IOs to work with reading in the data generated from my ADC. The ADC is
>clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my
data
>4 bits transitioning at 250Mhz. I am then configuring the FPGA to store
the
>data after it has been serial to parallel converted within the FPGA then
I
>read it out later after it has taken the data so I can process my FFT in
>matlab. My problem is I know my ADC is working since I first took the
data
>over a scope, but I want to speed up the measuring process by using a
cool
>and fancy FPGA. My question is, can any help me in setting up the rocket
>IOs so ensure it does not miss any bits or transitions? If 1 in just 1000
>samples it wrong my FFT is completely crap and I cant use it!
>
>My present setup, which I have no clue if I am correct, is I use the
>rockets to sync to the incoming data (250MHz bits) only ( not the output
>clock). I then use the same clock recovered for the data to then clock
the
>data into memory. My question is, is there a better way to do this? Cant
i
>use my 500MHz clock to just clock the other data rocket IOs or since the
>rocket IOs work off of a PLL, I cant do that.....
>
>I feel this must be a standard thing in using the rocket IOs... I just
>don't have any clue on the proper setup.  If anyone could help that would
>be great!
>
>
>
>Jgk
>
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

I am slightly confused as you are talking about LVDS and Rocket IO which
are not the same. Usually with ADC designs you would input the LVDS signals
from the ADC into the FPGA and use the ISERDES block clocked from the ADC
clock. You may also have to use some soft of calibartion scheme involving
an IDELAY block to ensure all bits are synchronised.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152065
Subject: Re: XST 13.1 explodes with generic of enum type with only one member
From: Alan Fitch <apf@invalid.invalid>
Date: Wed, 29 Jun 2011 19:37:53 +0100
Links: << >>  << T >>  << A >>
On 28/06/11 22:57, Jonathan Bromley wrote:
> On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote:
> 
<snip>
>> Generally broken stuff in XST can be worked around by writing a wrapper
>> round the top level - which is also a bit rubbish I suppose.
> 
> Ho hum.  At least it's about four orders of magnitude less 
> horrible than the day job's current concern, which is all
> about what is or isn't a constant in SystemVerilog
> covergroups.  Never in the field of, etc, etc, have
> so many different tools given so many different
> "not yet implemented" errors...

I am still confused by constantness (constantosity??) in SV. I tried
putting a const in a package, and then initialising another constant to
it in a module. Quartus threw it out as not constant. localparams seem
to work fine. I guess I've been mis-guided by VHDL

Alan

-- 
Alan Fitch

Article: 152066
Subject: Re: XST 13.1 explodes with generic of enum type with only one member
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Wed, 29 Jun 2011 21:09:14 +0100
Links: << >>  << T >>  << A >>
On Wed, 29 Jun 2011 19:37:53 +0100, Alan Fitch wrote:

>I am still confused by constantness (constantosity??) in SV.

Hmm, getting seriously OT here, but anyhow...

> I tried putting a const in a package, and then
> initialising another constant to
>it in a module. Quartus threw it out as not constant. localparams seem
>to work fine.

First thing to get straight is that const doesn't mean 
constant in SV; it's closer to "read-only".  Consts
can be initialised, but not altered after initialisation,
unless they're data members of a class in which case they
can be written only once in the class's constructor, or
they are ref arguments to a subprogram in which case
they refer to something that's read-only from the
subprogram's point of view.  In all these cases, the
things in question are variables, not constants.

Parameters and localparams, au contraire, are truly
constant (look for "constant expression" in 1800-2009).
Their value is determined during elaboration and is
immutable thenceforward.  This elaboration-time 
determination of value means that parameters, and
indeed constant expressions in general, can be used
to specify and control the attributes of a data type
such as bit-width.  Can't do that with a const.
Similarly, any attributes scavenged from a data type
such as $left() are also constant expressions.

And then, just for laughs, there are the rules about
constant expressions not being allowed to include
any hierarchical (cross-module) references.

Never mind, it could be worse.  I spent about four
months fighting the function/operator overload
resolution rules in C++ a little while ago.  That
was truly a nightmare.  Bring back VHDL...
-- 
Jonathan Bromley

Article: 152067
Subject: Re: Virtex 5 Rocket IO design for reading in ADC data.
From: "jgk2004" <john.kauffman@n_o_s_p_a_m.n_o_s_p_a_m.uni-ulm.de>
Date: Thu, 30 Jun 2011 01:00:53 -0500
Links: << >>  << T >>  << A >>
Hello Jon,

I have output LVDS drive on my asic chip which I am then interfacing to the
rocket IOs of the FPGA.  Sorry for the confusion. So you are saying thou
that I should not try any clock recoverary but just the clock from my asic?
 Is there anything else I would need to know to get this working properly?

Thanks so much

Jgk


>>Hello all,
>>
>>I am presently working with a virtix 5 FPGA and trying to get the rocket
>>IOs to work with reading in the data generated from my ADC. The ADC is
>>clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my
>data
>>4 bits transitioning at 250Mhz. I am then configuring the FPGA to store
>the
>>data after it has been serial to parallel converted within the FPGA then
>I
>>read it out later after it has taken the data so I can process my FFT in
>>matlab. My problem is I know my ADC is working since I first took the
>data
>>over a scope, but I want to speed up the measuring process by using a
>cool
>>and fancy FPGA. My question is, can any help me in setting up the rocket
>>IOs so ensure it does not miss any bits or transitions? If 1 in just
1000
>>samples it wrong my FFT is completely crap and I cant use it!
>>
>>My present setup, which I have no clue if I am correct, is I use the
>>rockets to sync to the incoming data (250MHz bits) only ( not the output
>>clock). I then use the same clock recovered for the data to then clock
>the
>>data into memory. My question is, is there a better way to do this? Cant
>i
>>use my 500MHz clock to just clock the other data rocket IOs or since the
>>rocket IOs work off of a PLL, I cant do that.....
>>
>>I feel this must be a standard thing in using the rocket IOs... I just
>>don't have any clue on the proper setup.  If anyone could help that
would
>>be great!
>>
>>
>>
>>Jgk
>>
>>	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>>
>
>I am slightly confused as you are talking about LVDS and Rocket IO which
>are not the same. Usually with ADC designs you would input the LVDS
signals
>from the ADC into the FPGA and use the ISERDES block clocked from the ADC
>clock. You may also have to use some soft of calibartion scheme involving
>an IDELAY block to ensure all bits are synchronised.
>
>Jon	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152068
Subject: Re: Virtex 5 Rocket IO design for reading in ADC data.
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Thu, 30 Jun 2011 02:48:26 -0500
Links: << >>  << T >>  << A >>
>Hello Jon,
>
>I have output LVDS drive on my asic chip which I am then interfacing to
the
>rocket IOs of the FPGA.  Sorry for the confusion. So you are saying thou
>that I should not try any clock recoverary but just the clock from my
asic?
> Is there anything else I would need to know to get this working
properly?
>
>Thanks so much
>
>Jgk
>
>
>>>Hello all,
>>>
>>>I am presently working with a virtix 5 FPGA and trying to get the
rocket
>>>IOs to work with reading in the data generated from my ADC. The ADC is
>>>clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my
>>data
>>>4 bits transitioning at 250Mhz. I am then configuring the FPGA to store
>>the
>>>data after it has been serial to parallel converted within the FPGA
then
>>I
>>>read it out later after it has taken the data so I can process my FFT
in
>>>matlab. My problem is I know my ADC is working since I first took the
>>data
>>>over a scope, but I want to speed up the measuring process by using a
>>cool
>>>and fancy FPGA. My question is, can any help me in setting up the
rocket
>>>IOs so ensure it does not miss any bits or transitions? If 1 in just
>1000
>>>samples it wrong my FFT is completely crap and I cant use it!
>>>
>>>My present setup, which I have no clue if I am correct, is I use the
>>>rockets to sync to the incoming data (250MHz bits) only ( not the
output
>>>clock). I then use the same clock recovered for the data to then clock
>>the
>>>data into memory. My question is, is there a better way to do this?
Cant
>>i
>>>use my 500MHz clock to just clock the other data rocket IOs or since
the
>>>rocket IOs work off of a PLL, I cant do that.....
>>>
>>>I feel this must be a standard thing in using the rocket IOs... I just
>>>don't have any clue on the proper setup.  If anyone could help that
>would
>>>be great!
>>>
>>>
>>>
>>>Jgk
>>>
>>>	   
>>>					
>>>---------------------------------------		
>>>Posted through http://www.FPGARelated.com
>>>
>>
>>I am slightly confused as you are talking about LVDS and Rocket IO which
>>are not the same. Usually with ADC designs you would input the LVDS
>signals
>>from the ADC into the FPGA and use the ISERDES block clocked from the
ADC
>>clock. You may also have to use some soft of calibartion scheme
involving
>>an IDELAY block to ensure all bits are synchronised.
>>
>>Jon	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

I am even more confused now as first you say you have an ADC and now you
say an ASIC. I think you need to specify exactly what you have. Is it an
ADC from say TI or is it a custom ASIC chip? Rocket IO do not even use LVDS
type signals so I dont really see what you are trying to do.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152069
Subject: Re: Virtex 5 Rocket IO design for reading in ADC data.
From: "jgk2004" <john.kauffman@n_o_s_p_a_m.n_o_s_p_a_m.uni-ulm.de>
Date: Thu, 30 Jun 2011 03:55:06 -0500
Links: << >>  << T >>  << A >>
Hello Jon,

I designed a custom ASIC sigma delta ADC and i do not decimate on chip.  so
thus my data is coming out on 4 bits at 250MHz (clocked at 500MHz).  On my
ASIC, i designed custom 1.2V LVDS drivers that need a 100ohm termination
off chip.  I am using the rocket IOs and terminating them internally by
programming them to have 100Ohm termination.  I then set the rocket IOs to
be lvds standard inputs.... which I think is correct to read in my data.  I
have to use the rocket IOs since my data is at 250MHz.....clocked at
500Mhz..  Am I doing anything wrong here?  What type of signals would you
normally use rocket IOs at... and even at high data rates.... I would think
lvds type signals...  Now what i think i am having trouble with is setting
up the syncing...

Is that alittle bit more clear?

Jgk



>>Hello Jon,
>>
>>I have output LVDS drive on my asic chip which I am then interfacing to
>the
>>rocket IOs of the FPGA.  Sorry for the confusion. So you are saying thou
>>that I should not try any clock recoverary but just the clock from my
>asic?
>> Is there anything else I would need to know to get this working
>properly?
>>
>>Thanks so much
>>
>>Jgk
>>
>>
>>>>Hello all,
>>>>
>>>>I am presently working with a virtix 5 FPGA and trying to get the
>rocket
>>>>IOs to work with reading in the data generated from my ADC. The ADC is
>>>>clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my
>>>data
>>>>4 bits transitioning at 250Mhz. I am then configuring the FPGA to
store
>>>the
>>>>data after it has been serial to parallel converted within the FPGA
>then
>>>I
>>>>read it out later after it has taken the data so I can process my FFT
>in
>>>>matlab. My problem is I know my ADC is working since I first took the
>>>data
>>>>over a scope, but I want to speed up the measuring process by using a
>>>cool
>>>>and fancy FPGA. My question is, can any help me in setting up the
>rocket
>>>>IOs so ensure it does not miss any bits or transitions? If 1 in just
>>1000
>>>>samples it wrong my FFT is completely crap and I cant use it!
>>>>
>>>>My present setup, which I have no clue if I am correct, is I use the
>>>>rockets to sync to the incoming data (250MHz bits) only ( not the
>output
>>>>clock). I then use the same clock recovered for the data to then clock
>>>the
>>>>data into memory. My question is, is there a better way to do this?
>Cant
>>>i
>>>>use my 500MHz clock to just clock the other data rocket IOs or since
>the
>>>>rocket IOs work off of a PLL, I cant do that.....
>>>>
>>>>I feel this must be a standard thing in using the rocket IOs... I just
>>>>don't have any clue on the proper setup.  If anyone could help that
>>would
>>>>be great!
>>>>
>>>>
>>>>
>>>>Jgk
>>>>
>>>>	   
>>>>					
>>>>---------------------------------------		
>>>>Posted through http://www.FPGARelated.com
>>>>
>>>
>>>I am slightly confused as you are talking about LVDS and Rocket IO
which
>>>are not the same. Usually with ADC designs you would input the LVDS
>>signals
>>>from the ADC into the FPGA and use the ISERDES block clocked from the
>ADC
>>>clock. You may also have to use some soft of calibartion scheme
>involving
>>>an IDELAY block to ensure all bits are synchronised.
>>>
>>>Jon	   
>>>					
>>>---------------------------------------		
>>>Posted through http://www.FPGARelated.com
>>>	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>>
>
>I am even more confused now as first you say you have an ADC and now you
>say an ASIC. I think you need to specify exactly what you have. Is it an
>ADC from say TI or is it a custom ASIC chip? Rocket IO do not even use
LVDS
>type signals so I dont really see what you are trying to do.
>
>Jon	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152070
Subject: Re: Virtex 5 Rocket IO design for reading in ADC data.
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Thu, 30 Jun 2011 05:26:34 -0500
Links: << >>  << T >>  << A >>
>Hello Jon,
>
>I designed a custom ASIC sigma delta ADC and i do not decimate on chip. 
so
>thus my data is coming out on 4 bits at 250MHz (clocked at 500MHz).  On
my
>ASIC, i designed custom 1.2V LVDS drivers that need a 100ohm termination
>off chip.  I am using the rocket IOs and terminating them internally by
>programming them to have 100Ohm termination.  I then set the rocket IOs
to
>be lvds standard inputs.... which I think is correct to read in my data. 
I
>have to use the rocket IOs since my data is at 250MHz.....clocked at
>500Mhz..  Am I doing anything wrong here?  What type of signals would you
>normally use rocket IOs at... and even at high data rates.... I would
think
>lvds type signals...  Now what i think i am having trouble with is
setting
>up the syncing...
>
>Is that alittle bit more clear?
>

You would normally use Rocket IO for signals that are in the GHz range.
LVDS on a Virtex 5 would easily handle a 250 MHz signal. Take a look at the
Xilinx website as they have some application notes on interfacing ADCs. You
do not want to be using Rocket IO for this type of application.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152071
Subject: Re: Virtex 5 Rocket IO design for reading in ADC data.
From: "jgk2004" <john.kauffman@n_o_s_p_a_m.n_o_s_p_a_m.uni-ulm.de>
Date: Thu, 30 Jun 2011 05:43:54 -0500
Links: << >>  << T >>  << A >>
Hello Jon,

So I do understand that 250MHz isn't fast, and the rocket IOs operate up to
3+GHz. The reason why I am using the rocket IOs now is because my next ASIC
will be clocked at 1GHz to 1.5GHz.... So I was thinking if I can get the
rocket ios working at 250MHz it should be problem reprogramming them to a
higher rate.

When you say that LVDS on the virtex 5 could easily be handled at 250MHz
would I then need a core clock at above 250MHz?  Also what is hte max LVDS
could be used on the virtex 5 without the rocket IOs? Can i use LVDS at
1GHz?

Jgk



>You would normally use Rocket IO for signals that are in the GHz range.
>LVDS on a Virtex 5 would easily handle a 250 MHz signal. Take a look at
the
>Xilinx website as they have some application notes on interfacing ADCs.
You
>do not want to be using Rocket IO for this type of application.
>
>Jon	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152072
Subject: Re: XST 13.1 explodes with generic of enum type with only one
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 30 Jun 2011 11:09:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Wed, 29 Jun 2011 13:15:02 +0100, Jonathan Bromley wrote:

> On Mon, 27 Jun 2011 23:36:49 +0100, Jonathan Bromley wrote:
> 
>>   INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
> [...]
>>I'll file the case, but thought y'all might be interested.
> 
> Wow.  Serious kudos to Xilinx's support team.  I got an intelligent,
> courteous response overnight, and then a real working fix three hours
> later.
> 
> The fix is to add
> 
>   -use_new_parser yes

AHA!

I had heard that XST13 used a new VHDL front end, and was dreading 
training it to understand code tweaked to suit old XST foibles.

If this is a problem with the old parser, that suggests older versions of 
XST might blow up in the same way. Have you tried XST12 or earlier?

Also it's good to know that both parsers are available in case of trouble.

> Apparently it's the default if you're using newer devices, though I
> haven't investigated that in detail.  I'm using a heritage Spartan-3.
> 
> Problem solved, job done, happy customer.

And if newer really = better, then kudos to the XST team.

I haven't got around to trying out my carefully cultivated nest of vipers 
on ISE13 yet.

- Brian

Article: 152073
Subject: Re: Virtex 5 Rocket IO design for reading in ADC data.
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Thu, 30 Jun 2011 06:47:51 -0500
Links: << >>  << T >>  << A >>
>Hello Jon,
>
>So I do understand that 250MHz isn't fast, and the rocket IOs operate up
to
>3+GHz. The reason why I am using the rocket IOs now is because my next
ASIC
>will be clocked at 1GHz to 1.5GHz.... So I was thinking if I can get the
>rocket ios working at 250MHz it should be problem reprogramming them to a
>higher rate.
>
>When you say that LVDS on the virtex 5 could easily be handled at 250MHz
>would I then need a core clock at above 250MHz?  Also what is hte max
LVDS
>could be used on the virtex 5 without the rocket IOs? Can i use LVDS at
>1GHz?
>
>Jgk

It seem to me as though you dont really understand the Virtex 5
architecture. You need to read the user guide and data sheet to get a feel
what is possible with a certain IO technology. Rocket IO uses CML type
drivers which are different to LVDS. LVDS upto 1.25 Gb/s is possible. 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152074
Subject: [ANNOUNCE] DSP-FPGA Programming Contest
From: DSPtronics <techsupport@dsptronics.com>
Date: Thu, 30 Jun 2011 07:37:50 -0500
Links: << >>  << T >>  << A >>
DPStronics (http://www.dsptronics.com) is hosting a design contest 
(http://dsptronics.webfactional.com).



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