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
2017JanFebMarApr2017

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 150075

Article: 150075
Subject: Re: Multiple clock domains
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 09 Dec 2010 19:04:35 -0800
Links: << >>  << T >>  << A >>
On Thu, 9 Dec 2010 18:12:46 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>On Dec 8, 3:16pm, Vaughn <vaughnb...@gmail.com> wrote:
>> Replaying to the question below:
>>
>> > Does Altera check hold times?
>>
>> Yes, Altera tools check hold times. We check all timing constraints:
>> setup & hold, plus the asynchronous reset equivalents (recovery &
>> removal) at all timing corners (3 in our latest devices), with on-die
>> variation and jitter models applied at each corner. The corners cover
>> large, correlated variation, while the "within corner" min/max
>> variation and clock uncertainty models cover less correlated variation
>> and timing jitter.
>>
>> If TimeQuest says it works, and you have properly timing constrained
>> the design, it will be robust.
>>
>> Regards,
>>
>> Vaughn Betz
>> Altera
>
>Not trying to pick on Altera as I think this is a problem with all
>vendors' products.  But how do you verify that your timing constraints
>are correct?  It is easy to say that any part of a design will be
>correct if you have done your design work right.  But 90% of
>engineering is making sure that it is correct.  There are many
>different methods, techniques and tools to assist the process of
>verification for nearly every aspect of design work.  I don't know of
>any that will verify that your design is properly constrained for
>timing.
>
>I have never figured out why no one seems to see this as a problem.
>Is there something I am missing?

Maybe yes, maybe no. The simple fact is that if you design fully
synchronous systems with single clock, the only additional
constraint(s)  to clock period  you need are the external IO timing.
For most of the designs setting the clock period(s) is enough to
constrain all of your design (and with a DCM setting the period of the
input clock is enough most of the time too).
If, on the other hand, you have asynchronous clocks and/or resets,
multi-cycle paths, ripple clocks then you need to pay extra attention.
There are several tools which check for each of these conditions and
verify the timing constraints you set in flow but these tools are
quite expensisve and mostly (only?) used in ASIC flow. For FPGAs most
people seem to ignore these conditions and use the silicon to test
their designs. I am amazed that some people don't even simulate their
designs and go from editor to bit file directly and test on hardware.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 150076
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: Rob <nothear@nowhere.com>
Date: Thu, 09 Dec 2010 23:09:45 -0500
Links: << >>  << T >>  << A >>

On 12/9/2010 11:50 AM, Gabor wrote:
> On Dec 9, 11:02 am, "j."<garas....@gmail.com>  wrote:
>> Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
>> Serializer) to send data. Unfortunately it also sends start and stop
>> bits, 12-bit each word total (@480MHz). Task is to build a receiver in
>> FPGA. However, both Xilinx and Altera built-in SERDES circuits support
>> only 10-bit words ("deserialization factor"). Is there any way to
>> interface them with the above DS92LV1021 chip?
>
> Many of the newer Xilinx chips can do deserialization at these rates
> using standard
> I/O's rather than the "GTP" or "Rocket I/O".  I expect newer Altera
> parts can do the
> same.  For Xilinx there are some app notes on "high-speed LVDS" you
> can look for
> on their site.
>
> -- Gabor

Be careful here, this chip embeds the clock in the data stream.  In 
other words, it does not send a separate synchronous clock along with 
the serialized data.

You will be forced into an FPGA that has something like a DPA (dynamic 
phase aligner) to find the eye of the data and extract a clock. 
Typically it is the higher end family of FPGA's that offer these types 
of interfaces, but they come with a high price tag.

It might just be more cost effective to use the receiver chip by 
National and go into your FPGA with parallel data.  You could then 
easily get into a very cost effective FPGA.

Rob


