From: VR Newsgroups: comp.arch.fpga Subject: Crossing a clock domain Date: Mon, 3 Dec 2001 04:43:19 +0000 (UTC) Organization: University of Texas at Dallas Lines: 33 Sender: Vasant Ramasubramanian Message-ID: <9uevt7$1aq$1@news.utdallas.edu> NNTP-Posting-Host: apache.utdallas.edu X-Trace: news.utdallas.edu 1007354599 1370 129.110.16.9 (3 Dec 2001 04:43:19 GMT) X-Complaints-To: abuse@utdallas.edu NNTP-Posting-Date: Mon, 3 Dec 2001 04:43:19 +0000 (UTC) User-Agent: tin/1.4.3-20000502 ("Marian") (UNIX) (SunOS/5.8 (sun4u)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!news.tamu.edu!news.utdallas.edu!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12082 Hey all. I have a uC that's updating a register in my XC4010E via a standard "three-wire" SPI. The uC writes to an 8-bit shift register in the FPGA -- the uC's SPI clock is used to clock the FPGA flip-flops and the SPI_nCS (chip select) is used as the ENABLE(active low) to the register for shifting. To prevent any odd behavior, I am double buffering my data -- the shift register is one buffer, and I parallel load the data from the shift register into a second 8-bit register, which is clocked by my FPGA native 40MHz clock. (The 2nd register feeds the inputs of a loadable free running counter). My problem is in the the control of the second register. I only want this register to update when data(in the SPI register) is valid but the SPI register is being clocked by something completely asynchronous to the FPGA's clock. My first idea was to use the SPI_nCS as the ENABLE(active high) on the second register; the register would clock in data on rising edges of the FPGA clock and only when SPI_nCS was high. Since the SPI_nCS "envelope" surrounds an SPI transaction, when the signal is NOT low, I know an SPI operation wouldn't be occurring. I also wondered if a better solution might be to use three T-flip-flops and divide down the uC's SPI clock by 8, so on the 8th clock(when the last bit from the uC gets clocked into the shiftreg) I register the SPI register's data. I would use the output from the third T-FF as the ENABLE(active high) on my 2nd register and still clock the 2nd register from the FPGA 40MHz clock. I'm sure all of the above will work, but I didn't know which would be a better solution (if any) and if there are other things to keep in mind. Thanks, VR. ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: Crossing a clock domain Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: References: <9uevt7$1aq$1@news.utdallas.edu> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 133 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr14.news.prodigy.com 1007364386 ST000 216.103.85.188 (Mon, 03 Dec 2001 02:26:26 EST) NNTP-Posting-Date: Mon, 03 Dec 2001 02:26:26 EST X-UserInfo1: FKPO@MC@@S@_BPLX^BN@^QLAUKXD@D@MGPW^OBPLAH[\RWYAKVUOPCW[ML\JXUCKVFDYZKBMSFX^OMSAFNTINTDDMVW[X\THOPXZRVOCJTUTPC\_JSBVX\KAOTBAJBVMZTYAKMNLDI_MFDSSOLXINH__FS^\WQGHGI^C@E[A_CF\AQLDQ\BTMPLDFNVUQ_VM Date: Mon, 03 Dec 2001 07:26:26 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!newscon02.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr14.news.prodigy.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12095 On Mon, 3 Dec 2001 04:43:19 +0000 (UTC), VR wrote: >Hey all. > >I have a uC that's updating a register in my XC4010E via a standard "three-wire" SPI. > >The uC writes to an 8-bit shift register in the FPGA -- the uC's SPI clock is used to clock >the FPGA flip-flops and the SPI_nCS (chip select) is used as the ENABLE(active low) to the >register for shifting. So far, so good. We will call this reg the SPIReg. >To prevent any odd behavior, I am double buffering my data -- the shift register is one >buffer, and I parallel load the data from the shift register into a second 8-bit register, >which is clocked by my FPGA native 40MHz clock. (The 2nd register feeds the inputs of a >loadable free running counter). OK, we call this reg the ReloadReg. Although you dont say so, all the following assumes that your free running counter will reload from the ReloadReg at some arbitrary time with respect to the updating process. I.E. it could use the second register while a new value is arriving, or has just arrived, is about to arrive. >My problem is in the the control of the second register. Well actually, the problem is when to load ReloadReg (the second registe) >I only want this register to update when data(in the SPI register) is valid Right >but the SPI register is being clocked by something completely asynchronous >to the FPGA's clock. Right >My first idea was to use the SPI_nCS as the ENABLE(active high) on the second >register; the register would clock in data on rising edges of the FPGA clock and >only when SPI_nCS was high. This wont work. The failure scenario is that there is a race condition between SPI_nCS going high, and the next FPGA clock. ENABLE for ReloadReg has a setup and hold time requirement for reliable loading. This can be violated by this scheme. This will lead to an incorrect value loaded into ReloadReg, comprising of some new bits and some old bits, or metastability. If you are unlucky, while the ReloadReg has junk in it, it will be used as the reload value. Following FPGA clocks will correct the value, but there is a finite probability of the above scenario happening. >Since the SPI_nCS "envelope" surrounds an SPI transaction, when the signal is NOT low, I know >an SPI operation wouldn't be occurring. The problem is on the boundary of SPI_nCS going from low to high. There is also an issue with SPI_nCS going from high to low, and potentially corrupting a load at this point too, but because the prior contents, and the data on the D pins are the same, this wont cause problems. >I also wondered if a better solution might be to use three T-flip-flops and divide down the >uC's SPI clock by 8, so on the 8th clock(when the last bit from the uC gets clocked into the >shiftreg) I register the SPI register's data. I would use the output from the third T-FF as >the ENABLE(active high) on my 2nd register and still clock the 2nd register from the FPGA >40MHz clock. This still has the problem of your ReloadReg enable being in the wrong clock domain. >I'm sure all of the above will work, but I didn't know which would be a better solution (if >any) and if there are other things to keep in mind. I'm sure the above will eventually fail. Here's what I would do (have done in dozens of production designs ). You are right to be concerned about the data for your counter being in a register that is clocked by the same clock as the counter. The only issue is how to load ReloadReg reliably. Consider the following: 1) Once the SPIReg has been updated, we only need to copy it once into ReloadReg 2) The SPI clock is significantly slower than the 40MHz FPGA clock, so you can take a few 40MHz cycles to get the data safely over into the 40MHz domain, since it will take far longer for the SPI system to send a new value. 3) Since the SPI system is async to the 40MHz system, your design cant be sensitive to the exact 40MHz cycle in which ReloadReg is updated. So taking 3 * 40MHz cycles to do it safely is fine. Here is a structure that will work reliably: Connect 4 D flipflops as a 4 bit shifter (Q0 to D1, Q1 to D2, Q2 to D3, Q3 to D4). Clock the shifter with the 40MHz. Connect the input D0 to SPI_nCS. Connect a 4 input AND gate to Q0, Q1, Q2, and ~Q3 , to detect the sequence 1,1,1,0 . This will occur after SPI_nCS has gone high, and 3 clocks of 40MHz. If a metastability occured or you failed a setup/hold requirement, you might see something like the following: 1,0,0,0 0,0,0,0 1,0,0,0 1,1,0,0 1,1,1,0 <- match case 1,1,1,1 1,1,1,1 Regardless of metastabilities, by the time you get a match, things will be settled, as you have taken 75 ns , which should be more than enough given the characteristics of current FPGAs. Take the output of the AND gate and pass it through 1 more FF. Now we have 100ns of resolution time (and update latency) . Note that the match signal will only be high for one 25ns cycle. Use the output of this FF as the active high enable for ReloadReg. This should be extremely reliable. >Thanks, >VR. Philip Freidin Philip Freidin Fliptronics ###### From: "Austin Franklin" Newsgroups: comp.arch.fpga Subject: Re: Crossing a clock domain Date: Tue, 4 Dec 2001 13:42:17 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <9uevt7$1aq$1@news.utdallas.edu> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Complaints-To: newsabuse@supernews.com Lines: 21 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12148 "Philip Freidin" wrote in message news:mv7m0u4c8rsdmoi2hpc4hc9mdn115bpfbk@4ax.com... > On Mon, 3 Dec 2001 04:43:19 +0000 (UTC), VR > wrote: > >Hey all. > > > >I have a uC that's updating a register in my XC4010E via a standard "three-wire" SPI. > > The other night I took a look at this post, and was hoping you (or Ray, but I somehow suspected you would) would answer it...since I knew it would take me a while to respond...and I'm rather busy right now... so...thanks for answering, and I second your response, it's just what I would have said ;-) ###### From: kahhean@hotmail.com (Chua Kah Hean) Newsgroups: comp.arch.fpga Subject: Re: Crossing a clock domain Date: 4 Dec 2001 18:14:25 -0800 Organization: http://groups.google.com/ Lines: 48 Message-ID: References: <9uevt7$1aq$1@news.utdallas.edu> NNTP-Posting-Host: 165.21.83.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1007518465 24306 127.0.0.1 (5 Dec 2001 02:14:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 5 Dec 2001 02:14:25 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!feed2.onemain.com!feed1.onemain.com!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12150 Hi Philip, Just out of curiosity... > If a metastability occured or you failed a setup/hold requirement, you might > see something like the following: > > 1,0,0,0 <- (1) > 0,0,0,0 <- (2) > 1,0,0,0 > 1,1,0,0 > 1,1,1,0 <- match case > 1,1,1,1 > 1,1,1,1 I do not understand how (1) going to (2) is possible. I am thinking you are showing the possible scenario when we sample the SPI enable signal right on its rising transition. The '1' output from the first FF in (1) may be undergoing meta-instability, so in (2), the second FF may clock out either '1' or '0'. But surely in (2), the first FF would be outputting a '1'? I am thinking we may see something like below. > 1,0,0,0 <- (1) > 1,0,0,0 <- (2) > 1,1,0,0 > 1,1,1,0 <- match case > 1,1,1,1 > 1,1,1,1 Also, is the 4th FF necessary? Can't we just decode on 2nd and 3rd FF being "10"? (see below) > 1,0,0 > 1,0,0 > 1,1,0 <- match case > 1,1,1 Also, why can't we use the decoded enable signal directly (instead of passing it through yet another FF, as you described in your post). I am questioning very minor details. But I don't want to miss knowing anything fundamental pitfall. :-) Thanks in advance. TA TA kahhean ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: Crossing a clock domain Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: References: <9uevt7$1aq$1@news.utdallas.edu> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 219 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr21.news.prodigy.com 1007537061 ST000 216.103.85.188 (Wed, 05 Dec 2001 02:24:21 EST) NNTP-Posting-Date: Wed, 05 Dec 2001 02:24:21 EST X-UserInfo1: Q[R_PJSCTS@_BPLX^BN@^QLAUKXD@D@MGPW^OBPLAH[\BTUCCNSKQFCY@TXDX_WHSVB]ZEJLSNY\^J[CUVSA_QLFC^RQHUPH[P[NRWCCMLSNPOD_ESALHUK@TDFUZHBLJ\XGKL^NXA\EVHSP[D_C^B_^JCX^W]CHBAX]POG@SSAZQ\LE[DCNMUPG_VSC@VJM Date: Wed, 05 Dec 2001 07:24:22 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!newscon02.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr21.news.prodigy.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12155 On 4 Dec 2001 18:14:25 -0800, kahhean@hotmail.com (Chua Kah Hean) wrote: >Hi Philip, Hi > .... following stuff .... >I am questioning very minor details. But I don't want to miss knowing >anything fundamental pitfall. :-) You are right to ask these questions, I will address each one. In particular, my answer to you gave recommendations, without explanation or justification. I will try and remedy this in this response. As your questions indicate, you understand my intent, just not why I am making the recomendations that I have made. On 4 Dec 2001 18:14:25 -0800, kahhean@hotmail.com (Chua Kah Hean) wrote: >Hi Philip, > >Just out of curiosity... > >> If a metastability occured or you failed a setup/hold requirement, you might >> see something like the following: >> >> 1,0,0,0 <- (1) >> 0,0,0,0 <- (2) >> 1,0,0,0 >> 1,1,0,0 >> 1,1,1,0 <- match case >> 1,1,1,1 >> 1,1,1,1 > >I do not understand how (1) going to (2) is possible. I am thinking >you are showing the possible scenario when we sample the SPI enable >signal right on its rising transition. The '1' output from the first >FF in (1) may be undergoing meta-instability, so in (2), the second FF >may clock out either '1' or '0'. But surely in (2), the first FF >would be outputting a '1'? I am thinking we may see something like >below. > >> 1,0,0,0 <- (1) >> 1,0,0,0 <- (2) >> 1,1,0,0 >> 1,1,1,0 <- match case >> 1,1,1,1 >> 1,1,1,1 You are right. But the problem is with the fact that I didnt explain the time scale for the sequence. You have made the reasonable assumption that each line of my table is the result after each rising clock (in the 40 MHz domain). But what I was intending to show is the first flipflop going metastable, and going from 0 to 1 and back to 0 within 1 cycle. The rest of the lines of the table are the shift register state after each clock. Here is the table again, with some time stamps. The 40MHz clock rising edge occurs every 25ns, starting at T = 0 ns. The flipflops have a clock to output settling time delay of 1 ns 0,0,0,0 time = 0 ns 0,0,0,0 time = 1 ns 0,0,0,0 time = 25 ns 1,0,0,0 time = 26ns 0,0,0,0 time = 30ns 1,0,0,0 time = 51ns 1,1,0,0 time = 76 ns 1,1,1,0 time = 101 ns <- match case 1,1,1,1 time = 126 ns 1,1,1,1 time = 151 ns We see at time 30 ns that Q0 returns back to 0 without a clock event. I.E. it went metastable because the D input was changing very close to T = 25 ns You will note that if we remove the line for 30 ns, we get the table you suggested. I.E. only show the state after each rising clock edge. >Also, is the 4th FF necessary? Can't we just decode on 2nd and 3rd FF >being "10"? (see below) > >> 1,0,0 >> 1,0,0 >> 1,1,0 <- match case >> 1,1,1 Yes we could, but it would not be as reliable. We could even throw away the 3rd FF, and just decode 1,0 , and this would also work, but would be even less reliable. As you may know, the time it takes a FF to resolve a metastable state is unbounded (could be infinity), but the probability that it takes longer than some specified time is a negative exponential function of the specified time (called the resolution time). My above example suggests that the first FF resolves the metastability in less than 5 ns. But this is not guaranteed, it could take longer (with lower probability of happening). Let's look at the highly unlikely case of the metastability taking 24.5 ns to resolve, and it resolves back to 0: 0,0,0,0 time = 0 ns 0,0,0,0 time = 1 ns 0,0,0,0 time = 25 ns 1,0,0,0 time = 26ns FF 0 has gone metastable, but out put is seen as 1 1,0,0,0 time = 49.0ns 0,0,0,0 time = 49.5ns FF 0 resolves metastability, goes back to 0, but FF 1 sees enough of FF 0 being 1 to go to 1 itself, but FF 1 goes metastable 1,1,0,0 time = 51 ns FF 0 now goes to solid 1, FF 1 is metastable 1,0,0,0 time = 54 ns FF 1 resolves metastable and goes back to 0. 1,1,0,0 time = 76 ns FF 0 and 1 are both solid 1 1,1,1,0 time = 101 ns <- match case 1,1,1,1 time = 126 ns 1,1,1,1 time = 151 ns How likely is this? Very rare, but possible. An old rule of thumb is that the probability of metastability not being resolved drops by a factor of 40 for every additional nanosecond of resolution time. So for however rare the resolves in 5 ns case might have been, this case is far less likely: (in the following "^" is "raised to the power") Resolved by 49.5 ns, clock was at 25 ns => 24.5 ns resolution time. 24.5 ns - 5 ns => 19.5 ns probability ratio is 1 divided by 40^19.5 which my calculator says is about 1.7 * 10^31 If the 5 ns case occured once per second, the 24.5 ns case would occur once per 5.5 * 10^23 years. More than enough time for you to ship the product, get your bonus cheque, and change jobs and be working for another company before a failure occurs. But: A) the 40 times improvement may be itself off by a factor of 4, either way (i.e. 10 thru to 160). B) I might be building big systems with 100s or 1000s of such sub circuits. C) I might be shipping millions of systems. (although it is hard to imagine a high volume consumer product that would need 1000 synchronization boundaries :-) D) maybe the failure rate at 5 ns occurs 1000 times a second This could give numbers like: (1000 / (10^19.5)) * 1000 * 1000000 = 3.16 * 10^-17 * 10^3 * 10^6 = 3.16 * 10^-8 (failures per second across all systems built) => 1 failure per 1.0027 years. ( i.e. build 1,000,000 systems each with 1000 resoultion circuits, each of which fails 1000 times a second at the 5 ns resolution time, and given an extra 19.5 ns of resoultion time, and the improvement for resolution is a factor of 10 per each extra ns) Are these numbers silly. Yep. Do they show that even with great amounts of resolving time (19.5 ns is lots) , I can still contrive a situation where failures may occur before I have moved on to my next job. Plus, chip vendors dont have up to date metastability numbers for current products, and I probably made some mistakes in the above math. Would you want a pacemaker from a batch that one of will fail every year? does your answer change if the batch size is 1000000 pacemakers? Coming back to reality, let me just say that at some point my eyes just gloss over and it is easier to add an extra stage or two of resolution, and know that the mean time to failure exceeds the life of the universe, rather than figure out if the failure rate is once a year or once a mega-year. This assumes that the latency is not a big issue. This is what your case is like. If latency is an issue, then detailed analysis is required, to minimize the number of stages. So, now on to the answer :-) My recommendation was look for 1,1,1,0 Which has a 25 ns resolving time from FF 0 to FF 1 , and 25 ns more from FF 1 to FF 2. FF 3 is not involved in this calculation, as we are detecting that it is still 0. So basically 2 stages of resolution, or 50 ns. From experience with FPGAs, this should be more than enough. Dropping out the last stage as you asked, and matching 1,1,0 basically only gives a single stage of metastability resolution. Without detailed calculations, I would not feel comfortable with this. >Also, why can't we use the decoded enable signal directly (instead of >passing it through yet another FF, as you described in your post). By passing it through 1 more FF, I get 2 things. First, I get to be really comfortable, because it is adding another (approx) 25 ns of resolution time, and second, the timing model for distribution of the CE signal from this last FF, is simple as no gates are involved. >I am questioning very minor details. But I don't want to miss knowing >anything fundamental pitfall. :-) I hope you find the above useful. >Thanks in advance. >TA TA >kahhean Philip Freidin, Metastability Crusader. Philip Freidin Fliptronics ###### From: assaf_sarfati@yahoo.com (Assaf Sarfati) Newsgroups: comp.arch.fpga Subject: Re: Crossing a clock domain Date: 5 Dec 2001 21:50:29 -0800 Organization: http://groups.google.com/ Lines: 42 Message-ID: <44b0ca4e.0112052150.aa7ada3@posting.google.com> References: <9uevt7$1aq$1@news.utdallas.edu> NNTP-Posting-Host: 62.90.193.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1007617829 29194 127.0.0.1 (6 Dec 2001 05:50:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 6 Dec 2001 05:50:29 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!news-in-sanjose!cyclone-sf.pbi.net!216.218.192.242!news.he.net!news!sn-xit-03!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12196 Hi, If the SPI clock is much slower than the FPGA clock (1/8 or less), it may be easier to synchronize the three input signals and run the whole receive logic on the global FPGA clock: * Use a two-FF synchronizer on all input lines (one may be in the I/O pad); * Use an Edge Detector on the synchronized SPI-clock to enable shifting of an (also synchronized) SPI-data bit into your shift-register. VR wrote in message news:<9uevt7$1aq$1@news.utdallas.edu>... > Hey all. > > I have a uC that's updating a register in my XC4010E via a standard "three-wire" SPI. > > The uC writes to an 8-bit shift register in the FPGA -- the uC's SPI clock is used to clock > the FPGA flip-flops and the SPI_nCS (chip select) is used as the ENABLE(active low) to the > register for shifting. > > To prevent any odd behavior, I am double buffering my data -- the shift register is one > buffer, and I parallel load the data from the shift register into a second 8-bit register, > which is clocked by my FPGA native 40MHz clock. (The 2nd register feeds the inputs of a > loadable free running counter). > > My problem is in the the control of the second register. I only want this register to update > when data(in the SPI register) is valid but the SPI register is being clocked by something > completely asynchronous to the FPGA's clock. > > My first idea was to use the SPI_nCS as the ENABLE(active high) on the second register; the > register would clock in data on rising edges of the FPGA clock and only when SPI_nCS was high. > Since the SPI_nCS "envelope" surrounds an SPI transaction, when the signal is NOT low, I know > an SPI operation wouldn't be occurring. > > I also wondered if a better solution might be to use three T-flip-flops and divide down the > uC's SPI clock by 8, so on the 8th clock(when the last bit from the uC gets clocked into the > shiftreg) I register the SPI register's data. I would use the output from the third T-FF as > the ENABLE(active high) on my 2nd register and still clock the 2nd register from the FPGA > 40MHz clock. > > I'm sure all of the above will work, but I didn't know which would be a better solution (if > any) and if there are other things to keep in mind. > > Thanks, > VR.