Engineering Students being taught DSP on 20 year old processors RMIT

[IanB]

Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum?  Do I want them to climb that learning curve on my payroll?

I suggest you have no choice. Pretty much anyone can learn the basics of IEEE 754 float representations in short order. On the other hand, it probably takes years of practical experience to learn all the pitfalls of floating point arithmetic and how to avoid them.

On the theme of previous comments, isn't it better that students have formed a general understanding of how to represent floating point numbers on a binary machine and how to do computations with them, and perhaps when it might be better not to use floating point?

[westfw]

The instructor is having us program a Motorolla DSP56800 processor using assembly language

A look at NXP and Digikey shows that the DSP56f8xx and MC56F8xx (based on the same architecture) are alive and apparently well, with relatively modern variants aimed at the current crop of "embedded DSP" applications (motor control, SMPS management, etc.)

So aside from all the other arguments, it might not be as bad a choice as you think, depending on which chips you're actually targeting.

[rsjsouza]

It sounds like if you are presented with two hypothetical candidates:

• has used an A9 ARM
• knows when to choose an IIR or FIR and how to determine the precision required in the intermediate calculations

then you would choose the former.

I wouldn't; none of the companies I've worked for would have either.

First, I don't believe anyone has argued in favor of not teaching students about filters and bit growth.  This goes beyond failing to answer the question the OP asked, and into the category of making stuff up at random to bolster a weak argument.

Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum?  Do I want them to climb that learning curve on my payroll?

They way I see it, the choice would be:

• Has used a C6000, SHARC, whatever and has seen an IIR/FIR filter C implementation in one of the vendor's toolchains; may know all its intrinsics and quirks or use a vendor library; may not know other vendors' toolchain intrinsics, quirks and libraries; may know little to nothing on how to make such filter in assembly and its architecture pitfalls of signal extension, addressing modes, etc.
• Has used a 56k, a C30, whatever and knows how to make an IIR/FIR filter in assembly taking into account its register allocation, signal extension and addressing modes; may know little to nothing on how to implement such filter in C;
• Has used a general purpose processor (ARM, x86) in the role of Digital Signal Processing and has seen an IIR/FIR filter C implementation in one of the vendor's toolchains; may or may not know anything about intrinsics; may leave university believing DSPs are a thing of the past and have no place in today's world... 

[NorthGuy]

Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum?  Do I want them to climb that learning curve on my payroll?

Hopefully he will learn floats on some other course.

Most of the DSP operations (FFT, FIR, IIR etc.) do not need floats. Meddling with about any DSP (no matter how old) even for a short time will reveal this. And this is one of the things which is worth learning about DSPs.

[Vernichtung]

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

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

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.

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...
       
I am thoroughly thankful for everyone's replies, whilst it has somewhat  made the issue even more unclear it is great to hear from people in the industry and their opinions on the topic.

[IanB]

I will re-quote vealmike from above, because what he said resonated exactly with my experience.

To stand out as an interview candidate requires a demonstration of an enthusiasm, interest and aptitude for engineering. It is the eagerness to learn, structured, rigorous thinking, analytical and problem solving skills that make you good at your job.

If you have those skills and you are interviewing at a company that doesn't seem to value them, you should consider whether you really would want to work there. It is the possession of those attributes in an environment where they are valued and encouraged that can really make work rewarding.

As (until quite recently) the guy sitting next to the hiring manager asking the technical questions, I couldn't disagree more.
These are graduates, not battle hardened engineers. I do not expect them to hit the ground running. I do not expect that their tool chain or processor specific experience will be relevant  to me anyway.

What I do expect is a good understanding of the principles. I want them to know how the hardware does what it does. I want them to know how to approach problem solving.

But most importantly, I want them to have an aptitude and a thirst for engineering. A graduate engineer has a box of tools, but lacks the experience to apply them in a work environment. When they join the team they have to be taught. The more eager they are to learn, the better.

Technologies come and go. I couldn't give a flying poop what processor was learnt at Uni, it will be outmoded in seven years anyway. What's important is the principles.

It is far more important for a grad to have the correct attitude and enthusiasm than experience of the right toolchain.

[hamster_nz]

Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum?  Do I want them to climb that learning curve on my payroll?

Just in case it ever helps, have them read these two papers on their coffee breaks:

What Every Programmer Should Know About Floating-Point Arithmetic:  http://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf

What Every Computer Scientist Should Know About Floating-Point Arithmetic:
http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf

[vealmike]

I interviewed a guy around six years ago. A Masters graduate in microelectronics from one of the UKs most reliable universities (with a first in electronics at bachelors level). The job was some design, mainly debug of new designs.
He was OK, had worked on relevant hardware. Was clearly not that interested in electronics outside of the fact that it paid his bills.