Article: 150077
Subject: Re: Multiple clock domains
From: rickman <gnuarm@gmail.com>
Date: Thu, 9 Dec 2010 21:17:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 9, 10:04=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Thu, 9 Dec 2010 18:12:46 -0800 (PST), rickman <gnu...@gmail.com>
> wrote:
>
>
>
> >On Dec 8, 3:16 pm, Vaughn <vaughnb...@gmail.com> wrote:
> >> Replaying to the question below:
>
> >> > Does Altera check hold times?
>
> >> Yes, Altera tools check hold times. We check all timing constraints:
> >> setup & hold, plus the asynchronous reset equivalents (recovery &
> >> removal) at all timing corners (3 in our latest devices), with on-die
> >> variation and jitter models applied at each corner. The corners cover
> >> large, correlated variation, while the "within corner" min/max
> >> variation and clock uncertainty models cover less correlated variation
> >> and timing jitter.
>
> >> If TimeQuest says it works, and you have properly timing constrained
> >> the design, it will be robust.
>
> >> Regards,
>
> >> Vaughn Betz
> >> Altera
>
> >Not trying to pick on Altera as I think this is a problem with all
> >vendors' products. =A0But how do you verify that your timing constraints
> >are correct? =A0It is easy to say that any part of a design will be
> >correct if you have done your design work right. =A0But 90% of
> >engineering is making sure that it is correct. =A0There are many
> >different methods, techniques and tools to assist the process of
> >verification for nearly every aspect of design work. =A0I don't know of
> >any that will verify that your design is properly constrained for
> >timing.
>
> >I have never figured out why no one seems to see this as a problem.
> >Is there something I am missing?
>
> Maybe yes, maybe no. The simple fact is that if you design fully
> synchronous systems with single clock, the only additional
> constraint(s) =A0to clock period =A0you need are the external IO timing.

That's a pretty big simplification.  The fact that you have a single
clock does not mean that your entire design runs in one clock cycle.
One of the trickier parts of timing constraints is getting the right
clock timing applied to the right sections of logic in a design.  In
any given design I have large amounts of logic that run at many clock
cycles multiples.  If I try to spec these multi-clock sections I run
the risk of under-constraining some part of the design I didn't intend
to apply that constraint to.  To the best of my knowledge there is no
way to verify that my timing constraints are correct.


> For most of the designs setting the clock period(s) is enough to
> constrain all of your design (and with a DCM setting the period of the
> input clock is enough most of the time too).
> If, on the other hand, you have asynchronous clocks and/or resets,
> multi-cycle paths, ripple clocks then you need to pay extra attention.

"Pay extra attention"... that is what it is all about.  I can pay tons
of attention, but I make mistakes... even when I'm not posting to
newsgroups late at night.  The hard part of engineering is figuring
out ways of catching those mistakes.  I am talking about the nearly
total lack of verification of timing constraints.  Bad constraints can
create some of the worst intermittent bugs you have ever seen.


> There are several tools which check for each of these conditions and
> verify the timing constraints you set in flow but these tools are
> quite expensisve and mostly (only?) used in ASIC flow. For FPGAs most
> people seem to ignore these conditions and use the silicon to test
> their designs. I am amazed that some people don't even simulate their
> designs and go from editor to bit file directly and test on hardware.

I've never seen any of these tools, but maybe that's because I work
with FPGAs.  Testing timing in silicon is not a very good way to
verify constraints.  To properly test timing you would need to get
your hands on the slowest chips that meet the specs, drop the power
supply voltage to the minimum level and then heat them up to the max
operating temp.  Only then can you say your timing is correct by
testing.  I had to do this once when I worked with routing and timing
tools that didn't properly estimate timing... we suspected on high
fanout nets.  Even when the tools said we met timing, the design could
fail on the bench and guess what made them work... cold spray!  The
vendor suspected... guess what... our timing constraints!  We bought a
chip heater and tested at elevated temp with a lowered Vdd and used
the worst speed chips we could find.  The product shipped, but only
after many long weeks of over time!

As to not simulating, that is the lazy man carrying the heavy load.
They think it will be fewer trips, but in the end it costs dearly.  I
am mostly satisfied that my designs work perfectly (except for spec
errors) when I try them on the bench.  Simulation just makes life so
much easier!  In fact, my simulations are as complex as the design
being tested!

Rick

Article: 150078
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Fri, 10 Dec 2010 00:52:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On 9 Dez., 17:02, "j." <garas....@gmail.com> wrote:
> Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
> Serializer) to send data. Unfortunately it also sends start and stop
> bits, 12-bit each word total (@480MHz). Task is to build a receiver in
> FPGA. However, both Xilinx and Altera built-in SERDES circuits support
> only 10-bit words ("deserialization factor"). Is there any way to
> interface them with the above DS92LV1021 chip?

