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 157650

Article: 157650
Subject: Re: Altera Cyclone II
From: Michael <michael_laajanen@yahoo.com>
Date: Tue, 20 Jan 2015 14:11:16 +0100
Links: << >>  << T >>  << A >>
Hi,
On 01/19/15 09:54 PM, Tomas D. wrote:
> "Michael" <michael_laajanen@yahoo.com> wrote in message
> news:chp7vjFof2bU1@mid.individual.net...
>> Hi,
>>
><snip>

> Hello Michael,
> you have two options:
> 1) If you use PLL, then use LOCKED output as a reset to your logic. Create a
> counter, that will set PLL areset input to high when you need a reset.
> 2) A hardware reset by routing IO pin to nCONFIG input, which would have a
> pull-up resistor. When the FPGA is reseted, the pull-up would ensure the
> nCONFIG is high and the FPGA can enter user mode. When user-mode is reached,
> the output is kept high until the reset is needed. This will reset the FPGA
> completely.
>
> Regards
> Tomas D.
>
>
Thanks Tomas, I will start with the first suggestion.

cheers

Michael


Article: 157651
Subject: Re: Altera Cyclone II
From: =?windows-1252?Q?Adam_G=F3rski?= <gorskiamalpawpkropkapeel_@xx>
Date: Tue, 20 Jan 2015 17:04:11 +0100
Links: << >>  << T >>  << A >>

>> Hello Michael,
>> you have two options:
>> 1) If you use PLL, then use LOCKED output as a reset to your logic.
>> Create a
>> counter, that will set PLL areset input to high when you need a reset.

>>
>> Regards
>> Tomas D.
>>
>>
> Thanks Tomas, I will start with the first suggestion.

Hello,

Be careful using PLL lock signal. PLL once locked is NOT locked forever 
and re-lock may occurs. See documentation.

BR

Adam

Article: 157652
Subject: Re: Altera Cyclone II
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 20 Jan 2015 09:49:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, January 19, 2015 at 3:54:33 PM UTC-5, Tomas D. wrote:
> "Michael" <michael_...@yahoo.com> wrote in message=20

> you have two options:
> 1) If you use PLL, then use LOCKED output as a reset to your logic. Creat=
e a=20
> counter, that will set PLL areset input to high when you need a reset.

This won't do what the OP asked.  What was asked was a way to reset all of =
the flip flops.  Reseting the PLL in order to cause it to unlock won't do t=
hat.  All it will do is shut off the clocks for a period of time until the =
PLLs come back online.  That by itself does absolutely nothing to any of th=
e flip flops.  You're presuming that the 'locked' PLL output is already bei=
ng explicitly used to reset every flip flop in the design either directly o=
r through some reset code in the FPGA design, but a simple 'D' flip flop wi=
ll not react at all.

Q <=3D D when rising_edge(Clock);

> 2) A hardware reset by routing IO pin to nCONFIG input, which would have =
a=20
> pull-up resistor. When the FPGA is reseted, the pull-up would ensure the=
=20
> nCONFIG is high and the FPGA can enter user mode. When user-mode is reach=
ed,=20
> the output is kept high until the reset is needed. This will reset the FP=
GA=20
> completely.
>=20
Perusal of the datasheet shows that this approach is not guaranteed to work=
.  The datasheet specifies a maximum of 800 ns from nConfig low to Conf_Don=
e low as well as a minimum of 2 us for nConfig to stay low.  So you can onl=
y count on the FPGA to produce a maximum low time on nConfig of less than h=
alf the required minimum.

Also, this approach goes too far in that not only are the flip flops reset =
(as was requested), but the entire FPGA has now lost it's configuration and=
 is brain dead.  To recover, the FPGA will need to be reconfigured which me=
ans that whatever circuit that responds to some external event that causes =
FPGA configuration to occur in the first place (like powerup in many design=
s) needs to be restarted.  The configuration circuit would have to monitor =
Conf_Done and look for a high to low transition to cause it to once again c=
onfigure the FPGA.

Kevin Jennings

Article: 157653
Subject: Re: Altera Cyclone II
From: jonesandy@comcast.net
Date: Tue, 20 Jan 2015 20:46:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Initialize up-counters to even values, and the maximum synchronization error is 1 for an asynchronously released reset.

Andy


Article: 157654
Subject: [RANT] XILINX, Are you freaking kidding me ?
From: Simon <google@gornall.net>
Date: Wed, 21 Jan 2015 10:34:32 -0800 (PST)
Links: << >>  << T >>  << A >>

So I wanted to know if it was possible to update an old embedded-developmen=
t kit license that's expired. There's nothing on xilinx' site as far as I c=
an see that allows for old licenses to be renewed. So I go to the support s=
ection, fill out the form explaining the situation and send it off.

I promptly get back a canned reply...

--- Cut Here ---
Thank you for your inquiry,
=20
There are three ways to purchase Xilinx products:

Xilinx Sales Reps: http://www.xilinx.com/company/contact/sales-offices.htm =
=20
=B7       Sales representatives can help if you do not know which products =
are best for your design.
=20
Online Store: http://www.xilinx.com/onlinestore/
=B7       The Xilinx Online Store provides a quick and simple way to purcha=
se Xilinx design tools and a selection of development boards and kits direc=
tly from Xilinx. Simply locate your product of interest and click the "Buy"=
 link from anywhere on Xilinx.com to get started.

Things to consider before purchasing from the Xilinx Online Store:

=B7       Tax Exempt orders must be placed through distribution.
=B7       On-line purchases are by credit card only.  No purchase orders pl=
ease.
Xilinx accepts the following credit cards:  Visa, MasterCard, and American =
Express
=B7       No Intellectual Products are sold on the On-line Store
=20
Xilinx Distributors: http://www.xilinx.com/company/contact/index.htm
=20
=B7       Xilinx Authorized Distributors offer access to a comprehensive se=
t of Xilinx design tools, IP cores, devices, development boards and kits.

=B7       The Xilinx Productivity Advantage (XPA) Bundling Program is only =
offered when purchasing through a Xilinx Authorized Distributor.  To learn =
more about how to reduce your design productivity solution costs, please vi=
sit http://www.xilinx.com/xpa/.
=20
University Faculty:  http://www.xilinx.com/university/professors/index.htm
=B7       Universities may be eligible for full versions of design tools at=
 no charge. University professors must initiate the request at the Universi=
