Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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 doArticle: 154502
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
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 commandsArticle: 154504
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, AllanArticle: 154505
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.comArticle: 154506
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, JonArticle: 154507
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. JonArticle: 154508
> 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. JonArticle: 154509
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. -- GaborArticle: 154510
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.comArticle: 154511
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. -- glenArticle: 154512
> 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, JonArticle: 154513
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.ukArticle: 154514
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. RickArticle: 154515
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 JenningsArticle: 154516
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.ukArticle: 154517
>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.comArticle: 154518
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. -- glenArticle: 154519
>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.comArticle: 154520
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. JonArticle: 154521
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. JonArticle: 154522
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.ukArticle: 154523
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.ukArticle: 154524
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:
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