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 127350

Article: 127350
Subject: FPGA program cable suggestion
From: taco <tralalal@joepie.nl>
Date: Wed, 19 Dec 2007 10:38:54 +0100
Links: << >>  << T >>  << A >>
Has any a good suggestion for a fpga program cable, which is known to work
with linux (64 bits)?
Thanks
T. 

Article: 127351
Subject: Xilinx's ML505
From: "John Aderseen" <John@Aderseen.com>
Date: Wed, 19 Dec 2007 11:09:33 +0100
Links: << >>  << T >>  << A >>
Hello group,

Anybody know if DAC plugin modules exist for the Xilinx ML505/ML506 board ?

Thanks,

John 



Article: 127352
Subject: Re: sampling error between 2 clocks
From: "RCIngham" <robert.ingham@gmail.com>
Date: Wed, 19 Dec 2007 05:18:30 -0600
Links: << >>  << T >>  << A >>
Why ask for expert help and refuse to try to see if the proferred answer
solves the problem?


Article: 127353
Subject: Emacs as GUI for NIOS-II
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Wed, 19 Dec 2007 12:43:20 +0100
Links: << >>  << T >>  << A >>

Which makefile should I use and where should the current working
directory be located if I want to run a NIOS-II software build from
the command line or emacs (linux or cygwin) rather than using Eclipse?

Have anybodu used Emacs/GUD to interface to the NIOS-II gdb debugger?

Thanks
Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 127354
Subject: Re: BGA reflow soldering using vapor phase
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 19 Dec 2007 04:10:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On 18 Dez., 20:07, kislo <kisl...@student.sdu.dk> wrote:
> I am doing some initial research regarding PCB design process with a
> Spartan3E (FT256) .. Have i understood it correctly that avnet are the
> only distributor of xilinx FPGA=B4s ? .. in that case, i can order a
> Spartan3E witch is not lead free .. and here comes the problem -> we
> have vapor phase equipment to solder the BGA on the PCB. This vapor
> phase machine uses liquid which reach 240degrees (Pb-free soldering),
> will this damage the non-Pb-free FPGA? If it does, i have to convince
> some ppl to buy some other liquid with lower vapor temperature :/
>
> I have read the Device Package Userguide (ug112), regarding the Reflow
> soldering process .. it dosent address the vapor phase process but i
> guess its the same as for a normal oven process? .. is it critical to
> obey the ramp temperature requirements?
>
> Regards
> Kim

there are several suppliers, not only avnet, so try push all of them
to get pb-free versions

vapor thing is almost the ONLY thing suitable for BGAs, so if you have
that equipment be happy.

for best results the correct temperature profile is sure required, but
i guess your assembly department will know about that.

you possible can use the pb-free profile for pb package too, at least
for the development boards

Antti






Article: 127355
Subject: Re: BGA reflow soldering using vapor phase
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Wed, 19 Dec 2007 04:24:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On 19 Dez., 13:10, Antti <Antti.Luk...@googlemail.com> wrote:

> you possible can use the pb-free profile for pb package too, at least
> for the development boards

We had only 50% yield with that approach recently, albeit not with an
FPGA.

Kolja

Article: 127356
Subject: Re: FPGA program cable suggestion
From: taco <tralalal@joepie.nl>
Date: Wed, 19 Dec 2007 13:27:11 +0100
Links: << >>  << T >>  << A >>
taco wrote:

> Has any a good suggestion for a fpga program cable, which is known to work
> with linux (64 bits)?
> Thanks
> T.
let it be. I just ordered the xilinx usb cable. 


Article: 127357
Subject: Re: sampling error between 2 clocks
From: KJ <Kevin.Jennings@unisys.com>
Date: Wed, 19 Dec 2007 04:47:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 9:46 pm, wxy0...@gmail.com wrote:
> > Yes, see above and get rid of all of your processes that are clocked by
> > 'CLKI_DIV'
>
> Thanks!
>
> But do you mean to let all logic clocked by CLKI,
> meanwhile use CLKI_DIV as a clk_enable?
Yes.

>
> That would make all the logic run at 300MHz.
That's correct.

> I want to use concurrent logic to achieve lower clock frequency,
> that is why I am using  CLKI_DIV.