ty Faculty link above.
=20
Thank you,
Xilinx Development System Team
--- Cut Here ---

... which is useless [I know what I want to use it for, so no sales reps; T=
he online store doesn't provide any option I can see; I can't see distribut=
ors being interested in upgrading a kit I bought directly from Xilinx; I'm =
not at university].=20

I didn't actually read the reply until the next day due to work/home email =
filters, so once I've read it, I send in another request, pointing out that=
 the canned reply wasn't useful and asking the same question again, along w=
ith "Is it really the case that I have to but a new piece of hardware (whic=
h I don't want or need) in order to extend a license for a product I bought=
 directly from you ?" because the only way I can see it being possible on t=
he xilinx site is to re-purchase the same board, thus getting a new license=
.

Guess what. A few seconds later I get back the exact *same* reply, word for=
 word. No attempt to read/parse the question I asked, just an apparent cann=
ed reply for any license/purchase question.

I wanted to work on this in the background, with a project that I think cou=
ld be useful for my work, but it's not official, so I can't go to the suppo=
rt guys here at work. I would have liked to have tried to use the same devi=
ce manufacturer as the tens-of-thousands-of-dollars boards that we have her=
e at work, for ease of later porting, but I'm now so frustrated by the lack=
 of human response, I'm going to look at Altera (or anyone else, really, al=
l I want is PCIe and some DDR ram)=20

I *was* prepared to put down my own hard-earned cash to do this, but I'll b=
e damned if they're getting any of my money now, if they can't even answer =
a simple question like this, I can't see them being any use once I've spent=
 the money.

Giving up on Xilinx.

Simon.

Article: 157655
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 21 Jan 2015 19:17:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
Simon <google@gornall.net> wrote:
 
> So I wanted to know if it was possible to update an old 
> embedded-development kit license that's expired. There's nothing 
> on xilinx' site as far as I can see that allows for old licenses 
> to be renewed. So I go to the support section, fill out the form 
> explaining the situation and send it off.

I am not sure which software or chips you are interested in.

I am running the webpack (free) version that, each time I run it,
tells me that my license has expired, but I can keep using it.

I could install a newer version, but haven't done that.

The free version does all the chips that I could afford, so I
haven't been interested in others. 

-- glen

Article: 157656
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: Simon <google@gornall.net>
Date: Wed, 21 Jan 2015 11:36:51 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, January 21, 2015 at 11:17:46 AM UTC-8, glen herrmannsfeldt wr=
ote:
> Simon wrote:
> =20
> > So I wanted to know if it was possible to update an old=20
> > embedded-development kit license that's expired. There's nothing=20
> > on xilinx' site as far as I can see that allows for old licenses=20
> > to be renewed. So I go to the support section, fill out the form=20
> > explaining the situation and send it off.
>=20
> I am not sure which software or chips you are interested in.
>=20
> I am running the webpack (free) version that, each time I run it,
> tells me that my license has expired, but I can keep using it.
>=20
> I could install a newer version, but haven't done that.
>=20
> The free version does all the chips that I could afford, so I
> haven't been interested in others.=20

Thanks - the board I have could actually be used with Webpack. The extra li=
cense gets me access to the embedded development kit though. It could be ki=
nd of useful to have the micro blaze...

Another wrinkle (that I put into the original request to Xilinx, but of cou=
rse was subsequently ignored) is that the old machine that was used for the=
 licence-id has long since departed to that computer museum in the sky. I t=
hink I'm allowed 3 "re-licencing" events, so perhaps I'll try just changing=
 the license to the new host-id, and running the app. I don't care if it wa=
rns me, as long as it works  - I'm not that familiar with how xilinx licens=
ing works though.

So cheers! I'll give it a go. You've been a whole lot more useful than xili=
nx support :)

Simon

Article: 157657
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 21 Jan 2015 14:48:04 -0500
Links: << >>  << T >>  << A >>
Simon wrote:
> On Wednesday, January 21, 2015 at 11:17:46 AM UTC-8, glen herrmannsfeldt wrote:
>> Simon wrote:
>>  
>>> So I wanted to know if it was possible to update an old 
>>> embedded-development kit license that's expired. There's nothing 
>>> on xilinx' site as far as I can see that allows for old licenses 
>>> to be renewed. So I go to the support section, fill out the form 
>>> explaining the situation and send it off.
>> I am not sure which software or chips you are interested in.
>>
>> I am running the webpack (free) version that, each time I run it,
>> tells me that my license has expired, but I can keep using it.
>>
>> I could install a newer version, but haven't done that.
>>
>> The free version does all the chips that I could afford, so I
>> haven't been interested in others. 
> 
> Thanks - the board I have could actually be used with Webpack. The extra license gets me access to the embedded development kit though. It could be kind of useful to have the micro blaze...
> 
> Another wrinkle (that I put into the original request to Xilinx, but of course was subsequently ignored) is that the old machine that was used for the licence-id has long since departed to that computer museum in the sky. I think I'm allowed 3 "re-licencing" events, so perhaps I'll try just changing the license to the new host-id, and running the app. I don't care if it warns me, as long as it works  - I'm not that familiar with how xilinx licensing works though.
> 
> So cheers! I'll give it a go. You've been a whole lot more useful than xilinx support :)
> 
> Simon

Xilinx licenses don't expire, only the updates / maintenance expires.
So theoretically you still own the license to use the software version
up to the limit of your maintenance contract (typically one year from
last purchase).

If this was an older version of ISE, the license may have been tied to
a MAC address or C-drive serial number, either of which would be in
human readable form in the license file.  Also either of these are
easy to clone in a new system.  If you still have the old license.dat
file you might not need to "re-license" if you can clone the MAC
or disk S/N.  I have done this in the past when old systems went up
in smoke.

-- 
Gabor

