Engineering Students being taught DSP on 20 year old processors RMIT

[janoc]

I once interviewed a candidate who was finishing up his fourth year in an electrical engineering program at a well-respected university who did not know what a diode was.

How so? In function, in composition (e.g. doped Silicon), on a schematic (arrow bar symbol), or what a random component labeled D2 on a PCB was?

I had an engineering master student in an exam that had no idea about how to multiply matrices - he claimed he never needed it! And bachelor students (2nd-3rd year) that have never seen fractions and had no idea how to calculate with them ... Also a large and reputable uni.

[Sal Ammoniac]

I once interviewed a candidate who was finishing up his fourth year in an electrical engineering program at a well-respected university who did not know what a diode was.

How so? In function, in composition (e.g. doped Silicon), on a schematic (arrow bar symbol), or what a random component labeled D2 on a PCB was?

In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.

[Mr. Scram]

In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.

What the hell is going on at those institutions?

[KE5FX]

In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.

What the hell is going on at those institutions?

Nothing.  They're turning out some of the best Z80 programmers of all time.  Of all time!

[nctnico]

To quote Professor Kingsfield in The Paper Chase: "You teach yourselves the law, but I train your minds. You come in here with a skull full of mush; you leave thinking like a lawyer."

But it would be nice if the students learn that using the laws used in the country they study in today and not the laws used in the Roman empire 2000 years ago.

You would be surprised but Roman law is actually taught in pretty much any law school today because its principles are in many cases the foundation of how modern law systems work. And many concepts that were introduced in it are still as valid as they were 2000 years ago.

OK, bad example but nowadays we don't crucify people and slavery has been banned for a while as well.

I have also faced this when teaching at the university. University is not there to teach you the tools but to show you the general principles. The role of the teacher is not to show you which buttons in the IDE to press or how to work a specific chip/technology (which will likely be obsolete by the time you graduate anyway) but to help the student understand the common principles behind it.

IMHO it is still better to use industry standards to teach principles than using obscure languages and hardware. There is a general concensus that there is a disconnect by what students learn in school and what they meet at their first job. There is also a difference between the various levels. A BSc graduate will be expected to work hands-on on hardware where an MSc graduate is likely to land a job which is at a more theoretical level.

[691175002]

Most reputable Computer Science programs start in Scheme, a language that is never used (and will never be used) in the real world.  In fact, a computer science program that starts off in a "practical" language (Python, Java) is generally viewed with suspicion.

This is because new languages and technology incorporate layers and layers of abstraction which make it impossible to truly understand what is going on.  Unless you understand computers at their most basic level you will eventually be surprised, and your depth of knowledge will be unable to predict or explain the behaviors you observe.

I will say from experience that it is very easy to move "up" the chain of abstraction.  An experienced assembly, C++, and lisp programmer can learn any programming language in days, whereas someone who has only used Java/Python will not be able to move down the stack without intensive study.  This is because new technologies build on old ones, and wrap the underlying structure in more convenient abstractions.  If you know operations A, B and C, then you can recognize new feature D as A+B.  But if you just use D for everything, you won't understand the subtle edge cases of A+B or even know that C is possible.


There are several reasons why it is not useful to study new technology and languages.  Firstly, they change very quickly so intensively focusing on one toolchain is pointless.  Secondly, and more importantly, learning a new toolchain is very easy (and more or less mundane) if you have a strong understanding of the basics.

On the other hand there is definitely a disconnect between school and work.  Picking up new technologies is a very valuable skill in itself, so I think Dave's idea of having one class where you just screw around with current technology is a great idea.

[nctnico]

I will say from experience that it is very easy to move "up" the chain of abstraction.  An experienced assembly, C++, and lisp programmer can learn any programming language in days

This is because new technologies build on old ones, and wrap the underlying structure in more convenient abstractions.

Not in the modern world. Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting. The difference is like creating an opamp from discrete transistors versus using an opamp which comes as a chip in a package.

[Unordung]

In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.

What the hell is going on at those institutions?

Nothing.  They're turning out some of the best Z80 programmers of all time.  Of all time!

You sir win the internets! =D 

[NorthGuy]

Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

[tggzzz]

Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.

The documentation will, at best, indicate how to invoke the libraries, but they certainly won't tell you the limits of what you are asking the library to accomplish - and often won't indicate the "infelicities" in the implementation.

When, for example, did you see an RPC library that mentioned the Byzantine General's problem, or a distributed cache library that mentioned the Split Brain problem, or a distributed transaction library that mentioned that Two-phase Commits can silently fail? Or, at a lower level, a flip-flop datasheet that defines its metastability time constants?

[coppice]

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.