Then I asked about buck converters. They are as common as muck in the micro world, a decent knowledge of power distribution is a must have. So I asked him to draw a buck converter, he couldn't. So I drew one on the whiteboard and asked him to explain it's operation, he couldn't.

In the end we'd boiled down to a capacitor driven by a constant current source, the guy was asked to show how the capacitor voltage varied over time. No scale on the graph, no tricks. He still couldn't do it.

I gave plenty of encouragement, explaining where he didn't know and praising where he did. I'd been doing my best to make the guy comfortable, asking easy questions. It could have just been brain freeze, but this is SO fundamental that it was inexcusable.

My point, well the guy failed the interview on two counts. Firstly because electronics was just a job to him. Actually at the level he was being brought in to do, I was OK with that. I don't think he was going to be a driven enthusiastic self learner, but if he was a competent 9 to 5er then that's fine. I'd have preferred someone whose job was their passion, but they can be hard to find.

What he really failed for was having built his knowledge on sand. Whilst he did have relevant experience on our architecture, he didn't have the underpinning fundamentals at his fingertips.

If, on the off chance the interview candidate reads this, he will no doubt recognise the scenario. I don't exactly obfusticate my name much! To to that candidate: I'm sorry. I gave you every opportunity I could and I tried to let you shine. Perhaps I misjudged you, but I had to do so on your interview performance.

I'll let y'all ponder the moral of the story.

[Ice-Tea]

...whilst it has somewhat  made the issue even more unclear...

It didn't. The fact that there's 4 pages of discussion means that at least the assumption that "Old crap. Bad Teacher" is much too binary (pun intended) a conclusion.

[tggzzz]

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.

Specific technology has a half life of a few years at most before it is outdated. What you use on one project will be out of date on the project after next, or probably irrelevant if you change employer.

Corollary: the most important skills you need are to know how to learn new technology, and how to choose which new technology to ignore (because it is merely a variant of something you already know) -- and what hasn't changed no matter which specific piece of technology you happen to be using at the moment.

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

You are describing what a company wants from an experienced contractor or a technician, not what they expect from a new graduate employee nor an engineer.

Learn the fundamentals on any processor. Demonstrate your interest and initiative to potential employers by transferring that knowledge to an implementation on a £5 ARM board you have bought and used on your own time. That will get you an interview and you can discuss the relative merits during the interview.

[coppice]

The instructor is having us program a Motorolla DSP56800 processor using assembly language

A look at NXP and Digikey shows that the DSP56f8xx and MC56F8xx (based on the same architecture) are alive and apparently well, with relatively modern variants aimed at the current crop of "embedded DSP" applications (motor control, SMPS management, etc.)

So aside from all the other arguments, it might not be as bad a choice as you think, depending on which chips you're actually targeting.

While this is true, it doesn't make for the kind of uninformed meaningless rants so much loved in this forum. Best ignore reality, eh?

[coppice]

Specific technology has a half life of a few years at most before it is outdated. What you use on one project will be out of date on the project after next, or probably irrelevant if you change employer.

More specifically, a good deal of what seems like hot topics in the first year of a 4 year degree course will be old hat in your first year of employment. Stick to strategic knowledge until near the end of your course, and try to pick up some relevant tactical knowledge near the end. That way, you'll have a reasonable balance between the two, and the tactical knowledge you get will be fresher and more relevant.

One of the big shifts I see in graduates now versus 40 years ago, when I graduated, is a huge increase in the tactical knowledge most people leave college with, and a commensurate drop in strategic knowledge. Its easy to see why. Debt based education makes people so focussed on that first job, and starting to cope with that debt, that it blinds them to the need to get a solid basis for a long career from their studies. Debt based education is going to prove very destructive to economies in the longer term.

[CatalinaWOW]

I will add that while I thought university was kind of intense, it was nothing like real world employment.  I learned more in the first six months on the job than I had at school.  And continued to learn at a significant rate for the rest of my career.

New technologies, new components, new toolchains, new manufacturing processes, new applications, all of the peripheral things to engineering (marketing, finance, warranty, HR, legal .....).  And in many cases, having to do the archaeology to do something with an obsolete architecture.

[NorthGuy]

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

Test this. Do the same project, but with what you perceive is the modern technology. Then compare the two and analyze differences. If you can do it, then they tought you well. If you cannot, you will have to fill in the blanks by yourself.