Article: 157658
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: rickman <gnuarm@gmail.com>
Date: Wed, 21 Jan 2015 17:03:18 -0500
Links: << >>  << T >>  << A >>
On 1/21/2015 1:34 PM, Simon wrote:
>
> So I wanted to know if it was possible to update an old embedded-development kit license that's expired. There's nothing on xilinx' site as far as I can see that allows for old licenses to be renewed. So I go to the support section, fill out the form explaining the situation and send it off.
>
> I promptly get back a canned reply...
>
> --- Cut Here ---
> Thank you for your inquiry,
>
> There are three ways to purchase Xilinx products:
>
> Xilinx Sales Reps: http://www.xilinx.com/company/contact/sales-offices.htm
> ·       Sales representatives can help if you do not know which products are best for your design.
>
> Online Store: http://www.xilinx.com/onlinestore/
> ·       The Xilinx Online Store provides a quick and simple way to purchase Xilinx design tools and a selection of development boards and kits directly from Xilinx. Simply locate your product of interest and click the "Buy" link from anywhere on Xilinx.com to get started.
>
> Things to consider before purchasing from the Xilinx Online Store:
>
> ·       Tax Exempt orders must be placed through distribution.
> ·       On-line purchases are by credit card only.  No purchase orders please.
> Xilinx accepts the following credit cards:  Visa, MasterCard, and American Express
> ·       No Intellectual Products are sold on the On-line Store
>
> Xilinx Distributors: http://www.xilinx.com/company/contact/index.htm
>
> ·       Xilinx Authorized Distributors offer access to a comprehensive set of Xilinx design tools, IP cores, devices, development boards and kits.
>
> ·       The Xilinx Productivity Advantage (XPA) Bundling Program is only offered when purchasing through a Xilinx Authorized Distributor.  To learn more about how to reduce your design productivity solution costs, please visit http://www.xilinx.com/xpa/.
>
> University Faculty:  http://www.xilinx.com/university/professors/index.htm
> ·       Universities may be eligible for full versions of design tools at no charge. University professors must initiate the request at the University Faculty link above.
>
> Thank you,
> Xilinx Development System Team
> --- Cut Here ---
>
> ... which is useless [I know what I want to use it for, so no sales reps; The online store doesn't provide any option I can see; I can't see distributors being interested in upgrading a kit I bought directly from Xilinx; I'm not at university].
>
> I didn't actually read the reply until the next day due to work/home email filters, so once I've read it, I send in another request, pointing out that the canned reply wasn't useful and asking the same question again, along with "Is it really the case that I have to but a new piece of hardware (which I don't want or need) in order to extend a license for a product I bought directly from you ?" because the only way I can see it being possible on the xilinx site is to re-purchase the same board, thus getting a new license.
>
> Guess what. A few seconds later I get back the exact *same* reply, word for word. No attempt to read/parse the question I asked, just an apparent canned reply for any license/purchase question.
>
> I wanted to work on this in the background, with a project that I think could be useful for my work, but it's not official, so I can't go to the support guys here at work. I would have liked to have tried to use the same device manufacturer as the tens-of-thousands-of-dollars boards that we have here at work, for ease of later porting, but I'm now so frustrated by the lack of human response, I'm going to look at Altera (or anyone else, really, all I want is PCIe and some DDR ram)
>
> I *was* prepared to put down my own hard-earned cash to do this, but I'll be damned if they're getting any of my money now, if they can't even answer a simple question like this, I can't see them being any use once I've spent the money.
>
> Giving up on Xilinx.

Instead of ranting, maybe you should look at your approach.  What you 
call the "support" channel is just a minimum effort at helping those who 
don't really have support.  If they suggest that you contact sales, then 
why not contact sales?  I'm sure they will point you in the right 
direction.  They don't exist solely for taking orders.

I haven't dealt with Xilinx in some years but I have the same issues 
with Lattice.  I find that human support through FAEs is pretty good. 
Also they have a separate channel for licenses which are updated every 
year for free.  Apparently unlike Xilinx, the Lattice license will stop 
your software from working when it expires.  That part royally sucks. 
It is always on a Friday after 5 PM when I fire up Lattice Diamond (or 
previously the "classic" tool) only to find it has expired and I won't 
be working on the project over the weekend as I had planned.  I am 
starting to learn however and have added the license expiration date to 
my calendar with a 2 week in advance reminder.

-- 

Rick

