VHDL expert puzzle

[Mike Perkins]

On 27/11/2012 14:44, Thomas Stanka wrote:

On 26 Nov., 19:14, rickman <gnu...@gmail.com> wrote:
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

I sign this statement

I would agree to this further. For this puzzle, some vendor
synthesisers have treated sensitivity lists differently and made
different assumptions to complicate things still further.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[Jan Decaluwe]

On 11/28/2012 02:15 PM, Mike Perkins wrote:

On 27/11/2012 14:44, Thomas Stanka wrote:
On 26 Nov., 19:14, rickman <gnu...@gmail.com> wrote:
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

I sign this statement


I would agree to this further. For this puzzle, some vendor
synthesisers have treated sensitivity lists differently and made
different assumptions to complicate things still further.

There a issues at multiple levels with this. However
a major one has only to do with modeling and simulation,
namely whether adding the delays should make a difference
to the behavior of the clock output (as he claims),
or not (which is what we see and expect).

Any standard VHDL simulator should give the same answer here.

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

 

The flaw in the design is that a constant integer "countmax" is compared with an LFSR that counts in a random way. This means that the output period will not be as expected.

 

[Michael S]

On Nov 25, 9:11 pm, Jan Decaluwe <j...@jandecaluwe.com> 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=2....

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

An original code is o.k. except for bad style, as mentioned by just
about everybody above, and for kludgy idea to use MLSR to divide
clock.
At least what's implemented is real 14-bit MLSR with period = 2^14-1.
It appears to divide the input clock by 24998 and that's supposedly
was an original intention. Or did he tried to divide by 25000? Or, may
be he really divides by 25000 and I miscalculated by one somewhere?
Anyway, it's pretty close

A "fixed" code is much worse.
It, supposedly unintentionally, implements 15-bit LSR with
period=7905, i.e. *not* MLSR. Input clock is divided by 11684. It's
sounds damn unlikely that that was an intention.

 

[Michael S]

On Nov 27, 5:10 pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:

On 25 Nov., 20:11, Jan Decaluwe <j...@jandecaluwe.com> 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.

If this code is from an experienced designer I see that much flaws,
that have no effect of synthesis or simulation itself, but on
readability.
The sensitivity list is horrible and will cause unnecessary simulator
load, the code indention is best effort to confuse readers. Some code
beautify would do better. And as simple as this design is, a real
world code without any comments is only good for protecting your
failures from reviewers.

The usage of integer as start value for a lfsr is quite error prone. A
hex value would be easier to read and would allow to design this
module without integer or unsigned values.

On this one, and only this one, I disagree.

That clk_out is missing in reset path leads to one cycle latency of
rst to clk_out, that is most likely not intended here. But you could
only guess if that has impact on system or is even necessary.

I also don't like naming synchronous reset 'rst'. I'd rather prefere
'srst" or 'sreset'.

If there is an abvious error in cycle lenght (be it start value or
feedback function), you can see this in simulation. I assume if you
use lfsr, you know that you should double check this, if you are not
really sure what you are doing.

bye Thomas

Just about everything he wrote on the second page makes no sense.

 

[Michael S]

On Nov 28, 5:50 pm, Michael S <already5cho...@yahoo.com> wrote:

On Nov 27, 5:10 pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de
wrote:









On 25 Nov., 20:11, Jan Decaluwe <j...@jandecaluwe.com> 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.

If this code is from an experienced designer I see that much flaws,
that have no effect of synthesis or simulation itself, but on
readability.
The sensitivity list is horrible and will cause unnecessary simulator
load, the code indention is best effort to confuse readers. Some code
beautify would do better. And as simple as this design is, a real
world code without any comments is only good for protecting your
failures from reviewers.

The usage of integer as start value for a lfsr is quite error prone. A
hex value would be easier to read and would allow to design this
module without integer or unsigned values.

On this one, and only this one, I disagree.