The 12 bit word length is a non issue: use a 6x deserializer. You get
your 12 bit word as two 6 bit nibbles. Piece of cake.
However, the clock recovery that the other poster talks about is more
difficult.
Without a PLL or other specialized support circuitry you would need 3x
oversampling to recover the clock and phase reliably in a digital
circuit.
Therefore you end up at 1440Mbps, which is just out of reach for a
virtex-5 (710MHz fmax = 1420Mbps).
With 103% VCC you should be OK on a virtex-5.

Kolja

Article: 150079
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: "j." <garas.rez@gmail.com>
Date: Fri, 10 Dec 2010 02:50:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Thank you for the answers.

> Be careful here, this chip embeds the clock in the data stream. =A0In
> other words, it does not send a separate synchronous clock along with
> the serialized data.

Actually, AFAIK this "embedded clock" is indeed derived from the
start-stop bit. To get synchronized the transmitter needs to issue
some kind of synchronization pattern, I can imagine simply "all
ones".
In this case the stop bit is the only zero in the data stream, can be
used to start synchronization.


> You will be forced into an FPGA that has something like a DPA (dynamic
> phase aligner) to find the eye of the data and extract a clock.
> Typically it is the higher end family of FPGA's that offer these types
> of interfaces, but they come with a high price tag.

In my case the situation is a bit easier, both the transmitter and
the receiver uses the same clock source, thus the frequency
is always the same, the phase might be different (even for
the data channels, as the wires have slightly different length)
but constant. Thus if the correct phase has been established
it remains correct.

Of course in presence of a considerable jitter the phase needs
to get realigned in some way.


> It might just be more cost effective to use the receiver chip by
> National and go into your FPGA with parallel data. =A0You could then
> easily get into a very cost effective FPGA.

The problem is that the FPGA should receive data from 96 similar
10:1 LVDS Channels. There is no board space for 96 National chips.

In addition no FPGA has 96 independent embedded PLLs.

Janos



Article: 150080
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 10 Dec 2010 10:52:58 +0000
Links: << >>  << T >>  << A >>
"j." <garas.rez@gmail.com> writes:

> Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
> Serializer) to send data. Unfortunately it also sends start and stop
> bits, 12-bit each word total (@480MHz). Task is to build a receiver in
> FPGA. However, both Xilinx and Altera built-in SERDES circuits support
> only 10-bit words ("deserialization factor"). Is there any way to
> interface them with the above DS92LV1021 chip?

I have done this for a very similar link (just in LUTs) in a Spartan3E
at 27MHz, IIRC it would probably go to 30ish MHz - pushing it to 40MHz
would be beyond it.

I also had the benefit of enough control of the system to get it to
send a series of all-zeros words at startup which made finding the
sampling point much easier!

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 150081
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: Thomas Entner <thomas.entner99@gmail.com>
Date: Fri, 10 Dec 2010 03:03:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On 10 Dez., 09:52, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> On 9 Dez., 17:02, "j." <garas....@gmail.com> wrote:
>
> > Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
> > Serializer) to send data. Unfortunately it also sends start and stop
> > bits, 12-bit each word total (@480MHz). Task is to build a receiver in
> > FPGA. However, both Xilinx and Altera built-in SERDES circuits support
> > only 10-bit words ("deserialization factor"). Is there any way to
> > interface them with the above DS92LV1021 chip?
>
> The 12 bit word length is a non issue: use a 6x deserializer. You get
> your 12 bit word as two 6 bit nibbles. Piece of cake.
> However, the clock recovery that the other poster talks about is more
> difficult.
> Without a PLL or other specialized support circuitry you would need 3x
> oversampling to recover the clock and phase reliably in a digital
> circuit.
> Therefore you end up at 1440Mbps, which is just out of reach for a
> virtex-5 (710MHz fmax = 1420Mbps).
> With 103% VCC you should be OK on a virtex-5.
>
> Kolja

We are successfully deserializing a 60MWord/s (720Mbps) data-stream
with a Cyclone III by using DPA. However, it is tricky and we do also
not achieve the same cable-length as with the National deserializer
(but reasonable lengths). So if there is no real requirement (cost,
space) to get rid of the external deserializer, it will be the easier
option to use the dedicated chip.

Thomas

www.entner-electronics.com