If the idea of doing the new project doesn't sound appealing, think about other things. You're about to start a career where you will do this stuff 8 hours a day (or may be 10, even 12 if the company pushes harder than you can resist). Given that you spend 8 hours every day sleeping, the time you spend at work is the vast majority of your life. If doing a small project doesn't sound exciting then do you really want to spend all your life doing this?

[tszaboo]

It was easy for me. When I did BSC EE, we learned 8051.
Down to the opcode. We were given hex code, state of the registers, and a printed reference manual, what does this program do? Real hardcore stuff. And digital logic meant connecting AND gates together, and doing Karnaugh maps.

And afterwards, as a MSC EE, when you already choose specialization, you got the recent stuff. I had Embedded Systems, so I studied the latest ARM they could get their hands on. And FPGAs.

Bear in mind, that we did not have the completely useless "Industrial engineer" BSC ( not even jack of all trades).

If you only learn the best and newest stuff, you never became a good engineer. Why? Because the reference manual for a Cortex M3 is 1000 pages. You will never read it. For the 8051 it was some 60-100 pages. We went through everything. We learned how to understand this stuff. Not just the good pieces, the boring pieces also.
We made segmentation faults by hand, and optimized code for BCD computation. It was a lot of fun. But not for the ARM. Nobody does that. We wrote code in C, and we only looked the ASM code just to compare it with something.

If you only learn how to do X on Y, then you are a code monkey, not an engineer.

[Z80]

If you are being taught DSP principles then the hardware you do your labs on really doesn't matter that much.  You can implement an FFT on a dedicated DSP chip or a PC or an old Commodore 64, as long as you understand the algorithm and the underlying DFT that's what matters.  As to your future employers training you, well any IT employer that doesn't keep it's engineers trained and up to date will quickly fall behind and get swept away by those that do.

[Kalvin]

Just attend the class and use the given processor. Buy a cheap $25 ARM STM32F4-based discovery kit and implement the algorithms and exercises in C using fixed point and floating point. You will learn quite a lot and you will learn the ARM as a byproduct.

[MT]

If you only learn the best and newest stuff, you never became a good engineer. Why? Because the reference manual for a Cortex M3 is 1000 pages. You will never read it.  If you only learn how to do X on Y, then you are a code monkey, not an engineer.

H7 ref manual is 3180 pages half of it is sentence building faults, incomplete function descriptions, wrong function description, French/Italian thinking to English translation gobbedoboodido which for a coding monkey, engineer as well as a unistudent easily fit under the label of  "dabbling with new evil shit" where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza and accompanying truck load of black fizzy drink delivered in aluminium cans wondering why just "they" have been punished by dealing with this evil new shit made by other E-engineers at ST who all once upona time was unistudents too!

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.

At the end of the day its not about getting employed and having a career its about execute whatever your managment tell you to as an employee. If they ask(not even ask, just hint) you to implement DSP in such a way that regulations and laws can be circumvented YOU BETTER DO SO else "your fired" (Trumpism). No education or work merits in the world can stand a battle against the ego of a narcissistic management.

https://www.nytimes.com/2017/08/25/business/volkswagen-engineer-prison-diesel-cheating.html
https://www.nytimes.com/2017/05/17/business/volkswagen-muller-diesel-emissions.html

[tggzzz]

If you only learn how to do X on Y, then you are a code monkey, not an engineer.

Blunt, but there's a lot of validity in that.

There's nothing wrong with being a "code-monkey"; they are very useful within their limits. What is irritating is when code-monkeys refuse to accept their limitations and refuse to accept that engineers have different valuable skills. Ditto engineers w.r.t code-monkeys' skills.

The OP might care to think about what they want in their career. If they don't yet know (which is probable), then it is wise to avoid closing doors that don't need to be closed.

Do the class, get good marks, do a home-project which replicates the work on an ARM, work out the relative advantages/disadvantages and why they are that way. Companies and interviewers will appreciate that.

[vodka]

First, I don't believe anyone has argued in favor of not teaching students about filters and bit growth.  This goes beyond failing to answer the question the OP asked, and into the category of making stuff up at random to bolster a weak argument.
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum?  Do I want them to climb that learning curve on my payroll?

I don't think even many DSP major graduate students understand limitations and funny effects of IEEE754. This is a typical capability that can only be learned the hard way, in an actual project, after getting bitten.
Nowadays DSP major in universities are more focusing on communication algorithms and CS-CE-ST (math&stat) collaboration research (deep learning on image processing, etc.), no one is interested in diving deep down to the root of the underlying computation implementation.

