«

On 11/29/2012 03:22 PM, rickman wrote:

> I think the "Just forget about it" comment was on the second page of
> comments and there were six when I read it. So I guess he is getting
> beat up pretty badly. I feel for him.

I wouldn't worry too much Let me summarize.

Let's be clear about how bad this really is. He describes
the simulation with delays, and draws all kinds of
nonsensical conclusions from it. However, by simulating
his code, everybody can verify that it simply doesn't behave
in the way he describes. He makes his points while
misrepresenting his own (public!) code.

For days, I have been trying to point out that there is
something fundamentally wrong here No reaction from
the community on APP on this particular point. In
the end, the OP came back and stated (screamed) that
he "just does not care whether his code works or not".
Those who do "are missing the point". (I think he means
that he should be praised for using the word "testbench").

Guess what: again no reaction to this date on APP.
The only behavior that has been criticized is my
own, for calling this article "sloppy". (I confess.)

In short, he is getting away with this.

--
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

On 11/29/2012 10:28 AM, Michael S wrote:
> On Nov 29, 4:50 pm, "Kerry Imming"<kcimm...@pobox.com> wrote:
>>
>> I think the problem is not the LFSR, but that the XNOR operation can be
>> non-intuitive.
>>
>> For example: a XNOR b XNOR c is equivalent to a XOR b XOR c
>> Since there is an even number of inversions, the inversions cancel out.
>> In the given example, there is an odd number of XNORs, so it works as
>> written.
>>
>> My preferred style would be. d<= NOT (a XOR b XOR c);
>>
>> - Kerry
>
> Yes, that's exactly what I meant to say.
>

Actually, this is an example why you *don't* want to convert to XOR.
The example given was converted wrongly.

d <= NOT (a XOR b XOR c)
is not the same as
d <= a XNOR b XNOR c
which is what I believe Kerry is saying.

d <= a XOR b XOR c
would be the same as
d <= a XNOR b XNOR c

XNOR is only non-intuitive because you haven't worked with it much.
Just like it is not uncommon to use NOR and NAND, I think XNOR has a
place in the vocab of logic designers.

Rick

On 11/29/2012 12:21 PM, Jan Decaluwe wrote:
> On 11/29/2012 03:22 PM, rickman wrote:
>
>> I think the "Just forget about it" comment was on the second page of
>> comments and there were six when I read it. So I guess he is getting
>> beat up pretty badly. I feel for him.
>
> I wouldn't worry too much Let me summarize.
>
> Let's be clear about how bad this really is. He describes
> the simulation with delays, and draws all kinds of
> nonsensical conclusions from it. However, by simulating
> his code, everybody can verify that it simply doesn't behave
> in the way he describes. He makes his points while
> misrepresenting his own (public!) code.
>
> For days, I have been trying to point out that there is
> something fundamentally wrong here No reaction from
> the community on APP on this particular point. In
> the end, the OP came back and stated (screamed) that
> he "just does not care whether his code works or not".
> Those who do "are missing the point". (I think he means
> that he should be praised for using the word "testbench").
>
> Guess what: again no reaction to this date on APP.
> The only behavior that has been criticized is my
> own, for calling this article "sloppy". (I confess.)
>
> In short, he is getting away with this.

I read his blog and I read some of the responses, both at the start and
at the current end (it looks like no one has posed in a couple of days
now). The blog thread is all about the mistake the guy made in
analyzing the operation of the code.

What/where is APP?

As far as the guy "getting away with this" I don't get what you mean.
Why is this an issue?

I think others may understand what you are saying. It just isn't such a
big deal if the response is not as dramatic as you may have expected. I
don't think anyone is really "criticizing" you. They just don't agree
that this is such a big issue.

I try to not get upset by things that happen on Internet forums. Its
like the quote from the movie Chinatown... "Forget it, Jake; it's
Chinatown".

Rick

"rickman" <> wrote in message
news:k987ht$94j$...
>
> Actually, this is an example why you *don't* want to convert to XOR. The
> example given was converted wrongly.
>
> d <= NOT (a XOR b XOR c)
> is not the same as
> d <= a XNOR b XNOR c
> which is what I believe Kerry is saying.
>
> d <= a XOR b XOR c
> would be the same as
> d <= a XNOR b XNOR c
>
> XNOR is only non-intuitive because you haven't worked with it much. Just
> like it is not uncommon to use NOR and NAND, I think XNOR has a place in
> the vocab of logic designers.
>

Apologies... I should have used different variables for my "prefered style"
example.

- Kerry

On Nov 29, 7:54*pm, rickman <gnu...@gmail.com> wrote:
> On 11/29/2012 10:28 AM, Michael S wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 29, 4:50 pm, "Kerry Imming"<kcimm...@pobox.com> *wrote:
>
> >> I think the problem is not the LFSR, but that the XNOR operation can be
> >> non-intuitive.
>
> >> For example: * a XNOR b XNOR c *is equivalent to a XOR b XOR c
> >> Since there is an even number of inversions, the inversions cancel out..
> >> In the given example, there is an odd number of XNORs, so it works as
> >> written.
>
> >> My preferred style would be. * *d<= NOT (a XOR b XOR c);
>
> >> - Kerry
>
> > Yes, that's exactly what I meant to say.
>
> Actually, this is an example why you *don't* want to convert to XOR.
> The example given was converted wrongly.
>
> d <= NOT (a XOR b XOR c)
> is not the same as
> d <= a XNOR b XNOR c
> which is what I believe Kerry is saying.
>
> d <= a XOR b XOR c
> would be the same as
> d <= a XNOR b XNOR c
>
> XNOR is only non-intuitive because you haven't worked with it much.
> Just like it is not uncommon to use NOR and NAND, I think XNOR has a
> place in the vocab of logic designers.
>
> Rick