Article: 150082
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: Thomas Entner <thomas.entner99@gmail.com>
Date: Fri, 10 Dec 2010 03:08:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On 10 Dez., 11:50, "j." <garas....@gmail.com> wrote:

> In my case the situation is a bit easier, both the transmitter and
> the receiver uses the same clock source, thus the frequency
> is always the same, the phase might be different (even for
> the data channels, as the wires have slightly different length)
> but constant. Thus if the correct phase has been established
> it remains correct.
>

This should make things much easier, especially if you have the same
routing-delay on all channels. It would be difficult if you have to
sample the channels all on a different phase (maybe you could adjust
the phase on the transmitter side).

Thomas

www.entner-electronics.com

Article: 150083
Subject: Re: LPDDR on spartan-3e
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 10 Dec 2010 12:25:45 GMT
Links: << >>  << T >>  << A >>
jonpry <jonpry@gmail.com> wrote:

>> Cant say I am a great fan of MIG. The design seems incredibly bloated and
>> not very easy to get to run at a reasonable speed. I ended up writing my
>> own DDR2 controller.
>> You should check that MIG and the device allows you to run at such a slow
>> speed. You really need a good simulation to start with all timings
>> verified. Check the datasheet to verify that no timings are being violated.
>> Can you not look at the data on a scope to see if you are getting the
>> correct signals and verify timing? Memory can be a pain to get working so
>> you need to be as meticulous as possible.
>
>The MIG controller is a bit complicated, but it does appear to be the
>correct architecture for LPDDR parts. On the scope I can see that the
>memory is indeed working properly, so its timings must be fine.
>Whether or not the memory is meeting the fpga's timing is a different
>story.

MIG is way too bloated especially on Spartan devices.

>I've managed to confirm that what is happening in simulation when
>clock is slower than 12ns, is indeed what is happening in hardware at
>any speed from 10 to 100 mhz.  I guess I will need to rewrite the dqs
>fifo enable stuff. I think if dqs comes after some margin the logic is
>just broken and won't turn off.
>
>> They do _not_ have delay-locked
>> loops in them, so read timing almost works better using your internal
>> clock than the DQS signal.
>
>This argument seems backwards to me. There is almost no point on using
>DQS on regular DDR parts because the the DLL phase aligns it to the
>master clock, giving you a multitude of good options. But with no DLL,
>there is no phase guarantee, forcing you to use a truly source
>synchronous design.

There is a phase quarantee (if you clock the memory from the FPGA) but
you need to calculate it by yourself. On a Spartan 3e you should be
able to achieve 100 to 125MHz depending on the speed grade. An added
bonus of writing your own DDR controller is that you can use any I/O
pin to connect the memory.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 150084
Subject: Re: spacewire project on opencores.org
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 10 Dec 2010 06:57:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On 8 Dez., 20:10, Alessandro Basili <alessandro.bas...@cern.ch> wrote:
> after some struggles I have eventually found the time to revive an old
> project on opencores which hasn't been updated since a while:
>
> a spacewire link and router.
>
[..]
>
> Any feedback is appreciated.

I think spacewire is not the best example for open cores (At least
unless you manage to get ESA as co-supporter which is unlikely as ESA
has allready spacewire cores).
Open cores tend to have a lack in documentation and verification,
which is a no-go for developing space electronics.
Even if you target on public science projects it is very likely that
you need to ensure the "space-readiness" in many aspects for a core
before you can use it.

For spacewire interface I consider the effort to proof the quality of
a core clearly exceeding the effort for writting the core for your
own.

Are you firm with developing according to ECSS-Q 60 02? I would expect
a core development to be complaint to this before using it without
further quality checking in case of the core not beeing provided from
ESA for a ESA project.

In case of detailed questions you may also conntact me by sending an
email. You should change the receive-address to thomas
@domain_from_email when replying.

best regards Thomas

Article: 150085
Subject: Re: LPDDR on spartan-3e
From: jonpry <jonpry@gmail.com>
Date: Fri, 10 Dec 2010 07:23:59 -0800 (PST)
Links: << >>  << T >>  << A >>
> There is a phase quarantee (if you clock the memory from the FPGA) but
> you need to calculate it by yourself. On a Spartan 3e you should be
> able to achieve 100 to 125MHz depending on the speed grade. An added
> bonus of writing your own DDR controller is that you can use any I/O
> pin to connect the memory.