There are many many libraries where you have no need to understand what's going on under the hood, and most of those don't even come with documentation that indicates what might be happening under the hood. Graphics and other user interface toolkits come to mind. There are many other libraries where its vital to understand what is happening under the hood, and it is extensively documented. The major of DSP libraries are in this category.

[tggzzz]

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.

There are many many libraries where you have no need to understand what's going on under the hood, and most of those don't even come with documentation that indicates what might be happening under the hood. Graphics and other user interface toolkits come to mind. There are many other libraries where its vital to understand what is happening under the hood, and it is extensively documented. The major of DSP libraries are in this category.

And there are many many many libraries that don't fit into either of those categories. I noted an infinitesimal proportion of them in the examples you snipped.

Sorry, but that's the economics of the real world.

[NorthGuy]

Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.

Of course. However, the standard practice is to skip understanding and just use the library. This is one of the major mechanisms of bloat proliferation.

[rstofer]

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

Somehow, I think the user does need to know how the libraries work, and in great detail.  I seem to recall a Mars Lander crashing because of a mixup between units (Imperial vs Metric).  It's been a long time but I also remember discussions at an aerospace company about the accuracy of their numerical analysis library.  Something to do with not wanting the airplane to fall out of the sky.  There  were a bunch of math majors working on improving accuracy.

All algorithms trade off one thing for another.  If there were a perfect algorithm, the floating point library would still mess it up.  We all know that series expansions often require infinite terms and, since we don't have the time, we cut it short.  The question is, how much accuracy are we willing to give up.

[CatalinaWOW]

I will say from experience that it is very easy to move "up" the chain of abstraction.  An experienced assembly, C++, and lisp programmer can learn any programming language in days

This is because new technologies build on old ones, and wrap the underlying structure in more convenient abstractions.

Not in the modern world. Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting. The difference is like creating an opamp from discrete transistors versus using an opamp which comes as a chip in a package.

Your example proves 691175002 s point.  Those never having dealt with transistors (known what is inside the box) make many mistakes in the application of op-amps.  Those who do really do appreciate not having to go through the details of design and layout to make the op-amp - they buy the package and use it - appropriately.  And to push the analogy even further - a course or lab on OP AMP design based on a 741 op amp is totally appropriate - even though it was not just designed, but obsolete before most of the students were born.  And even though they are unlikely to actually use a 741 professionally.  The flaws that exist in all OP AMPs are readily apparent in the 741, and the students will be made aware of them, and their impact on system performance.  And then should be able to use a modern part and properly predict its performance in the application du jour.

[westfw]

Most reputable Computer Science programs start in Scheme...

I find that difficult to believe...   Got any references?
https://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-u-s-universities/fulltext
Scheme is 40+ years old and relatively LISP-based, isn't it?  LISP did achieve some commercial success...
It somewhat reminds me of my own Alma Mater, where they taught PL/1 (actually PL/C) to the CS majors, and then all the subsequent classes pretty much abandoned it for fortran, because PL/C didn't INTERFACE to anything, and only ran on one of the campus machines.   (I think; I was an EE major, so I pretty much cherry-picked CS classes.)

I will say from experience that it is very easy to move "up" the chain of abstraction.  An experienced assembly, C++, and lisp programmer can learn any programming language in days

Yeah, I can write Assembly and C-like programs in half-a-dozen more modern languages.  I don't consider that a particularly valuable skill. :-(  OTOH, many new graduates can't "code" at all, by industry standards.

On the third hand, "Computer Science" is DIFFERENT than "coding."  If you take, say, the online class from Princeton in "Data Structures and Algorithms", they use Java and it's beautifully abstract.  The language subset needed is pretty minimal, the libraries needed are minimal, and you can really focus on the algorithms themselves, even if you're not really much of a Java programmer.  (I highly recommend the class, BTW...)  And you can take other classes, and read papers, and find any number of instances where you look at it and say:  "Hah!  *THIS* is Computer Science!"  And while coding may be easier to "move up" the abstraction layers, the Science is easier to move down...
But most jobs and real-world problems are more in the realm of engineering or worse...

[Sal Ammoniac]

Most reputable Computer Science programs start in Scheme...

I find that difficult to believe...   Got any references?

"6.037 Structure and Interpretation of Computer Programs" at MIT still uses Scheme as its language.

[agehall]

Wow I never expected such a question to raise such robust debate among the community.

However I feel the need to clarify a few things.

Firstly coming here is step one in finding a solution to this "problem". We are students our perception is that this hardware isn't the best device to be teaching DSP on.

That is just BS tbh. You are in class to learn things. At this stage, you will have to accept that others know better than you and trust their judgement.