Article: 157659
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: Gabor <gabor@szakacs.org>
Date: Wed, 21 Jan 2015 20:36:20 -0500
Links: << >>  << T >>  << A >>
On 1/21/2015 5:03 PM, rickman wrote:
> On 1/21/2015 1:34 PM, Simon wrote:
>>
>> So I wanted to know if it was possible to update an old
>> embedded-development kit license that's expired. There's nothing on
>> xilinx' site as far as I can see that allows for old licenses to be
>> renewed. So I go to the support section, fill out the form explaining
>> the situation and send it off.
>>
>> I promptly get back a canned reply...
>>
>> --- Cut Here ---
>> Thank you for your inquiry,
>>
>> There are three ways to purchase Xilinx products:
>>
>> Xilinx Sales Reps:
>> http://www.xilinx.com/company/contact/sales-offices.htm
>> ·       Sales representatives can help if you do not know which
>> products are best for your design.
>>
>> Online Store: http://www.xilinx.com/onlinestore/
>> ·       The Xilinx Online Store provides a quick and simple way to
>> purchase Xilinx design tools and a selection of development boards and
>> kits directly from Xilinx. Simply locate your product of interest and
>> click the "Buy" link from anywhere on Xilinx.com to get started.
>>
>> Things to consider before purchasing from the Xilinx Online Store:
>>
>> ·       Tax Exempt orders must be placed through distribution.
>> ·       On-line purchases are by credit card only.  No purchase orders
>> please.
>> Xilinx accepts the following credit cards:  Visa, MasterCard, and
>> American Express
>> ·       No Intellectual Products are sold on the On-line Store
>>
>> Xilinx Distributors: http://www.xilinx.com/company/contact/index.htm
>>
>> ·       Xilinx Authorized Distributors offer access to a comprehensive
>> set of Xilinx design tools, IP cores, devices, development boards and
>> kits.
>>
>> ·       The Xilinx Productivity Advantage (XPA) Bundling Program is
>> only offered when purchasing through a Xilinx Authorized Distributor.
>> To learn more about how to reduce your design productivity solution
>> costs, please visit http://www.xilinx.com/xpa/.
>>
>> University Faculty:
>> http://www.xilinx.com/university/professors/index.htm
>> ·       Universities may be eligible for full versions of design tools
>> at no charge. University professors must initiate the request at the
>> University Faculty link above.
>>
>> Thank you,
>> Xilinx Development System Team
>> --- Cut Here ---
>>
>> ... which is useless [I know what I want to use it for, so no sales
>> reps; The online store doesn't provide any option I can see; I can't
>> see distributors being interested in upgrading a kit I bought directly
>> from Xilinx; I'm not at university].
>>
>> I didn't actually read the reply until the next day due to work/home
>> email filters, so once I've read it, I send in another request,
>> pointing out that the canned reply wasn't useful and asking the same
>> question again, along with "Is it really the case that I have to but a
>> new piece of hardware (which I don't want or need) in order to extend
>> a license for a product I bought directly from you ?" because the only
>> way I can see it being possible on the xilinx site is to re-purchase
>> the same board, thus getting a new license.
>>
>> Guess what. A few seconds later I get back the exact *same* reply,
>> word for word. No attempt to read/parse the question I asked, just an
>> apparent canned reply for any license/purchase question.
>>
>> I wanted to work on this in the background, with a project that I
>> think could be useful for my work, but it's not official, so I can't
>> go to the support guys here at work. I would have liked to have tried
>> to use the same device manufacturer as the
>> tens-of-thousands-of-dollars boards that we have here at work, for
>> ease of later porting, but I'm now so frustrated by the lack of human
>> response, I'm going to look at Altera (or anyone else, really, all I
>> want is PCIe and some DDR ram)
>>
>> I *was* prepared to put down my own hard-earned cash to do this, but
>> I'll be damned if they're getting any of my money now, if they can't
>> even answer a simple question like this, I can't see them being any
>> use once I've spent the money.
>>
>> Giving up on Xilinx.
>
> Instead of ranting, maybe you should look at your approach.  What you
> call the "support" channel is just a minimum effort at helping those who
> don't really have support.  If they suggest that you contact sales, then
> why not contact sales?  I'm sure they will point you in the right
> direction.  They don't exist solely for taking orders.
>
> I haven't dealt with Xilinx in some years but I have the same issues
> with Lattice.  I find that human support through FAEs is pretty good.
> Also they have a separate channel for licenses which are updated every
> year for free.  Apparently unlike Xilinx, the Lattice license will stop
> your software from working when it expires.  That part royally sucks. It
> is always on a Friday after 5 PM when I fire up Lattice Diamond (or
> previously the "classic" tool) only to find it has expired and I won't
> be working on the project over the weekend as I had planned.  I am
> starting to learn however and have added the license expiration date to
> my calendar with a 2 week in advance reminder.
>

Yeah, that does suck.  I think the main difference is that Lattice is
using third party tools like Synplify whose licenses are time-limited
and Lattice can't do anything about it.  It was the same for xilinx
back when they used the Aldec front-end and FPGA Express for synthesis.
No chip provider wants your license to expire if that means you won't
be designing in and buying their parts.  However the third party tool
providers are not getting revenue from chip sales and need another
approach.  I seem to recall that Xilinx dropped Aldec (or more likely
the other way around) because Aldec accused Xilinx of not properly
counting the seats of Foundation tools.

-- 
Gabor

Article: 157660
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: Simon <google@gornall.net>
Date: Wed, 21 Jan 2015 23:06:49 -0800 (PST)
Links: << >>  << T >>  << A >>
Well, it turns out I can install Linux under Parallels on my Mac, fudge the=
 MAC address to be that of the old machine, launch ISE and it asks for a li=
cence file. I downloaded the licence file from Xilinx, installed it, and it=
 works well - it seemed to give me a new year's worth of time for any dates=
 that weren't marked as 'permanent' in fact, and there's no warning message=
s on launch.

So, no thanks to Xilinx (well, ok, I'll be fair: some thanks for making the=
 licensing system work this way), but many thanks to those who know more ab=
out xilinx licensing than I do.

As for contacting sales, the FPGA guys where I work have enough trouble get=
ting Xilinx to help *them* out, and they spend lots (the last board they ga=
ve me to write drivers for cost ~$25k, mainly due to the FPGAs, and it's no=
t as though we just build 1 at a time...). I (personally) spend very little=
. I've never yet had any luck with a sales(wo)man who didn't see any sort o=
f profit in it for him/her. If the post-sales support is really handled by =
'sales', then it ought to be renamed as such; just like if the 'support' se=
ction of the website isn't actually there to provide "support", then it's a=
lso badly named. All IMHO of course.

Anyway, all's well that ends well. I can get on and try to implement my des=
ign, hopefully show the FPGA guys something they won't laugh *too* much at,=
 and maybe it'll even be useful.
=20
Simon

Article: 157661
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: Svenn <svenn.bjerkem@gmail.com>
Date: Thu, 22 Jan 2015 10:32:22 +0100
Links: << >>  << T >>  << A >>
I've been using Xilinx tools at work for chips not supported by WebPack.
Process is as following:
* Ask my Xilinx distributor for a quote on Xilinx Logic Edition.
* Get the quote and put it into our company purchase system.
* Wait for our purchase to do their job
* Wait for email from Xilinx that a new license is available
* Go to my Xilinx license page to redeem the license we paid for
* Tie the license to a network NIC (we use floating license)
* Download license file and restart flexlm
* Care about updating for one year
* After one year, either buy new license or don't bother

According to my distributors excellent FAE:
* A purchased Xilinx license is valid forever
* Updates are available 1 year from purchase.
* After this, the last update within the 1 year time is fixed
* To get an update after 1 year has passed, buy a new license
* There is no upgrade price reduction.
* Going from Logic Edition to System Edition is System Edition price

Of all FPGA tools we have, Xilinx is the least difficult one. As long as 
we do development on new FPGA chips, we buy a license. When product goes 
into production and development stops, we have a perpetual right to use 
the dev tools from Xilinx for maintenance of our product.

I see all the time that sneaky bugs needs to be rooted out two or three 
years into the product life. Xilinx will still work on the old license 
code, while ModelSim and Synopsys will require us to keep paying yearly 
fees to be allowed to use for a week or two to find a bug.

-- 
Svenn

Article: 157662
Subject: Send a pulse across clocks
From: Leo <capossio.leonardo@gmail.com>
Date: Thu, 22 Jan 2015 06:05:23 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello, I want to send a pulse from one clock domain to another, knowing tha=
t from the time event that this pulse is generated in the source clock doma=
in it arrives in the first rising edge of the destination clock domain and =
lasts exactly one clock period of the destination clock domain. Now, I know=
 this problem is not generic and is subject to timing constraints and clock=
 frequency/phase relationship. So the question would be, how to implement i=
t best in RTL with Xilinx technology and what time constraints to apply fro=
m source to destination FF. In particular the destination clock is a little=
 over half of the source clock frequency, the phase between them is unknown=
 and may change over time.

Currently my idea is to use the asynchronous preset/clear of the destinatio=
n FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-seri=
es FPGAs) there must be some relation between the clocks that allows the mi=
nimum pulse width and propagation of the asynchronous signal.

