Engineering Students being taught DSP on 20 year old processors RMIT

[LabSpokane]

And before you go accusing the faculty of laziness, perhaps you should actually assemble a semester's worth of technical curriculum and teach it first.  It's harder than it sounds.  It is far better to recycle and refine a good curriculum and focus on student learning than to constantly be chasing the bleeding edge whatsit.

There should be a compulsory class called "dabbling with new shit" where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza.

Oh, yes!

Don't forget "fixing broken shit so it doesn't break again 254." 

And, "un-hosing the last engineer's undocumented spaghetti Fortran (or insert arcane language here) 309."

[Yansi]

B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?

Irrelevant. Modern HR machine hires by matching resumes. Resume doesn't say what processors were used by your teachers in your classes. And I don't think anyone would ask you that on the interview.

But resumes might say what you have experience with. And yes, I've been asked on my interview, what processors did I use previously.

[Kalvin]

Motorola DSP56800 is quite different from DSP56000 / DSP56300 series. DSP56800 is 16-bit device where DSP56K is 24-bit device. I haven't used DSP56800, but programming DSP56300 in assembly was very nice and smooth experience compared to TI's 16-bit processors.

http://www.nxp.com/docs/en/reference-manual/DSP56800FM.pdf
http://www.nxp.com/docs/en/reference-manual/DSP56300FM.pdf

Modern DSP architectures are typically heavily parallel and programming then manually by human in assembly is very hard in order to take full advantage the parallel execution units. That's why modern DSP processors are typically programmed in C/C++ as the compiler can optimize the code generation to take full advantage of the parallel execution units.

I would not consider ARM as a DSP although it does have some DSP instructions. For general a DSP course studying the general algorithms even ARM should be quite suitable, though.

[Kjelt]

It is an electronics study which probably explain the registers and all the inners of the DSP, so I need to look at the entire class material before I judge, but how can you explain the DSP instruction set without having the students directly use this instruction set?
Therefore I think some classes of assembly just to let the student get a feel of what is happening on a lower layer is productive but not for the entire class.
They should go to a c compiler after a few classes and move on.

Then another argument when I am debugging with a normal microcontroller I often look at the assembly the compiler generated, it will not be the first time that I see that some things are missing (optimizer just killed it) because of something I forgot (compilers are very good these days so I first look between the chair and the keyboard  )
For a DSP I think this is even more trivial that you should have a feeling of the assembly.

[DrGeoff]

Surprised they were not at least using the Sharc.
AD had some cool dev modules and tools when that came out and I've come across several designs using them (in audio anyway).

[tggzzz]

The education should teach you about fundamental principles that will last a lifetime not about specific tools which will be outdated in a few years. Isaac Asimov wrote a story about that 60 years ago, it stuck in my mind, and is still as relevant today. It is worth speed-reading http://www.abelard.org/asimov.php

When learning, you need simple tools that allow you to see the fundamental principles; it is all too easy to become bogged down in boring and irrelevant details. See stackexchange for examples of "which button do I press", or "how do I set the timer to  cause an interrupt" type questions.

Depressingly little has changed in 35 years, except things are smaller/cheaper/faster, nanopower is becoming practical, and ADCs/DACs are significantly improved. Coming back to doing embedded processing after 20 years, all the tools (MCU, C, in-circuit debuggers) were familiar. There is little sign that things will change radically in the next decade. Bonus points: understand what needs to change, and why, and the characteristics necessary in new approaches.

If you want to impress an employer, do a project on your own. That will demonstrate interest in the subject, drive, initiative, goal-setting, implementation and finishing, and that you have learned what you would do better next time.

[Kjelt]

The education should teach you about fundamental principles that will last a lifetime not about specific tools which will be outdated in a few years.

I agree 100% , but fundamental principles can be boring and out of touch with applications.
The problem with current generation students is that they would like a practical application of what they are learning and have a shorter attention span (yeah I know I am generalizing but google generation X, Y, Z and see I am not the only one).
So to get a students attention what is cooler than giving them the development board for home, be it a beaglebone, rasp pi , nucleo or whatever and learn them in class how to create some practical applications with them. They are more enthousiastic than a dinosaur board from 1990 that can't be bought and/or programmed these days.
However DSP boards are a bigger price and the applications are not very DIY friendly or you should be an audio freak.

