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
Hi, On 01/19/15 09:54 PM, Tomas D. wrote: > "Michael" <michael_laajanen@yahoo.com> wrote in message > news:chp7vjFof2bU1@mid.individual.net... >> Hi, >> ><snip> > Hello Michael, > you have two options: > 1) If you use PLL, then use LOCKED output as a reset to your logic. Create a > counter, that will set PLL areset input to high when you need a reset. > 2) A hardware reset by routing IO pin to nCONFIG input, which would have a > pull-up resistor. When the FPGA is reseted, the pull-up would ensure the > nCONFIG is high and the FPGA can enter user mode. When user-mode is reached, > the output is kept high until the reset is needed. This will reset the FPGA > completely. > > Regards > Tomas D. > > Thanks Tomas, I will start with the first suggestion. cheers MichaelArticle: 157651
>> Hello Michael, >> you have two options: >> 1) If you use PLL, then use LOCKED output as a reset to your logic. >> Create a >> counter, that will set PLL areset input to high when you need a reset. >> >> Regards >> Tomas D. >> >> > Thanks Tomas, I will start with the first suggestion. Hello, Be careful using PLL lock signal. PLL once locked is NOT locked forever and re-lock may occurs. See documentation. BR AdamArticle: 157652
On Monday, January 19, 2015 at 3:54:33 PM UTC-5, Tomas D. wrote: > "Michael" <michael_...@yahoo.com> wrote in message=20 > you have two options: > 1) If you use PLL, then use LOCKED output as a reset to your logic. Creat= e a=20 > counter, that will set PLL areset input to high when you need a reset. This won't do what the OP asked. What was asked was a way to reset all of = the flip flops. Reseting the PLL in order to cause it to unlock won't do t= hat. All it will do is shut off the clocks for a period of time until the = PLLs come back online. That by itself does absolutely nothing to any of th= e flip flops. You're presuming that the 'locked' PLL output is already bei= ng explicitly used to reset every flip flop in the design either directly o= r through some reset code in the FPGA design, but a simple 'D' flip flop wi= ll not react at all. Q <=3D D when rising_edge(Clock); > 2) A hardware reset by routing IO pin to nCONFIG input, which would have = a=20 > pull-up resistor. When the FPGA is reseted, the pull-up would ensure the= =20 > nCONFIG is high and the FPGA can enter user mode. When user-mode is reach= ed,=20 > the output is kept high until the reset is needed. This will reset the FP= GA=20 > completely. >=20 Perusal of the datasheet shows that this approach is not guaranteed to work= . The datasheet specifies a maximum of 800 ns from nConfig low to Conf_Don= e low as well as a minimum of 2 us for nConfig to stay low. So you can onl= y count on the FPGA to produce a maximum low time on nConfig of less than h= alf the required minimum. Also, this approach goes too far in that not only are the flip flops reset = (as was requested), but the entire FPGA has now lost it's configuration and= is brain dead. To recover, the FPGA will need to be reconfigured which me= ans that whatever circuit that responds to some external event that causes = FPGA configuration to occur in the first place (like powerup in many design= s) needs to be restarted. The configuration circuit would have to monitor = Conf_Done and look for a high to low transition to cause it to once again c= onfigure the FPGA. Kevin JenningsArticle: 157653
Initialize up-counters to even values, and the maximum synchronization error is 1 for an asynchronously released reset. AndyArticle: 157654
So I wanted to know if it was possible to update an old embedded-developmen= t kit license that's expired. There's nothing on xilinx' site as far as I c= an see that allows for old licenses to be renewed. So I go to the support s= ection, fill out the form explaining the situation and send it off. I promptly get back a canned reply... --- Cut Here --- Thank you for your inquiry, =20 There are three ways to purchase Xilinx products: Xilinx Sales Reps: http://www.xilinx.com/company/contact/sales-offices.htm = =20 =B7 Sales representatives can help if you do not know which products = are best for your design. =20 Online Store: http://www.xilinx.com/onlinestore/ =B7 The Xilinx Online Store provides a quick and simple way to purcha= se Xilinx design tools and a selection of development boards and kits direc= tly from Xilinx. Simply locate your product of interest and click the "Buy"= link from anywhere on Xilinx.com to get started. Things to consider before purchasing from the Xilinx Online Store: =B7 Tax Exempt orders must be placed through distribution. =B7 On-line purchases are by credit card only. No purchase orders pl= ease. Xilinx accepts the following credit cards: Visa, MasterCard, and American = Express =B7 No Intellectual Products are sold on the On-line Store =20 Xilinx Distributors: http://www.xilinx.com/company/contact/index.htm =20 =B7 Xilinx Authorized Distributors offer access to a comprehensive se= t of Xilinx design tools, IP cores, devices, development boards and kits. =B7 The Xilinx Productivity Advantage (XPA) Bundling Program is only = offered when purchasing through a Xilinx Authorized Distributor. To learn = more about how to reduce your design productivity solution costs, please vi= sit http://www.xilinx.com/xpa/. =20 University Faculty: http://www.xilinx.com/university/professors/index.htm =B7 Universities may be eligible for full versions of design tools at= no charge. University professors must initiate the request at the Universi= ty Faculty link above. =20 Thank you, Xilinx Development System Team --- Cut Here --- ... which is useless [I know what I want to use it for, so no sales reps; T= he online store doesn't provide any option I can see; I can't see distribut= ors being interested in upgrading a kit I bought directly from Xilinx; I'm = not at university].=20 I didn't actually read the reply until the next day due to work/home email = filters, so once I've read it, I send in another request, pointing out that= the canned reply wasn't useful and asking the same question again, along w= ith "Is it really the case that I have to but a new piece of hardware (whic= h I don't want or need) in order to extend a license for a product I bought= directly from you ?" because the only way I can see it being possible on t= he xilinx site is to re-purchase the same board, thus getting a new license= . Guess what. A few seconds later I get back the exact *same* reply, word for= word. No attempt to read/parse the question I asked, just an apparent cann= ed reply for any license/purchase question. I wanted to work on this in the background, with a project that I think cou= ld be useful for my work, but it's not official, so I can't go to the suppo= rt guys here at work. I would have liked to have tried to use the same devi= ce manufacturer as the tens-of-thousands-of-dollars boards that we have her= e at work, for ease of later porting, but I'm now so frustrated by the lack= of human response, I'm going to look at Altera (or anyone else, really, al= l I want is PCIe and some DDR ram)=20 I *was* prepared to put down my own hard-earned cash to do this, but I'll b= e damned if they're getting any of my money now, if they can't even answer = a simple question like this, I can't see them being any use once I've spent= the money. Giving up on Xilinx. Simon.Article: 157655
Simon <google@gornall.net> wrote: > So I wanted to know if it was possible to update an old > embedded-development kit license that's expired. There's nothing > on xilinx' site as far as I can see that allows for old licenses > to be renewed. So I go to the support section, fill out the form > explaining the situation and send it off. I am not sure which software or chips you are interested in. I am running the webpack (free) version that, each time I run it, tells me that my license has expired, but I can keep using it. I could install a newer version, but haven't done that. The free version does all the chips that I could afford, so I haven't been interested in others. -- glenArticle: 157656
On Wednesday, January 21, 2015 at 11:17:46 AM UTC-8, glen herrmannsfeldt wr= ote: > Simon wrote: > =20 > > So I wanted to know if it was possible to update an old=20 > > embedded-development kit license that's expired. There's nothing=20 > > on xilinx' site as far as I can see that allows for old licenses=20 > > to be renewed. So I go to the support section, fill out the form=20 > > explaining the situation and send it off. >=20 > I am not sure which software or chips you are interested in. >=20 > I am running the webpack (free) version that, each time I run it, > tells me that my license has expired, but I can keep using it. >=20 > I could install a newer version, but haven't done that. >=20 > The free version does all the chips that I could afford, so I > haven't been interested in others.=20 Thanks - the board I have could actually be used with Webpack. The extra li= cense gets me access to the embedded development kit though. It could be ki= nd of useful to have the micro blaze... Another wrinkle (that I put into the original request to Xilinx, but of cou= rse was subsequently ignored) is that the old machine that was used for the= licence-id has long since departed to that computer museum in the sky. I t= hink I'm allowed 3 "re-licencing" events, so perhaps I'll try just changing= the license to the new host-id, and running the app. I don't care if it wa= rns me, as long as it works - I'm not that familiar with how xilinx licens= ing works though. So cheers! I'll give it a go. You've been a whole lot more useful than xili= nx support :) SimonArticle: 157657
Simon wrote: > On Wednesday, January 21, 2015 at 11:17:46 AM UTC-8, glen herrmannsfeldt wrote: >> Simon wrote: >> >>> So I wanted to know if it was possible to update an old >>> embedded-development kit license that's expired. There's nothing >>> on xilinx' site as far as I can see that allows for old licenses >>> to be renewed. So I go to the support section, fill out the form >>> explaining the situation and send it off. >> I am not sure which software or chips you are interested in. >> >> I am running the webpack (free) version that, each time I run it, >> tells me that my license has expired, but I can keep using it. >> >> I could install a newer version, but haven't done that. >> >> The free version does all the chips that I could afford, so I >> haven't been interested in others. > > Thanks - the board I have could actually be used with Webpack. The extra license gets me access to the embedded development kit though. It could be kind of useful to have the micro blaze... > > Another wrinkle (that I put into the original request to Xilinx, but of course was subsequently ignored) is that the old machine that was used for the licence-id has long since departed to that computer museum in the sky. I think I'm allowed 3 "re-licencing" events, so perhaps I'll try just changing the license to the new host-id, and running the app. I don't care if it warns me, as long as it works - I'm not that familiar with how xilinx licensing works though. > > So cheers! I'll give it a go. You've been a whole lot more useful than xilinx support :) > > Simon Xilinx licenses don't expire, only the updates / maintenance expires. So theoretically you still own the license to use the software version up to the limit of your maintenance contract (typically one year from last purchase). If this was an older version of ISE, the license may have been tied to a MAC address or C-drive serial number, either of which would be in human readable form in the license file. Also either of these are easy to clone in a new system. If you still have the old license.dat file you might not need to "re-license" if you can clone the MAC or disk S/N. I have done this in the past when old systems went up in smoke. -- GaborArticle: 157658
On 1/21/2015 1:34 PM, Simon wrote: > > So I wanted to know if it was possible to update an old embedded-development kit license that's expired. There's nothing on xilinx' site as far as I can see that allows for old licenses to be renewed. So I go to the support section, fill out the form explaining the situation and send it off. > > I promptly get back a canned reply... > > --- Cut Here --- > Thank you for your inquiry, > > There are three ways to purchase Xilinx products: > > Xilinx Sales Reps: http://www.xilinx.com/company/contact/sales-offices.htm > · Sales representatives can help if you do not know which products are best for your design. > > Online Store: http://www.xilinx.com/onlinestore/ > · The Xilinx Online Store provides a quick and simple way to purchase Xilinx design tools and a selection of development boards and kits directly from Xilinx. Simply locate your product of interest and click the "Buy" link from anywhere on Xilinx.com to get started. > > Things to consider before purchasing from the Xilinx Online Store: > > · Tax Exempt orders must be placed through distribution. > · On-line purchases are by credit card only. No purchase orders please. > Xilinx accepts the following credit cards: Visa, MasterCard, and American Express > · No Intellectual Products are sold on the On-line Store > > Xilinx Distributors: http://www.xilinx.com/company/contact/index.htm > > · Xilinx Authorized Distributors offer access to a comprehensive set of Xilinx design tools, IP cores, devices, development boards and kits. > > · The Xilinx Productivity Advantage (XPA) Bundling Program is only offered when purchasing through a Xilinx Authorized Distributor. To learn more about how to reduce your design productivity solution costs, please visit http://www.xilinx.com/xpa/. > > University Faculty: http://www.xilinx.com/university/professors/index.htm > · Universities may be eligible for full versions of design tools at no charge. University professors must initiate the request at the University Faculty link above. > > Thank you, > Xilinx Development System Team > --- Cut Here --- > > ... which is useless [I know what I want to use it for, so no sales reps; The online store doesn't provide any option I can see; I can't see distributors being interested in upgrading a kit I bought directly from Xilinx; I'm not at university]. > > I didn't actually read the reply until the next day due to work/home email filters, so once I've read it, I send in another request, pointing out that the canned reply wasn't useful and asking the same question again, along with "Is it really the case that I have to but a new piece of hardware (which I don't want or need) in order to extend a license for a product I bought directly from you ?" because the only way I can see it being possible on the xilinx site is to re-purchase the same board, thus getting a new license. > > Guess what. A few seconds later I get back the exact *same* reply, word for word. No attempt to read/parse the question I asked, just an apparent canned reply for any license/purchase question. > > I wanted to work on this in the background, with a project that I think could be useful for my work, but it's not official, so I can't go to the support guys here at work. I would have liked to have tried to use the same device manufacturer as the tens-of-thousands-of-dollars boards that we have here at work, for ease of later porting, but I'm now so frustrated by the lack of human response, I'm going to look at Altera (or anyone else, really, all I want is PCIe and some DDR ram) > > I *was* prepared to put down my own hard-earned cash to do this, but I'll be damned if they're getting any of my money now, if they can't even answer a simple question like this, I can't see them being any use once I've spent the money. > > Giving up on Xilinx. Instead of ranting, maybe you should look at your approach. What you call the "support" channel is just a minimum effort at helping those who don't really have support. If they suggest that you contact sales, then why not contact sales? I'm sure they will point you in the right direction. They don't exist solely for taking orders. I haven't dealt with Xilinx in some years but I have the same issues with Lattice. I find that human support through FAEs is pretty good. Also they have a separate channel for licenses which are updated every year for free. Apparently unlike Xilinx, the Lattice license will stop your software from working when it expires. That part royally sucks. It is always on a Friday after 5 PM when I fire up Lattice Diamond (or previously the "classic" tool) only to find it has expired and I won't be working on the project over the weekend as I had planned. I am starting to learn however and have added the license expiration date to my calendar with a 2 week in advance reminder. -- RickArticle: 157659
On 1/21/2015 5:03 PM, rickman wrote: > On 1/21/2015 1:34 PM, Simon wrote: >> >> So I wanted to know if it was possible to update an old >> embedded-development kit license that's expired. There's nothing on >> xilinx' site as far as I can see that allows for old licenses to be >> renewed. So I go to the support section, fill out the form explaining >> the situation and send it off. >> >> I promptly get back a canned reply... >> >> --- Cut Here --- >> Thank you for your inquiry, >> >> There are three ways to purchase Xilinx products: >> >> Xilinx Sales Reps: >> http://www.xilinx.com/company/contact/sales-offices.htm >> · Sales representatives can help if you do not know which >> products are best for your design. >> >> Online Store: http://www.xilinx.com/onlinestore/ >> · The Xilinx Online Store provides a quick and simple way to >> purchase Xilinx design tools and a selection of development boards and >> kits directly from Xilinx. Simply locate your product of interest and >> click the "Buy" link from anywhere on Xilinx.com to get started. >> >> Things to consider before purchasing from the Xilinx Online Store: >> >> · Tax Exempt orders must be placed through distribution. >> · On-line purchases are by credit card only. No purchase orders >> please. >> Xilinx accepts the following credit cards: Visa, MasterCard, and >> American Express >> · No Intellectual Products are sold on the On-line Store >> >> Xilinx Distributors: http://www.xilinx.com/company/contact/index.htm >> >> · Xilinx Authorized Distributors offer access to a comprehensive >> set of Xilinx design tools, IP cores, devices, development boards and >> kits. >> >> · The Xilinx Productivity Advantage (XPA) Bundling Program is >> only offered when purchasing through a Xilinx Authorized Distributor. >> To learn more about how to reduce your design productivity solution >> costs, please visit http://www.xilinx.com/xpa/. >> >> University Faculty: >> http://www.xilinx.com/university/professors/index.htm >> · Universities may be eligible for full versions of design tools >> at no charge. University professors must initiate the request at the >> University Faculty link above. >> >> Thank you, >> Xilinx Development System Team >> --- Cut Here --- >> >> ... which is useless [I know what I want to use it for, so no sales >> reps; The online store doesn't provide any option I can see; I can't >> see distributors being interested in upgrading a kit I bought directly >> from Xilinx; I'm not at university]. >> >> I didn't actually read the reply until the next day due to work/home >> email filters, so once I've read it, I send in another request, >> pointing out that the canned reply wasn't useful and asking the same >> question again, along with "Is it really the case that I have to but a >> new piece of hardware (which I don't want or need) in order to extend >> a license for a product I bought directly from you ?" because the only >> way I can see it being possible on the xilinx site is to re-purchase >> the same board, thus getting a new license. >> >> Guess what. A few seconds later I get back the exact *same* reply, >> word for word. No attempt to read/parse the question I asked, just an >> apparent canned reply for any license/purchase question. >> >> I wanted to work on this in the background, with a project that I >> think could be useful for my work, but it's not official, so I can't >> go to the support guys here at work. I would have liked to have tried >> to use the same device manufacturer as the >> tens-of-thousands-of-dollars boards that we have here at work, for >> ease of later porting, but I'm now so frustrated by the lack of human >> response, I'm going to look at Altera (or anyone else, really, all I >> want is PCIe and some DDR ram) >> >> I *was* prepared to put down my own hard-earned cash to do this, but >> I'll be damned if they're getting any of my money now, if they can't >> even answer a simple question like this, I can't see them being any >> use once I've spent the money. >> >> Giving up on Xilinx. > > Instead of ranting, maybe you should look at your approach. What you > call the "support" channel is just a minimum effort at helping those who > don't really have support. If they suggest that you contact sales, then > why not contact sales? I'm sure they will point you in the right > direction. They don't exist solely for taking orders. > > I haven't dealt with Xilinx in some years but I have the same issues > with Lattice. I find that human support through FAEs is pretty good. > Also they have a separate channel for licenses which are updated every > year for free. Apparently unlike Xilinx, the Lattice license will stop > your software from working when it expires. That part royally sucks. It > is always on a Friday after 5 PM when I fire up Lattice Diamond (or > previously the "classic" tool) only to find it has expired and I won't > be working on the project over the weekend as I had planned. I am > starting to learn however and have added the license expiration date to > my calendar with a 2 week in advance reminder. > Yeah, that does suck. I think the main difference is that Lattice is using third party tools like Synplify whose licenses are time-limited and Lattice can't do anything about it. It was the same for xilinx back when they used the Aldec front-end and FPGA Express for synthesis. No chip provider wants your license to expire if that means you won't be designing in and buying their parts. However the third party tool providers are not getting revenue from chip sales and need another approach. I seem to recall that Xilinx dropped Aldec (or more likely the other way around) because Aldec accused Xilinx of not properly counting the seats of Foundation tools. -- GaborArticle: 157660
Well, it turns out I can install Linux under Parallels on my Mac, fudge the= MAC address to be that of the old machine, launch ISE and it asks for a li= cence file. I downloaded the licence file from Xilinx, installed it, and it= works well - it seemed to give me a new year's worth of time for any dates= that weren't marked as 'permanent' in fact, and there's no warning message= s on launch. So, no thanks to Xilinx (well, ok, I'll be fair: some thanks for making the= licensing system work this way), but many thanks to those who know more ab= out xilinx licensing than I do. As for contacting sales, the FPGA guys where I work have enough trouble get= ting Xilinx to help *them* out, and they spend lots (the last board they ga= ve me to write drivers for cost ~$25k, mainly due to the FPGAs, and it's no= t as though we just build 1 at a time...). I (personally) spend very little= . I've never yet had any luck with a sales(wo)man who didn't see any sort o= f profit in it for him/her. If the post-sales support is really handled by = 'sales', then it ought to be renamed as such; just like if the 'support' se= ction of the website isn't actually there to provide "support", then it's a= lso badly named. All IMHO of course. Anyway, all's well that ends well. I can get on and try to implement my des= ign, hopefully show the FPGA guys something they won't laugh *too* much at,= and maybe it'll even be useful. =20 SimonArticle: 157661
I've been using Xilinx tools at work for chips not supported by WebPack. Process is as following: * Ask my Xilinx distributor for a quote on Xilinx Logic Edition. * Get the quote and put it into our company purchase system. * Wait for our purchase to do their job * Wait for email from Xilinx that a new license is available * Go to my Xilinx license page to redeem the license we paid for * Tie the license to a network NIC (we use floating license) * Download license file and restart flexlm * Care about updating for one year * After one year, either buy new license or don't bother According to my distributors excellent FAE: * A purchased Xilinx license is valid forever * Updates are available 1 year from purchase. * After this, the last update within the 1 year time is fixed * To get an update after 1 year has passed, buy a new license * There is no upgrade price reduction. * Going from Logic Edition to System Edition is System Edition price Of all FPGA tools we have, Xilinx is the least difficult one. As long as we do development on new FPGA chips, we buy a license. When product goes into production and development stops, we have a perpetual right to use the dev tools from Xilinx for maintenance of our product. I see all the time that sneaky bugs needs to be rooted out two or three years into the product life. Xilinx will still work on the old license code, while ModelSim and Synopsys will require us to keep paying yearly fees to be allowed to use for a week or two to find a bug. -- SvennArticle: 157662
Hello, I want to send a pulse from one clock domain to another, knowing tha= t from the time event that this pulse is generated in the source clock doma= in it arrives in the first rising edge of the destination clock domain and = lasts exactly one clock period of the destination clock domain. Now, I know= this problem is not generic and is subject to timing constraints and clock= frequency/phase relationship. So the question would be, how to implement i= t best in RTL with Xilinx technology and what time constraints to apply fro= m source to destination FF. In particular the destination clock is a little= over half of the source clock frequency, the phase between them is unknown= and may change over time. Currently my idea is to use the asynchronous preset/clear of the destinatio= n FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-seri= es FPGAs) there must be some relation between the clocks that allows the mi= nimum pulse width and propagation of the asynchronous signal. Any help is appreaciated.Article: 157663
On Thu, 22 Jan 2015 06:05:23 -0800, Leo wrote: > Hello, I want to send a pulse from one clock domain to another, knowing > that from the time event that this pulse is generated in the source > clock domain it arrives in the first rising edge of the destination > clock domain and lasts exactly one clock period of the destination clock > domain. Huh? That's not at all clear. You're saying that the pulse always arrives on "the first rising edge of the destination clock domain" -- you mean the first rising edge after power up? Always? Or do you mean the first rising edge ever? Then you say the pulse lasts exactly one period of the destination clock domain -- how can it do that, when it's being sourced in a different domain? > Now, I know this problem is not generic and is subject to timing > constraints and clock frequency/phase relationship. So the question > would be, how to implement it best in RTL with Xilinx technology and > what time constraints to apply from source to destination FF. In > particular the destination clock is a little over half of the source > clock frequency, the phase between them is unknown and may change over > time. > > Currently my idea is to use the asynchronous preset/clear of the > destination FF, which would mean that on an specific part (Xilinx > Spartan 6 or 7-series FPGAs) there must be some relation between the > clocks that allows the minimum pulse width and propagation of the > asynchronous signal. If the pulse _from_ the faster clock domain always lasts two source clocks, then you should be able to reliably capture it with a plain old register. However, we get back to your unclear opening paragraph. Assuming that the pulse is of some shorter width, then yes you need to do something different. I don't know that you necessarily have LUT-by-LUT access to the preset (I'd have to spelunk through data sheets, or ask here). If you don't, you may have to build an RS FF, which should be possible with just a few lines of code. If you do that then you'll have some hold time requirement which the tools may or may not be able to calculate. > Any help is appreaciated. If you want what I think you want, it would be helpful to allow a few clock cycles of delay in the destination, to allow for synchronization (or metastability killing -- whatever). You haven't said how quickly you need to act on this pulse. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157664
On Thu, 22 Jan 2015 06:05:23 -0800 (PST) Leo <capossio.leonardo@gmail.com> wrote: > Hello, I want to send a pulse from one clock domain to another, knowing that from the time event that this pulse is generated in the source clock domain it arrives in the first rising edge of the destination clock domain and lasts exactly one clock period of the destination clock domain. Now, I know this problem is not generic and is subject to timing constraints and clock frequency/phase relationship. So the question would be, how to implement it best in RTL with Xilinx technology and what time constraints to apply from source to destination FF. In particular the destination clock is a little over half of the source clock frequency, the phase between them is unknown and may change over time. > > Currently my idea is to use the asynchronous preset/clear of the destination FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-series FPGAs) there must be some relation between the clocks that allows the minimum pulse width and propagation of the asynchronous signal. > > Any help is appreaciated. Pulse-toggle-pulse synchronizer. My go-to answer for this problem; there has to be a bizarre and compelling reason for me to do otherwise. Sending domain has a T-flop; so the pulse causes the output to transition. We don't care which way. The output of the T-flop goes into one flop, then a second, then a third, on the receiving domain. First gets rid of metastability. XOR of the second and the third is your reconstructed pulse. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157665
On Wed, 21 Jan 2015 23:06:49 -0800, Simon wrote: > Well, it turns out I can install Linux under Parallels on my Mac, fudge > the MAC address to be that of the old machine, launch ISE and it asks > for a licence file. I downloaded the licence file from Xilinx, installed > it, and it works well - it seemed to give me a new year's worth of time > for any dates that weren't marked as 'permanent' in fact, and there's no > warning messages on launch. > > So, no thanks to Xilinx (well, ok, I'll be fair: some thanks for making > the licensing system work this way), but many thanks to those who know > more about xilinx licensing than I do. > > As for contacting sales, the FPGA guys where I work have enough trouble > getting Xilinx to help *them* out, and they spend lots (the last board > they gave me to write drivers for cost ~$25k, mainly due to the FPGAs, > and it's not as though we just build 1 at a time...). I (personally) > spend very little. I've never yet had any luck with a sales(wo)man who > didn't see any sort of profit in it for him/her. If the post-sales > support is really handled by 'sales', then it ought to be renamed as > such; just like if the 'support' section of the website isn't actually > there to provide "support", then it's also badly named. All IMHO of > course. > > Anyway, all's well that ends well. I can get on and try to implement my > design, hopefully show the FPGA guys something they won't laugh *too* > much at, and maybe it'll even be useful. You may want to try your distributor. It's been a few years since I've actively worked on anything FPGA (apparently I write HDL for my algorithms so that real FPGA guys have something to sneer at), but when I did, I got zero help from Xilinx, and great big loads of help from our local Avnet field applications engineer. Avnet has some arrangement with Xilinx that makes sure that they get paid if you design in parts due to their efforts, and at least our local guy here has been incredibly helpful. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157666
El jueves, 22 de enero de 2015, 14:46:17 (UTC-3), Tim Wescott escribi=F3: > On Thu, 22 Jan 2015 06:05:23 -0800, Leo wrote: >=20 > > Hello, I want to send a pulse from one clock domain to another, knowing > > that from the time event that this pulse is generated in the source > > clock domain it arrives in the first rising edge of the destination > > clock domain and lasts exactly one clock period of the destination cloc= k > > domain. >=20 > Huh? That's not at all clear. >=20 > You're saying that the pulse always arrives on "the first rising edge of= =20 > the destination clock domain" -- you mean the first rising edge after=20 > power up? Always? Or do you mean the first rising edge ever? >=20 > Then you say the pulse lasts exactly one period of the destination clock= =20 > domain -- how can it do that, when it's being sourced in a different=20 > domain? >=20 > > Now, I know this problem is not generic and is subject to timing > > constraints and clock frequency/phase relationship. So the question > > would be, how to implement it best in RTL with Xilinx technology and > > what time constraints to apply from source to destination FF. In > > particular the destination clock is a little over half of the source > > clock frequency, the phase between them is unknown and may change over > > time. > >=20 > > Currently my idea is to use the asynchronous preset/clear of the > > destination FF, which would mean that on an specific part (Xilinx > > Spartan 6 or 7-series FPGAs) there must be some relation between the > > clocks that allows the minimum pulse width and propagation of the > > asynchronous signal. >=20 > If the pulse _from_ the faster clock domain always lasts two source=20 > clocks, then you should be able to reliably capture it with a plain old= =20 > register. However, we get back to your unclear opening paragraph. >=20 > Assuming that the pulse is of some shorter width, then yes you need to do= =20 > something different. I don't know that you necessarily have LUT-by-LUT= =20 > access to the preset (I'd have to spelunk through data sheets, or ask=20 > here). If you don't, you may have to build an RS FF, which should be=20 > possible with just a few lines of code. If you do that then you'll have= =20 > some hold time requirement which the tools may or may not be able to=20 > calculate. >=20 > > Any help is appreaciated. >=20 > If you want what I think you want, it would be helpful to allow a few=20 > clock cycles of delay in the destination, to allow for synchronization (o= r=20 > metastability killing -- whatever). You haven't said how quickly you nee= d=20 > to act on this pulse. >=20 > --=20 >=20 > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com You are right, after re-reading, it isn't clear. I want the pulse generated= on the rising edge of the source clk to be transported to the destination = clk domain in the first rising edge of the destination clk after the pulse = was generated. In other words I want the destination clock to catch the pul= se as fast as possible, and I also need the pulse to last a single clock cy= cle of the destination clk (I plan to shift it down a shift reg to delay it= ). I can leave with latency as long as this latency is always the same in dest= ination clk cycles. I need it because from the time that this pulse is generated in the source = clk, I need to count exactly 14 clk cycles of the destination clk to catch = correct data going down a pipeline on the destination clk.Article: 157667
El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribi=F3: > On Thu, 22 Jan 2015 06:05:23 -0800 (PST) > Leo wrote: >=20 > > Hello, I want to send a pulse from one clock domain to another, knowing= that from the time event that this pulse is generated in the source clock = domain it arrives in the first rising edge of the destination clock domain = and lasts exactly one clock period of the destination clock domain. Now, I = know this problem is not generic and is subject to timing constraints and c= lock frequency/phase relationship. So the question would be, how to impleme= nt it best in RTL with Xilinx technology and what time constraints to apply= from source to destination FF. In particular the destination clock is a li= ttle over half of the source clock frequency, the phase between them is unk= nown and may change over time. > >=20 > > Currently my idea is to use the asynchronous preset/clear of the destin= ation FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-= series FPGAs) there must be some relation between the clocks that allows th= e minimum pulse width and propagation of the asynchronous signal. > >=20 > > Any help is appreaciated. >=20 > Pulse-toggle-pulse synchronizer. My go-to answer for this problem; > there has to be a bizarre and compelling reason for me to do otherwise. >=20 > Sending domain has a T-flop; so the pulse causes the output to > transition. We don't care which way. The output of the T-flop goes > into one flop, then a second, then a third, on the receiving domain. > First gets rid of metastability. XOR of the second and the third is > your reconstructed pulse. >=20 > --=20 > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix. That is a good answer thank you. The only question I have is: does the XOR = output always have the same delay in destionation clk cycles (3 cycles), or= there might be a case where it takes more or less ?Article: 157668
On Thu, 22 Jan 2015 10:21:34 -0800 (PST) Leo <capossio.leonardo@gmail.com> wrote: > El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribi=C3=B3: > > On Thu, 22 Jan 2015 06:05:23 -0800 (PST) > > Leo wrote: > >=20 > > > Hello, I want to send a pulse from one clock domain to another, knowi= ng that from the time event that this pulse is generated in the source cloc= k domain it arrives in the first rising edge of the destination clock domai= n and lasts exactly one clock period of the destination clock domain. Now, = I know this problem is not generic and is subject to timing constraints and= clock frequency/phase relationship. So the question would be, how to imple= ment it best in RTL with Xilinx technology and what time constraints to app= ly from source to destination FF. In particular the destination clock is a = little over half of the source clock frequency, the phase between them is u= nknown and may change over time. > > >=20 > > > Currently my idea is to use the asynchronous preset/clear of the dest= ination FF, which would mean that on an specific part (Xilinx Spartan 6 or = 7-series FPGAs) there must be some relation between the clocks that allows = the minimum pulse width and propagation of the asynchronous signal. > > >=20 > > > Any help is appreaciated. > >=20 > > Pulse-toggle-pulse synchronizer. My go-to answer for this problem; > > there has to be a bizarre and compelling reason for me to do otherwise. > >=20 > > Sending domain has a T-flop; so the pulse causes the output to > > transition. We don't care which way. The output of the T-flop goes > > into one flop, then a second, then a third, on the receiving domain. > > First gets rid of metastability. XOR of the second and the third is > > your reconstructed pulse. > >=20 > > --=20 > > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > > Email address domain is currently out of order. See above to fix. >=20 > That is a good answer thank you. The only question I have is: does the XO= R output always have the same delay in destionation clk cycles (3 cycles), = or there might be a case where it takes more or less ? In rereading, it's not quite what you asked for, with a minimum latency solution, nor what you later asked for with a deterministic latency solution. The problem is, with truly asynchronous clocks, shortening latency increases risk, and deterministic latency is impossible. Think about a scope, triggering on your source clock edge. The relative location of your destination clock edge is uniformly distributed everywhere on the screen, up to and including mere picoseconds either way from the source edge. That means that when you hit the first flop on the destination domain (and that needs to be ONE flop, never ever ever two with an expectation they'll behave the same) you have a guarantee that sometimes you'll violate the setup timing of that flop. When you do that, it goes metastable -- the internal nodes hit a linear state that is neither 1 or zero, and stay there until the positive feedback pushes them to one rail or the other, an amount of time that is probabilistic rather than deterministic. Whether it'll settle to the old or new value is anyone's guess. But the moral of the story is: accept that there's 1 clock of variability in that latency and design your system to live with it. If you can't, then you can't have an async clock crossing there. --=20 Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157669
On Thu, 22 Jan 2015 10:21:34 -0800, Leo wrote: > El jueves, 22 de enero de 2015, 14:50:13 (UTC-3), Rob Gaddi escribió: >> On Thu, 22 Jan 2015 06:05:23 -0800 (PST) >> Leo wrote: >> >> > Hello, I want to send a pulse from one clock domain to another, >> > knowing that from the time event that this pulse is generated in the >> > source clock domain it arrives in the first rising edge of the >> > destination clock domain and lasts exactly one clock period of the >> > destination clock domain. Now, I know this problem is not generic and >> > is subject to timing constraints and clock frequency/phase >> > relationship. So the question would be, how to implement it best in >> > RTL with Xilinx technology and what time constraints to apply from >> > source to destination FF. In particular the destination clock is a >> > little over half of the source clock frequency, the phase between >> > them is unknown and may change over time. >> > >> > Currently my idea is to use the asynchronous preset/clear of the >> > destination FF, which would mean that on an specific part (Xilinx >> > Spartan 6 or 7-series FPGAs) there must be some relation between the >> > clocks that allows the minimum pulse width and propagation of the >> > asynchronous signal. >> > >> > Any help is appreaciated. >> >> Pulse-toggle-pulse synchronizer. My go-to answer for this problem; >> there has to be a bizarre and compelling reason for me to do otherwise. >> >> Sending domain has a T-flop; so the pulse causes the output to >> transition. We don't care which way. The output of the T-flop goes >> into one flop, then a second, then a third, on the receiving domain. >> First gets rid of metastability. XOR of the second and the third is >> your reconstructed pulse. > > That is a good answer thank you. The only question I have is: does the > XOR output always have the same delay in destionation clk cycles (3 > cycles), or there might be a case where it takes more or less ? When the source and destination clock edges are close to happening at the same time there will be an uncertainty of which destination clock catches the transition on the T-flop -- but that uncertainty will be with you always anyway. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157670
Rob Gaddi wrote: [snip] > > That means that when you hit the first flop on the destination domain > (and that needs to be ONE flop, never ever ever two with an expectation > they'll behave the same) you have a guarantee that sometimes you'll > violate the setup timing of that flop. When you do that, it goes > metastable -- the internal nodes hit a linear state that is neither 1 > or zero, and stay there until the positive feedback pushes them to one > rail or the other, an amount of time that is probabilistic rather than > deterministic. Whether it'll settle to the old or new value is > anyone's guess. > This is a bit over-pessimistic. The setup and hold time of a flop are spec'd over PVT. The metastability window is much much smaller than the window specified by the setup and hold times. What you do get between the setup and hold time is a window when you can't know for sure over all temperature, voltage, and process whether the change in the input will propagate to the output on that clock cycle, or whether it will not go through until the next cycle. > But the moral of the story is: accept that there's 1 clock of > variability in that latency and design your system to live with it. If > you can't, then you can't have an async clock crossing there. > Again if you want to be pessimistic, you could add the setup/hold time violation window to the destination clock period and call that the variation in latency you will see. However this ignores the fact that the device will be operating at the same PVT point on one cycle that it is on the next cycle. Anyway the toggle business is a very good idea since it means you don't need to deal with asynchronous set/reset in the destination clock domain to stretch a short pulse. -- GaborArticle: 157671
On Thu, 22 Jan 2015 14:05:05 -0500 GaborSzakacs <gabor@alacron.com> wrote: > Rob Gaddi wrote: > > [snip] > > > > > That means that when you hit the first flop on the destination domain > > (and that needs to be ONE flop, never ever ever two with an expectation > > they'll behave the same) you have a guarantee that sometimes you'll > > violate the setup timing of that flop. When you do that, it goes > > metastable -- the internal nodes hit a linear state that is neither 1 > > or zero, and stay there until the positive feedback pushes them to one > > rail or the other, an amount of time that is probabilistic rather than > > deterministic. Whether it'll settle to the old or new value is > > anyone's guess. > > > > This is a bit over-pessimistic. The setup and hold time of a flop are > spec'd over PVT. The metastability window is much much smaller than > the window specified by the setup and hold times. What you do get > between the setup and hold time is a window when you can't know > for sure over all temperature, voltage, and process whether the > change in the input will propagate to the output on that clock > cycle, or whether it will not go through until the next cycle. > Right, but with an async clock crossing you are GUARANTEED to occasionally end up inside of that admittedly small window. Likewise, when you do, the probability function of how long resolution will take has (if I recall correctly) an exponential PDF. On modern FPGAs, the resolution function becomes more likely to be resolved than not in something absurd like 100 ps, making the chances that it's not done resolving in the span of a reasonable clock period something on the order of being hit by a bus that is being hit by lightning. But you still don't know whether you're going to get a 0 or a 1. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157672
On Thursday, January 22, 2015 at 1:21:37 PM UTC-5, Leo wrote: > That is a good answer thank you. The only question I have is: does the XO= R output always have the same delay in destionation clk cycles (3 cycles), = or there might be a case where it takes more or less ? Since the clock phases are unknown and (presumably) different and shifting = relative to each other, then it could be longer. The most likely answer is= that it would occasionally take one extra clock. If you consider metastab= ility, then there could be likely yet another extra clock or an exponential= ly decreasing probability of even more. There is no way to guarantee that = the very next destination clock edge will be the one that grabs the pulse s= ince you haven't designed in a way to guarantee that you won't violate setu= p/hold time requirements. So the delay in clock cycles will look something like this: 3 : Happens when setup/hold time is not violated 4 : May happen when setup/hold time is violated but no metastability 5 or more : Will happen when setup/hold time is violated and metastability = occurs Kevin JenningsArticle: 157673
Tim Wescott <seemywebsite@myfooter.really> wrote:
> Assuming that the pulse is of some shorter width, then yes you need to do
> something different. I don't know that you necessarily have LUT-by-LUT
> access to the preset (I'd have to spelunk through data sheets, or ask
> here). If you don't, you may have to build an RS FF, which should be
> possible with just a few lines of code. If you do that then you'll have
> some hold time requirement which the tools may or may not be able to
> calculate.
Not so long ago, I wrote this:
module S2504(out, in, phi1, phi2);
output out;
input in, phi1, phi2;
reg q1, q2;
reg [511:0] s1, s2;
wire R, S;
always @(posedge phi1) q1 <= in;
always @(posedge phi2) q2 <= in;
always @(negedge phi2) s1 <= {s1[510:0], q1};
always @(negedge phi1) s2 <= {s2[510:0], q2};
assign R=~(S & phi1), S=~(R & phi2);
assign out=(R & s2[511]) | (S & s1[511]);
endmodule
There is a warning message about a combinatorial loop, but I believe
it works.
In case it isn't obvious, it is a shift register with a two-phase
clock that shifts on the falling edge of either phase. The output
is from the last shift (falling edge).
The real 2504 is a pMOS dynamic shift register.
-- glen
Article: 157674
On 1/22/2015 12:50 PM, Rob Gaddi wrote:
> On Thu, 22 Jan 2015 06:05:23 -0800 (PST)
> Leo <capossio.leonardo@gmail.com> wrote:
>
>> Hello, I want to send a pulse from one clock domain to another, knowing that from the time event that this pulse is generated in the source clock domain it arrives in the first rising edge of the destination clock domain and lasts exactly one clock period of the destination clock domain. Now, I know this problem is not generic and is subject to timing constraints and clock frequency/phase relationship. So the question would be, how to implement it best in RTL with Xilinx technology and what time constraints to apply from source to destination FF. In particular the destination clock is a little over half of the source clock frequency, the phase between them is unknown and may change over time.
>>
>> Currently my idea is to use the asynchronous preset/clear of the destination FF, which would mean that on an specific part (Xilinx Spartan 6 or 7-series FPGAs) there must be some relation between the clocks that allows the minimum pulse width and propagation of the asynchronous signal.
>>
>> Any help is appreaciated.
>
> Pulse-toggle-pulse synchronizer. My go-to answer for this problem;
> there has to be a bizarre and compelling reason for me to do otherwise.
>
> Sending domain has a T-flop; so the pulse causes the output to
> transition. We don't care which way. The output of the T-flop goes
> into one flop, then a second, then a third, on the receiving domain.
> First gets rid of metastability. XOR of the second and the third is
> your reconstructed pulse.
I think this is similar to the circuit I use except I use feedback from
the To clock domain to make the From FF toggle. This makes it
impossible for too frequent triggers in the first domain screwing up the
pulse in the other domain.
FromLogic : process (FromClk, FromReset)
begin
if (FromReset = '1') then
FromSync <= '0';
elsif (rising_edge(FstClk)) then
FromSync <= not ToSync;
end if;
end process FromLogic;
ToLogic : process (ToClk, ToReset)
begin
if (ToReset = '1') then
ToSync <= '0';
ToSync_d <= '0';
elsif (rising_edge(FstClk)) then
ToSync <= FromSync;
ToSync_d <= ToSync;
end if;
end process ToLogic;
PulseOut <= ToSync XOR ToSync_d;
I haven't tested the above code so I won't guaranty it works correctly.
The idea is that either edge of FromSync creates a pulse in the To
clock domain. Only one edge ca be generated until the first edge is
"seen" by the logic in the To domain. The relative speeds of the two
clock domains is not important.
Some people add another FF in the To domain to help with metastability.
But what you really need is slack time which should be no problem if
you spec it in the timing constraint of the appropriate logic paths.
--
Rick
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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