Some questions you should ponder then....
What is the point of the 300 MHz then?
How low of a clock frequency are you trying to achieve?
What is the reason for needing this lower clock frequency?

The only real correct answer to all of the above is that you have some
chunk of logic that needs to run at 300, and some other chunks that
just can't because they fail timing.  If that is not the situation,
then use CLKI_DIV as a clock enable and be done with it.

IF that is your situation, you should first consider breaking up the
chunk-o-logic that doesn't run at 300 into smaller pipelined chunks
that can.

Finally, if you really do need the two clocks, then any communication
between the CLKI and CLKI_DIV should be treated as if they are totally
asynchronous clocks which generally means inserting fifos to move the
data across the clock domains.

>
> Even if V4SX55 can run at 300MHz,
> I don't think it's a good idea.
>
1. Explain why you don't think it's a good idea.
2. Then explain why your design is attempting to run at least part of
it at 300 MHz.
3. Then explain why your answer to #2 is not in violation of your
answer to #1.

>  And I still have to worry about the skew of CLKI_DIV,
>  and the phase relationship beteen the 2 clocks,
> which is the main problem.
CLKI_DIV would no longer be a clock, you would not need to worry about
the skew of CLKI_DIV and the phase relationship.  Anyplace you
previously were looking for a rising edge of CLKI_DIV (as a clock) you
would replace with "if CLKI_DIV = '0'" as a clock enable as I
demonstrated.  If you had any code that was looking for falling edges
of CLKI_DIV you would replace it with "if CLKI_DIV = '1'" (as a clock
enable).

> You know, if use BUFG to drive CLKI_DIV,
> the phase relationship is hard to control,
> If not, the skew will be a huge problem.
> These 2 problems are all I got right now,
> and they are still there!
And the root cause of the problem is that you're using CLKI to
generate CLKI_DIV which will inherently generate skew between these
two signals.  Even in simulation, they do not happen simultaneously,
CLKI_DIV will happen on the next simulation delta.  When they are both
used as clocks you'll have the problems that you're seeing, if you use
CLKI_DIV as a clock enable as Symon and I have pointed out you won't.

If you want to beat your head against the wall trying to solve this go
ahead but all you'll get is a headache and a flaky design that will
mysteriously work (or not) when you first power it on, then will not
work (or work) once it has been powered up for some period of
time....which you'll attribute to some mysterious temperature
sensitivity....but the reason for the 'sensitivity' is improper design
and failing timing analysis which is what your timing report is
telling you right now.

>
> I really wanna know your solution in detail.
What detail do you think was not disclosed previously?

Kevin Jennings

Article: 127358
Subject: Re: sampling error between 2 clocks
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 19 Dec 2007 13:20:26 +0000
Links: << >>  << T >>  << A >>
On Tue, 18 Dec 2007 18:46:38 -0800 (PST), wxy0624@gmail.com wrote:

>> Yes, see above and get rid of all of your processes that are clocked by
>> 'CLKI_DIV'
>
>
>Thanks!
>
>But do you mean to let all logic clocked by CLKI,
>meanwhile use CLKI_DIV as a clk_enable?
>
>That would make all the logic run at 300MHz.

Exactly.

>I want to use concurrent logic to achieve lower clock frequency,
>that is why I am using  CLKI_DIV.

But why?

> And I still have to worry about the skew of CLKI_DIV,
> and the phase relationship beteen the 2 clocks,
>which is the main problem.

No - you let the tools worry about them. If the tools can 
achieve timings WITHOUT issuing warnings, there is no worrying to be
done. 

This approach lets the timing constraints necessary on the 150MHz clock
to be correctly inferred by the tools. And there are no clock domain
crossings to worry about.

- Brian

Article: 127359
Subject: Xilinx EDK PPC405+FSL
From: "u_stadler@yahoo.de" <u_stadler@yahoo.de>
Date: Wed, 19 Dec 2007 06:22:33 -0800 (PST)
Links: << >>  << T >>  << A >>
hi

i'm using edk 9.1 and i have to write my own ip core. i want to use
the ppc405 in a virtex 4 an was wondering if that supports the fsl
link. in the datasheet for the fsl link it only talks about the
microblaze processor...
can i expect to work the fsl link also with the ppc?
should i expect any difficulties?

