FPGA Algorithms, what?

[steamedhams]

I had an interview of an entry level job yesterday and the interviewer asked me "what algorithms have you written?".

I am stilling thinking about that question.. we never focused on algorithms at uni, just basic vhdl bit manipulation, bin2grey..etc


(Just as a side note, the interview stopped abruptly after that question, they didn't even get to introductions or explain the company much.. i had to ask about it. They also called me an hour late..)

[ataradov]

It really depends on the company focus. Most of the things that could be considered "algorithms" for FPGAs would be in the area of DSP, so things like FFT, filtering, modems.

It is a somewhat strange question in general, but it may make more sense if you describe the type of the position.

[steamedhams]

http://nolam.com/ip-cores/

[AndyC_772]

I think it's a good question. An algorithm is just a way of accomplishing some useful task; it doesn't have to be listed in a chapter of some FPGA design manual entitled "Algorithms" in order to 'count'. The abilty to devise and implement an algorithm shows that you can look at a system, figure out the details of how to make it do something useful, and implement that method to make it work in practice.

It doesn't need to be complicated, nor does it need to be an implementation of some "standard" algorithm for solving some generic problem.

For example, a few years ago I did a project for a customer which involved a single master control device connected to a number of slaves on a common bus. In any given system, the master needs to know the number of slaves which are connected, and each slave needs a unique identifier so the master can communicate with it.

Rather than require each board to be individually programmed, I came up with a simple algorithm involving a sensor which was fitted to each slave PCB anyway. The method wasn't complicated, but it enabled each board to assign itself a unique ID, and the master ended up knowing exactly how many slaves were connected and what order they were in.

You can probably figure out for yourself how it worked; all you need to know is that every device on the bus receives everything that is transmitted by every other device. Provided you can trigger one sensor at a time, you have a way to make each slave unique.

IMHO describing a problem like this and how you chose to solve it is much more interesting than describing how you implemented, say, a fast or space efficient CRC.

[steamedhams]

I explained an algorithm I wrote to monitor dynamic power consumption. And some other smaller implementations.

Honestly, I think they were looking for specific things like protocols I've used and anything to do with HSSL.

I had a different experience with a company doing high speed transaction stuff. They really wanted search algos and things of that nature.
I'm going to start a list of a specific technology and what algos relate to that as often expect (for instance) that I know everything about CAN because I've worked with USB...
The wonderful world of job hunting...

Cheers

[tggzzz]

I explained an algorithm I wrote to monitor dynamic power consumption. And some other smaller implementations.

Honestly, I think they were looking for specific things like protocols I've used and anything to do with HSSL.

I had a different experience with a company doing high speed transaction stuff. They really wanted search algos and things of that nature.
I'm going to start a list of a specific technology and what algos relate to that as often expect (for instance) that I know everything about CAN because I've worked with USB...
The wonderful world of job hunting...

Cheers

If they were interested in specific technology, they should have asked about it. If not already knowing that technology locks you out of the job, then they probably should be looking at a short-term contractor rather than a permanent employee.

You can and should use your previous experience to demonstrate that you will learn new topics when appropriate - such as the particular technology relevant to them.

[sigma_xi]

I am stilling thinking about that question.. we never focused on algorithms at uni, just basic vhdl bit manipulation, bin2grey..etc

Interesting, it seems that other universities are just as bad when it comes to FPGA/Embedded System education as the one I went to. I can proudly say that I have been taught the syntax of at least 3 different modelling languages (Verilog, VHDL, SystemC, B-Method,...), but the most advanced project in terms of actual implementations was square root computation and a small ALU.

Regardless, as the others have pointed out, I too think that it is not as important to talk about actual implementations. I would most likely ask them to be more specific about the problems (like filtering or similar) and then you can start discussing methods to solve particular problems. If you know how to approach a certain task, it should not matter whether or not you have implemented it in the past, or that you are an expert in language X. 

[steamedhams]

Covered the exact same thing you did.

We also did a small FPGA project camera using a development board from Altera that didnt work well.
It was basically setting up IP blocks and then using different memory blocks to capture the incoming pixels.

I went to a Uni called Supelec which people said was good but after my time there.. I see things differently. But covid did make Uni pretty crappy at times... 

[NorthGuy]

http://nolam.com/ip-cores/

Look at this page. They have CAN, UART, even PWM (What kind of insane people will pay for PWM IP core?).

These are protocols, not algorithms. I guess that's what they meant. Perhaps they don't know the difference.

If you ever find a good job, the people who interview you will try to figure how you think, how you approach problems, can you be creative, persistent, responsible etc. If they focus mostly on your experience (what IPs, what languages) or credentials, the job is likely to be boring.

There are exceptions of course. Small startup leaders might not know what to ask, but working for them may be quite interesting.

[sigma_xi]

If you ever find a good job, the people who interview you will try to figure how you think, how you approach problems, can you be creative, persistent, responsible etc. If they focus mostly on your experience (what IPs, what languages) or credentials, the job is likely to be boring.

I agree.

[hamster_nz]

Just like to throw in CORDIC, which is an algorithm often used on FPGAs.

Are LFSRs an algorithm? I guess it depends on context they are used in....  Data scramblers, ECC codes, random bit generators, CRCs...

[steamedhams]

The company asked to meet again... 

[hamster_nz]

The company asked to meet again... 

You are awesome, but feel unsure of yourself because there is so much you know you don't know...

Maybe it is imposter syndrome in action?

Good luck!

[tggzzz]

The company asked to meet again... 

You are awesome, but feel unsure of yourself because there is so much you know you don't know...

Maybe it is imposter syndrome in action?

Never be afraid to say "I don't know" - provided you can also say "... but this is what looks like the core problem and this is how I would approach solving that problem. Sounds fun". If somebody is prepared to admit they don't know X, then I'm more likely to believe them when they say they do know Y.

Don't forget to imagine yourself in the job, imagine what you want/need to understand, and ask lots of questions to find the answers. One classic is to imagine you need equipment they don't possess: what is necessary for you to obtain it?

[Mario87]

You are awesome, but feel unsure of yourself because there is so much you know you don't know...

Maybe it is imposter syndrome in action?

Good luck!

I know this all too well! Always thinking "I don't know XYZ so I don't think I'll be good as this job", even when the manager thinks I can do it. The put me into it, feel totally out of my depth for a bit, then I start getting into it, seeing things that are familiar, reading up on unfamiliar things or asking questions and by the time a few months has passed I'm deemed one of the most useful people in the team!

However, I do also always say "if it's meant to be, it will be". So if a job is for me, then come hell or high water it's going to happen.

For the OP - always believe in yourself, as said above, be honest if you don't know something, but also explain how you would attempt to find a solution as it shows you are not the type who just says "I don't know, can someone else do this for me", my experience has shown there are lots of people like that in companies and the thing which has always helped me and set me apart (which the managers always pick up on) is if there is a problem, I will get to the bottom of it no matter what, even if it takes time and I need to ask others for advice or go and read about it.

Then next time you have the problem you know exactly what to do and you just keep building your knowledge like that.

However, sometimes I do still think that even though I am good at my job and I know it, in an interview situation when asked and awkward question I may really struggle with it. Not everyone is great at interviews, but a good manager will usually pick up on what you can bring to the table despite not acing an interview, and honestly those are the best managers to work for in my opinion.

[steamedhams]

Here is some general information if anyone out there cares to hear:

So I went to the technical interview. They said it was an American style interview, whatever that means. I had a pretty bad vibe from the place.
Anyways, the guy gave me a piece of paper and said design a system using fsm/pseudo-code to handle uart (parity bit, start bit, stop bit, sampling speed)

I thought it was a good task. I did not really prepare at all for the interview but I was able to answer.
I was using it as practice for jobs I am more interested in.

One thing I took away from the interview and all of the processes I have to go through now:
- brush up on all the basics.
- it saves more time to just create some hobby projects, a git, reports, articles and make it accessible instead of applying to every company.. you do the test.. practice for interviews...
- if you get test anxiety like me, bring hobby projects into the test because some managers will prefer seeing a board than you completing a test.
- you can also say you don't want tests, you would prefer show you a project... they just want to see you know something, make it easy for them.
- if you don't like the team, don't take the job unless you can see it get better... 

[SiliconWizard]

I had an interview of an entry level job yesterday and the interviewer asked me "what algorithms have you written?".

I am stilling thinking about that question.. we never focused on algorithms at uni, just basic vhdl bit manipulation, bin2grey..etc

But, are you sure the interviewer was specifically thinking of FPGAs (and more generally speaking, digital design) when asking this question?
They may just have wanted to figure out if you were at all familiar with algorithmics, which could be a required skill for the job.

Note that you can of course implement "algorithms" on FPGAs, even if what you tend to think about first when hearing this word is "software".

Not knowing much about your studies, the company your interviewed for or the exact content of the interview, it's hard to give more comments. But I'll just say that if you're a fresh engineer (I'm assuming EE engineer here from what you briefly said?), I find it odd that you wouldn't be familiar with algorithmics, at least the basics. Or is it just that you failed, on the moment, to see the link with FPGAs? (In which case, I guess you haven't given HDL development a lot of thought before... which could very well be the point the interviewer wanted to figure out here.)

