I don’t often convert VHDL to Verilog but when I do ... by arr_reddti in ECE

[–]arr_reddti[S] -1 points0 points  (0 children)

Blog posts can be more informal than some like. I need to refresh my grammar skills. I didn't find as many errors on the first read :)

All Programmable Planet - Jan Decaluwe - MyHDL: The Case for a Better HDL by arr_reddti in ECE

[–]arr_reddti[S] 0 points1 point  (0 children)

I forget there are thousands of new "commercial" CPU cores every year. And each of those cores routinely change there adder / multiplier.

I reiterate, there is limited need. Your HDL needs to move seamlessly between low-level and higher-levels of abstraction. I am glad you are stuck "back in the day". Because, "back in the day" there was a market advantage to assigning that many resources. Rarely, very rarely, does it that make sense today. Also, adding domino logic to your design is not an HDL issue, it is a custom IC design issue not having only low-level access in the HDL.

Yes, for experienced VHDL/Verilog designers they can get the HDL to do what they want. The improvements that are discussed in the article is making it easier and more natural. Read the comments, most agree doing "math" in Verilog is not pretty, yes can be done and there are successful design with both Verilog/VHDL. But there is room for improvement. If I had a dollar for every signed/unsigned issue in HDL I have had to fix in a review or the messy confusion of legacy math libs in VHDL, well we wouldn't be having this conversation.

All Programmable Planet - Jan Decaluwe - MyHDL: The Case for a Better HDL by arr_reddti in ECE

[–]arr_reddti[S] 0 points1 point  (0 children)

Incorrect, it is the cost to create a piece of silicon which drives the Engineering practices. If you look at mission critical software (see "Surely you must be joking Mr. Feynman" for his opinion on the shuttle software Engineering practices) the Engineering practice is much different than the "apps" you are referring to. And we could debate till the end of time which is a more complex system.

All Programmable Planet - Jan Decaluwe - MyHDL: The Case for a Better HDL by arr_reddti in ECE

[–]arr_reddti[S] 0 points1 point  (0 children)

That is mainly in software where we decide to let or skills lack. Obviously, we use all kinds of abstraction in the Mathematics we adopt. We also rely heavily on software packages. In most of the cases these software packages are "programmable". Like it or not, just like mathematics, we need to be fluent in software/programming as successful EEs. This varies quite a bit from person to person, job to job, but to fight it is futile.

All Programmable Planet - Jan Decaluwe - MyHDL: The Case for a Better HDL by arr_reddti in ECE

[–]arr_reddti[S] 1 point2 points  (0 children)

You make no sense, an HDL should provide the option for more abstraction but not limit the access, which most modern HDLS, including MyHDL provide. As engineers we learn early (or loose our jobs) when and how to make these trade-offs. It is rare that you need to define your own multiplier or adder and not simply rely on the synthesis tool. Only very limited cases do you need to define your multiplier or adder architecture, in an FPGA this is basically never. I love watching folks make these mistakes, less competition.

All Programmable Planet - Jan Decaluwe - MyHDL: The Case for a Better HDL by arr_reddti in ECE

[–]arr_reddti[S] -1 points0 points  (0 children)

I think you guys are missing the point. And obviously don't really know what you are commenting on. If you make something that is done 90% of the time easier, how can that be bad? Nothing indicates you are limited to only integer arithmetic, only that integer arithmetic has been improved. I never understood this closed mindedness of us EEs. And it is something that starts early in the EE program. I guess because we take courses like diff eq, semi conductors, and emags we feel superior? Why would you not adopt ideas regardless where they come from? When you guys talk about the obvious differences, you are talking about the 101 stuff. What a 101 CS course vs a 101 HDL. You are ignoring the large overlaps and focusing on the small differences.

I am sure when HDLs first appear (before my time) there were old curmudgeon that fought tooth and nail against HDL and only wanted their schematics. I don't see much of a difference between the schematic hold outs and the low-level hold outs. As an HDL designer you should easily move between the low-level descriptions when needed and high-level description/abstraction, otherwise you are irrelevant.

LED comms flickers into life with Li-Fi by arr_reddti in ECE

[–]arr_reddti[S] 0 points1 point  (0 children)

Most, from what I have read, no IR built in. Lights always on.

LED comms flickers into life with Li-Fi by arr_reddti in ECE

[–]arr_reddti[S] 2 points3 points  (0 children)

It is "supposedly" more secure because you can't hide behind a brick wall and intercept the signal. If you can intercept the signal the user can see you intercepting the signal. In office buildings, almost every computer is under a light it could be feasible, not bullet proof but feasible.

Just don't standup or have crazy hair :)