Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 154500

Article: 154500
Subject: Re: Error while running implementation through unix command line
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 19 Nov 2012 14:14:38 -0800
Links: << >>  << T >>  << A >>
On Mon, 19 Nov 2012 14:07:23 -0800 (PST)
sathishkumar5991@gmail.com wrote:

> 
> Hi Rob,
> 
> I am working on my assignment which is to use scripting to invoke all the xilinx tools such as synthesis,Translate,map,Par and bitgen.I am using makefile for my assignment.I have a problem running this command in the terminal.
> 
> xst -ifn filename.xst -ofn filename.syr
> 
> The error in the terminal reads like this:
> 
> make: execvp : xst :permission denied.
> Please help me on this as i am new to xilinx.Thanks,
> 
> Sathish

It sounds like you're having permission problems with the actual
executable.  When you say you're running that command in the terminal,
are you actually running it straight from a command prompt, or are you
running it through your makefile?

Also, are you on Windows or Linux?

You need to get things to where when you type just xst at the command
prompt, you get into the XST program's extremely unuseful shell
interface.  If you can do that, you should be able to run it from a
makefile as well; until you can there's no reason to be bothering with
the scripts.

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

Article: 154501
Subject: Re: Error while running implementation through unix command line
From: sathishkumar5991@gmail.com
Date: Mon, 19 Nov 2012 14:40:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, 19 November 2012 17:14:39 UTC-5, Rob Gaddi  wrote:
> On Mon, 19 Nov 2012 14:07:23 -0800 (PST)
> 
> sathishkumar5991@gmail.com wrote:
> 
> 
> 
> > 
> 
> > Hi Rob,
> 
> > 
> 
> > I am working on my assignment which is to use scripting to invoke all the xilinx tools such as synthesis,Translate,map,Par and bitgen.I am using makefile for my assignment.I have a problem running this command in the terminal.
> 
> > 
> 
> > xst -ifn filename.xst -ofn filename.syr
> 
> > 
> 
> > The error in the terminal reads like this:
> 
> > 
> 
> > make: execvp : xst :permission denied.
> 
> > Please help me on this as i am new to xilinx.Thanks,
> 
> > 
> 
> > Sathish
> 
> 
> 
> It sounds like you're having permission problems with the actual
> 
> executable.  When you say you're running that command in the terminal,
> 
> are you actually running it straight from a command prompt, or are you
> 
> running it through your makefile?
> 
> 
> 
> Also, are you on Windows or Linux?
> 
> 
> 
> You need to get things to where when you type just xst at the command
> 
> prompt, you get into the XST program's extremely unuseful shell
> 
> interface.  If you can do that, you should be able to run it from a
> 
> makefile as well; until you can there's no reason to be bothering with
> 
> the scripts.
> 
> 
> 
> -- 
> 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> 
> Email address domain is currently out of order.  See above to fix.

Sorry for not giving the complete details.I am using linux. Here is what i did

I have created my makefile taking a project from one of the previous assignments.
1.I created a directory which has my makefile .
2.I copied my  *.v and *.xst files from one of the assignments to that directory.
3.Opened the directory which has my makefile in the terminal and typed  "make".

The error message displayed in my terminal when i run the above command  is       
make:execvp:xst: permission denied
make : **** [filename.ngc] error 127.Please let me know what i got to do

Article: 154502
Subject: Re: Error while running implementation through unix command line
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 19 Nov 2012 14:48:15 -0800
Links: << >>  << T >>  << A >>
On Mon, 19 Nov 2012 14:40:38 -0800 (PST)
sathishkumar5991@gmail.com wrote:

> On Monday, 19 November 2012 17:14:39 UTC-5, Rob Gaddi  wrote:
> > On Mon, 19 Nov 2012 14:07:23 -0800 (PST)
> > 
> > sathishkumar5991@gmail.com wrote:
> > 
> > 
> > 
> > > 
> > 
> > > Hi Rob,
> > 
> > > 
> > 
> > > I am working on my assignment which is to use scripting to invoke all the xilinx tools such as synthesis,Translate,map,Par and bitgen.I am using makefile for my assignment.I have a problem running this command in the terminal.
> > 
> > > 
> > 
> > > xst -ifn filename.xst -ofn filename.syr
> > 
> > > 
> > 
> > > The error in the terminal reads like this:
> > 
> > > 
> > 
> > > make: execvp : xst :permission denied.
> > 
> > > Please help me on this as i am new to xilinx.Thanks,
> > 
> > > 
> > 
> > > Sathish
> > 
> > 
> > 
> > It sounds like you're having permission problems with the actual
> > 
> > executable.  When you say you're running that command in the terminal,
> > 
> > are you actually running it straight from a command prompt, or are you
> > 
> > running it through your makefile?
> > 
> > 
> > 
> > Also, are you on Windows or Linux?
> > 
> > 
> > 
> > You need to get things to where when you type just xst at the command
> > 
> > prompt, you get into the XST program's extremely unuseful shell
> > 
> > interface.  If you can do that, you should be able to run it from a
> > 
> > makefile as well; until you can there's no reason to be bothering with
> > 
> > the scripts.
> > 
> > 
> > 
> > -- 
> > 
> > Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> > 
> > Email address domain is currently out of order.  See above to fix.
> 
> Sorry for not giving the complete details.I am using linux. Here is what i did
> 
> I have created my makefile taking a project from one of the previous assignments.
> 1.I created a directory which has my makefile .
> 2.I copied my  *.v and *.xst files from one of the assignments to that directory.
> 3.Opened the directory which has my makefile in the terminal and typed  "make".
> 
> The error message displayed in my terminal when i run the above command  is       
> make:execvp:xst: permission denied
> make : **** [filename.ngc] error 127.Please let me know what i got to do