[SiliconWizard]

Just like to throw in CORDIC, which is an algorithm often used on FPGAs.

Are LFSRs an algorithm? I guess it depends on context they are used in....  Data scramblers, ECC codes, random bit generators, CRCs...

Of course. The very general definition of an algorithm is a defined sequence of steps. Now of course some could nitpick or debate definitions to no end.
But as long as a given operation requires several steps which each can depend on the previous ones, then, IMHO, it's an algorithm.

[SiliconWizard]

The company asked to meet again... 

Note that, if the company has an "american style" for interviews as you mentioned, this does not surprise me.

I've found it common with the american approach that interviews would cover a lot of questions, some being of course go/nogo questions, but a lot of others being just there to figure you out. That just helps them see what your strong and weak points are, how you react to situations when you *don't know* something. They don't expect you to be able to answer precisely everything they ask. So sometimes you just feel like you failed the interview, whereas it's not the case. All the questions, even those you seem to have failed, will more or less help them see which of the open positions would be best for you, what would be your strong points and those you'll need to work on, etc. That also means, sometimes they'll offer you a position in the company that is not exactly the one you applied for.

[radiolistener]

most of all they wanted to know how deep is your experience with HDL code.

Most of all they wanted to hear algorithms which is very often used on HDL code, such as DSP (NCO, CIC, FIR, FFT) or some generic algorithms like LFSR, CRC or cryptographic stuff like hashing MD5, SHA or DES, AES, etc.

I think exact algorithm doesn't matter, they just wanted to know if you have done some algorithms in the past to estimate your level. If you have done something, they will ask how you done it, which problems you fight with and how you solved them. It will help to estimate your skills in problem solving.