VHDL expert puzzle

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

d
Reply to
rickman
Loading thread data ...

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

Reply to
rickman

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

- Kerry

Reply to
Kerry Imming

e
.

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

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

Apparently.

Good advice.

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com 
     Python as a HDL: http://www.myhdl.org 
 Click to see the full signature
Reply to
Jan Decaluwe

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.

Reply to
Michael S

Ok, fair enough.

Rick

Reply to
rickman

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

Reply to
rickman

But now you're letting this guy's postings bother you so much that the two sentences you just wrote contradict each other.

I don't follow how you think it makes no sense for you to write high qualit y blogs alongside someone who you (and apparently others) think writes low quality ones. If APP has no editorial board or peer review process (which is what it looks like to me), then there is no quality control mechanism ot her than the replies to the blog. So you can't choose your fellow bloggers ...but you can control that by blogging elsewhere if you so choose.

It seems to me that you took what probably looked to you at first to be an 'interesting' problem and found that the author had (to be polite) a few er rors and that it was just a dud rather than something interesting. Maybe y ou're put off by the time you invested in it...you seem to have taken offen se that the author basically blew it all off rather than taking the posting s as useful corrective feedback. So what? Don't make it any sort of perso nal (or non-personal) issue to you since that is something you can control.

Kevin Jennings

Reply to
KJ

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

Reply to
Bart Fox

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

Reply to
glen herrmannsfeldt

It's a personal issue for me, but it shouldn't become one for anybody else here. I was looking for technical feedback and confirmation of my findings, and I got it.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com 
     Python as a HDL: http://www.myhdl.org 
 Click to see the full signature
Reply to
Jan Decaluwe

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

formatting link

My HDL design blog on Sigasi:

formatting link

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com 
     Python as a HDL: http://www.myhdl.org 
 Click to see the full signature
Reply to
Jan Decaluwe

From those replies (or lack of replies) I infer, perhaps incorrectly, whether I have an audience myself. If there's no interest or support to correct even the most basic and flagrant errors, I admit that I have some doubts.

Correct. So the question I have to answer for myself is whether APP is giving me the short-term added value (a large interested audience) that I thought it would give me. The site has significant disadvangages too: it's hard to find old posts back, and the comment section's threading mechanism doesn't work well.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com 
     Python as a HDL: http://www.myhdl.org 
 Click to see the full signature
Reply to
Jan Decaluwe

.

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

Reply to
Thomas Stanka

g.  In your example, you have actual function (the muxing and enabling) b etween the clocks so you're describing a gated clock system.  That system , if built, could very well behave exactly as you have described but not be what the designer intended simply because the designer did not account for the clock skew.  The simulation without the added delay very well may de scribe the actual hardware.  In this case, adding the delay 'to fix the s imulation' would be sweeping the design error under the rug until it eventu ally is uncovered in real hardware.

k as this:

is instance the 'clk1

Reply to
Thomas Stanka

I agree it is hard to imagine. If I would have got a penny for every bug I detected within EDA-Tools, I would be rich. And there are sometimes issues real hard to believe that I'm the first to detect. So I'm no longer surprised, if another major bug happens in EDA-World.

Reply to
Thomas Stanka

I fully agree with that, and I have been through that experience myself.

Unfortunately, it looks like were not going to find out in this case ;-)

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com 
     Python as a HDL: http://www.myhdl.org 
 Click to see the full signature
Reply to
Jan Decaluwe

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 based on my experience with the tools and looking at other's code.

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

Reply to
rickman

My understanding is that logic delays in FPGAs are always longer than clock delays on the clock trees so that you can't have a hold time violation. If the clock is routed on the signal routing then all bets are off. I don't know how well the timing analysis does with verifying clock delays on the signal routing because I have never needed to use it that I can remember.

Rick

Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.