As I said, the first thing you need to do is figure out if you have
execute permissions on xst at all.  Just type 'xst' at the command
prompt and see what you get; I'm betting you can't run it at all.

I'm guessing you're at a university.  If I'm right, and I'm right
that you can't run xst, then what you need to do is contact your system
administrator and find out why you can't.  Most likely it's locked down
to some group that you need to be made a member of.

Or when you type xst, you'll find that Linux can't find your executable
at all; it's not on your PATH.  In that case you need to get your PATH
configured correctly, there's a file in the Xilinx install that'll be
called something like settings32.csh that can help you.

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

Article: 154503
Subject: Re: Error while running implementation through unix command line
From: sathishkumar5991@gmail.com
Date: Mon, 19 Nov 2012 14:57:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, 19 November 2012 17:48:16 UTC-5, Rob Gaddi  wrote:
> On Mon, 19 Nov 2012 14:40:38 -0800 (PST)
> 
> sathishkumar5991@gmail.com wrote:
> 
> 
> 
> > On Monday, 19 November 2012 17:14:39 UTC-5, Rob Gaddi  wrote:
> 
> > > On Mon, 19 Nov 2012 14:07:23 -0800 (PST)
> 
> > > 
> 
> > > sathishkumar5991@gmail.com wrote:
> 
> > > 
> 
> > > 
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > Hi Rob,
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > I am working on my assignment which is to use scripting to invoke all the xilinx tools such as synthesis,Translate,map,Par and bitgen.I am using makefile for my assignment.I have a problem running this command in the terminal.
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > xst -ifn filename.xst -ofn filename.syr
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > The error in the terminal reads like this:
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > make: execvp : xst :permission denied.
> 
> > > 
> 
> > > > Please help me on this as i am new to xilinx.Thanks,
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > Sathish
> 
> > > 
> 
> > > 
> 
> > > 
> 
> > > It sounds like you're having permission problems with the actual
> 
> > > 
> 
> > > executable.  When you say you're running that command in the terminal,
> 
> > > 
> 
> > > are you actually running it straight from a command prompt, or are you
> 
> > > 
> 
> > > running it through your makefile?
> 
> > > 
> 
> > > 
> 
> > > 
> 
> > > Also, are you on Windows or Linux?
> 
> > > 
> 
> > > 
> 
> > > 
> 
> > > You need to get things to where when you type just xst at the command
> 
> > > 
> 
> > > prompt, you get into the XST program's extremely unuseful shell
> 
> > > 
> 
> > > interface.  If you can do that, you should be able to run it from a
> 
> > > 
> 
> > > makefile as well; until you can there's no reason to be bothering with
> 
> > > 
> 
> > > the scripts.
> 
> > > 
> 
> > > 
> 
> > > 
> 
> > > -- 
> 
> > > 
> 
> > > Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> 
> > > 
> 
> > > Email address domain is currently out of order.  See above to fix.
> 
> > 
> 
> > Sorry for not giving the complete details.I am using linux. Here is what i did
> 
> > 
> 
> > I have created my makefile taking a project from one of the previous assignments.
> 
> > 1.I created a directory which has my makefile .
> 
> > 2.I copied my  *.v and *.xst files from one of the assignments to that directory.
> 
> > 3.Opened the directory which has my makefile in the terminal and typed  "make".
> 
> > 
> 
> > The error message displayed in my terminal when i run the above command  is       
> 
> > make:execvp:xst: permission denied
> 
> > make : **** [filename.ngc] error 127.Please let me know what i got to do
> 
> 
> 
> As I said, the first thing you need to do is figure out if you have
> 
> execute permissions on xst at all.  Just type 'xst' at the command
> 
> prompt and see what you get; I'm betting you can't run it at all.
> 
> 
> 
> I'm guessing you're at a university.  If I'm right, and I'm right
> 
> that you can't run xst, then what you need to do is contact your system
> 
> administrator and find out why you can't.  Most likely it's locked down
> 
> to some group that you need to be made a member of.
> 
> 
> 
> Or when you type xst, you'll find that Linux can't find your executable
> 
> at all; it's not on your PATH.  In that case you need to get your PATH
> 
> configured correctly, there's a file in the Xilinx install that'll be
> 
> called something like settings32.csh that can help you.
> 
> 
> 
> -- 
> 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> 
> Email address domain is currently out of order.  See above to fix.

Yeah.When i just run xst in command prompt it says permission denied.And yes,i am doing my maters.I will ask about this with my system administrator.Is this the reason that i am not able to run the commands like ngdbuild,map,par,bitgen.
It says command not found for all these commands 