thanks
urban

Article: 127360
Subject: Re: sampling error between 2 clocks
From: Andy <jonesandy@comcast.net>
Date: Wed, 19 Dec 2007 07:08:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 19, 7:20 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Tue, 18 Dec 2007 18:46:38 -0800 (PST), wxy0...@gmail.com wrote:
> >> Yes, see above and get rid of all of your processes that are clocked by
> >> 'CLKI_DIV'
>
> >Thanks!
>
> >But do you mean to let all logic clocked by CLKI,
> >meanwhile use CLKI_DIV as a clk_enable?
>
> >That would make all the logic run at 300MHz.
>
> Exactly.
>
> >I want to use concurrent logic to achieve lower clock frequency,
> >that is why I am using  CLKI_DIV.
>
> But why?
>
> > And I still have to worry about the skew of CLKI_DIV,
> > and the phase relationship beteen the 2 clocks,
> >which is the main problem.
>
> No - you let the tools worry about them. If the tools can
> achieve timings WITHOUT issuing warnings, there is no worrying to be
> done.
>
> This approach lets the timing constraints necessary on the 150MHz clock
> to be correctly inferred by the tools. And there are no clock domain
> crossings to worry about.
>
> - Brian

Another approach might be to generate the 150 MHz clock with a BUFGE,
enabled by clki_div (keep in mind that such a clock may not be 50%
duty cycle). Or use a DCM.

Otherwise, you have been given the best advice, and only if you really
need the rest of your design to run at 150 (for power savings, etc?)
should you actually generate a slower clock signal, and then there are
good ways to do it (what I suggested above) and bad ways (what you
were doing).

If your logic that you want to run at 150 MHz is too complex to run at
300, then you can use a 150 MHz clock enable as suggested previously,
with multi-cycle path constraints to relax timing on those paths that
have two 300 MHz cycles to complete. However, this is generally more
error prone, since incorrectly specified multi-cycle paths can usually
only be found by a simulation that exercises the incorrectly specified
path.

As to the difference between lab operation and simulation warnings,
even if you were to test with your voltage at the lowest possible
value, and raise the temperature to the highest, consider that your
lab experiment works on a sample of one FPGA, from one production lot.
If you plan on producing more than just the board you have in the lab,
you need to solve the problems indicated by the simulator and/or
timing analysis tool. "Works in the lab" is necessary, but not
sufficient for "works in production".

Andy

Article: 127361
Subject: Re: VCCIO issue on Xilinx Spartan3E !
From: "Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com>
Date: Wed, 19 Dec 2007 16:19:50 +0100
Links: << >>  << T >>  << A >>
austin wrote:

> Larry,
> 
> The FPGA is not a battery.  If there is that high a voltage on
> unconnected banks, well, they are obviously connected to something,
> aren't they?
> 
> It could be that you have a 5V CMOS driver driving an input in that
> (those) bank(s), which causes the upper protection diode(s) to be
> forward biased.
> 
> The voltages you have reported are greater than the abs max in the data
> sheet, so you risk blowing out the gates/junctions on the IO transistors
> in those banks -- DON'T DO THAT!
> 
> Austin

Austin,

Yes, you saw the correct trouble : FORWARD BIASE.

But how? An pin on a connector can output io signal coming from Bank1 or 
can drive a regulated 5V. The selection of these two output are done 
with a analog FET switch. BUT, the pull-down resistor setting the Switch 
was 470k instead the 4k7 ;-)... Before the configuration of the FPGA, 
the 5V was coming on one io of bank1 then via the protection diode the 
5V comes on all the VCCIO of bank1 and Bank3...
Note: after configuration of the SP3 all comes correct since the FPGA 
drives the analog switch :-)

The Spartan3E was stressed, but still working !

Thank you Austin.

Regards,
Larry

Article: 127362
Subject: Re: Xilinx EDK PPC405+FSL
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 19 Dec 2007 07:22:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 19, 8:22 am, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote:
> hi
>
> i'm using edk 9.1 and i have to write my own ip core. i want to use
> the ppc405 in a virtex 4 an was wondering if that supports the fsl
> link. in the datasheet for the fsl link it only talks about the
> microblaze processor...
> can i expect to work the fsl link also with the ppc?
> should i expect any difficulties?
>
> thanks
> urban


