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 11/22/2012 11:59 PM, Jon Elson wrote: > James823 wrote: > >> Hi, >> >> I've been looking at synchronising data across clock domains, and have >> managed to confuse myself. >> Can someone confirm (or correct me) that the following is true. >> >> Metastability may occur if the input D changes value during the set-up and >> hold times, however the enable can be completely asynchronous without ever >> causing a problem? >> >> If not, then even something as simple as testing a switch is pressed would >> cause problems right? > Metastability on modern CMOS processes is a pretty rare event. Supposedly, > Xilinx has found that the window for metastability on their FFs is > no more than a couple of ps wide! So, unless you have extremely fast > data rates or a timing that puts the transition right over the window, > it could take years for you to get one true metastable event. I don't have the stats memorized, but I don't think this is an accurate description. If you design is truly async then the rate is such that with a number of units in the field you will likely see failures long before the warranty period is up... lol But by providing even as little as two nanoseconds of settling time the probability is hugely reduced so that it would then be years if not centuries between failures for thousands of units. But this is also related to the significance of a failure. If it is a router handling Internet traffic in a user's home, I think a failure once a month per unit will never be noticed. If it is a more critical application a failure once a decade across the product line might be a problem. > The real logic hazard is for a signal that changes near the clock > edge to propagate through the chip in such a way that the transition > arrives before the clock at some FFs, and after the clock at some > others, either due to routing or combinatorial delays. A simple > state machine can be sent to never-never land when this occurs. > By properly synchronizing when crossing clock boundaries, you > allow the tools to be sure that no signal can change state too > close to the setup time and cause such a hazard. Static timing analysis is typically used to eliminate such timing problems. That is FPGA 101 type stuff. Timing tools can't help you with clock crossings, but they are easy to do if you pay attention and don't miss any... that is the domain of project management. > Many people claim such problems were metastability, when they were > more prosaic logic hazards. Yes, the two are sometimes confused. RickArticle: 154526
On 23/11/2012 21:31, rickman wrote: > On 11/22/2012 1:40 PM, Mike Perkins wrote: >> On 22/11/2012 17:33, rickman wrote: >>> On 11/22/2012 9:35 AM, Mike Perkins wrote: >>>> >>>> Simplest is to use a fast clock, where the clock rate is many >>>> times the data rate. The original data clock can be sampled to >>>> determine when it transitions and the data read when it should >>>> be stable, if necessary using suitably delayed data using >>>> parallel latches. >>> >>> What??? How do you "sample" the input without dealing with >>> metastability in those samples? >> >> By taking a latched clock being high say for 2 High-Speed clocks >> before accepting it as a real clock-high. > > You aren't seeing the picture. This doesn't solve metastability in > any meaningful way. The edge detection logic can still be "glitched" > by metastability and disrupt the rest of the circuit. I didn't explain myself very well. The technique I was eluding to (badly) regards noisy and slow inputs (such as from a PS2 mouse) is to have a counter; to count up when the input is high, and to count down when the input is low. The output would only be changed to a "1" if the counter was at maximum and changed to a "0" if the counter was at minimum. > Easier is just to run the slow clock input through two FFs with no > logic between them and getting a metastability minimized signal. > Then you can use it as you wish. I agree and I said earlier the same about being latched through two FFs. >>> Another way to deal with the problem is to minimize and >>> encapsulate it. This means using a single clock for the entire >>> FPGA design other than the I/O interfaces where you sync the >>> signals as soon as possible. >> >> Entirely agree, but that's not always possible. > > When is this not possible? The only limitation would be that the > "master" clock to rule them all has to be the fastest by enough > margin to accommodate the jitter in the two clocks. This prevents > ever missing a transition. I was thinking of a modem example I came across where there were two clocks at near FPGA max speed; where each interface could wander in frequency either way. Given it was dealing with packets of data, it was much easier to a Block RAM FIFO to cross clock domains. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 154527
rickman <gnuarm@gmail.com> wrote: > On 11/22/2012 1:40 PM, Mike Perkins wrote: (snip) >> By taking a latched clock being high say for 2 High-Speed clocks before >> accepting it as a real clock-high. > You aren't seeing the picture. This doesn't solve metastability in any > meaningful way. The edge detection logic can still be "glitched" by > metastability and disrupt the rest of the circuit. > Easier is just to run the slow clock input through two FFs with no logic > between them and getting a metastability minimized signal. Then you can > use it as you wish. Well, how do you check if a signal was high for two clock cycles? Seem to me that you delay it through two FF's and AND them together. That could ignore real signals that are high for a short enough time, but there really shouldn't be any of those. Doesn't seem a bad thing to do in many cases. Metastability resolves exponentially. It is pretty much only a problem when the signal goes into logic with a propagation delay a large fraction, maybe 80% or 90% of a clock cycle. In that case, the extra FF multiplies the resolution time by a factor of 5 or 10, which decreases the probability of a problem by a power of 5 to 10. If it could happen one in 1e9 clock cycles without the extra FF, then it will then be one in 1e45 to 1e90 clock cycles. A am pretty sure no circuit has ever survives 1e90 clock cycles. -- glenArticle: 154528
rickman <gnuarm@gmail.com> wrote: > On 11/22/2012 11:59 PM, Jon Elson wrote: (snip) >> Metastability on modern CMOS processes is a pretty rare event. Supposedly, >> Xilinx has found that the window for metastability on their FFs is >> no more than a couple of ps wide! So, unless you have extremely fast >> data rates or a timing that puts the transition right over the window, >> it could take years for you to get one true metastable event. For an asynchronous system, you usually assume that the probability is uniform in time. So a 1GHz clock, with a pulse every ns, will hit your 1ps window on in every 1000 times, about every microsecond. > I don't have the stats memorized, but I don't think this is an accurate > description. If you design is truly async then the rate is such that > with a number of units in the field you will likely see failures long > before the warranty period is up... lol But by providing even as little > as two nanoseconds of settling time the probability is hugely reduced so > that it would then be years if not centuries between failures for > thousands of units. Well, an important thing left out is the resolution time. You need two numbers, the window size (or probability) of going into a metastable state, and the time constant (it goes into an exponent) on how long you stay in that state. Even if the window is 1ps, if it resolves in 100ps you aren't likely to see it. (You really can't set the clock period less than 90% of the actual delay, though most of that should be included in the specifications.) > But this is also related to the significance of a failure. If it is a > router handling Internet traffic in a user's home, I think a failure > once a month per unit will never be noticed. If it is a more critical > application a failure once a decade across the product line might be a > problem. Yes. But once it gets into the lifetime of the universe range, it is usually good enough. >> The real logic hazard is for a signal that changes near the clock >> edge to propagate through the chip in such a way that the transition >> arrives before the clock at some FFs, and after the clock at some >> others, either due to routing or combinatorial delays. A simple >> state machine can be sent to never-never land when this occurs. >> By properly synchronizing when crossing clock boundaries, you >> allow the tools to be sure that no signal can change state too >> close to the setup time and cause such a hazard. > Static timing analysis is typically used to eliminate such timing > problems. That is FPGA 101 type stuff. Timing tools can't help you > with clock crossings, but they are easy to do if you pay attention and > don't miss any... that is the domain of project management. Well, you have to have at least on FF on an asynchronous input. Metastability says you should have two. That still leaves the problem of multiple inputs. For FIFO's, the solution is to use gray code. You get either the previous or new value of the count, never any other values. >> Many people claim such problems were metastability, when they were >> more prosaic logic hazards. > Yes, the two are sometimes confused. Yes, both the single and multiple input case show up in actual designs. -- glenArticle: 154529
Mike Perkins <spam@spam.com> wrote: > On 23/11/2012 21:31, rickman wrote: >> On 11/22/2012 1:40 PM, Mike Perkins wrote: >>> By taking a latched clock being high say for 2 High-Speed clocks >>> before accepting it as a real clock-high. >> You aren't seeing the picture. This doesn't solve metastability in >> any meaningful way. The edge detection logic can still be "glitched" >> by metastability and disrupt the rest of the circuit. > I didn't explain myself very well. > The technique I was eluding to (badly) regards noisy and slow inputs > (such as from a PS2 mouse) is to have a counter; to count up when the > input is high, and to count down when the input is low. The output > would only be changed to a "1" if the counter was at maximum and changed > to a "0" if the counter was at minimum. OK, this is for decoding the output of a quadrature encoder. Even if you know the maximum rate, in the mouse case, how fast the mouse could move, if it is sitting right on the edge the outputs can change very often, or even stay between "0" and "1". The fast clock method works well in that case. Properly designed, only one input can be in a bad state at once, and the output can switch between those values (+1 and -1). -- glenArticle: 154530
James823 <3681@embeddedrelated> wrote: > I've been looking at synchronising data across clock domains, and have > managed to confuse myself. > Can someone confirm (or correct me) that the following is true. > Metastability may occur if the input D changes value during the set-up and > hold times, however the enable can be completely asynchronous without ever > causing a problem? The article http://www.technion.ac.il/~sbeer/publications/p3.pdf seems to have some pretty good data (actual numbers) on metastability. -- glenArticle: 154531
>James823 <3681@embeddedrelated> wrote: > >> I've been looking at synchronising data across clock domains, and have >> managed to confuse myself. >> Can someone confirm (or correct me) that the following is true. > >> Metastability may occur if the input D changes value during the set-up and >> hold times, however the enable can be completely asynchronous without ever >> causing a problem? > >The article http://www.technion.ac.il/~sbeer/publications/p3.pdf >seems to have some pretty good data (actual numbers) on >metastability. > >-- glen > Ahh you read my mind - I was just about to ask! Thanks, I'll give it a read. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154532
>>James823 <3681@embeddedrelated> wrote: >> >>> I've been looking at synchronising data across clock domains, and have >>> managed to confuse myself. >>> Can someone confirm (or correct me) that the following is true. >> >>> Metastability may occur if the input D changes value during the set-up >and >>> hold times, however the enable can be completely asynchronous without >ever >>> causing a problem? When it comes to enable (or reset), devices differ in the way they implement it. enable or reset may be available as ports on flips(designed at silicon level) or they may be applied through logic on the D port. In this second case enable or reset are directly involved in D value. In the case enable or reset are ports then it is matter of silicon design but I know altera defines timing violation in terms of D or enable or reset release. I usually visualise the flip as if it is in "sleep mode" when under reset or not enabled. Once it wakes up it should do so away from timing window even if D is stable (but has changed value compared to current Q) It is all eventually an issue of sampling a stable input or sampling by a stable device. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154533
rickman wrote: > I don't have the stats memorized, but I don't think this is an accurate > description. If you design is truly async then the rate is such that > with a number of units in the field you will likely see failures long > before the warranty period is up... lol But by providing even as little > as two nanoseconds of settling time the probability is hugely reduced so > that it would then be years if not centuries between failures for > thousands of units. > Yes, I certainly don't recommend NOT using the classic dual-rank FF to synchronize across clock boundaries. I'd want to be conservative. > But this is also related to the significance of a failure. If it is a > router handling Internet traffic in a user's home, I think a failure > once a month per unit will never be noticed. If it is a more critical > application a failure once a decade across the product line might be a > problem. Well, especially in TCP traffic, as long as the failure doesn't lock up the router, it would be a pretty benign failure. > >> The real logic hazard is for a signal that changes near the clock >> edge to propagate through the chip in such a way that the transition >> arrives before the clock at some FFs, and after the clock at some >> others, either due to routing or combinatorial delays. A simple >> state machine can be sent to never-never land when this occurs. >> By properly synchronizing when crossing clock boundaries, you >> allow the tools to be sure that no signal can change state too >> close to the setup time and cause such a hazard. > > Static timing analysis is typically used to eliminate such timing > problems. That is FPGA 101 type stuff. Timing tools can't help you > with clock crossings, but they are easy to do if you pay attention and > don't miss any... that is the domain of project management. Static timing finds real violations in propagation delay, but totally misses non-synchronized signals coming from off-chip. A static analysis says everything is fine, meaning that all signals generated WITHIN that clock domain meet the setup/hold requirements. And, I challenge you to find ANY logic designer who hasn't, at one time, missed putting a proper synchronizer on a signals that crossed a clock boundary. I sure know I have done it, and have been on projects where others have done it. > >> Many people claim such problems were metastability, when they were >> more prosaic logic hazards. > > Yes, the two are sometimes confused. And, that was really the big point I was trying to make, that what the OP was asking about was most likely NOT a real metastability problem, but a need to synchronize all inputs that cross a clock boundary. JonArticle: 154534
>Static timing finds real violations in propagation delay, but >totally misses non-synchronized signals coming from off-chip. >A static analysis says everything is fine, meaning that all signals >generated WITHIN that clock domain meet the setup/hold requirements. >And, I challenge you to find ANY logic designer who hasn't, at >one time, missed putting a proper synchronizer on a signals that >crossed a clock boundary. I sure know I have done it, and have >been on projects where others have done it. >> True, static timing analysis can only check paths between two registers and will ignore the first set of fpga input registers (unless it has info on external device output timing), any asynchronous input coming offchip and external device input registers(unless it has info on external device input timing). But it (or at least TimeQuest) default checks clock domain transfers unless the path is set false. Whether metastability occurs or not, it remains a fact that timing violations certainly cause immediate failures (may be corrected by freezing) and these may be due to logic errors at sampling. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154535
In the following link, a design is presented that alledgedly
has a flaw. The claim is that this is a simple case and
that any experienced designer will see the flaw immediately.
(I don't.)
http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705&
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com
Article: 154536Le 25/11/2012 20:11, Jan Decaluwe a écrit : > In the following link, a design is presented that alledgedly > has a flaw. The claim is that this is a simple case and > that any experienced designer will see the flaw immediately. > > (I don't.) > > http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& > The feedback term is 0 when the LFSR is all 0s so it won't count because it resets to all 0s. NicolasArticle: 154537
Le 25/11/2012 20:49, Nicolas Matringe a écrit : > Le 25/11/2012 20:11, Jan Decaluwe a écrit : >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> >> > The feedback term is 0 when the LFSR is all 0s so it won't count because > it resets to all 0s. Or maybe not... What's that 'xnor' operator ? I've never used it before. NicolasArticle: 154538
On 25/11/12 19:49, Nicolas Matringe wrote: > Le 25/11/2012 20:11, Jan Decaluwe a écrit : >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> > The feedback term is 0 when the LFSR is all 0s so it won't count because > it resets to all 0s. > > Nicolas > I don't think so - with XOR gates you mustn't use all zeros, but he's used XNOR, so you mustn't use all '1's. regards Alan -- Alan FitchArticle: 154539
On 25/11/12 19:11, Jan Decaluwe wrote: > In the following link, a design is presented that alledgedly > has a flaw. The claim is that this is a simple case and > that any experienced designer will see the flaw immediately. > > (I don't.) > > http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& > I guess it also depends what he means by flaw. The only signal required in the sensitivity list is clk; and if he'd made LFSR type unsigned, he wouldn't have needed the type conversions. But I guess that doesn't affect functionality (which I assume is what is meant by a flaw). Perhaps I should read the second page of the post... Of course it may just be that the feedback taps on the LFSR are wrong for a maximal length sequence, but I can't be bothered to look that up :-) Alan -- Alan FitchArticle: 154540
Haven't looked well but about the only unusual thing is the sensitivity list and the the author's explanation which is wrong. D0 is synchronised because it is dependent on lfsr bits. The author should say that he needed one clock latency functionally on D0 instead. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154541
On 11/25/2012 09:02 PM, Alan Fitch wrote:
> On 25/11/12 19:11, Jan Decaluwe wrote:
>> In the following link, a design is presented that alledgedly
>> has a flaw. The claim is that this is a simple case and
>> that any experienced designer will see the flaw immediately.
>>
>> (I don't.)
>>
>> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705&
>>
>
> I guess it also depends what he means by flaw. The only signal required
> in the sensitivity list is clk; and if he'd made LFSR type unsigned, he
> wouldn't have needed the type conversions.
>
> But I guess that doesn't affect functionality (which I assume is what is
> meant by a flaw).
Correct. The superfluous signals in the sensitivity list are
messy, but they don't affect behavior.
> Perhaps I should read the second page of the post...
I think you may find it interesting.
> Of course it may just be that the feedback taps on the LFSR are wrong
> for a maximal length sequence, but I can't be bothered to look that up :-)
Of course not. Again, he claims that an experienced designer
would see it immediately.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com
Article: 154542On 25/11/12 20:13, Jan Decaluwe wrote: > On 11/25/2012 09:02 PM, Alan Fitch wrote: >> On 25/11/12 19:11, Jan Decaluwe wrote: >>> In the following link, a design is presented that alledgedly >>> has a flaw. The claim is that this is a simple case and >>> that any experienced designer will see the flaw immediately. >>> >>> (I don't.) >>> >>> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >>> >> >> I guess it also depends what he means by flaw. The only signal required >> in the sensitivity list is clk; and if he'd made LFSR type unsigned, he >> wouldn't have needed the type conversions. >> >> But I guess that doesn't affect functionality (which I assume is what is >> meant by a flaw). > > Correct. The superfluous signals in the sensitivity list are > messy, but they don't affect behavior. > >> Perhaps I should read the second page of the post... > > I think you may find it interesting. > OK I cracked and read it. I don't really understand what's going on, I would have to simulate it (though of course you've already done that Jan!). I agree there's something fishy about adding output delays. What difference would that make in this case? >> Of course it may just be that the feedback taps on the LFSR are wrong >> for a maximal length sequence, but I can't be bothered to look that up :-) > By moving the assignment to d0 into the process, he has implied another flip-flop, which makes me think that my guess that the feedback taps are wrong is correct - though there's no way an experienced designer could spot that (unless they'd memorized that table in XAPP 210 - I've memorized the app note number, but not the table :-) ). > Of course not. Again, he claims that an experienced designer > would see it immediately. Mysteriouser and mysteriouser... Alan > > Jan > -- Alan FitchArticle: 154543
On 11/25/2012 2:11 PM, Jan Decaluwe wrote: > In the following link, a design is presented that alledgedly > has a flaw. The claim is that this is a simple case and > that any experienced designer will see the flaw immediately. > > (I don't.) > > http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& > I see two things I would flag. One is the fact that they include extraneous signal names in the sensitivity list. This can cause a simulation to run slowly, but I've never seen a synthesizer to create different logic because of it. The other is the omission of a reset assignment for the signal clk_out which is registered. This means the reset will simply disable the clk_out FF from changing state when rst is asserted, but otherwise the circuit will function normally. I don't see an error that will stop the design from working. The use of XNOR gates in the feedback means the all 1s state will latch up while the use of XOR gates in the feedback means the all 0s state will latch up. The XNOR is just an XOR with the output inverted which is the same as either one of the inputs inverted or all three inverted. Thinking of it as all three inverted clearly shows the symmetry of the latch up states. RickArticle: 154544
On 11/25/2012 3:27 PM, rickman wrote: > On 11/25/2012 2:11 PM, Jan Decaluwe wrote: >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> >> > > I see two things I would flag. One is the fact that they include > extraneous signal names in the sensitivity list. This can cause a > simulation to run slowly, but I've never seen a synthesizer to create > different logic because of it. > > The other is the omission of a reset assignment for the signal clk_out > which is registered. This means the reset will simply disable the > clk_out FF from changing state when rst is asserted, but otherwise the > circuit will function normally. > > I don't see an error that will stop the design from working. > > The use of XNOR gates in the feedback means the all 1s state will latch > up while the use of XOR gates in the feedback means the all 0s state > will latch up. The XNOR is just an XOR with the output inverted which is > the same as either one of the inputs inverted or all three inverted. > Thinking of it as all three inverted clearly shows the symmetry of the > latch up states. > > Rick Looking at Page 2 of the article I don't see what he is going on about. I don't think he knows either... The first response in his blog is trying to grapple with what seems to be an error in his analysis and his response is... "Oh i dunno, its far too early in the morning ;-) anyway the point is it didn't work and now it does Hurrah!!, and hitting things with hammers when they don't work, although satisfying, does get expensive." I'm not going to read 6 pages of reverse sequence blog to try to understand the gist of this conversation, but clearly the original article is just a big goof on the author's part. I hope no newbies read it and get very confused by all the nonsense. One blog comment is rather pertinent. Hamster said, "I'm quite sure that a good test bench will be far more complex than the unit under test, and far harder to write." This has been my experience and I think this point should be emphasized with engineers time and time again! Writing code is easy. Writing verified code, not so much. RickArticle: 154545
The big flaw is the combinatorial feedback of bit 0. since d0 <= xnor...bit0 and bit0 is assigned do. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154546
>The big flaw is the combinatorial feedback of bit 0. since d0 <= >xnor...bit0 >and bit0 is assigned do. > >Kaz > >--------------------------------------- >Posted through http://www.FPGARelated.com > sorry correcting myself: there is one register between bit0 and d0. I believe the author has wrong observation. if simulation worked it should work in hardware. The fact that it didn't then it worked by moving d0 to clocked process is fishy. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154547
On 11/25/2012 08:11 PM, Jan Decaluwe wrote:
> In the following link, a design is presented that alledgedly
> has a flaw. The claim is that this is a simple case and
> that any experienced designer will see the flaw immediately.
>
> (I don't.)
>
> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705&
>
I thank each one of you very much for the comments.
It's good to talk to people who care about these matters
and know what they are talking about. On APP, there was
almost no progress during 5 (five!) days.
Even better, one of the comments inspired me to construct
an hypothesis of what went wrong here. Alan Fitch wondered
why lfsr was not an unsigned to make the comparison nicer.
Suppose that in his original code (not the one he posted)
the comparison would be with a bitstring of the wrong
size. That would always fail and explain the behavior
that he describes.
He may have misunderstood the fix when making changes
to the code. Where he then gets his strange explanations
is anybody's guess.
Thanks,
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com
Article: 154548Le 25/11/2012 21:53, rickman a écrit : > One blog comment is rather pertinent. Hamster said, "I'm quite sure > that a good test bench will be far more complex than the unit under > test, and far harder to write." This has been my experience and I think > this point should be emphasized with engineers time and time again! > Writing code is easy. Writing verified code, not so much. Rule of thumb I once heard is to put twice as much engineers in verification as there are in design. Funnily, the company I worked for at the time did exactly the reverse. And surprisingly they were kicked out of the project (and I resigned) NicolasArticle: 154549
On 11/25/2012 6:31 PM, Jan Decaluwe wrote: > On 11/25/2012 08:11 PM, Jan Decaluwe wrote: >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> >> > > I thank each one of you very much for the comments. > > It's good to talk to people who care about these matters > and know what they are talking about. On APP, there was > almost no progress during 5 (five!) days. > > Even better, one of the comments inspired me to construct > an hypothesis of what went wrong here. Alan Fitch wondered > why lfsr was not an unsigned to make the comparison nicer. > > Suppose that in his original code (not the one he posted) > the comparison would be with a bitstring of the wrong > size. That would always fail and explain the behavior > that he describes. > > He may have misunderstood the fix when making changes > to the code. Where he then gets his strange explanations > is anybody's guess. This is one of the reasons why I've never created a blog or other "expert" column on the web. I may be fairly experienced, but by writing things like this blog I may be showing what things I *don't* know rather than what I do... lol 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