Article: 154504
Subject: Re: Question about TCL command of modelsim
From: Allan Herriman <allanherriman@hotmail.com>
Date: 20 Nov 2012 09:15:22 GMT
Links: << >>  << T >>  << A >>
On Mon, 19 Nov 2012 15:55:06 +0000, HT-Lab wrote:

> On 18/11/2012 11:04, Allan Herriman wrote:
>> On Sat, 17 Nov 2012 09:05:22 +0000, HT-Lab wrote:
>>
>>> On 16/11/2012 19:31, fl wrote:
>>>> Hi,
>>>>
> ..
>>>
>>> I am not sure what the number is after the "after" command, anybody?
>>>
>>> Hans.
>>> www.ht-lab.com
>>>
> ..
>>
>> http://www.tcl.tk/man/tcl/TclCmd/after.htm
>>
>> "after ms Ms must be an integer giving a time in milliseconds."
>>
>> Regards,
>> Allan
>>
> Sorry I wasn't clear, I meant the number displayed by Modelsim after the
> "after" command:
> 
> For example:
> 
> after 100 echo "Hello World"
> # after#1668 # Hello World after 100 echo "Hello World"
> # after#1677 # Hello World after 100 echo "Hello World"
> # after#1685 # Hello World
> 
> Where does 1668,1677 etc come from? It doesn't seem to be related to any
> of the simstats values.
> 
> Not important, just curious,


>From the link I posted earlier:

"The after command returns an identifier that can be used to cancel the 
delayed command using after cancel. "


Regards,
Allan

Article: 154505
Subject: Re: Question about TCL command of modelsim
From: HT-Lab <hans64@htminuslab.com>
Date: Tue, 20 Nov 2012 13:42:52 +0000
Links: << >>  << T >>  << A >>
On 20/11/2012 09:15, Allan Herriman wrote:
..
>>>
>> Sorry I wasn't clear, I meant the number displayed by Modelsim after the
>> "after" command:
>>
>> For example:
>>
>> after 100 echo "Hello World"
>> # after#1668 # Hello World after 100 echo "Hello World"
>> # after#1677 # Hello World after 100 echo "Hello World"
>> # after#1685 # Hello World
>>
>> Where does 1668,1677 etc come from? It doesn't seem to be related to any
>> of the simstats values.
>>
>> Not important, just curious,
>
>
>  From the link I posted earlier:
>
> "The after command returns an identifier that can be used to cancel the
> delayed command using after cancel. "
>
>
> Regards,
> Allan
>

Ah, yes, I should have RTFWP :-)

Thanks,
Hans
www.ht-lab.com


Article: 154506
Subject: Spartan 3A startup
From: Jon Elson <elson@pico-systems.com>
Date: Tue, 20 Nov 2012 12:35:07 -0600
Links: << >>  << T >>  << A >>
So, after being assured Spartan 3A should be around for a while
(Thanks, all who commented) I made a board for a Spartan XC3S50A
in the 144 lead package.  I am using an SST25VF010A serial SPI
PROM for configuration.  I have my own reset monitor to drive
the PROG-B/ pin, and that seems to be working correctly.
I have it set for the master SPI mode, with M<2:0> set
for 001 and VS<2:0> set for 101 as the Xilinx config doc
says to do.

But, at power-on, I don't get any configuration activity.
What I see is short positive pulses on all the pins connected to the
serial PROM, and then they go Hi-Z and fall slowly back to zero.
This repeats at about a 1 second rate.  Manually triggering
the PROG_B/ doesn't seem to do anything.  I have left INIT_B
open, is this right?

The config document for SPI shows some greyed-out resistors,
with no explanation in the text that I can find about what
they are for or whether they are needed.  I know Spartan 2E
needed a 3.3K pull-up on the INIT pin.

So, any from the trenches experience with SPI configuration of
a Spartan 3A would be greatly appreciated!

Thanks,

Jon


Article: 154507
Subject: Re: Spartan 3A startup
From: Jon Elson <jmelson@wustl.edu>
Date: Tue, 20 Nov 2012 15:01:26 -0600
Links: << >>  << T >>  << A >>
Jon Elson wrote:

OOps, I think I found at least the first goof.  I forgot to hook
up VCCAUX!  I thought it was for special voltage output drivers,
but not so.

Jon

Article: 154508
Subject: Re: Spartan 3A startup
From: Jon Elson <elson@pico-systems.com>
Date: Wed, 21 Nov 2012 00:03:04 -0600
Links: << >>  << T >>  << A >>
> Jon Elson wrote:
> 
> OOps, I think I found at least the first goof.  I forgot to hook
> up VCCAUX!
Ah, that helped a lot!  Next problem turned out to be that the
bit ordering of an MCS file is reversed for Xilinx or SPI
EPROM chips in the file.  When I selected the PROM formatter
to make Xilinx EPROM files instead of SPI, the FPGA accepted
the configuration.  It now is doing things that look right on
a scope, but it doesn't seem to be communicating with the
test computer.  I'll probably have to hook up the logic
analyzer to see where it is going wrong.

Jon