Let's agree to disagree.
I think, that all three, XNOR, NOR and NAND are equally unacceptable
in HDL coding for FPGA.

On 11/29/2012 07:18 PM, rickman wrote:

> I read his blog and I read some of the responses, both at the start
> and at the current end (it looks like no one has posed in a couple of
> days now). The blog thread is all about the mistake the guy made in
> analyzing the operation of the code.
>
> What/where is APP?

The abbreviation for All Programmable Planet, the site
on which this blog is located.

> As far as the guy "getting away with this" I don't get what you mean.
> Why is this an issue?

It's not an issue. I was only pointing out that there is
no need for you "to feel for him"

(For full disclosure and information only: it is actually
an issue for me personally - since some time I am also a blogger
on APP and I have spent lots of time trying to write high quality
blogs. That makes little sense if it turns out you can write
anything you want without having to worry about correctness.)

> I think others may understand what you are saying. It just isn't
> such a big deal if the response is not as dramatic as you may have
> expected. I don't think anyone is really "criticizing" you. They
> just don't agree that this is such a big issue.

Apparently.

> I try to not get upset by things that happen on Internet forums. Its
> like the quote from the movie Chinatown... "Forget it, Jake; it's
> Chinatown".

Good advice.

--
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

On Nov 29, 9:30*pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> On 11/29/2012 07:18 PM, rickman wrote:
>
> > I read his blog and I read some of the responses, both at the start
> > and at the current end (it looks like no one has posed in a couple of
> > days now). *The blog thread is all about the mistake the guy made in
> > analyzing the operation of the code.
>
> > What/where is APP?
>
> The abbreviation for All Programmable Planet, the site
> on which this blog is located.
>
> > As far as the guy "getting away with this" I don't get what you mean.
> > Why is this an issue?
>
> It's not an issue. I was only pointing out that there is
> no need for you "to feel for him"
>
> (For full disclosure and information only: it is actually
> an issue for me personally - since some time I am also a blogger
> on APP and I have spent lots of time trying to write high quality
> blogs. That makes little sense if it turns out you can write
> anything you want without having to worry about correctness.)
>
> > I think others may understand what you are saying. *It just isn't
> > such a big deal if the response is not as dramatic as you may have
> > expected. *I don't think anyone is really "criticizing" you. *They
> > just don't agree that this is such a big issue.
>
> Apparently.
>
> > I try to not get upset by things that happen on Internet forums. *Its
> > like the quote from the movie Chinatown... "Forget it, Jake; it's
> > Chinatown".
>
> Good advice.
>
> --
> 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

I think, the logical mistake that he made in his second attempt and,
more importantly, the fact that he failed to notice it by manual
observation of simulation result give you an excellent opportunity to
evangelize self-checking testbenchs in your own blog.

On 11/29/2012 2:30 PM, Michael S wrote:
> On Nov 29, 7:54 pm, rickman<gnu...@gmail.com> wrote:
>>
>> XNOR is only non-intuitive because you haven't worked with it much.
>> Just like it is not uncommon to use NOR and NAND, I think XNOR has a
>> place in the vocab of logic designers.
>>
>> Rick
>
> Let's agree to disagree.
> I think, that all three, XNOR, NOR and NAND are equally unacceptable
> in HDL coding for FPGA.

Ok, fair enough.

Rick

On 11/29/2012 2:30 PM, Jan Decaluwe wrote:
> On 11/29/2012 07:18 PM, rickman wrote:
>
>> As far as the guy "getting away with this" I don't get what you mean.
>> Why is this an issue?
>
> It's not an issue. I was only pointing out that there is
> no need for you "to feel for him"
>
> (For full disclosure and information only: it is actually
> an issue for me personally - since some time I am also a blogger
> on APP and I have spent lots of time trying to write high quality
> blogs. That makes little sense if it turns out you can write
> anything you want without having to worry about correctness.)


I have a friend who is starting a non-profit regarding cold water
safety. He has a lot of trouble with people just not getting the idea
that cold water is very dangerous and that it would save lives if the
word is spread more widely. But some continue to spout nonsense and
post crap to websites and videos with silly (and wrong) rules about when
the water is dangerous and how long you can survive in it. He is trying
to distance himself from the flotsam and jetsam. So I feel *your* pain
too. lol

I think what would be best is to not push too hard, but just to give it
time. I am gradually learning that with most stuff Internet, much like
they say to count to 10 before responding to spoken words, it is good to
wait a day or even two before responding to things on the Internet. I'm
trying to learn that myself.

The bottom line is this guy won't impact you much really. What blogs
have you done? I'd like to read them.

Rick

rickman wrote:
> I think for FPGAs it is very common to specify an async reset to assign
> the configuration value of each FF, so I have come to expect async
> resets.
Dream on. It ist *not* common to use asnchronous resets on every flipflop.

This is your opinion or the opinion of the academic VHDL book you read.

In synchronous designs an asynchronous reset has no right.
Make an synchronous reset from your asynchronous reset input on one
place, and all will work.

Bart Fox