My board is not fully assembled yet. Normally the clock would be
supplied from the PLL's in an omap3 processor. But it is not populated
yet, so I am supplying the clock from off board. Living in the third
world, there is a shortage of clock sources at hand. I have a 50mhz
oscillator, and whatever i can synthesize on another fpga board. The
synthetic clocks do not seem to work at even 50mhz. So I'm going to
put off further speed testing until the clocking situation improves.
It may work for all I know. everything looks fine on the scope at
100mhz anyways.

Article: 150086
Subject: xilinx spartan 6 deserialization
From: Serkan <oktem@su.sabanciuniv.edu>
Date: Fri, 10 Dec 2010 07:38:56 -0800 (PST)
Links: << >>  << T >>  << A >>

    I just have 1 fast LVDS data line. I need to have 10 bits of data
in a register , every 5 clock cycles(DDR), coming from only 1
differential data line.

 Dear Gurus,

1-  Can I deserialize a 240 Mhz , LVDS, DDR input coming data using a
10:1 serdes ratio. (clk is also LVDS)
2-  I want to do it with data width = 1( D = 1), is it possible?
3-  Do I have to put delay to clk inputs. If not why is there a delay
element (IODELAY2) in xapp1064.pdf
4-  Do I have to use the pll concept. Is there any other solution?
5-  In the documentation of spartan 6 deserialization 16:1 is shown
but with a SDR rate. Can it be changed to DDR?


=================================================================

PS1:  I am using Spartan 6,  slx100, -3
PS2:  I checked xapp1064.pdf, ug381.pdf, ds162.pdf. I need more info
on IODELAY2 and ISERDES2.


best regards
Serkan

Article: 150087
Subject: Re: How to find latches in Xilinx ISE 10.1
From: "gcary" <greg@n_o_s_p_a_m.warp9td.com>
Date: Fri, 10 Dec 2010 11:10:13 -0600
Links: << >>  << T >>  << A >>
I found this thread when searching for a way to find a latch in my design. 
I discovered another very easy way to find latches in 10.1 of ISE.  I
placed and routed my design and then ran PlanAhead.  Go to Edit -> Find,
and choose "Instances".  The criteria should be "Type" "is" "Latch".  It
found the latch in the blink of an eye.  Turned out to be a Chipscope ILA
that had a latch in it.

Greg


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

Article: 150088
Subject: Re: LPDDR on spartan-3e
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 10 Dec 2010 19:16:02 GMT
Links: << >>  << T >>  << A >>
jonpry <jonpry@gmail.com> wrote:

>> There is a phase quarantee (if you clock the memory from the FPGA) but
>> you need to calculate it by yourself. On a Spartan 3e you should be
>> able to achieve 100 to 125MHz depending on the speed grade. An added
>> bonus of writing your own DDR controller is that you can use any I/O
>> pin to connect the memory.
>
>My board is not fully assembled yet. Normally the clock would be
>supplied from the PLL's in an omap3 processor. But it is not populated
>yet, so I am supplying the clock from off board. Living in the third
>world, there is a shortage of clock sources at hand. I have a 50mhz
>oscillator, and whatever i can synthesize on another fpga board. The
>synthetic clocks do not seem to work at even 50mhz. So I'm going to
>put off further speed testing until the clocking situation improves.
>It may work for all I know. everything looks fine on the scope at
>100mhz anyways.

Why aren't you using the clock multipliers in the Spartan3e? You can
feed it almost any clock you want and create any clock frequency you
need. If the memory is connected to the FPGA, you should also clock
the memory from the FPGA. This eliminates the clock input to the clock
net timing uncertainty.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 150089
Subject: Re: LPDDR on spartan-3e
From: jonpry <jonpry@gmail.com>
Date: Fri, 10 Dec 2010 13:46:07 -0800 (PST)
Links: << >>  << T >>  << A >>
> Why aren't you using the clock multipliers in the Spartan3e? You can
> feed it almost any clock you want and create any clock frequency you
> need. If the memory is connected to the FPGA, you should also clock
> the memory from the FPGA. This eliminates the clock input to the clock
> net timing uncertainty.