Article: 154509
Subject: Re: Spartan 3A startup
From: Gabor <gabor@szakacs.invalid>
Date: Wed, 21 Nov 2012 17:09:16 -0500
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> So, after being assured Spartan 3A should be around for a while
> (Thanks, all who commented) I made a board for a Spartan XC3S50A
> in the 144 lead package.  I am using an SST25VF010A serial SPI
> PROM for configuration.  I have my own reset monitor to drive
> the PROG-B/ pin, and that seems to be working correctly.
> I have it set for the master SPI mode, with M<2:0> set
> for 001 and VS<2:0> set for 101 as the Xilinx config doc
> says to do.
> 
> But, at power-on, I don't get any configuration activity.
> What I see is short positive pulses on all the pins connected to the
> serial PROM, and then they go Hi-Z and fall slowly back to zero.
> This repeats at about a 1 second rate.  Manually triggering
> the PROG_B/ doesn't seem to do anything.  I have left INIT_B
> open, is this right?
> 
> The config document for SPI shows some greyed-out resistors,
> with no explanation in the text that I can find about what
> they are for or whether they are needed.  I know Spartan 2E
> needed a 3.3K pull-up on the INIT pin.
> 
> So, any from the trenches experience with SPI configuration of
> a Spartan 3A would be greatly appreciated!
> 
> Thanks,
> 
> Jon
> 
Even before reading your next post I suspected a power issue.  Also
INIT_B should be pulled up.  If it has an internal pullup, that might
be OK, but the configuration process will be delayed if INIT_B
stays low after releasing PROGRAM_B, so I usually add an external
pullup anyway.

-- Gabor

Article: 154510
Subject: Set-up and hold times and metastability
From: "James823" <3681@embeddedrelated>
Date: Thu, 22 Nov 2012 01:35:31 -0600
Links: << >>  << T >>  << A >>
Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

If not, then even something as simple as testing a switch is pressed would
cause problems right? 

Thanks for the help
James

-- PS sorry if this is a double post, I got an error when previously
sending	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154511
Subject: Re: Set-up and hold times and metastability
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 22 Nov 2012 08:27:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
James823 <3681@embeddedrelated> wrote:
 
> I've been looking at synchronising data across clock domains, and have
> managed to confuse myself.
> Can someone confirm (or correct me) that the following is true.
 
> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?

Doesn't seem right to me. If D has the same value as Q, then there
should be no problem. If not, it seems to me just as bad as changing Q.
 
> If not, then even something as simple as testing a switch is pressed would
> cause problems right? 

The traditional method of using a second FF should still work. 

Also, remember the second problem that comes from not meeting
setup/hold, when you have more than one FF some might get the new
value, some keep the old. That is completely separate from
metastability, but also causes systems to fail.

-- glen

Article: 154512
Subject: Re: Set-up and hold times and metastability
From: Jon <jon@beniston.com>
Date: Thu, 22 Nov 2012 02:02:21 -0800 (PST)
Links: << >>  << T >>  << A >>
> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?

No, the enable will have a setup and hold time as well.

Even async resets can cause metastability, if it violates the recovery time.

> If not, then even something as simple as testing a switch is pressed would
> cause problems right? 

Yes. 

Depending on the type of switch, you also might need to consider debouncing.

Cheers,
Jon

Article: 154513
Subject: Re: Set-up and hold times and metastability
From: Mike Perkins <spam@spam.com>
Date: Thu, 22 Nov 2012 14:35:41 +0000
Links: << >>  << T >>  << A >>
On 22/11/2012 07:35, James823 wrote:
> Hi,
>
> I've been looking at synchronising data across clock domains, and have
> managed to confuse myself.
> Can someone confirm (or correct me) that the following is true.
>
> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?

The enable is really a latch enable with all the same issues of 
metastability of a clock.

> If not, then even something as simple as testing a switch is pressed would
> cause problems right?
>

There are a number of ways of achieving moving data across clock domains.

Simplest is to use a fast clock, where the clock rate is many times the 
data rate.  The original data clock can be sampled to determine when it 
transitions and the data read when it should be stable, if necessary 
using suitably delayed data using parallel latches.

A typical method is to buffer the data in a FIFO which typically uses 
Gray code counters for pointers.  Input and output valid data enables 
can be built into the FIFO.

I often use Block Ram based FIFO for moving line or block data from a 
video source clock domain to memory and back again.  Here I might use 
flags to signify when a block of data is ready for the second clock domain.

In general the problem is reduced to having a single signal to denote 
valid data.  Where any uncertainty will not by itself corrupt data.

Hope that helps.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 154514
Subject: Re: Set-up and hold times and metastability
From: rickman <gnuarm@gmail.com>
Date: Thu, 22 Nov 2012 12:33:20 -0500
Links: << >>  << T >>  << A >>
On 11/22/2012 9:35 AM, Mike Perkins wrote:
> On 22/11/2012 07:35, James823 wrote:
>> Hi,
>>
>> I've been looking at synchronising data across clock domains, and have
>> managed to confuse myself.
>> Can someone confirm (or correct me) that the following is true.
>>
>> Metastability may occur if the input D changes value during the set-up
>> and
>> hold times, however the enable can be completely asynchronous without
>> ever
>> causing a problem?
>
> The enable is really a latch enable with all the same issues of
> metastability of a clock.
>
>> If not, then even something as simple as testing a switch is pressed
>> would
>> cause problems right?
>>
>
> There are a number of ways of achieving moving data across clock domains.
>
> Simplest is to use a fast clock, where the clock rate is many times the
> data rate. The original data clock can be sampled to determine when it
> transitions and the data read when it should be stable, if necessary
> using suitably delayed data using parallel latches.