Any help is appreaciated.

Article: 157663
Subject: Re: Send a pulse across clocks
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Thu, 22 Jan 2015 11:46:10 -0600
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2015 06:05:23 -0800, Leo wrote:

> Hello, I want to send a pulse from one clock domain to another, knowing
> that from the time event that this pulse is generated in the source
> clock domain it arrives in the first rising edge of the destination
> clock domain and lasts exactly one clock period of the destination clock
> domain.

Huh?  That's not at all clear.

You're saying that the pulse always arrives on "the first rising edge of 
the destination clock domain" -- you mean the first rising edge after 
power up?  Always?  Or do you mean the first rising edge ever?

Then you say the pulse lasts exactly one period of the destination clock 
domain -- how can it do that, when it's being sourced in a different 
domain?

> Now, I know this problem is not generic and is subject to timing
> constraints and clock frequency/phase relationship. So the question
> would be, how to implement it best in RTL with Xilinx technology and
> what time constraints to apply from source to destination FF. In
> particular the destination clock is a little over half of the source
> clock frequency, the phase between them is unknown and may change over
> time.
> 
> Currently my idea is to use the asynchronous preset/clear of the
> destination FF, which would mean that on an specific part (Xilinx
> Spartan 6 or 7-series FPGAs) there must be some relation between the
> clocks that allows the minimum pulse width and propagation of the
> asynchronous signal.

If the pulse _from_ the faster clock domain always lasts two source 
clocks, then you should be able to reliably capture it with a plain old 
register.  However, we get back to your unclear opening paragraph.

Assuming that the pulse is of some shorter width, then yes you need to do 
something different.  I don't know that you necessarily have LUT-by-LUT 
access to the preset (I'd have to spelunk through data sheets, or ask 
here).  If you don't, you may have to build an RS FF, which should be 
possible with just a few lines of code.  If you do that then you'll have 
some hold time requirement which the tools may or may not be able to 
calculate.

> Any help is appreaciated.

If you want what I think you want, it would be helpful to allow a few 
clock cycles of delay in the destination, to allow for synchronization (or 
metastability killing -- whatever).  You haven't said how quickly you need 
to act on this pulse.

-- 

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

Article: 157664
Subject: Re: Send a pulse across clocks
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Thu, 22 Jan 2015 09:50:17 -0800
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
Leo <capossio.leonardo@gmail.com> wrote:

> Hello, I want to send a pulse from one clock domain to another, knowing that from the time event that this pulse is generated in the source clock domain it arrives in the first rising edge of the destination clock domain and lasts exactly one clock period of the destination clock domain. Now, I know this problem is not generic and is subject to timing constraints and clock frequency/phase relationship. So the question would be, how to implement it best in RTL with Xilinx technology and what time constraints to apply from source to destination FF. In particular the destination clock is a little over half of the source clock frequency, the phase between them is unknown and may change over time.
> 
> Currently my idea is to use the asynchronous preset/clear of the destination FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-series FPGAs) there must be some relation between the clocks that allows the minimum pulse width and propagation of the asynchronous signal.
> 
> Any help is appreaciated.

Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
there has to be a bizarre and compelling reason for me to do otherwise.

Sending domain has a T-flop; so the pulse causes the output to
transition.  We don't care which way.  The output of the T-flop goes
into one flop, then a second, then a third, on the receiving domain.
First gets rid of metastability.  XOR of the second and the third is
your reconstructed pulse.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157665
Subject: Re: [RANT] XILINX, Are you freaking kidding me ?
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Thu, 22 Jan 2015 11:54:07 -0600
Links: << >>  << T >>  << A >>
On Wed, 21 Jan 2015 23:06:49 -0800, Simon wrote:

> Well, it turns out I can install Linux under Parallels on my Mac, fudge
> the MAC address to be that of the old machine, launch ISE and it asks
> for a licence file. I downloaded the licence file from Xilinx, installed
> it, and it works well - it seemed to give me a new year's worth of time
> for any dates that weren't marked as 'permanent' in fact, and there's no
> warning messages on launch.
> 
> So, no thanks to Xilinx (well, ok, I'll be fair: some thanks for making
> the licensing system work this way), but many thanks to those who know
> more about xilinx licensing than I do.
> 
> As for contacting sales, the FPGA guys where I work have enough trouble
> getting Xilinx to help *them* out, and they spend lots (the last board
> they gave me to write drivers for cost ~$25k, mainly due to the FPGAs,
> and it's not as though we just build 1 at a time...). I (personally)
> spend very little. I've never yet had any luck with a sales(wo)man who
> didn't see any sort of profit in it for him/her. If the post-sales
> support is really handled by 'sales', then it ought to be renamed as
> such; just like if the 'support' section of the website isn't actually
> there to provide "support", then it's also badly named. All IMHO of
> course.
> 
> Anyway, all's well that ends well. I can get on and try to implement my
> design, hopefully show the FPGA guys something they won't laugh *too*
> much at, and maybe it'll even be useful.

You may want to try your distributor.  It's been a few years since I've 
actively worked on anything FPGA (apparently I write HDL for my algorithms 
so that real FPGA guys have something to sneer at), but when I did, I got 
zero help from Xilinx, and great big loads of help from our local Avnet 
field applications engineer.  Avnet has some arrangement with Xilinx that 
makes sure that they get paid if you design in parts due to their efforts, 
and at least our local guy here has been incredibly helpful.

-- 

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

Article: 157666
Subject: Re: Send a pulse across clocks
From: Leo <capossio.leonardo@gmail.com>
Date: Thu, 22 Jan 2015 10:15:06 -0800 (PST)
Links: << >>  << T >>  << A >>
El jueves, 22 de enero de 2015, 14:46:17 (UTC-3), Tim Wescott escribi=F3:
> On Thu, 22 Jan 2015 06:05:23 -0800, Leo wrote:
>=20
> > Hello, I want to send a pulse from one clock domain to another, knowing
> > that from the time event that this pulse is generated in the source
> > clock domain it arrives in the first rising edge of the destination
> > clock domain and lasts exactly one clock period of the destination cloc=
k
> > domain.
>=20
> Huh?  That's not at all clear.
>=20
> You're saying that the pulse always arrives on "the first rising edge of=
=20
> the destination clock domain" -- you mean the first rising edge after=20
> power up?  Always?  Or do you mean the first rising edge ever?
>=20
> Then you say the pulse lasts exactly one period of the destination clock=
=20
> domain -- how can it do that, when it's being sourced in a different=20
> domain?
>=20
> > Now, I know this problem is not generic and is subject to timing
> > constraints and clock frequency/phase relationship. So the question
> > would be, how to implement it best in RTL with Xilinx technology and
> > what time constraints to apply from source to destination FF. In
> > particular the destination clock is a little over half of the source
> > clock frequency, the phase between them is unknown and may change over
> > time.
> >=20
> > Currently my idea is to use the asynchronous preset/clear of the
> > destination FF, which would mean that on an specific part (Xilinx
> > Spartan 6 or 7-series FPGAs) there must be some relation between the
> > clocks that allows the minimum pulse width and propagation of the
> > asynchronous signal.
>=20
> If the pulse _from_ the faster clock domain always lasts two source=20
> clocks, then you should be able to reliably capture it with a plain old=
=20
> register.  However, we get back to your unclear opening paragraph.
>=20
> Assuming that the pulse is of some shorter width, then yes you need to do=
=20
> something different.  I don't know that you necessarily have LUT-by-LUT=
=20
> access to the preset (I'd have to spelunk through data sheets, or ask=20
> here).  If you don't, you may have to build an RS FF, which should be=20
> possible with just a few lines of code.  If you do that then you'll have=
=20
> some hold time requirement which the tools may or may not be able to=20
> calculate.
>=20
> > Any help is appreaciated.
>=20
> If you want what I think you want, it would be helpful to allow a few=20
> clock cycles of delay in the destination, to allow for synchronization (o=
r=20
> metastability killing -- whatever).  You haven't said how quickly you nee=
d=20
> to act on this pulse.
>=20
> --=20
>=20
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

You are right, after re-reading, it isn't clear. I want the pulse generated=
 on the rising edge of the source clk to be transported to the destination =
clk domain in the first rising edge of the destination clk after the pulse =
was generated. In other words I want the destination clock to catch the pul=
se as fast as possible, and I also need the pulse to last a single clock cy=
cle of the destination clk (I plan to shift it down a shift reg to delay it=
).

I can leave with latency as long as this latency is always the same in dest=
ination clk cycles.

I need it because from the time that this pulse is generated in the source =
clk, I need to count exactly 14 clk cycles of the destination clk to catch =
correct data going down a pipeline on the destination clk.

Article: 157667
Subject: Re: Send a pulse across clocks
From: Leo <capossio.leonardo@gmail.com>
Date: Thu, 22 Jan 2015 10:21:34 -0800 (PST)
Links: << >>  << T >>  << A >>
El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribi=F3:
> On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
> Leo wrote:
>=20
> > Hello, I want to send a pulse from one clock domain to another, knowing=
 that from the time event that this pulse is generated in the source clock =
domain it arrives in the first rising edge of the destination clock domain =
and lasts exactly one clock period of the destination clock domain. Now, I =
know this problem is not generic and is subject to timing constraints and c=
lock frequency/phase relationship. So the question would be, how to impleme=
nt it best in RTL with Xilinx technology and what time constraints to apply=
 from source to destination FF. In particular the destination clock is a li=
ttle over half of the source clock frequency, the phase between them is unk=
nown and may change over time.
> >=20
> > Currently my idea is to use the asynchronous preset/clear of the destin=
ation FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-=
series FPGAs) there must be some relation between the clocks that allows th=
e minimum pulse width and propagation of the asynchronous signal.
> >=20
> > Any help is appreaciated.
>=20
> Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
> there has to be a bizarre and compelling reason for me to do otherwise.
>=20
> Sending domain has a T-flop; so the pulse causes the output to
> transition.  We don't care which way.  The output of the T-flop goes
> into one flop, then a second, then a third, on the receiving domain.
> First gets rid of metastability.  XOR of the second and the third is
> your reconstructed pulse.
>=20
> --=20
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

That is a good answer thank you. The only question I have is: does the XOR =
output always have the same delay in destionation clk cycles (3 cycles), or=
 there might be a case where it takes more or less ?

Article: 157668
Subject: Re: Send a pulse across clocks
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Thu, 22 Jan 2015 10:34:33 -0800
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2015 10:21:34 -0800 (PST)
Leo <capossio.leonardo@gmail.com> wrote:

> El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribi=C3=B3:
> > On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
> > Leo wrote:
> >=20
> > > Hello, I want to send a pulse from one clock domain to another, knowi=
ng that from the time event that this pulse is generated in the source cloc=
k domain it arrives in the first rising edge of the destination clock domai=
n and lasts exactly one clock period of the destination clock domain. Now, =
I know this problem is not generic and is subject to timing constraints and=
 clock frequency/phase relationship. So the question would be, how to imple=