Yes it does.

Look at the fcb2fsl_bridge pcore. You can find it in the EDK GUI at:

Project Information Area -> IP Catalog -> Bus_Bridge ->
fcb2fsl_bridge.

Regards,

John McCaskill
www.fastertechnology.com

Article: 127363
Subject: Re: BGA reflow soldering using vapor phase
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 19 Dec 2007 09:05:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On 19 Dez., 13:24, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> On 19 Dez., 13:10, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > you possible can use the pb-free profile for pb package too, at least
> > for the development boards
>
> We had only 50% yield with that approach recently, albeit not with an
> FPGA.
>
> Kolja
Hi,

if need prototypes quickly the 50% is fully acceptable, thats why i
suggested
i guess there actual yield depends on many factors as the package type
and moisture, etc..

Antti



Article: 127364
Subject: Re: sampling error between 2 clocks
From: mk <kal*@dspia.*comdelete>
Date: Wed, 19 Dec 2007 09:14:59 -0800
Links: << >>  << T >>  << A >>
On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ
<Kevin.Jennings@unisys.com> wrote:

>Finally, if you really do need the two clocks, then any communication
>between the CLKI and CLKI_DIV should be treated as if they are totally
>asynchronous clocks which generally means inserting fifos to move the
>data across the clock domains.

I don't think in general this makes sense; depending on the
capabilities of the STA tool, the way timing is checked starts at a
main pin and traces it through the clock buffers/delays for both
source and the target flops to calculate the clock arrival times. The
fact that a clock divider in one of the paths doesn't make the divided
clock asynchronous and the result is no less dependable then when all
the delays are just clock buffers/inverters. There is just one
clock->Q delay instead of a buffer and a good STA tool should be
account for that.

Article: 127365
Subject: Re: sampling error between 2 clocks
From: KJ <Kevin.Jennings@unisys.com>
Date: Wed, 19 Dec 2007 09:51:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 19, 12:14 pm, mk <kal*@dspia.*comdelete> wrote:
> On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ
>
> <Kevin.Jenni...@unisys.com> wrote:
> >Finally, if you really do need the two clocks, then any communication
> >between the CLKI and CLKI_DIV should be treated as if they are totally
> >asynchronous clocks which generally means inserting fifos to move the
> >data across the clock domains.
>
> I don't think in general this makes sense; depending on the
> capabilities of the STA tool, the way timing is checked starts at a
> main pin and traces it through the clock buffers/delays for both
> source and the target flops to calculate the clock arrival times. The
> fact that a clock divider in one of the paths doesn't make the divided
> clock asynchronous and the result is no less dependable then when all
> the delays are just clock buffers/inverters.

I don't disagree about how STA computes paths, but what I said was
"...the CLKI and CLKI_DIV should be treated as if they are totally
asynchronous clocks".  By that what I meant, was that one should
approach the design *as if* the two clocks are unrelated and use
proper clock domain crossing design techniques.  That will lead to a
robust design.

Trying to constrain your way to happiness generally results in
'brittle' designs where simple changes cause timing paths to now fail
and lead to another round of new constraints, random number seeds,
etc. because the synthesis tool was slightly off when it was
estimating delays when it used those constraints to try to optomize
timing during the mapping/fitting/routing process.

>There is just one
> clock->Q delay instead of a buffer and a good STA tool should be
> account for that.

And the OP's static timing analysis already is catching the
problem....the fact that he's not following good FPGA design practice
is causing him to try to stomp out the problem with constraints that
will keep biting until he changes the functional description of his
design.

KJ