What???  How do you "sample" the input without dealing with 
metastability in those samples?


> A typical method is to buffer the data in a FIFO which typically uses
> Gray code counters for pointers. Input and output valid data enables can
> be built into the FIFO.

I'm not sure what circuit you are describing.  The circuit I have always 
used is one where the enable or clock from the sending domain is run 
through a handshake circuit that synchronizes it to the receiving 
domain.  If necessary the data is buffered in a register.  A FIFO is 
only needed when the data rate can burst faster than the receiving clock 
rate.


> I often use Block Ram based FIFO for moving line or block data from a
> video source clock domain to memory and back again. Here I might use
> flags to signify when a block of data is ready for the second clock domain.
>
> In general the problem is reduced to having a single signal to denote
> valid data. Where any uncertainty will not by itself corrupt data.
>
> Hope that helps.
>

Another way to deal with the problem is to minimize and encapsulate it. 
  This means using a single clock for the entire FPGA design other than 
the I/O interfaces where you sync the signals as soon as possible.

Rick

Article: 154515
Subject: Re: Set-up and hold times and metastability
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 22 Nov 2012 10:40:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, November 22, 2012 2:35:31 AM UTC-5, James823 wrote:
> however the enable can be completely asynchronous without ever causing a
> problem?

The rule is that every input to a device that samples one signal with anoth=
er will have either setup/hold or (frequently) both requirements.  Flip flo=
ps, latches, memory, fifos are all examples of devices that sample one sign=
al (the input data) with another signal (the clock).

It's not clear when you refer to 'enable' if you're referring to the clock =
enable of a flip flop (in which case the above rule applies since 'enable' =
is just another input to the logic feeding the flip flop).  Or perhaps you =
mean a transparent latch (in which case the above rule applies...but setup/=
hold requirements will exist for the other signals relative to the active t=
o inactive edge of the enable signal).

Even the supposed 'asynchronous' reset or preset input to a flip flop will =
have timing requirements.  Specifically, the time that the reset/preset inp=
ut is released will almost always need to be controlled relative to the clo=
ck.  In most cases, it cannot be simply allowed to go inactive at any opint=
 in the clock cycle.

Kevin Jennings

Article: 154516
Subject: Re: Set-up and hold times and metastability
From: Mike Perkins <spam@spam.com>
Date: Thu, 22 Nov 2012 18:40:46 +0000
Links: << >>  << T >>  << A >>
On 22/11/2012 17:33, rickman wrote:
> On 11/22/2012 9:35 AM, Mike Perkins wrote:
>> On 22/11/2012 07:35, James823 wrote:
>>> Hi,
>>>
>>> I've been looking at synchronising data across clock domains, and
>>> have managed to confuse myself. Can someone confirm (or correct
>>> me) that the following is true.
>>>
>>> Metastability may occur if the input D changes value during the
>>> set-up and hold times, however the enable can be completely
>>> asynchronous without ever causing a problem?
>>
>> The enable is really a latch enable with all the same issues of
>> metastability of a clock.
>>
>>> If not, then even something as simple as testing a switch is
>>> pressed would cause problems right?
>>>
>>
>> There are a number of ways of achieving moving data across clock
>> domains.
>>
>> Simplest is to use a fast clock, where the clock rate is many times
>> the data rate. The original data clock can be sampled to determine
>> when it transitions and the data read when it should be stable, if
>> necessary using suitably delayed data using parallel latches.
>
> What???  How do you "sample" the input without dealing with
> metastability in those samples?

By taking a latched clock being high say for 2 High-Speed clocks before
accepting it as a real clock-high.

>> A typical method is to buffer the data in a FIFO which typically
>> uses Gray code counters for pointers. Input and output valid data
>> enables can be built into the FIFO.
>
> I'm not sure what circuit you are describing.  The circuit I have
> always used is one where the enable or clock from the sending domain
> is run through a handshake circuit that synchronizes it to the
> receiving domain.  If necessary the data is buffered in a register.
> A FIFO is only needed when the data rate can burst faster than the
> receiving clock rate.

I agree, it depends on relative clock speeds, the continuity of data,
whilst it is sent, and how it can be received by each clock domain.

>> I often use Block Ram based FIFO for moving line or block data from
>> a video source clock domain to memory and back again. Here I might
>> use flags to signify when a block of data is ready for the second
>> clock domain.
>>
>> In general the problem is reduced to having a single signal to
>> denote valid data. Where any uncertainty will not by itself corrupt
>> data.
>>
>> Hope that helps.
>>
>
> Another way to deal with the problem is to minimize and encapsulate
> it. This means using a single clock for the entire FPGA design other
> than the I/O interfaces where you sync the signals as soon as
> possible.