So what probably happens on universities/colleges with older teachers is that they stick with what they know and have and do not invest themselves in new technologies and keeping up with developments.
That happened even when I was at college, we had to copy the book out of which he teached because there was a 3rd edition reprint out and 5 out of the 12 chapters dissappeared from the book and were replaced but the teacher refused to adapt the lessons and exams 

[Ice-Tea]

There's another reason why "we" sometimes teach with old methods/devices: modern stuff is too perfect. When you're teaching opamps, per example, you can set up an excercise that gives bad results due to offset limations. With an ancient device, it will kick you in the face, quickly and without exception. Better devices will have vastly improved specs and will be less educational.

[dmills]

I actually find a few obscure assemblers or odd DSP chips to at least make a CV interesting, C on small cores should be a given...

However my number one interview question is "What have you built?", I actually tend to care about this far more then the details of some chip you may or may not know, I mean you will spend you whole career learning new chips, new languages and new ways of doing things, that is a given in engineering and is largely what makes it so cool.
I want to see the lessons that only come with building things, steam train, computer, rocket or treehouse I don't much care what you have built, but show me a passion for designing and making things and tell me what you would do differently if making that thing again (If there was a team involved, even better).

Maths, at least to the point of recognising the methods (I assume you are actually going to use matlab in reality), electromagnetism, DSP in a sort of Z transform and numerical stability kind of way, computer architecture, communications, some analogue some semiconductor physics, all that stuff is important, but without the desire to make things it is a route into financial services, not engineering.

Regards, Dan.

[tggzzz]

A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?

Yes. The specific type of hardware is irrelevant. Even digital hardware is irrelevant, for than matter.

The first DSP filter I created commercially was made from capacitors and switches, and had a Q of 4000 using 10% capacitors.

B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?

Yes.

I would hire someone that understands DSP. If they know that then they are in a decent position to choose whether to implement a solution in digital hardware, analogue hardware, mainframes, MCUs, DSP processors.  Someone that only understands one technology is someone that will use a hammer to insert screws, because they have been taught how to use hammers.

C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?

In my case, after returning after 20 years, about 30 minutes. Depressinly little had changed. It took longer to decide on which tools to use and to install them.

D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?

Depends on the job. Nobody fresh from university will understand C++ (although they probably think they do).  Even the language designers didn't understand what they were creating when they implemented templates - until someone rubbed their faces in it! https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

And then, of course, there's always the issue of which C++; later versions begin to overcome some of the infelicities in earlier versions - but you may not be allowed to use later versions!

E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)

An average processor, using average tools, and average programmers (because they are easily replaceable by cheaper average programmers).

[coppice]

If the DSP56800 family is older than some of your classmates you must be among some pretty young students. If I remember rightly it only reached the market in about 1999 or 2000. Oddly, perhaps, this makes it one of the younger processor cores on the market. The 56800 is NOT the 56000, or the 56100, or the 56300, which are all very different machines. It is a 16 bit core designed to execute DSP code well, without sucking too badly for bits of general purpose code mixed in with your DSP code. It is wrapped in a peripheral set that makes it really good for control oriented processing, like motor control, or digital power supplies. Its kinda clunky for most general purpose DSP applications, as none of the parts in the family have the kind of peripheral set or DMA controllers you would associated with general purpose DSP work.

Is your course supposed to teach you signal processing, or the nature of signal processing hardware architectures? If you are on a comms oriented course the 56800 sounds like an odd choice for teaching you either. If you are learning signal processing, the best place is on your PC. If you are learning about architectures for DSP in comms, something with a more appropriate peripheral mix would seem a better choice. The 56800 core is fine, but you really want to a device with rich DMA features, to see how most DSP applications are structured for good performance. They should probably also include some material about where FPGA/ASIC or processor based solution are more appropriate.

If you are learning about hardware architectures for signal processing you should be doing some assembly language work. Not huge amounts, but you should be doing enough to gain an understanding of just WHY things are structured the way they are, and how fragile performance on some of the key kernels of signal processing algorithms can be if the instruction set isn't quite right. DSP architectures can have instructions with extremely specific uses, limited only one application level purpose, because that thing turns out to be so important for performance on many occasions. You should get some basic understanding of these things. Remember you are at a respectable university, not a trade school running short courses. You should expect to gain in depth knowledge of the fields you study.