That clk_out is missing in reset path leads to one cycle latency of
rst to clk_out, that is most likely not intended here. But you could
only guess if that has impact on system or is even necessary.

I also don't like naming synchronous reset 'rst'. I'd rather prefere
'srst" or 'sreset'.

If there is an abvious error in cycle lenght (be it start value or
feedback function), you can see this in simulation. I assume if you
use lfsr, you know that you should double check this, if you are not
really sure what you are doing.

bye Thomas

Just about everything he wrote on the second page makes no sense.

Oh, another style flow is xnor.
The only valid use of xnor is when you want to obfuscate your
intentions.

 

[rickman]

On 11/28/2012 10:50 AM, Michael S wrote:

On Nov 27, 5:10 pm, Thomas Stanka<usenet_nospam_va...@stanka-web.de
wrote:
The usage of integer as start value for a lfsr is quite error prone. A
hex value would be easier to read and would allow to design this
module without integer or unsigned values.

On this one, and only this one, I disagree.

I had a bit of confusion on this one myself. Not that he was using an
integer per-se, but that he didn't explain in a comment why this value
was important or how it was derived. I had to consider that this value
was ill-conceived and didn't want to bother with looking up the LFSR and
calculating where this value would appear in the sequence, etc. It
would have been useful if he had added a comment saying the length of
the loop is xxx clocks or yyy time.

That clk_out is missing in reset path leads to one cycle latency of
rst to clk_out, that is most likely not intended here. But you could
only guess if that has impact on system or is even necessary.


I also don't like naming synchronous reset 'rst'. I'd rather prefere
'srst" or 'sreset'.

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. But if they use a sync reset, it doesn't bother me. I don't
expect that aspect of the reset to be part of the name. I think resets
are complex enough that they should be designed and documented at the
system level.

If there is an abvious error in cycle lenght (be it start value or
feedback function), you can see this in simulation. I assume if you
use lfsr, you know that you should double check this, if you are not
really sure what you are doing.

bye Thomas

Just about everything he wrote on the second page makes no sense.

Yes, I'm not sure what he was thinking. It is a bit funny how he
responds to this in the blog. He starts out discussing it a little
defensively and after three or four rounds of increasing defensiveness
on his side he says something like, "Just forget about it". I expect it
was a bit embarrassing to make a mistake so publicly. I'm sure we have
all made similar mistakes, the kind where we slap the side of our head
and say, "what was I thinking?" But to do it publicly is a different
matter.

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.

Rick

 

[rickman]

On 11/28/2012 10:55 AM, Michael S wrote:

Oh, another style flow is xnor.
The only valid use of xnor is when you want to obfuscate your
intentions.

I don't understand. What would you use in place of xnor? In LFSRs
there are two ways of coding them. Using the XOR function creates two
loops, one being the all zeros state. Using the XNOR function creates
two loops, one being the all ones state. What is wrong with using the
XNOR function to describe a LFSR with the all ones state as the excluded
state?

Rick

 

[Kerry Imming]

"rickman" <gnuarm@gmail.com> wrote in message
news:k97ral$oin$1@dont-email.me...

On 11/28/2012 10:55 AM, Michael S wrote:

Oh, another style flow is xnor.
The only valid use of xnor is when you want to obfuscate your
intentions.

I don't understand. What would you use in place of xnor? In LFSRs there
are two ways of coding them. Using the XOR function creates two loops,
one being the all zeros state. Using the XNOR function creates two loops,
one being the all ones state. What is wrong with using the XNOR function
to describe a LFSR with the all ones state as the excluded state?

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

 

[Michael S]

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.

 

[Jan Decaluwe]

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

 

[rickman]

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

 

[rickman]

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

 

[Kerry Imming]

"rickman" <gnuarm@gmail.com> wrote in message
news:k987ht$94j$1@dont-email.me...

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

 

[Jan Decaluwe]

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

 

[rickman]

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

 

[rickman]

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

 

[Michael S]

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.

 

[Michael S]

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.

 

[Bart Fox]

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