VHDL expert puzzle

[Jan Decaluwe]

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.

 

[rickman]

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]

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]

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

 

[Michael S]

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.

 

[Jan Decaluwe]

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.

 

[Michael S]

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


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


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.

 

[rickman]

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]

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

 

[Bart Fox]

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

 

[glen herrmannsfeldt]

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.

Yes, FPGAs usually have an asynchronous reset.

They at least usually have a reset when they come out of
configuration, which tends to be asynchronous to your clock.

Usually it is easy to also put your own signal into the same
reset line, but you don't have to do that.

So, it is common to have one, it may or may not be common
to use it, other than at the end of configuration.

-- glen

 

[Jan Decaluwe]

What blogs have you done? I'd like to read them.

My MyHDL blog on APP (APP uses no tags, sorry):

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=250236&

My HDL design blog on Sigasi:

http://www.sigasi.com/tag/janhdl

 

[Thomas Stanka]

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.

At least a asynchronous asserting but synchronous deasserting reset is
very reasonable in synchronous design.

Those who ignore reset when designing for vandor x or a often forget
that good code should be as much as possible vendor independant, as
you never know, when part of your code is reused on different
technology in which you have no guraanteed start-up value at power up.

regards Thomas

 

[rickman]

Dream on. It ist *not* common to use asnchronous resets on every flipflop.

I didn't say it was common to specify an async reset on *every* FF. I
said it is common to specify an async reset so that the configuration
value is assigned. You can do that on all of the FFs in the design or
you can do that one the twelve FFs that control your design or you can
do it on none. But if you want set a configuration value it is very
common to use an async reset to do that.

I think some or perhaps most vendors now provide a non-portable method
of setting the configuration value and some even will use an
initialization value in the declaration to do that. But I don't believe
this is very portable as of yet.

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

This is based on my experience with the tools and looking at other's code.

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.

I have no idea why you say an async reset won't work in a sync design.
Do I misunderstand your statement? I am talking about FPGAs where every
chip has an async reset during configuration. You can choose to use
this in your design or not, but it is there and it works no matter what
you do. I supposed I should have qualified my statement to FPGAs that
use RAM configuration and have to be configured. There aren't a lot of
true flash based device that come up instantly without a configuration
process.

Rick

 

[Andy]

On Thursday, November 29, 2012 11:55:39 PM UTC-6, Bart Fox wrote:
In synchronous designs an asynchronous reset has no right.

Get around much?

Note: when I refer to "asynchronous reset", I'm referring to an asynchronous reset controlled by a signal whose deasserting edge is properly synchronized to the corresponding clock domain. That way, the registers are releasedfrom reset on the same clock cycle, but reset asynchronously.

RAM based FPGA registers are initialized at power up, during configuration.Flash based FPGA registers are not initialized at power up, since there isno configuration step after power up, before the device is off and running..

A synchronous reset will not control register states if the clock does not run. If "no-clock" control is important in your domain, then you'll likely have to use asynchrounous resets.

Most safety-critical design standards require initialization of ALL registers at startup, which may occur more often than power up and/or configuration. The simplest, most reliable and verifiable method of doing so is with anasynchronous reset on every register.

There are plenty of designs where a lot of the registers may not really need a reset. But for all the work "saved" by surgically resetting only those things that "need a reset", you'll waste that much and more determining (and verifying!) which registers are which. Don't borrow trouble if you don't need to.

Granted, there are some FPGA families that have resources that only implement synchronous resets. If you use them, you have no choice, at least on those resources. And if you need "no-clock" control in the same device, you'llneed asynchronous resets at least on the outputs.

For those resources that require synchronous reset, I usually synchronize the asynchronous reset for that resource alone, rather than change everything else (that can be changed) to synchronous reset. In other words, I have to have a really good reason NOT to use an asynchronous reset on everything..

Andy

 

[Bart Fox]

Thank you *all* for your replys.
I think the reset topic is now enough clarified.
At least to me

Best regards,
Bart