Entirely agree, but that's not always possible.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 154517
Subject: Re: Set-up and hold times and metastability
From: "James823" <3681@embeddedrelated>
Date: Thu, 22 Nov 2012 13:42:50 -0600
Links: << >>  << T >>  << A >>
>On 11/22/2012 9:35 AM, Mike Perkins wrote:
>> On 22/11/2012 07:35, James823 wrote:
>>> Hi,
>>>
>>> I've been looking at synchronising data across clock domains, and have
>>> managed to confuse myself.
>>> Can someone confirm (or correct me) that the following is true.
>>>
>>> Metastability may occur if the input D changes value during the set-up
>>> and
>>> hold times, however the enable can be completely asynchronous without
>>> ever
>>> causing a problem?
>>
>> The enable is really a latch enable with all the same issues of
>> metastability of a clock.

[Mike]
This is where I have a problem. My understanding is that internally, the
clock is simply gated by the enable, so the effect of an asynchronous
enable is that the (clock AND enable) signal can have arbitrarily small
pulse width, i.e. if the following occurs:
 0) Initially clock is '0', enable is '1'
 1) clock goes to '1'
 2) enable goes to '0' after 1 ps or some other arbitrary time

Now, consider the standard NAND (or NOR) gate implementation as 2 layers of
SR latches. So long as the (clock AND enable) pulse width is sufficiently
long to propagate through the two NAND gates which it is connected, the
signal has now reached layer 1. Again, because the input was a pulse, so
too will this signal. The same thing now happens between the inputs to
layer 2, and the output updates. 
The reason for metastability caused by D changing is that a change in D
needs to propagate through 3 stages of NAND gates (due to the feedback
structure) before it reaches the inputs to layer 2.
This explains why we now typically have negative hold times and positive
set-up times. The clock takes 1 NAND propagation to get to the inputs of
layer 2, but the D signal takes 3, hence if the D signal changes 1 NAND
prop. time before the clock changes, the clock will reach the layer 2
inputs before the D signal i.e. negative hold time. 

Following the signals through like this, I can't see any reason that a
small pulse width will cause metastability at all. In fact the only issue I
can see is that if the pulse is short enough, then the signal won't
propagate because of the capacitance of the gates and internal
interconnect. However, this just means that the signal never gets anywhere,
so it's as if the pulse never occurred - hardly a problem at all.

Where's the flaw in my reasoning?

>>
>>> If not, then even something as simple as testing a switch is pressed
>>> would
>>> cause problems right?
>>>
>>
>> There are a number of ways of achieving moving data across clock
domains.
>>
>> Simplest is to use a fast clock, where the clock rate is many times the
>> data rate. The original data clock can be sampled to determine when it
>> transitions and the data read when it should be stable, if necessary
>> using suitably delayed data using parallel latches.
>
>What???  How do you "sample" the input without dealing with 
>metastability in those samples?
>
[Rickman]
This is exactly the reason that I started this thread - the more I thought
about it, the more I realised that the clock rate to data rate ratio is
irrelevant, and it kind of pulled the rug from under me.


Thanks for the quick replies :)	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154518
Subject: Re: Set-up and hold times and metastability
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 22 Nov 2012 21:07:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
James823 <3681@embeddedrelated> wrote:
>>On 11/22/2012 9:35 AM, Mike Perkins wrote:

(snip)
>>> The enable is really a latch enable with all the same issues of
>>> metastability of a clock.
 
> [Mike]
> This is where I have a problem. My understanding is that internally, the
> clock is simply gated by the enable, so the effect of an asynchronous
> enable is that the (clock AND enable) signal can have arbitrarily small
> pulse width, i.e. if the following occurs:
> 0) Initially clock is '0', enable is '1'
> 1) clock goes to '1'
> 2) enable goes to '0' after 1 ps or some other arbitrary time

Ones I know, have a MUX between Q and D before the FF logic.
Assuming a no-glitch MUX, if Q and D are the same, then there
should be no problem, but if they aren't, then it is the same
as changing D.

-- glen

Article: 154519
Subject: Re: Set-up and hold times and metastability
From: "James823" <3681@embeddedrelated>
Date: Thu, 22 Nov 2012 17:36:47 -0600
Links: << >>  << T >>  << A >>
>James823 <3681@embeddedrelated> wrote:
>>>On 11/22/2012 9:35 AM, Mike Perkins wrote:
>
>(snip)
>>>> The enable is really a latch enable with all the same issues of
>>>> metastability of a clock.
> 
>> [Mike]
>> This is where I have a problem. My understanding is that internally,
the
>> clock is simply gated by the enable, so the effect of an asynchronous
>> enable is that the (clock AND enable) signal can have arbitrarily small
>> pulse width, i.e. if the following occurs:
>> 0) Initially clock is '0', enable is '1'
>> 1) clock goes to '1'
>> 2) enable goes to '0' after 1 ps or some other arbitrary time
>
>Ones I know, have a MUX between Q and D before the FF logic.
>Assuming a no-glitch MUX, if Q and D are the same, then there
>should be no problem, but if they aren't, then it is the same
>as changing D.
>
>-- glen
>

I've noticed that this is how the compiler will synthesize code that has
complicated enable logic, but for simpler code it uses the enable (at least
using Quartus Web edition for a Cyclone II - the RTL viewer could be lying
to me about the true synthesis implementation though).