ment it best in RTL with Xilinx technology and what time constraints to app=
ly from source to destination FF. In particular the destination clock is a =
little over half of the source clock frequency, the phase between them is u=
nknown and may change over time.
> > >=20
> > > Currently my idea is to use the asynchronous preset/clear of the dest=
ination FF, which would mean that on an specific part (Xilinx Spartan 6 or =
7-series FPGAs) there must be some relation between the clocks that allows =
the minimum pulse width and propagation of the asynchronous signal.
> > >=20
> > > Any help is appreaciated.
> >=20
> > Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
> > there has to be a bizarre and compelling reason for me to do otherwise.
> >=20
> > Sending domain has a T-flop; so the pulse causes the output to
> > transition.  We don't care which way.  The output of the T-flop goes
> > into one flop, then a second, then a third, on the receiving domain.
> > First gets rid of metastability.  XOR of the second and the third is
> > your reconstructed pulse.
> >=20
> > --=20
> > Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> > Email address domain is currently out of order.  See above to fix.
>=20
> That is a good answer thank you. The only question I have is: does the XO=
R output always have the same delay in destionation clk cycles (3 cycles), =
or there might be a case where it takes more or less ?

In rereading, it's not quite what you asked for, with a minimum latency
solution, nor what you later asked for with a deterministic latency
solution.

The problem is, with truly asynchronous clocks, shortening latency
increases risk, and deterministic latency is impossible.  Think about
a scope, triggering on your source clock edge.  The relative location
of your destination clock edge is uniformly distributed everywhere on
the screen, up to and including mere picoseconds either way from the
source edge.