Mainly because the MIG design requires a CLK90, and there is no
CLKFX90. I think this is the root of the trouble. If I use a synthetic
clock from another fpga, it has DLL jitter in it, and although the DLL
in my design seems to stay locked for a few seconds while running on
such a source, things seem to not work quite right for that period of
time.

The memory is being clocked from the fpga, just I can't get a low
jitter input at anything other than 50mhz right now.

Article: 150090
Subject: Re: LPDDR on spartan-3e
From: jonpry <jonpry@gmail.com>
Date: Fri, 10 Dec 2010 14:04:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 10, 1:46=A0pm, jonpry <jon...@gmail.com> wrote:
> > Why aren't you using the clock multipliers in the Spartan3e? You can
> > feed it almost any clock you want and create any clock frequency you
> > need. If the memory is connected to the FPGA, you should also clock
> > the memory from the FPGA. This eliminates the clock input to the clock
> > net timing uncertainty.
>
> Mainly because the MIG design requires a CLK90, and there is no
> CLKFX90. I think this is the root of the trouble. If I use a synthetic
> clock from another fpga, it has DLL jitter in it, and although the DLL
> in my design seems to stay locked for a few seconds while running on
> such a source, things seem to not work quite right for that period of
> time.
>
> The memory is being clocked from the fpga, just I can't get a low
> jitter input at anything other than 50mhz right now.

I forgot to mention that for a time I tried cascaded DCM's in the one
fpga, but was not able to get it lock. Presumably I just did something
wrong, it was just easier to debug with the DLL's in different chips
because I am able to have a bank of different frequencies, and I just
plug in the wire and see what happens. Now that it is generally
working I suppose I could try cascaded DCM's again.

Article: 150091
Subject: Re: LPDDR on spartan-3e
From: Gabor <gabor@alacron.com>
Date: Fri, 10 Dec 2010 15:26:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 10, 5:04=A0pm, jonpry <jon...@gmail.com> wrote:
> On Dec 10, 1:46=A0pm, jonpry <jon...@gmail.com> wrote:
>
> > > Why aren't you using the clock multipliers in the Spartan3e? You can
> > > feed it almost any clock you want and create any clock frequency you
> > > need. If the memory is connected to the FPGA, you should also clock
> > > the memory from the FPGA. This eliminates the clock input to the cloc=
k
> > > net timing uncertainty.
>
> > Mainly because the MIG design requires a CLK90, and there is no
> > CLKFX90. I think this is the root of the trouble. If I use a synthetic
> > clock from another fpga, it has DLL jitter in it, and although the DLL
> > in my design seems to stay locked for a few seconds while running on
> > such a source, things seem to not work quite right for that period of
> > time.
>
> > The memory is being clocked from the fpga, just I can't get a low
> > jitter input at anything other than 50mhz right now.
>
> I forgot to mention that for a time I tried cascaded DCM's in the one
> fpga, but was not able to get it lock. Presumably I just did something
> wrong, it was just easier to debug with the DLL's in different chips
> because I am able to have a bank of different frequencies, and I just
> plug in the wire and see what happens. Now that it is generally
> working I suppose I could try cascaded DCM's again.

Cascading DCM's does not work particularly well.  There is more jitter
on the FX outputs of the DCM's than the CLK0, 90, 2X outputs.  The
second DCM therefore ends up with a jittery input clock.  If you want
to try cascading at 100 Mhz, just use the CLK2X output of the first
DCM to get a somewhat less jittery 100 Mhz and feed that into
the DCM for the 90 degree shift.  Unfortunately the Spartan 3 series
don't have PLL's, which would be a better choice for frequency
synthesis.

Regards,
Gabor

Article: 150092
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Fri, 10 Dec 2010 16:21:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On 10 Dez., 12:08, Thomas Entner <thomas.entne...@gmail.com> wrote:
> On 10 Dez., 11:50, "j." <garas....@gmail.com> wrote:
>
> > In my case the situation is a bit easier, both the transmitter and
> > the receiver uses the same clock source, thus the frequency
> > is always the same, the phase might be different (even for
> > the data channels, as the wires have slightly different length)
> > but constant. Thus if the correct phase has been established
> > it remains correct.
>
> This should make things much easier, especially if you have the same
> routing-delay on all channels. It would be difficult if you have to
> sample the channels all on a different phase (maybe you could adjust
> the phase on the transmitter side).