[jancumps]

..... where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza.

that's my kitchen

[nctnico]

I am the Student Staff Consultative comity representative and have been asked by my Cohorts to raise this with the university.
We are wanting the class to teach ARM processors over this ancient tech.

No, you don't want to learn ARM for a DSP class. ARM is not a DSP.

The distinction between typical DSP CPUs and general purpose CPUs has faded away over a decade ago. Most ARM cores have DSP instructions. Besides you can use any CPU for signal processing. There is nothing special about it because in the end it comes down to doing things with incoming data. Nowadays it is much more relevant to learn how to write robust algorithms in C/C++ instead of assembler. Branch prediction and caching make writing fast assembly language much more difficult while OTOH C/C++ compilers know all about the core's branch prediction strategy. The influence of caching can be perfectly handled in C/C++ by writing loops in a different way. Nowadays it is way more important to create code which portable so new products can be build on the foundation of existing products (code). You can buy performance but you can't buy time!

The DSP the OP refers to has been obsolete for quite a while now. It reminds me of a true story from about 2 decades ago. I was attending a technical discussion with a firm to see if we could use their DSP algorithms. x86 processor where starting to get way more powerfull than a handfull of DSPs on a board so we wanted to use a x86 for signal processing. It turned out all their DSP algorithms where coded in Motorola assembly for that specific DSP and therefore they couldn't port the code. They'd have to start writing from scratch. Ofcourse that didn't suit our needs so we ended up writing our own algorithms in C/C++.

Back in the old days I've also written DSP software in assembly but the Harvard architecture just sucked. Using things like lookup tables required to copy the table into RAM first IF there was enough space to begin with.

[MT]

Something which has kind of irked myself and my fellow students is our perceived absurdity of our Digital signal processing micro apps class.
The instructor is having us program a Motorolla DSP56800 processor using assembly language. 

When i was in college we had to learn repair TV's made out of tubes despite tubes being obsolete in TV's
for 25 years we didnt even get TV's made out of transistors. WHY? Becuse our mentor in repair TV class
was 64 years old and was about retiring next year so he didnt give a damn about us or the future!

So i can actually repair TV's made outof tubes! (fanfare) not that i ever had any use of that knowledge
in comercial life but in hobby life to build tube compressors with triods and pentods it did a tiny bit.

Strangely enough in 2017 tubes are more popular then ever!

[rsjsouza]

I am the Student Staff Consultative comity representative and have been asked by my Cohorts to raise this with the university.
We are wanting the class to teach ARM processors over this ancient tech.

No, you don't want to learn ARM for a DSP class. ARM is not a DSP.

The distinction between typical DSP CPUs and general purpose CPUs has faded away over a decade ago. Most ARM cores have DSP instructions.

I disagree. Although the differences between these have been reduced over the years, Digital Signal Processors offer much more in terms of special addressing and hardware loops - I clarify further here.

Nowadays it is much more relevant to learn how to write robust algorithms in C/C++ instead of assembler.

Agree 100%. I used DSP56000 on my DSP labs in 1999 and it was somewhat outdated already - given the compiler was very weak, we did everything in assembly to benefit from the architecture intricacies. Nowadays the modern compilers relegate the usage of assembly to very niche applications - and certainly you would be hard pressed to justify presenting it throughout an entire semester.

Can anyone offer any advise on how I can demonstrate the above 5 criteria?
If you cant could you just answer the following few questions, it may be helpful to show the answers to the Dean and Program manager.
A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)

You need to go to them with a solution, not just a complaint.
Who will write the new course material for the new hardware? This alone could dictate everything. If some DSP manufacturer has DSP kit that targets courses with pre-prepared class material and project example, then there is your solution.

Agree 100%. The proposal must include a path for integration into the course. The choice of processor for a Digital Signal Processing labs class is something tricky, but this course was probably prepared twenty years ago and nobody took over to update it. Several much more modern architectures with dirt cheap DSP development boards such as the F28379D Launchpad, heaps of example codes and even entire training sessions have a much more practical use and will certainly give the students an edge when they leave for the marketplace.

Another that has an entire teaching class is the somewhat older C5000 family.

[Sal Ammoniac]

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

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

[ez24]

