-2
\$\begingroup\$

I'm a Computer Engineering student and learned the basic sequential programming languages (C/assembly/Java) way before I was even introduced to HDLs. Thus, my whole programming logic was based upon sequential coding with a very specific execution flow.

Once introduced to HDLs, I and many of my colleagues ran into difficulties regarding the concurrent way a circuit can behave. We had a very clear understanding of combinational logic, but synthesizing a circuit in a language so similar to the "usual" sequential languages we were first taught was somewhat challenging.

Wouldn't it be better to teach HDLs before software programming languages to "hardware-driven" courses?

\$\endgroup\$

closed as primarily opinion-based by PeterJ, Matt Young, Leon Heller, Andy aka, Daniel Grillo Dec 10 '15 at 10:28

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

5
\$\begingroup\$

IMHO, "no". First, even though the sequential vs. concurrent issue takes some getting used to, the concept of precisely instructing a machine takes even more, and sequential languages are an easier and more accessible introduction to that - even apart from the languages themselves, just look at the cost, capability, flexibility, build time, and market size of the tools.

Once you get beyond basic combinatorial logic stages, most HDL designs are sequences of parallel operations anyway - be they state machines, pipelines, or stored-program processors in their own right. Further, most practical HDL designs will also require no small amount of sequential software to exercise or utilize them.

Finally, practically speaking in today's world of cheap microcontrollers, unless you are designing special ASIC functionality, you will almost always use a sequential program as your default choice, and resort to describing custom logic only where a sequentially programmed machine is substantially sub-optimal for the task - most often, when you need to do something relatively simple very quickly, or in massive parallel.

\$\endgroup\$
2
\$\begingroup\$

I have written lots of C code (and asm code) that was all event driven.

Typically from timer, watchdog, and I/O interrupts. With lots of schedulers to initiate periodic software functions.

In my experience, most schools do not teach the kind of thinking needed to handle event driven programming.

There are concurrent languages, often running on PLCs, ASICs, etc that are continuous, concurrent, etc. Mostly, after learning those languages, a programmer must be thinking in those languages to obtain the most out of them.

Then there are the I.A. languages like Lisp and Prolog that are completely different from either the sequential or event driven languages.

I.E. each language has its' strong and weak points. If a programmer wants (or needs) to use a specific language, then they need to learn that language, so they think of programming problems in the terms of that language.

Most programmers will never be programming FPGAs or ASICs or PLCs, but will be either doing application programming for business (COBOL, C, JAVA, ForTran, etc) or web design (HTML, XML, javascript, json, SQL, etc.

SO, IMO: the 'sequential' languages are best to learn first as they are the easiest to understand, so the basic concepts are known before learning the more esoteric languages.

And then there are the languages like C++ and C# and J# and many more that can be coded for either environment.

But first, the underlying concepts need to be understood.

Concepts Ranging from memory and register concepts, to the history of programming, to the Turing machine, to 'ancient' things that were the forerunners of today, such as ASCII, and 80/96 column punched cards and card readers and paper tape and magnetic tape with level shifting and low level programming of I/O devices, etc etc etc.

\$\endgroup\$
  • 1
    \$\begingroup\$ "I.A. languages like Lisp and Prolog that are completely different from either the sequential or event driven languages". First "I.A." should be "A.I.". Also, Lisp and Prolog aren't actually much different from sequential languages. Further one of Prolog's weaknesses is developers often need to take control of its sequential properties to solve real-world-scale problems; it is somewhat different for simple (trivial?) problems. Finally some of the 'concepts' listed rarely help, and may mislead (e.g. some algorithms were a response to technology restrictions which no longer apply). \$\endgroup\$ – gbulmer Dec 10 '15 at 7:43
  • \$\begingroup\$ BTW, HTML and XML are not programming languages. Also Fortran was FORTRAN, not ForTran, and Java is not an acronym; it was never JAVA etc. \$\endgroup\$ – gbulmer Dec 10 '15 at 7:51
  • \$\begingroup\$ @gbulmer, Actually, HTML, XML, are programming languages and FORTRAN was originally spelled ForTran because that was a short cut for Formula Translator etc. If a 'programmer' does not know the history of programming, memory concepts, etc etc. Then they will be severely handicapped, especially when they need to produce some code that is 'outside their comfort zone', like having to implement a communication protocol or 'bit-bang' a I/O port or implement an I/O optimizer for a Centronics printer or update some very old code that originally talked to a card reader/punch or ... \$\endgroup\$ – user3629249 Dec 10 '15 at 19:09
  • \$\begingroup\$ Definition of XML: "Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format which is both human-readable and machine-readable." \$\endgroup\$ – user3629249 Dec 10 '15 at 19:10
  • \$\begingroup\$ definition of HTML: "Hypertext Markup Language, a standardized system for tagging text files to achieve font, color, graphic, and hyperlink effects on World Wide Web pages." \$\endgroup\$ – user3629249 Dec 10 '15 at 19:11
1
\$\begingroup\$

Given that I have seen several HDL veterans who later in their career decided to learn C, and from there produced completely horrible code, I think it is a very bad idea to start with HDL as your first programming language.

Not so much because of the sequential versus event-driven program flow, but because high-level languages are so much more complex and also have more rigid requirements on readability. You can't write high-level language code like you write HDL, you need to apply some manner of program design, a concept which is mostly absent in HDL.

It is a fact that microcontrollers are far more commonly used than ASICs. And even when ASICs are used, they often have microcontrollers/microprocessors inside. So the main focus when teaching engineering should be microcontroller programming.

And looking at many examples of bare metal microcontroller programs for example posted on this site, where everything is a wall of code inside main(), with a few stray, barely thought-out functions, there is a desperate need for E.E school to focus more on program design, rather than subjects of peripheral interest such as HDL or digital logic.

\$\endgroup\$
  • \$\begingroup\$ While I somewhat agree with you, I feel that sighting code examples here, as evidence that EE schools don't focus on 'managing complexity', is a very biased sample. People are mostly asking questions because they don't know how to solve a problem. So we shouldn't judge industry from that our sample. We may make the code worse because we often ask for "the simplest case that demonstrates a bug", and the poster is tempted to doing that ASAP with least effort. Finally, I know a HDL professor; he believes students can be taught to organise their 'programs' to better manage complexity. \$\endgroup\$ – gbulmer Dec 10 '15 at 8:01
  • \$\begingroup\$ @gbulmer Of course you'll mainly find narrowed down examples on this site, but on the other hand you'll rarely ever find any hints of proper design either. So apart from students etc asking for help with narrow tasks, I think the site reflects the industry fairly well. It is a well-known problem that the embedded industry, just like any other present software industry, contains plenty of quacks and incompetents. Just open up pretty much any app note by any major silicon vendor that contains C source code and see for yourself. \$\endgroup\$ – Lundin Dec 10 '15 at 9:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.