It's amazing to see how narrow the view is for some students. I'm from a power electronics background, and I'm amazed by seeing so many power electronics graduate students that can talk control and modelling all day long but don't know how to drive a MOSFET properly.
I've also seen quite a few people enrolling PMIC course don't know how to design a flip flop nor how to Google that. I've seen people working with Virtuoso for multiple courses while not knowing any Linux commands other than those required to start Virtuoso.

The list goes on, and my point is university, even graduate education, doesn't give you much knowledge. What you get is vision and fundamental thing, then it's all up to you to fill in the blank.

So , i don't strange. My exdirector of the Engeneering School told us  on a lecture ,that the Lear Corporation Engineer Staff had hit a great quarrel to him, due to a scholarship holder didn't know calculate and  neither resize a thermal sink for  a  Power Electronics gear.

[tggzzz]

First, I don't believe anyone has argued in favor of not teaching students about filters and bit growth.  This goes beyond failing to answer the question the OP asked, and into the category of making stuff up at random to bolster a weak argument.
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum?  Do I want them to climb that learning curve on my payroll?

I don't think even many DSP major graduate students understand limitations and funny effects of IEEE754. This is a typical capability that can only be learned the hard way, in an actual project, after getting bitten.
Nowadays DSP major in universities are more focusing on communication algorithms and CS-CE-ST (math&stat) collaboration research (deep learning on image processing, etc.), no one is interested in diving deep down to the root of the underlying computation implementation.

It's amazing to see how narrow the view is for some students. I'm from a power electronics background, and I'm amazed by seeing so many power electronics graduate students that can talk control and modelling all day long but don't know how to drive a MOSFET properly.
I've also seen quite a few people enrolling PMIC course don't know how to design a flip flop nor how to Google that. I've seen people working with Virtuoso for multiple courses while not knowing any Linux commands other than those required to start Virtuoso.

The list goes on, and my point is university, even graduate education, doesn't give you much knowledge. What you get is vision and fundamental thing, then it's all up to you to fill in the blank.

So , i don't strange. My exdirector of the Engeneering School told us  on a lecture ,that the Lear Corporation Engineer Staff had hit a great quarrel to him, due to a scholarship holder didn't know calculate and  neither resize a thermal sink for  a  Power Electronics gear.

Well, depending on cost-sensitivity how close to the limit you are operating the components, that could be a very involved problem requiring skill in unfamiliar topics such as thermal FEM.

If that wasn't the case then an appropriate response would have been "I haven't done that before, but this is how I'll set about learning the topic...".

[JohnG]

Then I asked about buck converters. They are as common as muck in the micro world, a decent knowledge of power distribution is a must have. So I asked him to draw a buck converter, he couldn't. So I drew one on the whiteboard and asked him to explain it's operation, he couldn't.

In the end we'd boiled down to a capacitor driven by a constant current source, the guy was asked to show how the capacitor voltage varied over time. No scale on the graph, no tricks. He still couldn't do it.

I gave plenty of encouragement, explaining where he didn't know and praising where he did. I'd been doing my best to make the guy comfortable, asking easy questions. It could have just been brain freeze, but this is SO fundamental that it was inexcusable.

Believe it or not, I once interviewed a Ph.D. candidate in power electronics for an industrial R&D job who also could not explain how a buck converter worked. I am not making this up.

By the same token, I was once interviewed for a power electronics position. I was asked a question about thermal management in a certain real-world scenario where the temperatures were dominated by the heat capacity of the system, but the interviewer did not like my answer. I heard later through alternate channels that the interviewer did believe that such a thing could exist, so he gave me a thumbs-down. I was glad I did not get the job.

John

[Sal Ammoniac]

Believe it or not, I once interviewed a Ph.D. candidate in power electronics for an industrial R&D job who also could not explain how a buck converter worked. I am not making this up.

I find that very believable. 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.

[janoc]

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.

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.

In fact, many universities expressly teach programming with obscure languages (Scheme, Logo, Occam, Trilogy ...) that the student likely will never see again - it is done so that they can focus on teaching the concepts without the distraction of the technology and also to level the playing field in the class. There are few things more distracting than a smart-ass thinking they know what you are trying to teach already and are disturbing the entire class.

If you want to learn to use a new whizbang tool X, take an elective course (if it is offered) or pay for a vendor training afterwards. Or simply get the materials and start learning yourself. You will need to do that later in your career anyway, university is there only to get the student started.

From the point of view of the hiring manager there would be exactly zero difference whether the fresh grad used a gizmo X during the studies already or learned it themselves after school - in both cases they have zero real-world experience with it and would likely need to be trained first anyway. It is more important whether or not they have the foundations in place. Of course, that assumes an HR more competent than a trained monkey that only compares keywords on the CV.

[hamster_nz]

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?