I had the similar objections when I was taking classes at the university about 20 years ago. Some of those classes are now the ones I value the most because the principles are still valid while some of the classes that used modern stuff (at the time) are 100% irrelevant.

That said we are basing that on our very limited experience in the industry. What better way to understand the "problem"  then by asking directly the experienced professionals in the industry?
In asking you guys I have somewhat came to realize that the "problem" isn't so much of a "problem" but rather a  matter of expectations. Evident by the division among the replies.

I've found that nothing beats actual *work*-experience. What you are working on in the class room will always be pretty far from what you encounter in real life anyhow. No matter what you are taught in school, you will have a rough time to break into the work force as you are competing with more experienced people. Your way around that is to work hard and make sure you show potential employers that you can apply your knowledge to new situations and that you are willing to do more than what is the bare minimum. (I.e. what I'm saying is, do extra curricular stuff.!)

As students we are wanting to get an education which will get us employed, we want to understand the fundamentals whilst also having relevant skills which prepare us for our chosen career in the industry. We expect to stand out in interviews as having the relevant skills and the experience which are required  by the companies looking for staff. If your company mainly uses ARM processors (which in our opinion most do) you will naturally gravitate toward an applicant with experience in ARM over this 20+ year old processor.
Whilst many of you guys seem to agree this this ideology many also don't.

Your education doesn't get you employed - you do! Don't expect a university degree to imply that you will be hired. You are making all the wrong assumptions here. Anyone who hires someone who just graduated will not expect a whole lot of experience, because that just isn't possible. Sure they advertise that they would like 10+ years of experience from a 20yo and all kinds of unrealistic requirements. But that just tells you that the ad is written by a complete idiot or that it is a fantasy. Don't judge based on that - apply and see where it takes you.

It is all well and good to say you need to simply understand the principles and I somewhat agree. However expecting your employer to fit the bill while you learn to use modern hardware seems to be somewhat counter productive. Whilst an employer couldn't logically expect a graduate "to hit the ground running" they should reasonably expect them to hit the ground jogging or at least power walking....

If you have a degree and you just graduated, any decent employer should know what to expect imho.

Secondly the course is the final semester of an Advanced Diploma, we are using this hardware along with a hardware circuit we "designed" (filter pro did all the work for us) to filter an input signal into the DSP do a Fourier Transform using the DSP then send it to an external DAC, and back through another filter. Photo of my hardware below. We have one class using matlab to teach the theory. This is the only hardware exposure to DSP until the bachelor / Associate degree next semester. However fo some students this will be the ONLY exposure to DSP hardware before trying to enter the industry.

Depending on your degree - it's still not bad. I worked on a MScE in Computer Science and we had a grand total of two courses where we touched hardware to build something. Situation was pretty much the same for the EE students. If you know the theory, doing the practical stuff isn't all that difficult.

With that all said I / we understand nothing is going to change for us, there wouldn't be time or resource to change the curriculum. However it can be changed in the near future for future student studying this course. The only question is SHOULD it be changed...

You still have not presented any good reasons for why it should change.

Universities like using old platforms for several reasons (and not only in EE). One of them being that it allows students to focus on the important bits of the class, rather than cool new features in the platform. All the toolchains for old platforms are normally more mature and it is easier to debug (especially when we are talking about hardware).

My advice - focus your energy on something that will make it worth your time, like a personal project that you can talk about when you go to your first job interview. That will probably impress the potential employer much more than any class you've taken.

[Ian.M]

Is there a FPGA soft-core available for that DSP family?   If the labs could be transitioned onto an affordable FPGA board without the head of Faculty having to lean on all his Professors and associates to write a whole new course, there's a bigger chance of getting something done.  If it can also emulate all (or most) of the other legacy processors on the syllabus, so they can reduce the number of hardware platforms they have to support, and get rid of ancient 'in-house' custom ones, so much the better.

I remember struggling with a vile 'in-house' Z80 based system that sat between a VT100 terminal and the serial cable back to the departmental mainframe, which hosted a crappy C cross-compiler and a cross-assembler that didn't even use standard Zilog syntax. It had two controls - a Load/Run switch and a Reset button (which usually crashed your session), and two LEDs, Power and Halt.   The only way the word 'stable' could be applied to it was if prefixed with 'Augean', as it had so much buffering and glue logic between the CPU and the external bus connector in an attempt to protect the reasonably affordable CPU from student dumb-f**kery that you *COULDN'T* actually guarantee to meet the timing specs for any external memory access.   The general student consensus was the Z80 boxes needed to be kicked off the roof of the department then given a Viking funeral on the lake.   The brighter members of the class worked around the problem - e.g. It was easier to get the required lab work done at home on my ZX Spectrum  (I had the Hisoft C compiler and Hisoft Devpack Assembler + debugger), and stream the listing output to my main computer (back then, not a PC), run it through a script that massaged it to match the horrible cross-assembler,  dump it to a IBM PC formatted disk, and upload it, the sources and the HEX file (in case I had to attempt to demonstrate it in the lab) to the mainframe from one of the departmental PCs that had a terminal emulator, all so I could print it to the line printer to get it on the music ruled fanfold paper they expected the lab work to be submitted on.  Oddly enough it was difficult to convince final year students to take on a project that included a Z80 . . . .