Article: 127366
Subject: Re: Xilinx DCM outputs for DDR
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 19 Dec 2007 09:59:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 5:29 pm, Brian Davis <brimda...@aol.com> wrote:
> John_H wrote:
>
> > What's the best way to clock DDR flops from a DCM?
>
>  In V2, the two clock net scheme works best.
>
>  When doing this, I've avoided the DCM jitter by running
> the clock into a DIFF_OUT global buffer variant without
> using a DCM.
>
>  I haven't measured this in S3E.
>
>
>
> > Much of the early DDR information suggested using the 0 and 180 degree
> > outputs from the DCM.  I never considered this a good design practice
> > because the outputs are going through different BUFGs with different
> > clock loads on each net resulting in a designed-in skew that would
> > compromise the DDR sampling windows.
>
>  I've used isolated clock nets for just the DDR I/O, with a different
> net for the global logic clock, in my past V2 designs; this requires
> intentional LOCing of the global buffers to the clock sites having
> shared routing resources.
>
> I posted about this a while back on the "DIFF_OUT Buffer Example"
> thread, see this thread and the comments in the code example:
>
> http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/367ad...
>
>
>
> > Is there any real evidence one way or the other to suggest that one of
> > these approaches is better than the other?
>
>  I measured V2 clock duty cycle and DDR setup/hold, without
> any DCM involvement, by using a two channel HP8133A and
> forwarding the clock and DDR data output back out another
> LVDS pair to a 20 GHz sampler.
>
>
>
> > Don't newer parts route differential clocks for single global clock
> > nets now?  Or is that just the Virtex series?  My designs are
>
>  V4 and V5 have differential global routes, but in V4 some of the
> regional resources are still single ended ( and because V4 can't
> directly clock a global spline from a local clock input having the
> best DDR I/O performance, some creative clocking workarounds are
> required to avoid needing the same clock on a global & local input)
>
> Brian

Thanks for the discussion and the link to the previous thread.

I have the unfortunate need of using the DCMs to multiply the incoming
clock so I lose margin from the start.  In the other thread you
mentioned the DCM does 50% duty cycle correction - as I've known - but
the XAPPs *appear* to suggest that 50% duty cycle correction happens
local to the DCM - not at the global buffer feedback level - such that
duty cycle distortion in the global clock is still an issue.  Joy.

I really don't enjoy the idea of 3 global clocks to get the matched
0/180 clocks for the IOBs and the logic clock, but if it gains another
300 ps in margin, perhaps it's worth rearranging things.  I appreciate
that I'm not the only one who sees the clock loading difference as a
root issue that needs to be addressed.

Maybe XAPP485 didn't have it terribly wrong using the CLKFX and ~CLKFX
as the inputs to the two clock buffer (that I saw as a bastardization
of the 2 approaches).  If the 50% duty cycle correction is local to
the DCM and not the global clock, this inversion would work.  If the
50% duty cycle correction is global, however, the global clock
polarity that isn't part of the feedback path would be that much worse
off.

I have yet to find an app note or white paper that really addresses
the global 50% issue.  I'll look deeper into DCM literature and
perhaps try some 3-clock receive timing analysis to see how/if the
numbers differ.

Thanks,
- John_H

Article: 127367
Subject: Re: sampling error between 2 clocks
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 19 Dec 2007 10:08:36 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 6:46 pm, wxy0...@gmail.com wrote:
> > Yes, see above and get rid of all of your processes that are clocked by
> > 'CLKI_DIV'
>
> Thanks!
>
> But do you mean to let all logic clocked by CLKI,
> meanwhile use CLKI_DIV as a clk_enable?
>
> That would make all the logic run at 300MHz.
> I want to use concurrent logic to achieve lower clock frequency,
> that is why I am using  CLKI_DIV.
>
> Even if V4SX55 can run at 300MHz,
> I don't think it's a good idea.
>
>  And I still have to worry about the skew of CLKI_DIV,
>  and the phase relationship beteen the 2 clocks,
> which is the main problem.
> You know, if use BUFG to drive CLKI_DIV,
> the phase relationship is hard to control,
> If not, the skew will be a huge problem.
> These 2 problems are all I got right now,
> and they are still there!
>
> I really wanna know your solution in detail.

Sorry I'm late to the thread...

The main point I haven't seen communicated is that the clock-enabled
logic will, indeed, be running with a 300 MHz clock, but...

...you can specify a multi-cycle path for all the registers fed by the
clock enable to two 300 MHz clock cycles.

The place&route and timing analysis will make sure the single-cycle
300 MHz logic works at 300 MHz as you need.  The clock enable that
needs to reach the enabled flops within a 300 MHz period will be
routed properly.  The logic that wants to run slower, however,
requires only the lazy two cycles worth of delay to get the proper
results; the uncertain results when the clock is not enabled will not
affect your results.