That means that when you hit the first flop on the destination domain
(and that needs to be ONE flop, never ever ever two with an expectation
they'll behave the same) you have a guarantee that sometimes you'll
violate the setup timing of that flop.  When you do that, it goes
metastable -- the internal nodes hit a linear state that is neither 1
or zero, and stay there until the positive feedback pushes them to one
rail or the other, an amount of time that is probabilistic rather than
deterministic.  Whether it'll settle to the old or new value is
anyone's guess.

But the moral of the story is: accept that there's 1 clock of
variability in that latency and design your system to live with it.  If
you can't, then you can't have an async clock crossing there.

--=20
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


Article: 157669
Subject: Re: Send a pulse across clocks
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Thu, 22 Jan 2015 12:38:45 -0600
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2015 10:21:34 -0800, Leo wrote:

> El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribió:
>> On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
>> Leo wrote:
>> 
>> > Hello, I want to send a pulse from one clock domain to another,
>> > knowing that from the time event that this pulse is generated in the
>> > source clock domain it arrives in the first rising edge of the
>> > destination clock domain and lasts exactly one clock period of the
>> > destination clock domain. Now, I know this problem is not generic and
>> > is subject to timing constraints and clock frequency/phase
>> > relationship. So the question would be, how to implement it best in
>> > RTL with Xilinx technology and what time constraints to apply from
>> > source to destination FF. In particular the destination clock is a
>> > little over half of the source clock frequency, the phase between
>> > them is unknown and may change over time.
>> > 
>> > Currently my idea is to use the asynchronous preset/clear of the
>> > destination FF, which would mean that on an specific part (Xilinx
>> > Spartan 6 or 7-series FPGAs) there must be some relation between the
>> > clocks that allows the minimum pulse width and propagation of the
>> > asynchronous signal.
>> > 
>> > Any help is appreaciated.
>> 
>> Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
>> there has to be a bizarre and compelling reason for me to do otherwise.
>> 
>> Sending domain has a T-flop; so the pulse causes the output to
>> transition.  We don't care which way.  The output of the T-flop goes
>> into one flop, then a second, then a third, on the receiving domain.
>> First gets rid of metastability.  XOR of the second and the third is
>> your reconstructed pulse.
> 
> That is a good answer thank you. The only question I have is: does the
> XOR output always have the same delay in destionation clk cycles (3
> cycles), or there might be a case where it takes more or less ?

When the source and destination clock edges are close to happening at the 
same time there will be an uncertainty of which destination clock catches 
the transition on the T-flop -- but that uncertainty will be with you 
always anyway.

-- 

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

Article: 157670
Subject: Re: Send a pulse across clocks
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 22 Jan 2015 14:05:05 -0500
Links: << >>  << T >>  << A >>
Rob Gaddi wrote:

[snip]

> 
> That means that when you hit the first flop on the destination domain
> (and that needs to be ONE flop, never ever ever two with an expectation
> they'll behave the same) you have a guarantee that sometimes you'll
> violate the setup timing of that flop.  When you do that, it goes
> metastable -- the internal nodes hit a linear state that is neither 1
> or zero, and stay there until the positive feedback pushes them to one
> rail or the other, an amount of time that is probabilistic rather than
> deterministic.  Whether it'll settle to the old or new value is
> anyone's guess.
> 

This is a bit over-pessimistic.  The setup and hold time of a flop are
spec'd over PVT.  The metastability window is much much smaller than
the window specified by the setup and hold times.  What you do get
between the setup and hold time is a window when you can't know
for sure over all temperature, voltage, and process whether the
change in the input will propagate to the output on that clock
cycle, or whether it will not go through until the next cycle.

> But the moral of the story is: accept that there's 1 clock of
> variability in that latency and design your system to live with it.  If
> you can't, then you can't have an async clock crossing there.
> 

Again if you want to be pessimistic, you could add the setup/hold
time violation window to the destination clock period and call
that the variation in latency you will see.  However this ignores
the fact that the device will be operating at the same PVT
point on one cycle that it is on the next cycle.

Anyway the toggle business is a very good idea since it means you
don't need to deal with asynchronous set/reset in the destination
clock domain to stretch a short pulse.

-- 
Gabor

Article: 157671
Subject: Re: Send a pulse across clocks
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Thu, 22 Jan 2015 11:22:21 -0800
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2015 14:05:05 -0500
GaborSzakacs <gabor@alacron.com> wrote:

> Rob Gaddi wrote:
> 
> [snip]
> 
> > 
> > That means that when you hit the first flop on the destination domain
> > (and that needs to be ONE flop, never ever ever two with an expectation
> > they'll behave the same) you have a guarantee that sometimes you'll
> > violate the setup timing of that flop.  When you do that, it goes
> > metastable -- the internal nodes hit a linear state that is neither 1
> > or zero, and stay there until the positive feedback pushes them to one
> > rail or the other, an amount of time that is probabilistic rather than
> > deterministic.  Whether it'll settle to the old or new value is
> > anyone's guess.
> > 
> 
> This is a bit over-pessimistic.  The setup and hold time of a flop are
> spec'd over PVT.  The metastability window is much much smaller than
> the window specified by the setup and hold times.  What you do get
> between the setup and hold time is a window when you can't know
> for sure over all temperature, voltage, and process whether the
> change in the input will propagate to the output on that clock
> cycle, or whether it will not go through until the next cycle.
> 

Right, but with an async clock crossing you are GUARANTEED to
occasionally end up inside of that admittedly small window.
Likewise, when you do, the probability function of how long resolution
will take has (if I recall correctly) an exponential PDF.  On modern
FPGAs, the resolution function becomes more likely to be resolved than
not in something absurd like 100 ps, making the chances that it's not
done resolving in the span of a reasonable clock period something on the
order of being hit by a bus that is being hit by lightning. 

But you still don't know whether you're going to get a 0 or a 1.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157672
Subject: Re: Send a pulse across clocks
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 22 Jan 2015 11:38:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, January 22, 2015 at 1:21:37 PM UTC-5, Leo wrote:

> That is a good answer thank you. The only question I have is: does the XO=
R output always have the same delay in destionation clk cycles (3 cycles), =
or there might be a case where it takes more or less ?

Since the clock phases are unknown and (presumably) different and shifting =
relative to each other, then it could be longer.  The most likely answer is=
 that it would occasionally take one extra clock.  If you consider metastab=
ility, then there could be likely yet another extra clock or an exponential=
ly decreasing probability of even more.  There is no way to guarantee that =
the very next destination clock edge will be the one that grabs the pulse s=
ince you haven't designed in a way to guarantee that you won't violate setu=
p/hold time requirements.

So the delay in clock cycles will look something like this:
3 : Happens when setup/hold time is not violated
4 : May happen when setup/hold time is violated but no metastability
5 or more : Will happen when setup/hold time is violated and metastability =
occurs

Kevin Jennings

Article: 157673
Subject: RS Flip-flops, was: Send a pulse across clocks
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 23 Jan 2015 02:14:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <seemywebsite@myfooter.really> wrote:
 
> Assuming that the pulse is of some shorter width, then yes you need to do 
> something different.  I don't know that you necessarily have LUT-by-LUT 
> access to the preset (I'd have to spelunk through data sheets, or ask 
> here).  If you don't, you may have to build an RS FF, which should be 
> possible with just a few lines of code.  If you do that then you'll have 
> some hold time requirement which the tools may or may not be able to 
> calculate.

Not so long ago, I wrote this:

module S2504(out, in, phi1, phi2);
output out;
input in, phi1, phi2;
reg q1, q2;
reg [511:0] s1, s2;
wire R, S;
always @(posedge phi1) q1 <= in;
always @(posedge phi2) q2 <= in;
always @(negedge phi2) s1 <= {s1[510:0], q1};
always @(negedge phi1) s2 <= {s2[510:0], q2};
assign R=~(S & phi1), S=~(R & phi2);
assign out=(R & s2[511]) | (S & s1[511]);
endmodule

There is a warning message about a combinatorial loop, but I believe
it works.

In case it isn't obvious, it is a shift register with a two-phase
clock that shifts on the falling edge of either phase. The output
is from the last shift (falling edge). 

The real 2504 is a pMOS dynamic shift register.

-- glen


Article: 157674
Subject: Re: Send a pulse across clocks
From: rickman <gnuarm@gmail.com>
Date: Thu, 22 Jan 2015 21:56:05 -0500
Links: << >>  << T >>  << A >>
On 1/22/2015 12:50 PM, Rob Gaddi wrote:
> On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
> Leo <capossio.leonardo@gmail.com> wrote:
>
>> Hello, I want to send a pulse from one clock domain to another, knowing that from the time event that this pulse is generated in the source clock domain it arrives in the first rising edge of the destination clock domain and lasts exactly one clock period of the destination clock domain. Now, I know this problem is not generic and is subject to timing constraints and clock frequency/phase relationship. So the question would be, how to implement it best in RTL with Xilinx technology and what time constraints to apply from source to destination FF. In particular the destination clock is a little over half of the source clock frequency, the phase between them is unknown and may change over time.
>>
>> Currently my idea is to use the asynchronous preset/clear of the destination FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-series FPGAs) there must be some relation between the clocks that allows the minimum pulse width and propagation of the asynchronous signal.
>>
>> Any help is appreaciated.
>
> Pulse-toggle-pulse synchronizer.  My go-to answer for this problem;
> there has to be a bizarre and compelling reason for me to do otherwise.
>
> Sending domain has a T-flop; so the pulse causes the output to
> transition.  We don't care which way.  The output of the T-flop goes
> into one flop, then a second, then a third, on the receiving domain.
> First gets rid of metastability.  XOR of the second and the third is
> your reconstructed pulse.

I think this is similar to the circuit I use except I use feedback from 
the To clock domain to make the From FF toggle.  This makes it 
impossible for too frequent triggers in the first domain screwing up the 
pulse in the other domain.

   FromLogic : process (FromClk, FromReset)
   begin
     if (FromReset = '1') then
       FromSync  <= '0';
     elsif (rising_edge(FstClk)) then
       FromSync  <= not ToSync;
     end if;
   end process FromLogic;

   ToLogic : process (ToClk, ToReset)
   begin
     if (ToReset = '1') then
       ToSync  <= '0';
       ToSync_d  <= '0';
     elsif (rising_edge(FstClk)) then
       ToSync  <= FromSync;
       ToSync_d  <= ToSync;
     end if;
   end process ToLogic;

   PulseOut <= ToSync XOR ToSync_d;

I haven't tested the above code so I won't guaranty it works correctly. 
  The idea is that either edge of FromSync creates a pulse in the To 
clock domain.  Only one edge ca be generated until the first edge is 
"seen" by the logic in the To domain.  The relative speeds of the two 
clock domains is not important.

Some people add another FF in the To domain to help with metastability. 
  But what you really need is slack time which should be no problem if 
you spec it in the timing constraint of the appropriate logic paths.

-- 

Rick



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