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 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com... > > > > > On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote: > >> "Antti" <Antti.Luk...@googlemail.com> wrote in message > > >>news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com...= > > >> > Hi > > >> > FPGA has > >> > 1) 50mhz system clock from ext oscillator > >> > 2) 4Mhz clk that is async to the 50mhz > > >> > problem, the 4MHz clk input sees double clk pulse, error rate > >> > approximate 1 to 10.000.000 > > >> Not quite sure what you mean by a 'double clk pulse' but I'm assuming > >> that > >> you're feeding the 4MHz clock into 'something' in the FPGA that is > >> clocked > >> by 50 MHz. If that's the case, then what you need to verify in the fin= al > >> technology map that the 4MHz signal comes into exactly one flip flop an= d > >> the > >> output of that exactly one flip flop is what you use to clock anything > >> else...and to mitigate metastability a bit more, that 'anything else' > >> logic > >> might consist of again exactly one flop, the output of which is fed int= o > >> the > >> real logic (i.e. you're constucting a two flop synchronizer). You'll > >> also > >> want to add synthesis attributes to any of these synchronizing flops to= > >> insure that the logic doesn't get opotomized in a way that ends up > >> replicating the flops. In any case, verify the final routed result > >> brings > >> 4MHz into exactly one flop (and if adding a second sync flop that it to= o > >> is > >> the only load on the flop that captures the 4MHz) > > >> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input > >> Pin > > >> Since you haven't stated just how you're using the 4MHz clock inside th= e > >> FPGA, you should probably clarify that, but a failure rate every 0.2 > >> seconds > >> (10 M of the 50MHz clock) then it's quite apparent that one of the most= > >> likely causes of the failure is one of the following: > >> - Simple timing (whch will be fixed by what I outline in the previous > >> paragraph). > >> - Signal quality > >> 1. Measured at the FPGA, are the rising and falling edges of the 50= > >> MHz > >> monotonic? > >> 2. Measured at the FPGA, the 4 MHz clock doesn't have to be > >> absolutely > >> monotonic since it doesn't appear to be used to sample anything, but if= > >> it > >> dips and comes back up and the dip is low enough to appear to be a logi= c > >> low > >> than the 50 MHz could (and eventually will) sample it at precisely that= > >> bad > >> point. > >> - Could be power as well, not dipping out of spec at the FPGA are you? > > >> > unfortunatly the 4mhz clock needs to be used inside without phase > >> > delay, so oversampling and filtering with 50mhz is not an option, > >> > unless using very clever no delay glitch surpression filter > > >> Might want to elaborate on the reason for the 'without phase delay' > >> requirement, but assuming that to be the case then a different solution= > >> that > >> would minimize the phase delay would be to feed the 4MHz into an onchip= > >> PLL > >> (if you have one) to create a 48 MHz and use that instead of the 50 MHz= . > >> That way, the two clocks would maintain a fairly accurate phase > >> relationship > >> to one another thus avoiding violation of setup/hold time windows. > > >> If the reason for 'without phase delay' requirement is because of other= > >> FPGA > >> inputs that are synchronized to the 4MHz, then another solution might > >> simply > >> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz > >> clock > >> domain. > > >> > external small R/C circuit on 5mhz doesnt change the error rate much,= > >> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to > >> > give better results as using the 4mhz clock directly > > >> This sounds like you are using the 4MHz to drive logic...big mistake (s= ee > >> first paragraph for the solution). > > >> > any ideas how to really clean the 4mhz clock? > > >> Unless you've scoped the 4MHz clock, why do you think it's not 'clean'?= > > >> > or any thumb guess what is the likeliness to see double clk edges whe= n > >> > sampling 4mhz with async 50mhz? > > >> Violating timing, inadequate power at the point of use and signal > >> quality....when it comes right down to it those are the ONLY reasons. = In > >> the end, that's what you'll find here as well. > > >> > could the "error rate" of such sampling be that 1:10M what I am > >> > seeing? > > >> Sure, it simply depends on precisely what the setup/hold timing window = of > >> the actual part is. If you have freeze spray, a hot air gun and a simp= le > >> way to quickly get your error rate measurement then try hitting your FP= GA > >> with the hot, measure your error rate (repeat with the cold) and see if= > >> it > >> has a temperature dependency. If it clearly does, then you have a timi= ng > >> problem (see first paragraph for the solution), if it doesn't or is not= > >> clearly temp dependent, then you likely have a power problem. Based on= > >> the > >> bits of info you've provided, I'm leaning towards the timing. This is= > >> simply science experiment stuff and is not needed to engineer the > >> solution, > >> for that you need static timing analysis, proper clock domain crossing > >> design technique and proper power supply distribution. > > >> > I assume the 4 mhz clock is rather good, it coming from an ASIC and > >> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edg= e > >> > connector). I did kinda think its hard to belive that the clock edge > >> > is so slow or noisy that 50mhz sampling could ever see double/wrong > >> > edges but guess i am wrong > > >> No need to guess or speculate, unless you don't have a scope to simply > >> measure. > > >> > it doesnt seem to be cross talk either, as there arent much IOs > >> > toggling at all > > >> > hm it looks like in rare cases the error is also one clock pulse > >> > missing! > > >> Timing problems produce those symptoms as well. > > >> > :) any good suggestions are welcome, how to troubleshoot the issue > > >> Hopefully you'll find the above useful....to reiterate though, I can da= ng > >> near guarantee the fundamental reason for the failure will be > >> - Violating setup/hold time in the 50 MHz clock > >> - Signal quality (50 MHz or 4 MHz) > >> - Power > > >> What you need to do is measurement or analysis to either eliminate caus= es > >> or > >> turn up the design error. > > >> > unfortunatly the FPGA is actel so can use any on-chip logic analyzer > >> > core, and the chip is rather full also, some internal signal could be= > >> > routed out to external logic analyzer though if badly needed, but so > >> > far i am trying to fix the issue by thinking, and error-retry... > > >> You shouldn't need to bring out anything, static timing analysis and a > >> scope > >> will get you to the root cause. > > >> Good luck. > > >> Kevin Jennings > > > Hi all and thanks for all suggestions! > > some additional info > > > failing circuit > > > ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace > > FPGA input > > > >>F-F strobed with 50mhz > global clock buffer > 2 bit counter > > > now, this 2 bit counter sees > > * double clock from asic in about 1:10M pulses > > * missing clock from asic in about 1:100m pulses > > OK, so it appears that the 4 MHz input is being synchronized to the 50 MHz= > clock through a single flip flop, but have you verified that the final > routed design uses only one flip flop? > > Are you using the now synchronized 4 MHz signal as a clock? Do you know f= or > sure that the Actel device will properly generate an internal clock signal= > from the output of a flip flop? You can't see clock signal quality intern= al > to a device but that doesn't imply that it doesn't matter. If "output of = a > flip flop to the clock input of another" is not something that Actel handl= e > then maybe you shouldn't be doing that. > > > the asic clock is know to be perfect many other devices can receive it > > and have 0 error rate (have not seen error ever!) > > That's good to know. > > > the 50mhz clock signal quality, well it doesn matter, as whatever > > could be wrong, it could not explain the double and missing pulse > > counts ? > > Signal quality on the 50 MHz clock does matter...what if the osc is bad or= > flaky? It's not my first suspect either but again worth verifying at the > input to the FPGA with a scope (when you get access to one) so that it can= > be eliminated as a cause. > > > so what is failing is really simple circuit! > > it also looks like when double pulses are seen the FPGA is not > > changing any of its output so its no SSO noise > > That would also tend to lower power supply noise as a culprit too in my > mind...again, it can only be eliminated as a cause by verification with a > scope when you get a chance. > > > I could understand power supply noise to cause double pulses, but how > > to explain the missing pulses? > > Bad power is worse than a bad clock, all sorts of bad things can happen. > > > I dont have scope here now, but i have tried to troubleshoot the clock > > problem before and have looked the signals with scope without seeing > > anything helpful to get to the problem, i will do it again if I dont > > get it working this weekend > > From here it really smells like the problem is not properly synchronizing > the 4 MHz signal or that the internally generated clock is not a good cloc= k > for whatever reason. > > Also, is the output of the two bit counter directly observable to you and = is > that the reason you say that you miss a clock or get two every now and the= n > or is it because of some other downstream logic output? The reason for > asking is because no matter what you do, if you use the 'synchronized 4 MH= z' > to actually clock a flip flop the output of that two bit counter will be > skewed a bit from the 50 MHz clock because of the unavoidable clock to > output delay of the flip flop (plus possible additional skew from > differences in the clock distribution between the 50 MHz and the > 'synchronized 4 MHz' internal to the device. > > I've found and fixed many other designer's errors by getting rid of > internally generated clocks because, no matter how well you ... > > Erfahren Sie mehr =BB Hi Kevin, many thanks for all the detailed help! this morning I was pretty sure i have the correct answer to the problem - VCCINT bypass capacitor(s) but big disappointment, adding then (<=3D1.5mm from package) did not change the error rate at all !! :( after that I did remove some of the logic from FPGA (not related to the "counter") freeing some 30% of the FPGA, dropping FPGA utilization from 82 to 54% and the error rate dropped * double strobes: 1:500M * missing strobes: 0, - not happened yet, still running long term test the 4Mhz clock is really not a clock, its byte write strobe from external host most of the FPGA logic can/should be clocked with this strobe, and i see little reasons to move all that logic into 50mhz clock domain in 50mhz domains 2 modules exist, one of them is working fully on the "other side" of dual port RAM, and the other module is also not causing problems, it generates 8 clocks per strobe, and shifts in a byte my 2 bit counter is not directly observable, i have software access to return data addressed with the counter so I have test software that compares the returned to data to known good response and calculates the error types, either missing or extra strobe and displays the error counts and count of good responses ah, the 4 mhz strobe/clk is routed as global clock, I do insert the global buffer primitives by hand and verify that the are implemented by the tools as well. if any FF is clocked by local routing in Actel FPGA then it is complete disaster AnttiArticle: 130676
On 30 Mrz., 10:50, Antti <Antti.Luk...@googlemail.com> wrote: > On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote: > > > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > >news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...= > > > > On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote: > > >> "Antti" <Antti.Luk...@googlemail.com> wrote in message > > > >>news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com.= .. > > > >> > Hi > > > >> > FPGA has > > >> > 1) 50mhz system clock from ext oscillator > > >> > 2) 4Mhz clk that is async to the 50mhz > > > >> > problem, the 4MHz clk input sees double clk pulse, error rate > > >> > approximate 1 to 10.000.000 > > > >> Not quite sure what you mean by a 'double clk pulse' but I'm assuming= > > >> that > > >> you're feeding the 4MHz clock into 'something' in the FPGA that is > > >> clocked > > >> by 50 MHz. If that's the case, then what you need to verify in the f= inal > > >> technology map that the 4MHz signal comes into exactly one flip flop = and > > >> the > > >> output of that exactly one flip flop is what you use to clock anythin= g > > >> else...and to mitigate metastability a bit more, that 'anything else'= > > >> logic > > >> might consist of again exactly one flop, the output of which is fed i= nto > > >> the > > >> real logic (i.e. you're constucting a two flop synchronizer). You'll= > > >> also > > >> want to add synthesis attributes to any of these synchronizing flops = to > > >> insure that the logic doesn't get opotomized in a way that ends up > > >> replicating the flops. In any case, verify the final routed result > > >> brings > > >> 4MHz into exactly one flop (and if adding a second sync flop that it = too > > >> is > > >> the only load on the flop that captures the 4MHz) > > > >> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input > > >> Pin > > > >> Since you haven't stated just how you're using the 4MHz clock inside = the > > >> FPGA, you should probably clarify that, but a failure rate every 0.2 > > >> seconds > > >> (10 M of the 50MHz clock) then it's quite apparent that one of the mo= st > > >> likely causes of the failure is one of the following: > > >> - Simple timing (whch will be fixed by what I outline in the previous= > > >> paragraph). > > >> - Signal quality > > >> 1. Measured at the FPGA, are the rising and falling edges of the = 50 > > >> MHz > > >> monotonic? > > >> 2. Measured at the FPGA, the 4 MHz clock doesn't have to be > > >> absolutely > > >> monotonic since it doesn't appear to be used to sample anything, but = if > > >> it > > >> dips and comes back up and the dip is low enough to appear to be a lo= gic > > >> low > > >> than the 50 MHz could (and eventually will) sample it at precisely th= at > > >> bad > > >> point. > > >> - Could be power as well, not dipping out of spec at the FPGA are you= ? > > > >> > unfortunatly the 4mhz clock needs to be used inside without phase > > >> > delay, so oversampling and filtering with 50mhz is not an option, > > >> > unless using very clever no delay glitch surpression filter > > > >> Might want to elaborate on the reason for the 'without phase delay' > > >> requirement, but assuming that to be the case then a different soluti= on > > >> that > > >> would minimize the phase delay would be to feed the 4MHz into an onch= ip > > >> PLL > > >> (if you have one) to create a 48 MHz and use that instead of the 50 M= Hz. > > >> That way, the two clocks would maintain a fairly accurate phase > > >> relationship > > >> to one another thus avoiding violation of setup/hold time windows. > > > >> If the reason for 'without phase delay' requirement is because of oth= er > > >> FPGA > > >> inputs that are synchronized to the 4MHz, then another solution might= > > >> simply > > >> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz= > > >> clock > > >> domain. > > > >> > external small R/C circuit on 5mhz doesnt change the error rate muc= h, > > >> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to > > >> > give better results as using the 4mhz clock directly > > > >> This sounds like you are using the 4MHz to drive logic...big mistake = (see > > >> first paragraph for the solution). > > > >> > any ideas how to really clean the 4mhz clock? > > > >> Unless you've scoped the 4MHz clock, why do you think it's not 'clean= '? > > > >> > or any thumb guess what is the likeliness to see double clk edges w= hen > > >> > sampling 4mhz with async 50mhz? > > > >> Violating timing, inadequate power at the point of use and signal > > >> quality....when it comes right down to it those are the ONLY reasons.= In > > >> the end, that's what you'll find here as well. > > > >> > could the "error rate" of such sampling be that 1:10M what I am > > >> > seeing? > > > >> Sure, it simply depends on precisely what the setup/hold timing windo= w of > > >> the actual part is. If you have freeze spray, a hot air gun and a si= mple > > >> way to quickly get your error rate measurement then try hitting your = FPGA > > >> with the hot, measure your error rate (repeat with the cold) and see = if > > >> it > > >> has a temperature dependency. If it clearly does, then you have a ti= ming > > >> problem (see first paragraph for the solution), if it doesn't or is n= ot > > >> clearly temp dependent, then you likely have a power problem. Based = on > > >> the > > >> bits of info you've provided, I'm leaning towards the timing. This = is > > >> simply science experiment stuff and is not needed to engineer the > > >> solution, > > >> for that you need static timing analysis, proper clock domain crossin= g > > >> design technique and proper power supply distribution. > > > >> > I assume the 4 mhz clock is rather good, it coming from an ASIC and= > > >> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB e= dge > > >> > connector). I did kinda think its hard to belive that the clock edg= e > > >> > is so slow or noisy that 50mhz sampling could ever see double/wrong= > > >> > edges but guess i am wrong > > > >> No need to guess or speculate, unless you don't have a scope to simpl= y > > >> measure. > > > >> > it doesnt seem to be cross talk either, as there arent much IOs > > >> > toggling at all > > > >> > hm it looks like in rare cases the error is also one clock pulse > > >> > missing! > > > >> Timing problems produce those symptoms as well. > > > >> > :) any good suggestions are welcome, how to troubleshoot the issue > > > >> Hopefully you'll find the above useful....to reiterate though, I can = dang > > >> near guarantee the fundamental reason for the failure will be > > >> - Violating setup/hold time in the 50 MHz clock > > >> - Signal quality (50 MHz or 4 MHz) > > >> - Power > > > >> What you need to do is measurement or analysis to either eliminate ca= uses > > >> or > > >> turn up the design error. > > > >> > unfortunatly the FPGA is actel so can use any on-chip logic analyze= r > > >> > core, and the chip is rather full also, some internal signal could = be > > >> > routed out to external logic analyzer though if badly needed, but s= o > > >> > far i am trying to fix the issue by thinking, and error-retry... > > > >> You shouldn't need to bring out anything, static timing analysis and = a > > >> scope > > >> will get you to the root cause. > > > >> Good luck. > > > >> Kevin Jennings > > > > Hi all and thanks for all suggestions! > > > some additional info > > > > failing circuit > > > > ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace > > > FPGA input > > > > >>F-F strobed with 50mhz > global clock buffer > 2 bit counter > > > > now, this 2 bit counter sees > > > * double clock from asic in about 1:10M pulses > > > * missing clock from asic in about 1:100m pulses > > > OK, so it appears that the 4 MHz input is being synchronized to the 50 M= Hz > > clock through a single flip flop, but have you verified that the final > > routed design uses only one flip flop? > > > Are you using the now synchronized 4 MHz signal as a clock? Do you know= for > > sure that the Actel device will properly generate an internal clock sign= al > > from the output of a flip flop? You can't see clock signal quality inte= rnal > > to a device but that doesn't imply that it doesn't matter. If "output o= f a > > flip flop to the clock input of another" is not something that Actel han= dle > > then maybe you shouldn't be doing that. > > > > the asic clock is know to be perfect many other devices can receive it= > > > and have 0 error rate (have not seen error ever!) > > > That's good to know. > > > > the 50mhz clock signal quality, well it doesn matter, as whatever > > > could be wrong, it could not explain the double and missing pulse > > > counts ? > > > Signal quality on the 50 MHz clock does matter...what if the osc is bad = or > > flaky? It's not my first suspect either but again worth verifying at th= e > > input to the FPGA with a scope (when you get access to one) so that it c= an > > be eliminated as a cause. > > > > so what is failing is really simple circuit! > > > it also looks like when double pulses are seen the FPGA is not > > > changing any of its output so its no SSO noise > > > That would also tend to lower power supply noise as a culprit too in my > > mind...again, it can only be eliminated as a cause by verification with = a > > scope when you get a chance. > > > > I could understand power supply noise to cause double pulses, but how > > > to explain the missing pulses? > > > Bad power is worse than a bad clock, all sorts of bad things can happen.= > > > > I dont have scope here now, but i have tried to troubleshoot the clock= > > > problem before and have looked the signals with scope without seeing > > > anything helpful to get to the problem, i will do it again if I dont > > > get it working this weekend > > > From here it really smells like the problem is not properly synchronizin= g > > the 4 MHz signal or that the internally generated clock is not a good cl= ock > > for whatever reason. > > > Also, is the output of the two bit counter directly observable to you an= d is > > that the reason you say that you miss a clock or get two every now and t= hen > > or is it because of some other downstream logic output? The reason for > > asking is because no matter what you do, if you use the 'synchronized 4 = MHz' > > to actually clock a flip flop the output of that two bit counter will be= > > skewed a bit from the > > ... > > Erfahren Sie mehr =BB Hi all the FPGA resource % wasnt the thing after further reducing the utilization down to 37% the error rate increased and missing pulses re- apperared! but, when then removing the flop from 4mhz strobe AND changing synplify constraints: 45 minutes up and running no error detected so far pulse count >10G sure I need the design to work without error with FPGA utilization >=3D90% but seeing the PCB to not fail on the strobe is already some indicator that there is really nothing wrong with the 4mhz strobe signal, so no external conditioning required AnttiArticle: 130677
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com... On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com... > > > > > On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote: > >> "Antti" <Antti.Luk...@googlemail.com> wrote in message > > >>news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com... > > >> > Hi > > >> > FPGA has > >> > 1) 50mhz system clock from ext oscillator > >> > 2) 4Mhz clk that is async to the 50mhz > > >> > problem, the 4MHz clk input sees double clk pulse, error rate > >> > approximate 1 to 10.000.000 > > >> Not quite sure what you mean by a 'double clk pulse' but I'm assuming > >> that > >> you're feeding the 4MHz clock into 'something' in the FPGA that is > >> clocked > >> by 50 MHz. If that's the case, then what you need to verify in the > >> final > >> technology map that the 4MHz signal comes into exactly one flip flop > >> and > >> the > >> output of that exactly one flip flop is what you use to clock anything > >> else...and to mitigate metastability a bit more, that 'anything else' > >> logic > >> might consist of again exactly one flop, the output of which is fed > >> into > >> the > >> real logic (i.e. you're constucting a two flop synchronizer). You'll > >> also > >> want to add synthesis attributes to any of these synchronizing flops to > >> insure that the logic doesn't get opotomized in a way that ends up > >> replicating the flops. In any case, verify the final routed result > >> brings > >> 4MHz into exactly one flop (and if adding a second sync flop that it > >> too > >> is > >> the only load on the flop that captures the 4MHz) > > >> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input > >> Pin > > >> Since you haven't stated just how you're using the 4MHz clock inside > >> the > >> FPGA, you should probably clarify that, but a failure rate every 0.2 > >> seconds > >> (10 M of the 50MHz clock) then it's quite apparent that one of the most > >> likely causes of the failure is one of the following: > >> - Simple timing (whch will be fixed by what I outline in the previous > >> paragraph). > >> - Signal quality > >> 1. Measured at the FPGA, are the rising and falling edges of the 50 > >> MHz > >> monotonic? > >> 2. Measured at the FPGA, the 4 MHz clock doesn't have to be > >> absolutely > >> monotonic since it doesn't appear to be used to sample anything, but if > >> it > >> dips and comes back up and the dip is low enough to appear to be a > >> logic > >> low > >> than the 50 MHz could (and eventually will) sample it at precisely that > >> bad > >> point. > >> - Could be power as well, not dipping out of spec at the FPGA are you? > > >> > unfortunatly the 4mhz clock needs to be used inside without phase > >> > delay, so oversampling and filtering with 50mhz is not an option, > >> > unless using very clever no delay glitch surpression filter > > >> Might want to elaborate on the reason for the 'without phase delay' > >> requirement, but assuming that to be the case then a different solution > >> that > >> would minimize the phase delay would be to feed the 4MHz into an onchip > >> PLL > >> (if you have one) to create a 48 MHz and use that instead of the 50 > >> MHz. > >> That way, the two clocks would maintain a fairly accurate phase > >> relationship > >> to one another thus avoiding violation of setup/hold time windows. > > >> If the reason for 'without phase delay' requirement is because of other > >> FPGA > >> inputs that are synchronized to the 4MHz, then another solution might > >> simply > >> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz > >> clock > >> domain. > > >> > external small R/C circuit on 5mhz doesnt change the error rate much, > >> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to > >> > give better results as using the 4mhz clock directly > > >> This sounds like you are using the 4MHz to drive logic...big mistake > >> (see > >> first paragraph for the solution). > > >> > any ideas how to really clean the 4mhz clock? > > >> Unless you've scoped the 4MHz clock, why do you think it's not 'clean'? > > >> > or any thumb guess what is the likeliness to see double clk edges > >> > when > >> > sampling 4mhz with async 50mhz? > > >> Violating timing, inadequate power at the point of use and signal > >> quality....when it comes right down to it those are the ONLY reasons. > >> In > >> the end, that's what you'll find here as well. > > >> > could the "error rate" of such sampling be that 1:10M what I am > >> > seeing? > > >> Sure, it simply depends on precisely what the setup/hold timing window > >> of > >> the actual part is. If you have freeze spray, a hot air gun and a > >> simple > >> way to quickly get your error rate measurement then try hitting your > >> FPGA > >> with the hot, measure your error rate (repeat with the cold) and see if > >> it > >> has a temperature dependency. If it clearly does, then you have a > >> timing > >> problem (see first paragraph for the solution), if it doesn't or is not > >> clearly temp dependent, then you likely have a power problem. Based on > >> the > >> bits of info you've provided, I'm leaning towards the timing. This is > >> simply science experiment stuff and is not needed to engineer the > >> solution, > >> for that you need static timing analysis, proper clock domain crossing > >> design technique and proper power supply distribution. > > >> > I assume the 4 mhz clock is rather good, it coming from an ASIC and > >> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB > >> > edge > >> > connector). I did kinda think its hard to belive that the clock edge > >> > is so slow or noisy that 50mhz sampling could ever see double/wrong > >> > edges but guess i am wrong > > >> No need to guess or speculate, unless you don't have a scope to simply > >> measure. > > >> > it doesnt seem to be cross talk either, as there arent much IOs > >> > toggling at all > > >> > hm it looks like in rare cases the error is also one clock pulse > >> > missing! > > >> Timing problems produce those symptoms as well. > > >> > :) any good suggestions are welcome, how to troubleshoot the issue > > >> Hopefully you'll find the above useful....to reiterate though, I can > >> dang > >> near guarantee the fundamental reason for the failure will be > >> - Violating setup/hold time in the 50 MHz clock > >> - Signal quality (50 MHz or 4 MHz) > >> - Power > > >> What you need to do is measurement or analysis to either eliminate > >> causes > >> or > >> turn up the design error. > > >> > unfortunatly the FPGA is actel so can use any on-chip logic analyzer > >> > core, and the chip is rather full also, some internal signal could be > >> > routed out to external logic analyzer though if badly needed, but so > >> > far i am trying to fix the issue by thinking, and error-retry... > > >> You shouldn't need to bring out anything, static timing analysis and a > >> scope > >> will get you to the root cause. > > >> Good luck. > > >> Kevin Jennings > > > Hi all and thanks for all suggestions! > > some additional info > > > failing circuit > > > ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace > > FPGA input > > > >>F-F strobed with 50mhz > global clock buffer > 2 bit counter > > > now, this 2 bit counter sees > > * double clock from asic in about 1:10M pulses > > * missing clock from asic in about 1:100m pulses > > OK, so it appears that the 4 MHz input is being synchronized to the 50 MHz > clock through a single flip flop, but have you verified that the final > routed design uses only one flip flop? > > Are you using the now synchronized 4 MHz signal as a clock? Do you know > for > sure that the Actel device will properly generate an internal clock signal > from the output of a flip flop? You can't see clock signal quality > internal > to a device but that doesn't imply that it doesn't matter. If "output of > a > flip flop to the clock input of another" is not something that Actel > handle > then maybe you shouldn't be doing that. > > > the asic clock is know to be perfect many other devices can receive it > > and have 0 error rate (have not seen error ever!) > > That's good to know. > > > the 50mhz clock signal quality, well it doesn matter, as whatever > > could be wrong, it could not explain the double and missing pulse > > counts ? > > Signal quality on the 50 MHz clock does matter...what if the osc is bad or > flaky? It's not my first suspect either but again worth verifying at the > input to the FPGA with a scope (when you get access to one) so that it can > be eliminated as a cause. > > > so what is failing is really simple circuit! > > it also looks like when double pulses are seen the FPGA is not > > changing any of its output so its no SSO noise > > That would also tend to lower power supply noise as a culprit too in my > mind...again, it can only be eliminated as a cause by verification with a > scope when you get a chance. > > > I could understand power supply noise to cause double pulses, but how > > to explain the missing pulses? > > Bad power is worse than a bad clock, all sorts of bad things can happen. > > > I dont have scope here now, but i have tried to troubleshoot the clock > > problem before and have looked the signals with scope without seeing > > anything helpful to get to the problem, i will do it again if I dont > > get it working this weekend > > From here it really smells like the problem is not properly synchronizing > the 4 MHz signal or that the internally generated clock is not a good > clock > for whatever reason. > > Also, is the output of the two bit counter directly observable to you and > is > that the reason you say that you miss a clock or get two every now and > then > or is it because of some other downstream logic output? The reason for > asking is because no matter what you do, if you use the 'synchronized 4 > MHz' > to actually clock a flip flop the output of that two bit counter will be > skewed a bit from the 50 MHz clock because of the unavoidable clock to > output delay of the flip flop (plus possible additional skew from > differences in the clock distribution between the 50 MHz and the > 'synchronized 4 MHz' internal to the device. > > I've found and fixed many other designer's errors by getting rid of > internally generated clocks because, no matter how well you ... > > Erfahren Sie mehr » Hi Kevin, many thanks for all the detailed help! this morning I was pretty sure i have the correct answer to the problem - VCCINT bypass capacitor(s) but big disappointment, adding then (<=1.5mm from package) did not change the error rate at all !! :( after that I did remove some of the logic from FPGA (not related to the "counter") freeing some 30% of the FPGA, dropping FPGA utilization from 82 to 54% and the error rate dropped * double strobes: 1:500M * missing strobes: 0, - not happened yet, still running long term test the 4Mhz clock is really not a clock, its byte write strobe from external host most of the FPGA logic can/should be clocked with this strobe, and i see little reasons to move all that logic into 50mhz clock domain in 50mhz domains 2 modules exist, one of them is working fully on the "other side" of dual port RAM, and the other module is also not causing problems, it generates 8 clocks per strobe, and shifts in a byte my 2 bit counter is not directly observable, i have software access to return data addressed with the counter so I have test software that compares the returned to data to known good response and calculates the error types, either missing or extra strobe and displays the error counts and count of good responses ah, the 4 mhz strobe/clk is routed as global clock, I do insert the global buffer primitives by hand and verify that the are implemented by the tools as well. if any FF is clocked by local routing in Actel FPGA then it is complete disaster Antti ++++++++++++ I think you may have stated your problem! "the 4Mhz clock is really not a clock, its byte write strobe from external host" The strobe may be just a loose decode internal to the ASIC and may well glitch. A strobe should be used as an enabling signal - to 'strobe' data in to the FPGA you should use a clock enabled D type, with the ASIC clock to clock, the 'strobe' to enable, and data in.Article: 130678
On 30 Mrz., 12:42, "Icky Thwacket" <i...@it.it> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com... > On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote: > > > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > >news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...= > > > > On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote: > > >> "Antti" <Antti.Luk...@googlemail.com> wrote in message > > > >>news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com.= .. > > > >> > Hi > > > >> > FPGA has > > >> > 1) 50mhz system clock from ext oscillator > > >> > 2) 4Mhz clk that is async to the 50mhz > > > >> > problem, the 4MHz clk input sees double clk pulse, error rate > > >> > approximate 1 to 10.000.000 > > > >> Not quite sure what you mean by a 'double clk pulse' but I'm assuming= > > >> that > > >> you're feeding the 4MHz clock into 'something' in the FPGA that is > > >> clocked > > >> by 50 MHz. If that's the case, then what you need to verify in the > > >> final > > >> technology map that the 4MHz signal comes into exactly one flip flop > > >> and > > >> the > > >> output of that exactly one flip flop is what you use to clock anythin= g > > >> else...and to mitigate metastability a bit more, that 'anything else'= > > >> logic > > >> might consist of again exactly one flop, the output of which is fed > > >> into > > >> the > > >> real logic (i.e. you're constucting a two flop synchronizer). You'll= > > >> also > > >> want to add synthesis attributes to any of these synchronizing flops = to > > >> insure that the logic doesn't get opotomized in a way that ends up > > >> replicating the flops. In any case, verify the final routed result > > >> brings > > >> 4MHz into exactly one flop (and if adding a second sync flop that it > > >> too > > >> is > > >> the only load on the flop that captures the 4MHz) > > > >> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input > > >> Pin > > > >> Since you haven't stated just how you're using the 4MHz clock inside > > >> the > > >> FPGA, you should probably clarify that, but a failure rate every 0.2 > > >> seconds > > >> (10 M of the 50MHz clock) then it's quite apparent that one of the mo= st > > >> likely causes of the failure is one of the following: > > >> - Simple timing (whch will be fixed by what I outline in the previous= > > >> paragraph). > > >> - Signal quality > > >> 1. Measured at the FPGA, are the rising and falling edges of the = 50 > > >> MHz > > >> monotonic? > > >> 2. Measured at the FPGA, the 4 MHz clock doesn't have to be > > >> absolutely > > >> monotonic since it doesn't appear to be used to sample anything, but = if > > >> it > > >> dips and comes back up and the dip is low enough to appear to be a > > >> logic > > >> low > > >> than the 50 MHz could (and eventually will) sample it at precisely th= at > > >> bad > > >> point. > > >> - Could be power as well, not dipping out of spec at the FPGA are you= ? > > > >> > unfortunatly the 4mhz clock needs to be used inside without phase > > >> > delay, so oversampling and filtering with 50mhz is not an option, > > >> > unless using very clever no delay glitch surpression filter > > > >> Might want to elaborate on the reason for the 'without phase delay' > > >> requirement, but assuming that to be the case then a different soluti= on > > >> that > > >> would minimize the phase delay would be to feed the 4MHz into an onch= ip > > >> PLL > > >> (if you have one) to create a 48 MHz and use that instead of the 50 > > >> MHz. > > >> That way, the two clocks would maintain a fairly accurate phase > > >> relationship > > >> to one another thus avoiding violation of setup/hold time windows. > > > >> If the reason for 'without phase delay' requirement is because of oth= er > > >> FPGA > > >> inputs that are synchronized to the 4MHz, then another solution might= > > >> simply > > >> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz= > > >> clock > > >> domain. > > > >> > external small R/C circuit on 5mhz doesnt change the error rate muc= h, > > >> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to > > >> > give better results as using the 4mhz clock directly > > > >> This sounds like you are using the 4MHz to drive logic...big mistake > > >> (see > > >> first paragraph for the solution). > > > >> > any ideas how to really clean the 4mhz clock? > > > >> Unless you've scoped the 4MHz clock, why do you think it's not 'clean= '? > > > >> > or any thumb guess what is the likeliness to see double clk edges > > >> > when > > >> > sampling 4mhz with async 50mhz? > > > >> Violating timing, inadequate power at the point of use and signal > > >> quality....when it comes right down to it those are the ONLY reasons.= > > >> In > > >> the end, that's what you'll find here as well. > > > >> > could the "error rate" of such sampling be that 1:10M what I am > > >> > seeing? > > > >> Sure, it simply depends on precisely what the setup/hold timing windo= w > > >> of > > >> the actual part is. If you have freeze spray, a hot air gun and a > > >> simple > > >> way to quickly get your error rate measurement then try hitting your > > >> FPGA > > >> with the hot, measure your error rate (repeat with the cold) and see = if > > >> it > > >> has a temperature dependency. If it clearly does, then you have a > > >> timing > > >> problem (see first paragraph for the solution), if it doesn't or is n= ot > > >> clearly temp dependent, then you likely have a power problem. Based = on > > >> the > > >> bits of info you've provided, I'm leaning towards the timing. This = is > > >> simply science experiment stuff and is not needed to engineer the > > >> solution, > > >> for that you need static timing analysis, proper clock domain crossin= g > > >> design technique and proper power supply distribution. > > > >> > I assume the 4 mhz clock is rather good, it coming from an ASIC and= > > >> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB > > >> > edge > > >> > connector). I did kinda think its hard to belive that the clock edg= e > > >> > is so slow or noisy that 50mhz sampling could ever see double/wrong= > > >> > edges but guess i am wrong > > > >> No need to guess or speculate, unless you don't have a scope to simpl= y > > >> measure. > > > >> > it doesnt seem to be cross talk either, as there arent much IOs > > >> > toggling at all > > > >> > hm it looks like in rare cases the error is also one clock pulse > > >> > missing! > > > >> Timing problems produce those symptoms as well. > > > >> > :) any good suggestions are welcome, how to troubleshoot the issue > > > >> Hopefully you'll find the above useful....to reiterate though, I can > > >> dang > > >> near guarantee the fundamental reason for the failure will be > > >> - Violating setup/hold time in the 50 MHz clock > > >> - Signal quality (50 MHz or 4 MHz) > > >> - Power > > > >> What you need to do is measurement or analysis to either eliminate > > >> causes > > >> or > > >> turn up the design error. > > > >> > unfortunatly the FPGA is actel so can use any on-chip logic analyze= r > > >> > core, and the chip is rather full also, some internal signal could = be > > >> > routed out to external logic analyzer though if badly needed, but s= o > > >> > far i am trying to fix the issue by thinking, and error-retry... > > > >> You shouldn't need to bring out anything, static timing analysis and = a > > >> scope > > >> will get you to the root cause. > > > >> Good luck. > > > >> Kevin Jennings > > > > Hi all and thanks for all suggestions! > > > some additional info > > > > failing circuit > > > > ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace > > > FPGA input > > > > >>F-F strobed with 50mhz > global clock buffer > 2 bit counter > > > > now, this 2 bit counter sees > > > * double clock from asic in about 1:10M pulses > > > * missing clock from asic in about 1:100m pulses > > > OK, so it appears that the 4 MHz input is being synchronized to the 50 M= Hz > > clock through a single flip flop, but have you verified that the final > > routed design uses only one flip flop? > > > Are you using the now synchronized 4 MHz signal as a clock? Do you know= > > for > > sure that the Actel device will properly generate an internal clock sign= al > > from the output of a flip flop? You can't see clock signal quality > > internal > > to a device but that doesn't imply that it doesn't matter. If "output o= f > > a > > flip flop to the clock input of another" is not something that Actel > > handle > > then maybe you shouldn't be doing that. > > > > the asic clock is know to be perfect many other devices can receive it= > > > and have 0 error rate (have not seen error ever!) > > > That's good to know. > > > > the 50mhz clock signal quality, well it doesn matter, as whatever > > > could be wrong, it could not explain the double and missing pulse > > > counts ? > > > Signal quality on the 50 MHz clock does matter...what if the osc is bad = or > > flaky? It's not my first suspect either but again worth verifying at th= e > > input to the FPGA with a scope (when you get access to one) so that it c= an > > be eliminated as a cause. > > > > so what is failing is really simple circuit! > > > it also looks like when double pulses are seen the FPGA is not > > > changing any of its output so its no SSO noise > > > That would also tend to lower power supply noise as a culprit too in my > > mind...again, it can only be eliminated as a cause by verification with = a > > scope when you get a chance. > > > > I could understand power supply noise to cause double pulses, but how > > > to explain the missing pulses? > > > Bad power is worse than a bad clock, all sorts of bad things can happen.= > > > > I dont have scope here now, but i have tried to troubleshoot the clock= > > > problem before and have looked the signals with scope without seeing > > > anything helpful to get to the problem, i will do it again if I dont > > > get it working this weekend > > > From here it really smells like the problem is not properly synchronizin= g > > the 4 MHz signal or that the internally generated clock is not a good > > clock > > for whatever reason. > > > Also, is the output of the two bit counter directly observable to you an= d > > is > > that the reason you say that you miss a clock or get two every now and > > then > > or is it because of some other downstream logic output? The reason for > > asking is because no matter what you do, if you use the 'synchronized 4 > > MHz' > > to actually clock a flip flop the output of that two bit counter will be= > > skewed a bit from the 50 MHz clock because of the unavoidable clock to > > output delay of the flip flop (plus possible additional skew from > > differences in the clock distribution between the 50 MHz and the > > 'synchronized 4 MHz' internal to the device. > > > I've found and fixed many other designer's errors by getting rid of > > internally generated clocks because, no matter how well you ... > > > Erfahren Sie mehr =BB > > Hi Kevin, > > many thanks for all the detailed help! > > this morning I was pretty sure i have the correct answer to the > problem - VCCINT bypass capacitor(s) > but big disappointment, adding then (<=3D1.5mm from package) did not > change the error rate at all !! :( > > after that I did remove some of the logic from FPGA (not related to > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization > from 82 to 54% > > and the error rate dropped > * double strobes: 1:500M > * missing strobes: 0, - not happened yet, still running long term test > > the 4Mhz clock is really not a clock, its byte write strobe from > external host > > most of the FPGA logic can/should be clocked with this strobe, and i > see little reasons to move all that logic into 50mhz clock domain > > in 50mhz domains 2 modules exist, one of them is working fully on the > "other side" of dual port RAM, and the other module is also not > causing problems, it generates 8 clocks per strobe, and shifts in a > byte > > my 2 bit counter is not directly observable, i have software access to > return data addressed with the counter so I have test software that > compares the returned to data to known good response and calculates > the error types, either missing or extra strobe and displays the error > counts and count of good responses > > ah, the 4 mhz strobe/clk is routed as global clock, I do insert the > global buffer primitives by hand and verify that the are implemented > by the tools as well. > > if any FF is clocked by local routing in Actel FPGA then it is > complete disaster > > Antti > > ++++++++++++ > > I think you may have stated your problem! > > "the 4Mhz clock is really not a clock, its byte write strobe from > external host" > > The strobe may be just a loose decode internal to the ASIC and may well > glitch. A strobe should be used as an enabling signal - to 'strobe' data i= n > to the FPGA you should use a clock enabled D type, with the ASIC clock to > clock, the 'strobe' to enable, and data in. there is no asic clock coming only select active low and strobe(clk) idle high pulses low, write latch on rising edge and the strobe IS CLEAN no glitch pure signal tested verified... after applying the changes that made 0 error for 37% full FPGA to the full desing (82% full) the resulting design, well still has 0 clock error but the remaining portions of the design are no longer working.. so i need some more work to get the full design working properly AnttiArticle: 130679
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:731e01b9-cf36-47e0-aa73-b4bb693eb571@e67g2000hsa.googlegroups.com... On 30 Mrz., 12:42, "Icky Thwacket" <i...@it.it> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com... > On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote: > > > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > >news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com... > > > > On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote: > > >> "Antti" <Antti.Luk...@googlemail.com> wrote in message > > > >>news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com... > > > >> > Hi > > > >> > FPGA has > > >> > 1) 50mhz system clock from ext oscillator > > >> > 2) 4Mhz clk that is async to the 50mhz > > > >> > problem, the 4MHz clk input sees double clk pulse, error rate > > >> > approximate 1 to 10.000.000 > > > >> Not quite sure what you mean by a 'double clk pulse' but I'm assuming > > >> that > > >> you're feeding the 4MHz clock into 'something' in the FPGA that is > > >> clocked > > >> by 50 MHz. If that's the case, then what you need to verify in the > > >> final > > >> technology map that the 4MHz signal comes into exactly one flip flop > > >> and > > >> the > > >> output of that exactly one flip flop is what you use to clock > > >> anything > > >> else...and to mitigate metastability a bit more, that 'anything else' > > >> logic > > >> might consist of again exactly one flop, the output of which is fed > > >> into > > >> the > > >> real logic (i.e. you're constucting a two flop synchronizer). You'll > > >> also > > >> want to add synthesis attributes to any of these synchronizing flops > > >> to > > >> insure that the logic doesn't get opotomized in a way that ends up > > >> replicating the flops. In any case, verify the final routed result > > >> brings > > >> 4MHz into exactly one flop (and if adding a second sync flop that it > > >> too > > >> is > > >> the only load on the flop that captures the 4MHz) > > > >> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input > > >> Pin > > > >> Since you haven't stated just how you're using the 4MHz clock inside > > >> the > > >> FPGA, you should probably clarify that, but a failure rate every 0.2 > > >> seconds > > >> (10 M of the 50MHz clock) then it's quite apparent that one of the > > >> most > > >> likely causes of the failure is one of the following: > > >> - Simple timing (whch will be fixed by what I outline in the previous > > >> paragraph). > > >> - Signal quality > > >> 1. Measured at the FPGA, are the rising and falling edges of the > > >> 50 > > >> MHz > > >> monotonic? > > >> 2. Measured at the FPGA, the 4 MHz clock doesn't have to be > > >> absolutely > > >> monotonic since it doesn't appear to be used to sample anything, but > > >> if > > >> it > > >> dips and comes back up and the dip is low enough to appear to be a > > >> logic > > >> low > > >> than the 50 MHz could (and eventually will) sample it at precisely > > >> that > > >> bad > > >> point. > > >> - Could be power as well, not dipping out of spec at the FPGA are > > >> you? > > > >> > unfortunatly the 4mhz clock needs to be used inside without phase > > >> > delay, so oversampling and filtering with 50mhz is not an option, > > >> > unless using very clever no delay glitch surpression filter > > > >> Might want to elaborate on the reason for the 'without phase delay' > > >> requirement, but assuming that to be the case then a different > > >> solution > > >> that > > >> would minimize the phase delay would be to feed the 4MHz into an > > >> onchip > > >> PLL > > >> (if you have one) to create a 48 MHz and use that instead of the 50 > > >> MHz. > > >> That way, the two clocks would maintain a fairly accurate phase > > >> relationship > > >> to one another thus avoiding violation of setup/hold time windows. > > > >> If the reason for 'without phase delay' requirement is because of > > >> other > > >> FPGA > > >> inputs that are synchronized to the 4MHz, then another solution might > > >> simply > > >> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz > > >> clock > > >> domain. > > > >> > external small R/C circuit on 5mhz doesnt change the error rate > > >> > much, > > >> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to > > >> > give better results as using the 4mhz clock directly > > > >> This sounds like you are using the 4MHz to drive logic...big mistake > > >> (see > > >> first paragraph for the solution). > > > >> > any ideas how to really clean the 4mhz clock? > > > >> Unless you've scoped the 4MHz clock, why do you think it's not > > >> 'clean'? > > > >> > or any thumb guess what is the likeliness to see double clk edges > > >> > when > > >> > sampling 4mhz with async 50mhz? > > > >> Violating timing, inadequate power at the point of use and signal > > >> quality....when it comes right down to it those are the ONLY reasons. > > >> In > > >> the end, that's what you'll find here as well. > > > >> > could the "error rate" of such sampling be that 1:10M what I am > > >> > seeing? > > > >> Sure, it simply depends on precisely what the setup/hold timing > > >> window > > >> of > > >> the actual part is. If you have freeze spray, a hot air gun and a > > >> simple > > >> way to quickly get your error rate measurement then try hitting your > > >> FPGA > > >> with the hot, measure your error rate (repeat with the cold) and see > > >> if > > >> it > > >> has a temperature dependency. If it clearly does, then you have a > > >> timing > > >> problem (see first paragraph for the solution), if it doesn't or is > > >> not > > >> clearly temp dependent, then you likely have a power problem. Based > > >> on > > >> the > > >> bits of info you've provided, I'm leaning towards the timing. This > > >> is > > >> simply science experiment stuff and is not needed to engineer the > > >> solution, > > >> for that you need static timing analysis, proper clock domain > > >> crossing > > >> design technique and proper power supply distribution. > > > >> > I assume the 4 mhz clock is rather good, it coming from an ASIC and > > >> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB > > >> > edge > > >> > connector). I did kinda think its hard to belive that the clock > > >> > edge > > >> > is so slow or noisy that 50mhz sampling could ever see double/wrong > > >> > edges but guess i am wrong > > > >> No need to guess or speculate, unless you don't have a scope to > > >> simply > > >> measure. > > > >> > it doesnt seem to be cross talk either, as there arent much IOs > > >> > toggling at all > > > >> > hm it looks like in rare cases the error is also one clock pulse > > >> > missing! > > > >> Timing problems produce those symptoms as well. > > > >> > :) any good suggestions are welcome, how to troubleshoot the issue > > > >> Hopefully you'll find the above useful....to reiterate though, I can > > >> dang > > >> near guarantee the fundamental reason for the failure will be > > >> - Violating setup/hold time in the 50 MHz clock > > >> - Signal quality (50 MHz or 4 MHz) > > >> - Power > > > >> What you need to do is measurement or analysis to either eliminate > > >> causes > > >> or > > >> turn up the design error. > > > >> > unfortunatly the FPGA is actel so can use any on-chip logic > > >> > analyzer > > >> > core, and the chip is rather full also, some internal signal could > > >> > be > > >> > routed out to external logic analyzer though if badly needed, but > > >> > so > > >> > far i am trying to fix the issue by thinking, and error-retry... > > > >> You shouldn't need to bring out anything, static timing analysis and > > >> a > > >> scope > > >> will get you to the root cause. > > > >> Good luck. > > > >> Kevin Jennings > > > > Hi all and thanks for all suggestions! > > > some additional info > > > > failing circuit > > > > ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace > > > FPGA input > > > > >>F-F strobed with 50mhz > global clock buffer > 2 bit counter > > > > now, this 2 bit counter sees > > > * double clock from asic in about 1:10M pulses > > > * missing clock from asic in about 1:100m pulses > > > OK, so it appears that the 4 MHz input is being synchronized to the 50 > > MHz > > clock through a single flip flop, but have you verified that the final > > routed design uses only one flip flop? > > > Are you using the now synchronized 4 MHz signal as a clock? Do you know > > for > > sure that the Actel device will properly generate an internal clock > > signal > > from the output of a flip flop? You can't see clock signal quality > > internal > > to a device but that doesn't imply that it doesn't matter. If "output > > of > > a > > flip flop to the clock input of another" is not something that Actel > > handle > > then maybe you shouldn't be doing that. > > > > the asic clock is know to be perfect many other devices can receive it > > > and have 0 error rate (have not seen error ever!) > > > That's good to know. > > > > the 50mhz clock signal quality, well it doesn matter, as whatever > > > could be wrong, it could not explain the double and missing pulse > > > counts ? > > > Signal quality on the 50 MHz clock does matter...what if the osc is bad > > or > > flaky? It's not my first suspect either but again worth verifying at > > the > > input to the FPGA with a scope (when you get access to one) so that it > > can > > be eliminated as a cause. > > > > so what is failing is really simple circuit! > > > it also looks like when double pulses are seen the FPGA is not > > > changing any of its output so its no SSO noise > > > That would also tend to lower power supply noise as a culprit too in my > > mind...again, it can only be eliminated as a cause by verification with > > a > > scope when you get a chance. > > > > I could understand power supply noise to cause double pulses, but how > > > to explain the missing pulses? > > > Bad power is worse than a bad clock, all sorts of bad things can happen. > > > > I dont have scope here now, but i have tried to troubleshoot the clock > > > problem before and have looked the signals with scope without seeing > > > anything helpful to get to the problem, i will do it again if I dont > > > get it working this weekend > > > From here it really smells like the problem is not properly > > synchronizing > > the 4 MHz signal or that the internally generated clock is not a good > > clock > > for whatever reason. > > > Also, is the output of the two bit counter directly observable to you > > and > > is > > that the reason you say that you miss a clock or get two every now and > > then > > or is it because of some other downstream logic output? The reason for > > asking is because no matter what you do, if you use the 'synchronized 4 > > MHz' > > to actually clock a flip flop the output of that two bit counter will be > > skewed a bit from the 50 MHz clock because of the unavoidable clock to > > output delay of the flip flop (plus possible additional skew from > > differences in the clock distribution between the 50 MHz and the > > 'synchronized 4 MHz' internal to the device. > > > I've found and fixed many other designer's errors by getting rid of > > internally generated clocks because, no matter how well you ... > > > Erfahren Sie mehr » > > Hi Kevin, > > many thanks for all the detailed help! > > this morning I was pretty sure i have the correct answer to the > problem - VCCINT bypass capacitor(s) > but big disappointment, adding then (<=1.5mm from package) did not > change the error rate at all !! :( > > after that I did remove some of the logic from FPGA (not related to > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization > from 82 to 54% > > and the error rate dropped > * double strobes: 1:500M > * missing strobes: 0, - not happened yet, still running long term test > > the 4Mhz clock is really not a clock, its byte write strobe from > external host > > most of the FPGA logic can/should be clocked with this strobe, and i > see little reasons to move all that logic into 50mhz clock domain > > in 50mhz domains 2 modules exist, one of them is working fully on the > "other side" of dual port RAM, and the other module is also not > causing problems, it generates 8 clocks per strobe, and shifts in a > byte > > my 2 bit counter is not directly observable, i have software access to > return data addressed with the counter so I have test software that > compares the returned to data to known good response and calculates > the error types, either missing or extra strobe and displays the error > counts and count of good responses > > ah, the 4 mhz strobe/clk is routed as global clock, I do insert the > global buffer primitives by hand and verify that the are implemented > by the tools as well. > > if any FF is clocked by local routing in Actel FPGA then it is > complete disaster > > Antti > > ++++++++++++ > > I think you may have stated your problem! > > "the 4Mhz clock is really not a clock, its byte write strobe from > external host" > > The strobe may be just a loose decode internal to the ASIC and may well > glitch. A strobe should be used as an enabling signal - to 'strobe' data > in > to the FPGA you should use a clock enabled D type, with the ASIC clock to > clock, the 'strobe' to enable, and data in. >there is no asic clock coming >only >select active low > and >strobe(clk) idle high pulses low, write latch on rising edge >and the strobe IS CLEAN no glitch pure signal tested verified... >after applying the changes that made 0 error for 37% full FPGA >to the full desing (82% full) the resulting design, well still has 0 >clock error >but the remaining portions of the design are no longer working.. >so i need some more work to get the full design working properly >Antti No, I understand you do not have the clock - just saying that you SHOULD have the clock. The interface seems, at best, very flakey to me. If the strobe was clean you would have zero problems. The system should be 'right by design' and not have work arounds applied to cover up a problem.Article: 130680
Hi, All, I built a PowerPC system on Xilinx ML410 board (Virtex4 fx60), the system contains 64K OCM instruction memory and 64K PLB data memory. I used XMD to debug the system via the jtagppc, when I reset the system, the PC register went back to a address like "0Xfffff048". But according to the PPC manual, after reset, the PC should be "0Xfffffffc". Does anyone met the similar problem before? regards, louisArticle: 130681
Antti schrieb: [lot of text removed] > there is no asic clock coming > only Offtopic, but IMHO necessary. http://www.netmeister.org/news/learn2quote.html And this goes to many other posters in this NG. No offence. FalkArticle: 130682
hi all: i am currently working on a "toy" design of my first big project (in VHDL) on the Xilinx Spartan III starter kit. now facing a timer problem and i could not properlly solve it using my limited design experience, here is it: module A will prepare data for output (node : dout(7 downto 0)) to module B when it receive a READY signal from B. in order to notify B that the data is ready on the bus , A will ouput a signal DONE , but the DONE will be '1' after 30 ms A received signal READY and will just last 10 ms before going low. I wonder is there any standard or elegant way of implement the timer in VHDL? PLZ give me some hint! thank U all in advance ! :)Article: 130683
On 30 Mrz., 16:08, Falk Brunner <Falk.Brun...@gmx.de> wrote: > Antti schrieb: > > [lot of text removed] > > > there is no asic clock coming > > only > > Offtopic, but IMHO necessary. > > http://www.netmeister.org/news/learn2quote.html > > And this goes to many other posters in this NG. > > No offence. > Falk Dear Falk, really? unfortunatly i am using google groups so it sometimes hiding the quoted when replying, i had the feeling also that something is not perfect with the post, but was in hurry. sorry that it made you feel that you need to play the teacher guy. AnttiArticle: 130684
[snip] > >strobe(clk) idle high pulses low, write latch on rising edge > >and the strobe IS CLEAN no glitch pure signal tested verified... > >after applying the changes that made 0 error for 37% full FPGA > >to the full desing (82% full) the resulting design, well still has 0 > >clock error > >but the remaining portions of the design are no longer working.. > >so i need some more work to get the full design working properly > >Antti > > No, I understand you do not have the clock - just saying that you SHOULD > have the clock. The interface seems, at best, very flakey to me. If the > strobe was clean you would have zero problems. The system should be 'right > by design' and not have work arounds applied to cover up a problem. similar design WORKS in Xilinx FPGA always no workarounds needed. the actel version is optimized for actel fabric, what forced the use of global clock lines for some none clock nets, and other changes that reduced the logic utilization for Actel target architecture. the interface is not mine, and it is not flakey, it works and it works reliable and i can not change it. right now it also work in my FPGA with 82% percent full been working over 6 hours continuous testing, 0 errors. but with 82% full some of the other logic that worked, stopped working. so i need keep cleaning up the design and doing more and more iterations, when I remove the global buffers from non global signal the design would not fit the target device (actel generates 2 logic per many flip flops), my current design still has 22 flip flops mapped to 2 logic cells, and 23 flops mapped to 4 logic cell per flop, so wastin 91 logic cells or 8% of the total resources. I can try to run some more rounds of manual logic optimization, but this is not really a funny job. but using larger FPGA or FPGA from other vendor would increase the BOM cost for at least 1 usd more likely for 2 usd what is unacceptable for the design, so i need optimize and optimize and the fight actel tools and weirdness. I know very well that: "any digital design works AS DESIGNED" first attempt if it is done "correctly". It really does, but sometimes the way to it isnt so easy. so, the strobe is clean, 100% verfied, but there are cases where it appears to have problems in actel FPGA. Antti to Xilinx I would have saved many month of deep troubleshooting, would Xilinx had required package options for S3AN.. but now it was just another design loss for Xilinx. Maybe S4 will re-introduce small packages who know but for this project its too late anyway.Article: 130685
Hi,
I am trying to generate the ise project files from the system
generator token in simulink but i am getting the following error.
--------------------------------------------------------------------------------
Summary of Errors:
Error 0001: caught standard exception
Block: Unspecified
--------------------------------------------------------------------------------
Error 0001:
Reported by:
Unspecified
Details:
standard exception: XNetlistEngine:
An exception was raised:
com.xilinx.sysgen.netlist.NetlistInternal: couldn't write
C:\XUP\Workshops\advanced_dsp_flow\labs\lab1\xupv2p\xupv2pro\sysgen
\ngc_verilog_QS2P\coregen_1zCO/coregen_tmp/distributed_arithmetic_f?
r_filter_virtex_9_0_abceec866b698a15.coe
at C:/Xilinx/10.1/DSP_Tools/sysgen/scripts/SgNgcVerilog.pm line 62
--------------------------------------------------------------------------------
Any comments ?
Article: 130686Antti, You (and everyone else) will probably not believe me, but there have been beta testers running this for more than 6 months. AustinArticle: 130687
"move" <liubenyuan@gmail.com> wrote in message news:ce01257f-651a-4792-aa92-6238b902e219@d4g2000prg.googlegroups.com... > hi all: > > i am currently working on a "toy" design of my first big project (in > VHDL) on the Xilinx Spartan III starter kit. now facing a timer > problem and i could not properlly solve it using my limited design > experience, here is it: > > module A will prepare data for output (node : dout(7 downto 0)) to > module B when it receive a READY signal from B. in order to notify B > that the data is ready on the bus , A will ouput a signal DONE , but > the DONE will be '1' after 30 ms A received signal READY and will just > last 10 ms before going low. I wonder is there any standard or elegant > way of implement the timer in VHDL? > > PLZ give me some hint! > thank U all in advance ! :) 1. Create constants of type time (or pass in as generics of type time) the clock period of your clock and the time period for your delays. 2. Based on the value of those constants/generics compute the number of clocks that you would need to count (i.e. Max_count := Delay_Time / Clock_Period) 3. Declare an integer signal in the range from 0 to Max_Count -1 4. Create the code for a counter that counts from 0 to Max_Count - 1. When you get up to Max_Count - 1 your requested time interval has occurred so do whatever it is you want to do at that time. Kevin JenningsArticle: 130688
On 30 Mrz., 18:06, austin <aus...@xilinx.com> wrote: > Antti, > > You (and everyone else) will probably not believe me, but there have > been beta testers running this for more than 6 months. > > Austin Austin, sure I belive you! but they are not doing their job! How hard is that to understand? If every new major release causes instant frustration and/or has TTFFF (time to first fatal failure) less than 30 minutes, then your beta- testers have continously failed todo their job. I cant see it any other way. Antti AnttiArticle: 130689
Hi emeb, everyone,
emeb wrote:
> On Mar 20, 7:25 am, Paul Boven <boven@jive.nl> wrote:
>> Just ordered a Spartan 3A ExtremeDSP Starter Kit. It comes without a
>> programming cable, but I figured I could re-use the cable from my trusty
>> Digilent parallel cable from the Spartan-3 kit. The pinout is certainly
>> the same (6 pins single header). But I've just noticed that the Digilent
>> documentation states there is 2.8V on the connector while the new
>> Spartan-3A DSP board provides 2.5V. Will this work?
> The Digilent USB<->JTAG cable I bought a few weeks back operates from
> 1.8V - 5.5V. Which cable do you have?
The 'old' Digilent parallel cable says '2.8V to 5V' on the heat shrink
tube over the connector: This was the one that came with my Spartan-3
kit. Fortunately, it appears to work well with the 2.5V for the
Spartan-3A DSP 1800A kit as well. The newer Digilent parallel cables are
actually specified to work from 1.8V and upwards ('JTAG3 cable'). I've
decided to stay away from USB cables for the time being, don't need even
more hassles trying to make all this work under Ubuntu ;-)
Regards, Paul Boven.
Article: 130690"Antti" <Antti.Lukats@googlemail.com> wrote in message news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com... On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote: > the 4Mhz clock is really not a clock, its byte write strobe from > external host Let's be blunt, any signal that you use "rising_edge(xxx)", "falling_edge(xxx)", "xxx'event and xxx = '1'", "xxx'event and xxx='0' and all the other variants thereof are edge sensitive signals, whether it is a free running 'clock' is irrelevant. > > most of the FPGA logic can/should be clocked with this strobe, So then why did you (from an earlier post) bring this strobe into a flip flop that is clocked by the 50 MHz clock? You've created a new signal internal to the device that you can't observe and will be violating setup/hold timing by design which means that this signal will be metastable at some times and you're using edges of it internally....it's highly unlikely now that that internal signal is nice and monotonic...that's why you're seeing the flaky operation. If you intend to use the 4MHz clock/strobe/whatever to sample things inside the FPGA, then don't muck with it, use it directly as you would use the 50 MHz osc clock and don't insert any logic/flops/anything in the path. > and i see little reasons to move all that logic into 50mhz clock domain The reason is that the two clock domains almost inevitably will need to communicate with one another. That communication will be cross clock domains, it is 'usually' simpler to synchronize up front and then clock everything with one clock. The simple answer to the 'reason to move...' is to avoid the type of timing grief that you're experiencing. Then again, experience something for yourself is almost always the best teacher. > > ah, the 4 mhz strobe/clk is routed as global clock, I do insert the > global buffer primitives by hand and verify that the are implemented > by the tools as well. > Having to do gyrations with tools to get it to 'work', generally only results in things that work on certain boards, or start failing at different temperatures and other odd things. The reason is that the fundamental design issue has not been addressed, band aids have only been added to address symptoms seen on a limited set of boards. Fundamentally, you need to decide 1. If you want to have things running around internally in the FPGA in two different clock domains and use proper handshaking/dual clock fifo techniques everyplace signals from the two come together. 2. Synchronize the 4MHz to the 50 MHz up front and then run everything in the FPGA at 50 MHz and have only one clock domain. Either approach is viable, #1 will take more effort on your part to get working. Whether the payoff is worth it to you or not is a decision that only you can make. > if any FF is clocked by local routing in Actel FPGA then it is > complete disaster I think I said basically the same thing previously about having to fix many other designer's designs by getting rid of internally generated clocks. By the way, that type of design issue is not unique to Actel. Kevin JenningsArticle: 130691
Hi all, Here are my first impressions : First, I will not repeat "what's news" but I've seen some real improvements, mainly concerning GUI (like report, for cross probing to HDL editor with warnings, very useful; and so on...). Concerning P&R result, at first I was quite frustrated : many timing constraints not passed successful in 10.1 and in 9.2 every was ok. In fact 10.1 analyze more constraints (in my design, constraints between clocks, that was in fact not relevant). After adding some "TIG" everything was ok. At present, I'm just worry about LUT and FF increase after map : More Lut and FF (??? I've to investigate...) but more LUT used as Shift registers and less slices occupied. Concerning EDK10.1, I would be interested to know your thoughts about the improvements or problems ... Cheers ! Alain.Article: 130692
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:47efdf2b@clear.net.nz... > Antti wrote: > <paste> >> if any FF is clocked by local routing in Actel FPGA then it is >> complete disaster > > So the 'key' trigger condition is using local routing for clock ? > More likely, it's his use of a flip flop output which goes metastable as a clock input to another flop. >> the FPGA resource % wasnt the thing after further reducing the >> utilization down to 37% the error rate increased and missing pulses re- >> apperared! > > No, but these tests are to see if there is a CHANGE in failure rate, > as any change indicates a 'cross-talk sensistivity' - and you > do see significant changes in error rates :) > New routes produce differences in actual device timing which precludes one from making any judgments about 'cross-talk sensitivity' based on changes in failure rates.... Crosstalk happens, but is usually pretty far down on the checklist of actual causes for design failure....after timing, clock domain crossing (which is really timing as well), signal quality and power. KJArticle: 130693
On 30 Mrz., 21:42, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > <paste> > > > if any FF is clocked by local routing in Actel FPGA then it is > > complete disaster > > So the 'key' trigger condition is using local routing for clock ? > > > Hi all > > > the FPGA resource % wasnt the thing after further reducing the > > utilization down to 37% the error rate increased and missing pulses re- > > apperared! > > No, but these tests are to see if there is a CHANGE in failure rate, > as any change indicates a 'cross-talk sensistivity' - and you > do see significant changes in error rates :) > > > but, when then removing the flop from 4mhz strobe AND changing > > synplify constraints: > > What did changing the constraints do ? > > > > > 45 minutes up and running no error detected so far > > pulse count >10G > > > sure I need the design to work without error with FPGA utilization > > >>=90% but seeing the PCB to not fail on the strobe is already some > > indicator that there is really nothing wrong with the 4mhz strobe > > signal, so no external conditioning required > > Do you know if this is a time-domain problem (Tsu/Th) or a > crosstalk problem ? (device fabric not good enough for clocks) > or models not matching loading/skew effects in real device > (and being not as well tested, has been mised by Actel?) > > Did someone else find this issue with local clocks == dodgy - ISTR an > earlier thread ? > > -jg Jim http://www.actel.com/documents/Clock_Skew_AN.pdf look as example figure 9 there how do you like if your FPGA vendor suggest using this type of clock distribution? i do not have any local clocks, not any more, but i have seen those effects very well. I assumed the FGPA fitter tools to take care those situations or issue warning at least or that it shows in post place simulation, but no. those Actel FF that clock 100% false can pass fitter and show no problems in post-place sims also. my failure rate change may also be just different fitter run differences. I have no almost all working, that is no double or missing strobes, and the 50mhz domain part also working ok AnttiArticle: 130694
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:47eebe69@clear.net.nz... > KJ wrote: >> >> Your post never mentioned anything about having measured a slow edge on >> the 4MHz signal either. If the edge rate is within spec, adding a >> Schmitt trigger will have no effect. > > Not entirely true. > In the real analog world, there are other details that can > trip you up. Ground level shifting and series inductances all > conspire against clean digital operation... > > (The best schmitt is a non-inverting one.) > The usefulness of the trigger from an engineering perspective is to turn a slow edge into a faster one in order to meet input characteristics of a part that can not tolerate the slower edge. Use of a schmitt trigger to address any of the issues that you mention would only be considered if there are some other physical constraints that precludes the proper engineering solution which would consist of - Termination - Proper grounding - Differential signalling for the simple reason that the trigger would not be addressing the root cause issues that you brought up. KJArticle: 130695
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:368339ad-6636-4a63-a57e-9785bc3ac581@m36g2000hse.googlegroups.com... > On 30 Mrz., 21:42, Jim Granville <no.s...@designtools.maps.co.nz> > > http://www.actel.com/documents/Clock_Skew_AN.pdf > > look as example figure 9 there how do you like if your FPGA vendor > suggest using this type of clock distribution? > > i do not have any local clocks, not any more, but i have seen those > effects very well. So now everything is clocked by the 50 MHz clock then? Nothing by the 4 MHz strobe (or anything derived from it)? > I assumed the FGPA fitter tools to take care those > situations or issue warning It would show up when doing static timing analysis under fastest conditions (i.e. when analyzing for minimum delays, Tco, etc.) and where analysis between clock domains is enabled. > at least or that it shows in post place > simulation, but no. those Actel FF that clock 100% false can pass > fitter and show no problems in post-place sims also. > Post-place sims do not catch timing errors, they do not catch metastability problems. Generally they just take a long time to run. > my failure rate change may also be just different fitter run > differences. I have no almost all working, that is no double or > missing strobes, and the 50mhz domain part also working ok > Congrats....now try the freeze spray and the hot air gun to make sure that you're not sensitive to temperature KJArticle: 130696
Antti wrote: <paste> > if any FF is clocked by local routing in Actel FPGA then it is > complete disaster So the 'key' trigger condition is using local routing for clock ? > Hi all > > the FPGA resource % wasnt the thing after further reducing the > utilization down to 37% the error rate increased and missing pulses re- > apperared! No, but these tests are to see if there is a CHANGE in failure rate, as any change indicates a 'cross-talk sensistivity' - and you do see significant changes in error rates :) > but, when then removing the flop from 4mhz strobe AND changing > synplify constraints: What did changing the constraints do ? > > 45 minutes up and running no error detected so far > pulse count >10G > > sure I need the design to work without error with FPGA utilization > >>=90% but seeing the PCB to not fail on the strobe is already some > indicator that there is really nothing wrong with the 4mhz strobe > signal, so no external conditioning required Do you know if this is a time-domain problem (Tsu/Th) or a crosstalk problem ? (device fabric not good enough for clocks) or models not matching loading/skew effects in real device (and being not as well tested, has been mised by Actel?) Did someone else find this issue with local clocks == dodgy - ISTR an earlier thread ? -jgArticle: 130697
> Post-place sims do not catch timing errors, they do not catch metastability > problems. Generally they just take a long time to run. > > > my failure rate change may also be just different fitter run > > differences. I have no almost all working, that is no double or > > missing strobes, and the 50mhz domain part also working ok > > Congrats....now try the freeze spray and the hot air gun to make sure that > you're not sensitive to temperature > > KJ Kevin in actel FPGA following is possible: design including "one sincle clock 4mhz clocking a 32 bit wide shift register" all signals are perfect as signal quality now while this ALWAYS works when the rest of the FPGA is empy, it may also ALWAYS fail, if the rest of the FPGA is full (if the clock uses local routing). now if the routing delay and internal skew in FPGA cause place-and- route result that NEVER works, see actel appnote, then this delay SHOULD be known for the FPGA tools, and it should also in post-place simulations IMHO. so there should a way that tools report, hey your shift register clocked at 4mhz will not work! while it is ok, that local clk routing messes everything up, the tools should be able to report those errors, what they at least in some cases do not. maybe I am dumb. but that case as described above exist. AnttiArticle: 130698
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:b36154f4-2769-4630-9d56-e5af9224046a@c26g2000prf.googlegroups.com... >> Post-place sims do not catch timing errors, they do not catch >> metastability >> problems. Generally they just take a long time to run. >> >> > my failure rate change may also be just different fitter run >> > differences. I have no almost all working, that is no double or >> > missing strobes, and the 50mhz domain part also working ok >> >> Congrats....now try the freeze spray and the hot air gun to make sure >> that >> you're not sensitive to temperature >> >> KJ > > Kevin > > in actel FPGA following is possible: > > design including "one sincle clock 4mhz clocking a 32 bit wide shift > register" all signals are perfect as signal quality > > now while this ALWAYS works when the rest of the FPGA is empy, it may > also ALWAYS fail, if the rest of the FPGA is full (if the clock uses > local routing). > > now if the routing delay and internal skew in FPGA cause place-and- > route result that NEVER works, see actel appnote, then this delay > SHOULD be known for the FPGA tools, And you've verified that the timing analysis report indicates that all of the following analysis was performed with no timing violations? - Slow model (i.e. 'slow' part, prop delays at their slowest) - Fast model (i.e. 'slow' part, prop delays at their slowest) - Analysis between clock domains is being performed If that is not the case, then you're not getting the full picture from the static timing analysis and need to re-run the analysis. > and it should also in post-place > simulations IMHO. > Simulation can put things at 'fast', 'slow', (maybe 'typical') but it does those things for all signals in the same manner which may not reflect what the actual part is doing. Simulation has no way of saying that signal1 will switch somewhere between this time and that time and signal2 will switch between two other times so compute when the full min/max time range where some signal that uses signals 1 and 2 will change within a single run. That is why static timing analysis is the tool that needs to be used, it does exactly that. Besides, the simulation was (I'm assuming) reporting that your strobe signal was violating setup/hold time relative to the 50 MHz clock when you had it come into a flop clocked by the 50 MHz osc as you described in an earlier post. Presumably you were ignoring that message because it was convenient to do so and didn't consider what the ramifications of that could be (i.e. producing a metastable output signal that you use to clock other flops). > > maybe I am dumb. but that case as described above exist. > Not dumb, but maybe not understanding fully how to perform static timing analysis. Kevin JenningsArticle: 130699
In previous post... - Fast model (i.e. 'fast' part, prop delays at their fastst) KJ
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