As long as the multi-cycle constraint is properly applied, this all-
synchronous approach works even better than pipelining the logic to be
all 300 MHz.

Multi-cycle constraints and one high speed clock will solve many of
your troubles.

- John_H

Article: 127368
Subject: Re: Xilinx DCM outputs for DDR
From: "BobW" <nimby_NEEDSPAM@roadrunner.com>
Date: Wed, 19 Dec 2007 10:08:55 -0800
Links: << >>  << T >>  << A >>

"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:032b97a2-abf3-48c6-8039-af436b23f2f5@y5g2000hsf.googlegroups.com...
> On Dec 18, 5:29 pm, Brian Davis <brimda...@aol.com> wrote:
>> John_H wrote:
>>
>> > What's the best way to clock DDR flops from a DCM?
>>
>>  In V2, the two clock net scheme works best.
>>
>>  When doing this, I've avoided the DCM jitter by running
>> the clock into a DIFF_OUT global buffer variant without
>> using a DCM.
>>
>>  I haven't measured this in S3E.
>>
>>
>>
>> > Much of the early DDR information suggested using the 0 and 180 degree
>> > outputs from the DCM.  I never considered this a good design practice
>> > because the outputs are going through different BUFGs with different
>> > clock loads on each net resulting in a designed-in skew that would
>> > compromise the DDR sampling windows.
>>
>>  I've used isolated clock nets for just the DDR I/O, with a different
>> net for the global logic clock, in my past V2 designs; this requires
>> intentional LOCing of the global buffers to the clock sites having
>> shared routing resources.
>>
>> I posted about this a while back on the "DIFF_OUT Buffer Example"
>> thread, see this thread and the comments in the code example:
>>
>> http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/367ad...
>>
>>
>>
>> > Is there any real evidence one way or the other to suggest that one of
>> > these approaches is better than the other?
>>
>>  I measured V2 clock duty cycle and DDR setup/hold, without
>> any DCM involvement, by using a two channel HP8133A and
>> forwarding the clock and DDR data output back out another
>> LVDS pair to a 20 GHz sampler.
>>
>>
>>
>> > Don't newer parts route differential clocks for single global clock
>> > nets now?  Or is that just the Virtex series?  My designs are
>>
>>  V4 and V5 have differential global routes, but in V4 some of the
>> regional resources are still single ended ( and because V4 can't
>> directly clock a global spline from a local clock input having the
>> best DDR I/O performance, some creative clocking workarounds are
>> required to avoid needing the same clock on a global & local input)
>>
>> Brian
>
> Thanks for the discussion and the link to the previous thread.
>
> I have the unfortunate need of using the DCMs to multiply the incoming
> clock so I lose margin from the start.  In the other thread you
> mentioned the DCM does 50% duty cycle correction - as I've known - but
> the XAPPs *appear* to suggest that 50% duty cycle correction happens
> local to the DCM - not at the global buffer feedback level - such that
> duty cycle distortion in the global clock is still an issue.  Joy.
>
> I really don't enjoy the idea of 3 global clocks to get the matched
> 0/180 clocks for the IOBs and the logic clock, but if it gains another
> 300 ps in margin, perhaps it's worth rearranging things.  I appreciate
> that I'm not the only one who sees the clock loading difference as a
> root issue that needs to be addressed.
>
> Maybe XAPP485 didn't have it terribly wrong using the CLKFX and ~CLKFX
> as the inputs to the two clock buffer (that I saw as a bastardization
> of the 2 approaches).  If the 50% duty cycle correction is local to
> the DCM and not the global clock, this inversion would work.  If the
> 50% duty cycle correction is global, however, the global clock
> polarity that isn't part of the feedback path would be that much worse
> off.
>
> I have yet to find an app note or white paper that really addresses
> the global 50% issue.  I'll look deeper into DCM literature and
> perhaps try some 3-clock receive timing analysis to see how/if the
> numbers differ.
>
> Thanks,
> - John_H

The real issue about duty cycle distortion, in DDR interfaces, is how it 
affects setup/hold time. Doesn't the use of the (jittery) CLKFX outputs have 
a much bigger effect on setup/hold time?

Bob