The reason presumably is that having more than a small amount of logic on
the enable line effectively introduces a clock skew. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154520
Subject: Re: Spartan 3A startup
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 22 Nov 2012 22:53:24 -0600
Links: << >>  << T >>  << A >>
Gabor wrote:


> Even before reading your next post I suspected a power issue.  Also
> INIT_B should be pulled up.  If it has an internal pullup, that might
> be OK, but the configuration process will be delayed if INIT_B
> stays low after releasing PROGRAM_B, so I usually add an external
> pullup anyway.
Yes, this once per second pulsing really had to be either power
or some floating pin.  I'm pretty sure INIT_B does have internal
pullup, but I'll double check the docs.  Extra-fast config is
not required, here, it just needs to be finished before the PC
boots.

Anyway, found another goof, I had failed to solder one whole row
of pins on one of the voltage translator chips!  Now the
board is communicating with the PC, and some preliminary tests
all look OK.  I couldn't figure out how it could have been so
far off, as the VHDL is almost identical to the Spartan 2E
version.  The UCF pad assignment was the only real change,
so I was looking for a mis-assignment of one wrong pin
and not thinking as globally as I should have.

Jon

Article: 154521
Subject: Re: Set-up and hold times and metastability
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 22 Nov 2012 22:59:04 -0600
Links: << >>  << T >>  << A >>
James823 wrote:

> Hi,
> 
> I've been looking at synchronising data across clock domains, and have
> managed to confuse myself.
> Can someone confirm (or correct me) that the following is true.
> 
> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?
> 
> If not, then even something as simple as testing a switch is pressed would
> cause problems right?
Metastability on modern CMOS processes is a pretty rare event.  Supposedly,
Xilinx has found that the window for metastability on their FFs is
no more than a couple of ps wide!  So, unless you have extremely fast
data rates or a timing that puts the transition right over the window,
it could take years for you to get one true metastable event.

The real logic hazard is for a signal that changes near the clock
edge to propagate through the chip in such a way that the transition
arrives before the clock at some FFs, and after the clock at some
others, either due to routing or combinatorial delays.  A simple
state machine can be sent to never-never land when this occurs.
By properly synchronizing when crossing clock boundaries, you
allow the tools to be sure that no signal can change state too
close to the setup time and cause such a hazard.

Many people claim such problems were metastability, when they were
more prosaic logic hazards.

Jon

Article: 154522
Subject: Re: Set-up and hold times and metastability
From: Mike Perkins <spam@spam.com>
Date: Fri, 23 Nov 2012 13:08:44 +0000
Links: << >>  << T >>  << A >>
On 22/11/2012 19:42, James823 wrote:
>> On 11/22/2012 9:35 AM, Mike Perkins wrote:
>
> [Mike]
> This is where I have a problem. My understanding is that internally, the
> clock is simply gated by the enable, so the effect of an asynchronous
> enable is that the (clock AND enable) signal can have arbitrarily small
> pulse width, i.e. if the following occurs:
>   0) Initially clock is '0', enable is '1'
>   1) clock goes to '1'
>   2) enable goes to '0' after 1 ps or some other arbitrary time
>
> Now, consider the standard NAND (or NOR) gate implementation as 2 layers of
> SR latches. So long as the (clock AND enable) pulse width is sufficiently
> long to propagate through the two NAND gates which it is connected, the
> signal has now reached layer 1. Again, because the input was a pulse, so
> too will this signal. The same thing now happens between the inputs to
> layer 2, and the output updates.
> The reason for metastability caused by D changing is that a change in D
> needs to propagate through 3 stages of NAND gates (due to the feedback
> structure) before it reaches the inputs to layer 2.
> This explains why we now typically have negative hold times and positive
> set-up times. The clock takes 1 NAND propagation to get to the inputs of
> layer 2, but the D signal takes 3, hence if the D signal changes 1 NAND
> prop. time before the clock changes, the clock will reach the layer 2
> inputs before the D signal i.e. negative hold time.
>
> Following the signals through like this, I can't see any reason that a
> small pulse width will cause metastability at all. In fact the only issue I
> can see is that if the pulse is short enough, then the signal won't
> propagate because of the capacitance of the gates and internal
> interconnect. However, this just means that the signal never gets anywhere,
> so it's as if the pulse never occurred - hardly a problem at all.
>
> Where's the flaw in my reasoning?
>
>>>
>>>> If not, then even something as simple as testing a switch is pressed
>>>> would
>>>> cause problems right?
>>>>
>>>
>>> There are a number of ways of achieving moving data across clock
> domains.
>>>
>>> Simplest is to use a fast clock, where the clock rate is many times the
>>> data rate. The original data clock can be sampled to determine when it
>>> transitions and the data read when it should be stable, if necessary
>>> using suitably delayed data using parallel latches.
>>
>> What???  How do you "sample" the input without dealing with
>> metastability in those samples?
>>
> [Rickman]
> This is exactly the reason that I started this thread - the more I thought
> about it, the more I realised that the clock rate to data rate ratio is
> irrelevant, and it kind of pulled the rug from under me.
>
>

This is my view and I open to criticism.

Metastability by itself is easy to either cope with or you can eliminate 
it's effect.  Some thoughts:

A consequence of a changing data input for a latch can cause uncertainty 
of the latch output, and the worst case scenario is where the output is 
indeterminate, at non high or low output level, ie at mid-level.

Generally that output will end up either high or low at the end of the 
same clock period, however there is still a miniscule chance that this 
will remain at an indeterminate level.

If this output is used by a further latch, depending on setup or hold 
times the probability of still being indeterminate at this latch output 
is reduced much further.
However if this output is used by a number of latches, then these will 
have different thresholds, set-up and hold times such that these 
subsequent latches may occasionally each produce a different result.
In this case I generally double latch the signal (or more) before making 
it available for further circuitry.

However, when it comes to passing data, the real problem isn't so much 
metastability, but clock skew and varying data routing delays.  These 
are far more likely to corrupt data.

In general, if you consider metastability first, then all else tends 
falls into place.



-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 154523
Subject: Re: Set-up and hold times and metastability
From: Mike Perkins <spam@spam.com>
Date: Fri, 23 Nov 2012 14:35:29 +0000
Links: << >>  << T >>  << A >>
On 22/11/2012 19:42, James823 wrote:
>> On 11/22/2012 9:35 AM, Mike Perkins wrote:
>>> On 22/11/2012 07:35, James823 wrote:
>>>> Hi,
>>>>
>>>> I've been looking at synchronising data across clock domains, and have
>>>> managed to confuse myself.
>>>> Can someone confirm (or correct me) that the following is true.
>>>>
>>>> Metastability may occur if the input D changes value during the set-up
>>>> and
>>>> hold times, however the enable can be completely asynchronous without
>>>> ever
>>>> causing a problem?
>>>
>>> The enable is really a latch enable with all the same issues of
>>> metastability of a clock.
>
> [Mike]
> This is where I have a problem. My understanding is that internally, the
> clock is simply gated by the enable, so the effect of an asynchronous
> enable is that the (clock AND enable) signal can have arbitrarily small
> pulse width, i.e. if the following occurs:
>   0) Initially clock is '0', enable is '1'
>   1) clock goes to '1'
>   2) enable goes to '0' after 1 ps or some other arbitrary time
>
> Now, consider the standard NAND (or NOR) gate implementation as 2 layers of
> SR latches. So long as the (clock AND enable) pulse width is sufficiently
> long to propagate through the two NAND gates which it is connected, the
> signal has now reached layer 1. Again, because the input was a pulse, so
> too will this signal. The same thing now happens between the inputs to
> layer 2, and the output updates.
> The reason for metastability caused by D changing is that a change in D
> needs to propagate through 3 stages of NAND gates (due to the feedback
> structure) before it reaches the inputs to layer 2.
> This explains why we now typically have negative hold times and positive
> set-up times. The clock takes 1 NAND propagation to get to the inputs of
> layer 2, but the D signal takes 3, hence if the D signal changes 1 NAND
> prop. time before the clock changes, the clock will reach the layer 2
> inputs before the D signal i.e. negative hold time.
>
> Following the signals through like this, I can't see any reason that a
> small pulse width will cause metastability at all. In fact the only issue I
> can see is that if the pulse is short enough, then the signal won't
> propagate because of the capacitance of the gates and internal
> interconnect. However, this just means that the signal never gets anywhere,
> so it's as if the pulse never occurred - hardly a problem at all.
>
> Where's the flaw in my reasoning?

Causes of metastability are different thresholds, different delays, 
noise  and a limited slew rate of signals.

I'm not sure if D-Type flip-flops are such simple affairs in FPGAs, nor 
how an enable is implemented.

In short each latch has more than one gate driven by the D-input, and 
within the latch each signal will likely drive more than one gate. 
Hence metastability is inevitable.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 154524
Subject: Re: Set-up and hold times and metastability
From: rickman <gnuarm@gmail.com>
Date: Fri, 23 Nov 2012 16:31:51 -0500
Links: << >>  << T >>  << A >>
On 11/22/2012 1:40 PM, Mike Perkins wrote:
> On 22/11/2012 17:33, rickman wrote:
>> On 11/22/2012 9:35 AM, Mike Perkins wrote:
>>>
>>> Simplest is to use a fast clock, where the clock rate is many times
>>> the data rate. The original data clock can be sampled to determine
>>> when it transitions and the data read when it should be stable, if
>>> necessary using suitably delayed data using parallel latches.
>>
>> What??? How do you "sample" the input without dealing with
>> metastability in those samples?
>
> By taking a latched clock being high say for 2 High-Speed clocks before
> accepting it as a real clock-high.

You aren't seeing the picture.  This doesn't solve metastability in any 
meaningful way.  The edge detection logic can still be "glitched" by 
metastability and disrupt the rest of the circuit.

Easier is just to run the slow clock input through two FFs with no logic 
between them and getting a metastability minimized signal.  Then you can 
use it as you wish.


>> Another way to deal with the problem is to minimize and encapsulate
>> it. This means using a single clock for the entire FPGA design other
>> than the I/O interfaces where you sync the signals as soon as
>> possible.
>
> Entirely agree, but that's not always possible.

When is this not possible?  The only limitation would be that the 
"master" clock to rule them all has to be the fastest by enough margin 
to accommodate the jitter in the two clocks.  This prevents ever missing 
a transition.

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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search