Later, I had a friend who was a transfer student so didn't have prior history with the Z80 boxes.  He got suckered into taking on a Z80 based project the head of Faculty had been pushing for a few years. I actually saved  his project by lending him my Speccy, which by then I had upgraded with Microdrives so I no longer had to compile or assemble from cassette tape and a Multiface cartridge to provide a NMI button and a resident debugger.  Even with that lot already hanging off the unbuffered Z80 bus + his hardware which had a direct bus interface to a HD44780 LCD display + a job lot of ADCs, DACs, timers etc. to implement a frequency response measurement system from DC to 1MHz, once it was all double-sided foam taped to a baseboard to avoid the infamous 'ZX RAM pack wobble' crashes, it was more stable than the departmental hardware by a couple of orders of magnitude and it was faster to develop on.  There was much egg on face from technical services when he successfully demonstrated it live to the head of department running on my Speccy, made a small change to the U.I. on the spot to answer criticism, and made the proposal that the next version be based on a Speccy with a custom ROM and a keyboard overlay! 

[nctnico]

Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.

That way you won't get very far because you'd need to learn&know way too much for a single person to handle (unless your software doesn't go beyond 'hello world' console applications). If you write decent size applications I'm quite sure there is depedance on a library for which you don't know what it does exactly.

[Ian.M]

*MOST* hardware manufacturer supplied libraries are like gilded turds.  There's a shiny but very thin wrapper round the reeking mess inside.  The newer the hardware the higher the probability that the turd is soft centred and will explode in your face.  If you cant get access to the library source then *AVOID* being a bleeding edge developer on that platform! Standard language libraries are a much better bet as at least they have been pounded on hard by hundreds of thousands or even millions of users and if only 0.1% have bothered to file bug reports, most of the danger areas will be fairly well mapped and the more egregious bugs will have been patched.

[tggzzz]

Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.

That way you won't get very far because you'd need to learn&know way too much for a single person to handle (unless your software doesn't go beyond 'hello world' console applications). If you write decent size applications I'm quite sure there is depedance on a library for which you don't know what it does exactly.

Some of my software has gone far beyond that. The key is that you don't need to know "exactly", but you do need to know where the fundamental pain points are likely to be.

It is horrifying how frequently simple questions about fundamentals reveal skeletons lurking in the closet. Often the underlying reason is the library implementer didn't realise there were fundamentals that they needed to account for, and just coded up the "happy daze" scenarios about how it is supposed to work. Those of us that have been around the block as professional engineers know it is equally important to understand how things can fail, and to deal with those use-cases.

[coppice]

Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.

Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.

There are many many libraries where you have no need to understand what's going on under the hood, and most of those don't even come with documentation that indicates what might be happening under the hood. Graphics and other user interface toolkits come to mind. There are many other libraries where its vital to understand what is happening under the hood, and it is extensively documented. The major of DSP libraries are in this category.

And there are many many many libraries that don't fit into either of those categories. I noted an infinitesimal proportion of them in the examples you snipped.

Sorry, but that's the economics of the real world.

I thought the stuff I snipped was examples of bad libraries with inadequate documentation. There sure are plenty of those.

[nctnico]

*MOST* hardware manufacturer supplied libraries are like gilded turds.  There's a shiny but very thin wrapper round the reeking mess inside.

I'm not writing about crappy microcontroller libraries to wiggle GPIO pins but libraries which come with an OS or a programming framework.

[coppice]

*MOST* hardware manufacturer supplied libraries are like gilded turds.  There's a shiny but very thin wrapper round the reeking mess inside.  The newer the hardware the higher the probability that the turd is soft centred and will explode in your face.  If you cant get access to the library source then *AVOID* being a bleeding edge developer on that platform! Standard language libraries are a much better bet as at least they have been pounded on hard by hundreds of thousands or even millions of users and if only 0.1% have bothered to file bug reports, most of the danger areas will be fairly well mapped and the more egregious bugs will have been patched.

There is a major psychological problem in the semiconductor industry, where most people in control are silicon people and most non-silicon people are looked down on. This is not a good environment for either systems design or software development. This tends to show in the lack of attention to detail in the systems design of silicon, and even more so in the quality of the accompanying software.