Article: 127369
Subject: Quartus and simulation libraries...
From: Rick North <dontreplytothisaddy@hotmail.com>
Date: Wed, 19 Dec 2007 10:13:22 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all,

I used to work with Xilinx ISE, there you could compile the unisim,
simprim libraries. I have switched from Xilinx to Altera where I would
like to with the same ease compile Altera specific libraries. But I
have not found a similar way.

Is there such a script or do I need to do it manualy?

Regards,
/RN

Article: 127370
Subject: Re: BGA reflow soldering using vapor phase
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 19 Dec 2007 10:35:44 -0800
Links: << >>  << T >>  << A >>
kislo wrote:
> I am doing some initial research regarding PCB design process with a
> Spartan3E (FT256) .. Have i understood it correctly that avnet are the
> only distributor of xilinx FPGAs ? .. in that case, i can order a
> Spartan3E witch is not lead free .. and here comes the problem -> we
> have vapor phase equipment to solder the BGA on the PCB. This vapor
> phase machine uses liquid which reach 240degrees (Pb-free soldering),
> will this damage the non-Pb-free FPGA? If it does, i have to convince
> some ppl to buy some other liquid with lower vapor temperature :/
> 
> I have read the Device Package Userguide (ug112), regarding the Reflow
> soldering process .. it dosent address the vapor phase process but i
> guess its the same as for a normal oven process? .. is it critical to
> obey the ramp temperature requirements?
> 

The original premise behind this question is incorrect.

1) Avnet is only one of several distributors that sell Xilinx parts.
    Your posting address indicates that you are located in Denmark and
    Silica (an Avnet company) is the only local distributor.  Nu Horizons
    has offices in Germany and the UK.

2) The Spartan-3E family is available in both lead and PB-free
    packages.  Simply order the FTG256 (instead of the FT256) to get
    the PB-free package version.

Ed McGettigan
--
Xilinx Inc.

Article: 127371
Subject: Re: sampling error between 2 clocks
From: mk <kal*@dspia.*comdelete>
Date: Wed, 19 Dec 2007 10:43:55 -0800
Links: << >>  << T >>  << A >>
On Wed, 19 Dec 2007 09:51:28 -0800 (PST), KJ
<Kevin.Jennings@unisys.com> wrote:

>On Dec 19, 12:14 pm, mk <kal*@dspia.*comdelete> wrote:
>> On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ
>>
>> <Kevin.Jenni...@unisys.com> wrote:
>> >Finally, if you really do need the two clocks, then any communication
>> >between the CLKI and CLKI_DIV should be treated as if they are totally
>> >asynchronous clocks which generally means inserting fifos to move the
>> >data across the clock domains.
>>
>> I don't think in general this makes sense; depending on the
>> capabilities of the STA tool, the way timing is checked starts at a
>> main pin and traces it through the clock buffers/delays for both
>> source and the target flops to calculate the clock arrival times. The
>> fact that a clock divider in one of the paths doesn't make the divided
>> clock asynchronous and the result is no less dependable then when all
>> the delays are just clock buffers/inverters.
>
>I don't disagree about how STA computes paths, but what I said was
>"...the CLKI and CLKI_DIV should be treated as if they are totally
>asynchronous clocks".  By that what I meant, was that one should
>approach the design *as if* the two clocks are unrelated and use
>proper clock domain crossing design techniques.  That will lead to a
>robust design.

I think my problem is with the sections "should be treated ..." and "a
robust design" which to me sounds like if they're not, the result will
not be a robust design with which I disagree. Also forcing a design to
run at 2X MHz speed will push the synthesis a lot more than running it
at X. If one pays some attention to the first 2X->X boundary (ie
minimal or no logic in between), the STA will correctly manage the
clock tree and there will be no problems.
This way the design will be at least as robust as treating them async
and putting in async fifos which are quite complicated to design too.

Article: 127372
Subject: Re: Xilinx DCM outputs for DDR
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 19 Dec 2007 10:58:51 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 19, 10:08 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
>
> The real issue about duty cycle distortion, in DDR interfaces, is how it
> affects setup/hold time. Doesn't the use of the (jittery) CLKFX outputs have
> a much bigger effect on setup/hold time?
>
> Bob