If the FPGA has access to the clock source of the serializer, only the
phase has
to be determined at the receiver. That is actually pretty easy if you
can set the transmitter
to a know training pattern.
If you have a CPU in your system you can write software that controls
the variable
phase shift of an IDELAY to search for the right phase. This can be
done one input
at a time. Once you know the correct delay setting for your 96 inputs
your are good to go.

At 480Mbps there is not much to worry about. We do that at 1250Mbps
and have a reliable
sampling window of quite a few delay taps.


Kolja
cronologic.de

Article: 150093
Subject: Re: LPDDR on spartan-3e
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 12 Dec 2010 09:25:47 GMT
Links: << >>  << T >>  << A >>
jonpry <jonpry@gmail.com> wrote:

>> Why aren't you using the clock multipliers in the Spartan3e? You can
>> feed it almost any clock you want and create any clock frequency you
>> need. If the memory is connected to the FPGA, you should also clock
>> the memory from the FPGA. This eliminates the clock input to the clock
>> net timing uncertainty.
>
>Mainly because the MIG design requires a CLK90, and there is no
>CLKFX90. I think this is the root of the trouble. If I use a synthetic

???? Read the spartan3e datasheet and user manual. The DCM has 90, 180
and 270 degrees phase shift outputs and the ability to shift these
clocks by small steps as well.

>clock from another fpga, it has DLL jitter in it, and although the DLL
>in my design seems to stay locked for a few seconds while running on
>such a source, things seem to not work quite right for that period of
>time.

The DLL jitter is somewhere around 100ps p-p maximum. If your design
fails by that marging you better not start producing it. The FPGA is
quite tolerant to input jitter BTW.

Your problem sounds like the pulses from your clock source are not
wide enough or otherwise distorted. Get a >400MHz scope and check
whether pulse widths and rise times are within the specs the FPGA
requires.

>The memory is being clocked from the fpga, just I can't get a low
>jitter input at anything other than 50mhz right now.

You can cascade DCMs as well but you should read the Xilinx
application notes to get it right.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 150094
Subject: Re: PCI Architecture Question for Data Acquisition Board
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 12 Dec 2010 13:29:33 +0000
Links: << >>  << T >>  << A >>
On Wed, 1 Dec 2010 13:16:19 -0800 (PST), Sink0 <sink00@gmail.com> wrote:

>>
>> As a note, while I haven't done any Linux driver development our former
>> programmer did. He said that LDD 3rd ed. is chock full o' both errata
>> and things that were only true under the 2.4 kernel, not 2.6.
>>
>> --
>> Rob Gaddi, Highland Technology
>> Email address is currently out of order- Hide quoted text -
>>
>> - Show quoted text -
>
>Haha thank you for the information. Can you point me any other good
>reference? Other than the drivers already placed on the linux?

You still need LDD, because it has a different perspective. But a better book by
far for 2.6 kernels is "Essential Linux Device Drivers" by Venkateswaran.

- Brian

Article: 150095
Subject: Re: xilinx spartan 6 deserialization
From: Lorenz Kolb <newsgroups.lorenz.expires20110801@lkmail.de>
Date: Mon, 13 Dec 2010 10:17:22 +0100
Links: << >>  << T >>  << A >>
Serkan wrote:
>     I just have 1 fast LVDS data line. I need to have 10 bits of data
> in a register , every 5 clock cycles(DDR), coming from only 1
> differential data line.
> 
>  Dear Gurus,
> 
> 1-  Can I deserialize a 240 Mhz , LVDS, DDR input coming data using a
> 10:1 serdes ratio. (clk is also LVDS)

240 MHz shouldn't be a problem for the Spartan 6 pins.

> 2-  I want to do it with data width = 1( D = 1), is it possible?

What's your question? Input or Output datawidth?
 From my understanding you want a 1 bit input (240 MBit/s) deserialized 
to 10 bit (@24 MBit/s) output, right?
Don't see any reason why this shouldn't work.

> 3-  Do I have to put delay to clk inputs. If not why is there a delay
> element (IODELAY2) in xapp1064.pdf

What's the protocol you use for clock recovery/synchronization?

> 4-  Do I have to use the pll concept. Is there any other solution?