A lot of good advice here. 

One thing I learned was not to piss off the profs.  They have big egos.  I once complained about obsolete material and the prof said to take it up with the Dept Dean.  I asked who that was and he said he was  .  I knew I was in deep doo doo.  It turned out to be a hard course with him always calling on me.  The next semester the course was changed.

I think someone said to go to the dept with a solution along with your complaint.  Dave gave a couple of good sources for a school  (I am waiting for EEVBlog Univ).  My two cents are to go to the dept with that material and volunteer (along with some other students) to develop a course using this material.  Say you and the others are willing to be TAs for the new course.   Make it easy for the profs and school.  I think this would look good on your resume.  Who knows, maybe you will become a prof.

Keep in mind it is hard to train old dogs (your prof and me) new tricks.

Sometimes what someone writes brings back memories.  Someone said they learned Fortran on an IBM 370 using punch cards.  I also did.  What I remember is I forgot "end" at the end of the code.  When I started the program the guy running the 370 left the room.   I watch the print out go through about 2 feet of paper before he came back and yelled at me.  I used up all their paper and he closed the lab.  I had no clue what was going on 

[Ice-Tea]

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.

Here's the thing... Much of recent laws find their origin in Roman times. And a lot of others have been put forward to patch up deficiencies of those laws. So if you understand the olden, simple laws of yesteryear you'll understand much of the new ones and you may see why others, seemingly overly complex and without purpose came to be... 

[legacy]

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

Why are you so surprised and shocked?

DSP56000 is still used for Radar in avionics space and defense, and it comes with an excellent book targeting Motorola DSP56002, which has an interesting architecture as well as ISA!

In computer science it's also common to see courses based on 68HC11, as well as 68000, which are 38 years old at least!


You have to consider the complexity of modern staff, and you have to consider what really matters! Being focused on the iron? Or ... in getting the mind?

[Benta]

Vernichtung, I think you have the wrong expectations here.
First, as others have said, ARM is not a DSP. There are "DSP extensions", but it's still not a DSP.

Selecting the DSP56800 is not a bad choice for educational purposes. It has a general-purpose DSP architecture with all the elements for understanding what a DSP does: fast number crunching on real-time signals.
Sure, you can find newer devices, but they tend to add complexity not desirable for a basic course, like DMA etc.

Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.

Last, there is no real "industry-standard" for DSPs. Actually, most of the DSPs you won't even see, as they are often proprietary architectures deeply embedded in an SoC or loaded into an FPGA.
As an example, take the communication chips from Broadcom: they are shock-loaded with DSPs that do a fabulous job of filtering, demodulating, correlating, domain transforming etc., but you won't ever see them.

If you can put "Worked with and assembly-programmed DSPs used for ... " on your CV, you're in good shape.

"Worked with ARM" is a commodity today.

[nctnico]

Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.

That is another misconception. Who ever said signal processing needs to be fast and/or time critical? Like only signal processing can be time critical?

[Benta]

Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.

That is another misconception. Who ever said signal processing needs to be fast and/or time critical? Like only signal processing can be time critical?

Are you trolling? I never said that. But a reason for using a DSP is real-time signal processing. Otherwise, just GOTO any micro and a BASIC interpreter.

[KE5FX]

It is an electronics study which probably explain the registers and all the inners of the DSP, so I need to look at the entire class material before I judge, but how can you explain the DSP instruction set without having the students directly use this instruction set?

The "DSP instruction set" is pretty simple.  In fact, there are only two instructions, MUL and ADD. 

The rest -- all the rest -- is architecture and implementation.  Which are precisely the areas where it doesn't pay to fall 20 years behind.

[nctnico]

Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.

That is another misconception. Who ever said signal processing needs to be fast and/or time critical? Like only signal processing can be time critical?

Are you trolling? I never said that. But a reason for using a DSP is real-time signal processing. Otherwise, just GOTO any micro and a BASIC interpreter.

I just want to point out there is nothing magical or complex to signal processing. A lot of people seem to think digital signal processing ALWAYS needs special processors, FPGAs, assembly code, lots of complexity, etc. Nowadays you only need a DSP if you need to process lots of data very fast with a limited power budget. In opther words: nowadays DSPs only serve a niche market because PCs, microcontrollers and SoCs have lots of processing power.