The jitter is miserable for high speed DDR interfaces.  But when the
clock frequency comes in at 1/7th the bit rate and there's no PLLs in
the Spartan3E, the DCMs are a necessary evil.  I just want to make the
DCM jitter the *only* remaining loss to the design margins that I can
twiddle with.

- John_H

Article: 127373
Subject: Re: sampling error between 2 clocks
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 19 Dec 2007 11:00:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 19, 10:43 am, mk <kal*@dspia.*comdelete> wrote:
>
> I think my problem is with the sections "should be treated ..." and "a
> robust design" which to me sounds like if they're not, the result will
> not be a robust design with which I disagree. Also forcing a design to
> run at 2X MHz speed will push the synthesis a lot more than running it
> at X. If one pays some attention to the first 2X->X boundary (ie
> minimal or no logic in between), the STA will correctly manage the
> clock tree and there will be no problems.
> This way the design will be at least as robust as treating them async
> and putting in async fifos which are quite complicated to design too

If the synthesis uses multi-cycle constraints, the synthesis will not
be pushed.  The synthesis will make sure the combinatorial paths
conform to the needs of the multi-cycle path's period.

Article: 127374
Subject: Re: sampling error between 2 clocks
From: KJ <Kevin.Jennings@unisys.com>
Date: Wed, 19 Dec 2007 12:08:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 19, 1:43 pm, mk <kal*@dspia.*comdelete> wrote:
> On Wed, 19 Dec 2007 09:51:28 -0800 (PST), KJ
>
>
>
>
>
> <Kevin.Jenni...@unisys.com> wrote:
> >On Dec 19, 12:14 pm, mk <kal*@dspia.*comdelete> wrote:
> >> On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ
>
> >> <Kevin.Jenni...@unisys.com> wrote:
> >> >Finally, if you really do need the two clocks, then any communication
> >> >between the CLKI and CLKI_DIV should be treated as if they are totally
> >> >asynchronous clocks which generally means inserting fifos to move the
> >> >data across the clock domains.
>
> >> I don't think in general this makes sense; depending on the
> >> capabilities of the STA tool, the way timing is checked starts at a
> >> main pin and traces it through the clock buffers/delays for both
> >> source and the target flops to calculate the clock arrival times. The
> >> fact that a clock divider in one of the paths doesn't make the divided
> >> clock asynchronous and the result is no less dependable then when all
> >> the delays are just clock buffers/inverters.
>
> >I don't disagree about how STA computes paths, but what I said was
> >"...the CLKI and CLKI_DIV should be treated as if they are totally
> >asynchronous clocks".  By that what I meant, was that one should
> >approach the design *as if* the two clocks are unrelated and use
> >proper clock domain crossing design techniques.  That will lead to a
> >robust design.
>
> I think my problem is with the sections "should be treated ..." and "a
> robust design" which to me sounds like if they're not, the result will
> not be a robust design with which I disagree.

OK, we agree to disagree then.

> Also forcing a design to
> run at 2X MHz speed will push the synthesis a lot more than running it
> at X.

Pipelining or specifying multi-cycle paths addresses that concern.

> If one pays some attention to the first 2X->X boundary (ie
> minimal or no logic in between), the STA will correctly manage the
> clock tree and there will be no problems.

If generally true, then the OP wouldn't be having the setup problem
now would he?

The reason he is having this warning is because of the inherent skew
between the clock to a flip flop and the output of that flip flop and
using them both as clocks which can not be 'managed' no matter how
much attention you pay.  This is a clock domain crossing problem, and
while the frequency of the two clocks have a nominal relationship to
each other (i.e. one is 2x the other) there is NO controllable
relationship between the skew of the edges of these clocks and THAT is
what is causing the timing 'warning' and eventually a real failure.

> This way the design will be at least as robust as treating them async
> and putting in async fifos which are quite complicated to design too.- Hide quoted text -
>
Well, I certainly wouldn't bother to write the code to implement an
async FIFOs.  I would write code that the synthesis tool would infer
to be whatever hard macro that the device inherently has....could be
as simple as using the 'lpm_fifo_dc' (or using Mr. Wizard if one so
chooses).  The silicon guys are the ones that can properly implement
the async fifo, the FPGA designer needs to write code that causes that
stuff to be used.

Kevin Jennings



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