Have a look at 
http://www.missinglinkelectronics.com/files/papers/MLE-TB20091127.pdf 
and XAPP224 respectively.
You will need some reference clock, and you will have to use a PLL or 
DCM somewhere in the system, to generate the right clock(s) from that 
reference.

> 5-  In the documentation of spartan 6 deserialization 16:1 is shown
> but with a SDR rate. Can it be changed to DDR?

So again: what's the point here? I still don't get what you are trying 
to do, but you might also be interested in XAPP460,

Lorenz

Article: 150096
Subject: Re: Brain Cramps...
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Mon, 13 Dec 2010 12:48:57 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> On Dec 2, 10:32 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>> rickman wrote:

>>
>> Of course, I'm sure this is all obvious to you and I realize that
>> it must have been my explanation that was inadequate. But there
>> really was no need for this confusion. You could have seen all
>> these things for yourself by just spending one minute to see
>> the screencast. Sigh.
> 
> I don't know what a screencast is

I'll hold your hand:

http://en.wikipedia.org/wiki/Screencast

> and I have never seen a sales tool
> that conveyed any useful info in 1 minute.

Look, I can assure you that many good engineers find such a
screencast very useful. I am also of the opinion that the
people who make such things, for people like you, through
hard work, deserve much better than this. Your prejudices
are so high that you don't even want to *try*, even though
it takes only a fraction of the time you spend on writing
posts with a much lower information content. Beats me.

Time to review good old school engineering practices.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Article: 150097
Subject: Re: PCI Architecture Question for Data Acquisition Board
From: "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 13 Dec 2010 06:14:10 -0600
Links: << >>  << T >>  << A >>
>On Wed, 1 Dec 2010 13:16:19 -0800 (PST), Sink0 <sink00@gmail.com> wrote:
>
>>>
>>> As a note, while I haven't done any Linux driver development our
former
>>> programmer did. �He said that LDD 3rd ed. is chock full o' both
errata
>>> and things that were only true under the 2.4 kernel, not 2.6.
>>>
>>> --
>>> Rob Gaddi, Highland Technology
>>> Email address is currently out of order- Hide quoted text -
>>>
>>> - Show quoted text -
>>
>>Haha thank you for the information. Can you point me any other good
>>reference? Other than the drivers already placed on the linux?
>
>You still need LDD, because it has a different perspective. But a better
book by
>far for 2.6 kernels is "Essential Linux Device Drivers" by Venkateswaran.
>
>- Brian
>

Hmm thank you! I just got that on my hands right now i will start reading
it as soon as possible.. end of year is always a hell haha.. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150098
Subject: Re: Lattice XO2 video
From: Antti <antti.lukats@googlemail.com>
Date: Mon, 13 Dec 2010 04:15:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 7, 12:56=A0am, Gabor <ga...@alacron.com> wrote:
> On Dec 6, 12:06=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
>
> > On Dec 6, 3:13=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
>
> > >http://www.youtube.com/watch?v=3Dh_USk-HNgPA&feature=3Dplayer_detailpa=
ge
>
> > > Come on X and A - spice up your promo =A0videos!
>
> > Everybody chooses what is important to them. =A0Some like snazzy videos=
,
> > some like to ship product to customers...
>
> Well, then Lattice is doing both. =A0Their policy on new part
> announcement is to wait until they have at least _some_ silicon available=
. =A0Xilinx is
> already announcing Virtex 8 while not shipping V7.

well this time Lattice has broken thee policy, there are no MachXO
parts shipping?

Antti





Article: 150099
Subject: Re: Interfacing DS92LV1021 with FPGA serdes
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 13 Dec 2010 13:36:28 +0000
Links: << >>  << T >>  << A >>
Kolja Sulimma <ksulimma@googlemail.com> writes:

> If the FPGA has access to the clock source of the serializer, only the
> phase has
> to be determined at the receiver. That is actually pretty easy if you
> can set the transmitter
> to a know training pattern.
> If you have a CPU in your system you can write software that controls
> the variable
> phase shift of an IDELAY to search for the right phase. This can be
> done one input
> at a time. Once you know the correct delay setting for your 96 inputs
> your are good to go.

Or if no CPU, then a small state machine can also do the job (either
sweeping an IDELAY, or in my case the variable phase-shift of a DCM).

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware



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
2017JanFebMarApr2017

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