Getting in to the industry

[James823]

Hi,
I'm new to FPGAs but would like to get into the industry. Aside fro
building and playing around with toy projects, what can I do to help put m
ahead of the other EE graduates?
What kind of projects could be attempted with a starter kit that would pu
hairs on my chest so to speak?

Thanks
James



---------------------------------------
Posted through http://www.FPGARelated.com

 

[rickman]

On 9/23/2012 2:03 PM, James823 wrote:

Hi,
I'm new to FPGAs but would like to get into the industry. Aside from
building and playing around with toy projects, what can I do to help put me
ahead of the other EE graduates?
What kind of projects could be attempted with a starter kit that would put
hairs on my chest so to speak?

Thanks
James

There are a lot of industry sectors that use FPGAs. You would do well
to learn specifics about designs in sectors you are interested in
working. For example, a lot of DOD folks do digital receiver designs.
So if you want to work in DOD learning something about digital receivers
would serve you well.

Likewise there are key areas in each sector, so first figure out who you
want to work for and then go for the in depth learning of their needs.
This goes for all aspects of the job too. Before you interview with a
company, learn as much as you can about the company and the job.

Rick

 

[Rob Gaddi]

On Sun, 23 Sep 2012 13:03:27 -0500
"James823" <3681@embeddedrelated> wrote:

Hi,
I'm new to FPGAs but would like to get into the industry. Aside from
building and playing around with toy projects, what can I do to help put me
ahead of the other EE graduates?
What kind of projects could be attempted with a starter kit that would put
hairs on my chest so to speak?

Thanks
James



---------------------------------------
Posted through http://www.FPGARelated.com

The toy projects have value as well. The tools all have enough
"personality" to them that simply having bulled your way through them
in order to make anything work is a non-trivial achievement.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[hamilton]

On 9/25/2012 9:04 AM, jonesandy@comcast.net wrote:

Having worked with many impressive college new-hire FPGA developers during my career, their main shortcoming is a lack of understanding how the development process scales up from projects that a single designer or small team can execute in a few weeks, to larger projects that require many developers (and even more verification engineers) several months to complete a single generation of a progression of products.

They often do not yet understand the value of well-defined requirements (especially verifiable ones), and want to rush into coding before the overall design is far enough along.

Professional projects often involve multiple generations of a product, each one incrementally improving upon the previous one. This places extreme importance on planning, designing and coding for maintainability. It's not just about how few gates can run how fast.

Tools and techniques that are not often used in college projects include scripting everything so that results can be reliably repeated (by you and others), as well as employing version control and change management (issue tracking) tools.

In short, many new-hire (and a few experienced) FPGA developers lack the software engineering expertise to successfully execute larger scale projects in industry. Luckily, most firms have experienced lead engineers to help get talented but inexperienced new-hires up to speed.

So, how can you prepare yourself?

This is but one industry requirement.

Most companies are small 2-3 man operations that require "Get it done,
NOW" day to day functions.

I have worked for large companies that required lots of people and lots
of documentation.

Most companies I have consulted for were looking for a lone gun to "Get
it done. NOW".

College courses are like small companies, needs to get it done before
the end of the semester.

Take a project, it does not have to be that large or complex, and write a development plan for it, including more than one version or generation of the product. Include a summary schedule in your plan.

Write the requirements for the product as if you were not going to be the one developing (or verifying) it. Include a matrix that identifies which generations of the product have to meet which requirements. Do not write requirements that prescribe how the product will do something; instead write requirements for what the product must do, with observable criteria.

Write a verification plan (again, as if you were not going to be the one verifying it) with a matrix that shows how each requirement is going to be verified (simulation, analysis, test, inspection, etc.)

Write an Interface Control Document that defines the external interfaces. This document should be heavily referenced by the design requirements.

Write a design document describing the module hierarchy and interfaces between them (this will be the basis for the coding phase); this is where you start describing the "how" you should have left out of the requirements. For each module, summarize what the module needs to do; focus on the interfaces, and only enough internal detail such that coding decisions do not impact the interfaces.

Write a verification design document (similar to the design document, covering the verification models, tests, etc.) Make sure your verification does not include inspecting waveforms to see if a test passed, or comparing against a set of "golden waveforms". All simulations should indicate in a log file whether or not each test passed.

Then, and only then, start coding your design. Start coding your simulation environment. Then start testing your design (per your verification plan). Synthesize, place and route your design and verify timing and utilization requirements.

When you are finished with the first generation of all of the above, write a design analysis report, summarizing and referencing the evidence from verification (simulation and analysis) that all of your requirements have been satisfied. Every item in the verification matrix above should be covered in the verification report.

Rinse and repeat for successive generations of the product.

Throughout all of the above, employ version control on all code, scripts and documents. Emply issue-tracking tools to manage resolution of all defects found during verification, including necessary changes to documents, scripts, RTL and testbench code. This may seem like overkill for a one-man project. But you most likely will not be working professionally on one-man projects.

At the end of the project, write a project report. Include schedule performance (be honest!), and include "executive summaries" of the design analysis report(s), issue tracking metrics (especially graphs over time showing open and closed defects

Your probably thinking; "Wow, that's a lot of writing and not a lot of coding!" Your right, designing (especially with large projects) is about a lot more than coding.

Naturally, to complete all of this in a reasonable time, the product itself will probably have to be pretty small/simple. But going through the process, and being able to talk about it with with a prospective employer during an interview, will impress a prosepective employer. By demonstrating that you have thought and planned all of this out, and then executed it, you will be demonstrating to your prospective employer that you have at least an bit of an understanding of what it takes to develop FPGAs professionally. Keep in mind that your prospective employer will likely have their own process, tools, documentation standards, etc. (i.e. their own process standards) that may not match yours that closely, but the basic elements will be pretty similar, and your mastery of your own well thought out process will prepare you to master theirs.

Andy

 

Having worked with many impressive college new-hire FPGA developers during my career, their main shortcoming is a lack of understanding how the development process scales up from projects that a single designer or small team can execute in a few weeks, to larger projects that require many developers (and even more verification engineers) several months to complete a single generation of a progression of products.

They often do not yet understand the value of well-defined requirements (especially verifiable ones), and want to rush into coding before the overall design is far enough along.

Professional projects often involve multiple generations of a product, each one incrementally improving upon the previous one. This places extreme importance on planning, designing and coding for maintainability. It's not just about how few gates can run how fast.

Tools and techniques that are not often used in college projects include scripting everything so that results can be reliably repeated (by you and others), as well as employing version control and change management (issue tracking) tools.

In short, many new-hire (and a few experienced) FPGA developers lack the software engineering expertise to successfully execute larger scale projects in industry. Luckily, most firms have experienced lead engineers to help get talented but inexperienced new-hires up to speed.

So, how can you prepare yourself?

Take a project, it does not have to be that large or complex, and write a development plan for it, including more than one version or generation of the product. Include a summary schedule in your plan.

Write the requirements for the product as if you were not going to be the one developing (or verifying) it. Include a matrix that identifies which generations of the product have to meet which requirements. Do not write requirements that prescribe how the product will do something; instead write requirements for what the product must do, with observable criteria.

Write a verification plan (again, as if you were not going to be the one verifying it) with a matrix that shows how each requirement is going to be verified (simulation, analysis, test, inspection, etc.)

Write an Interface Control Document that defines the external interfaces. This document should be heavily referenced by the design requirements.

Write a design document describing the module hierarchy and interfaces between them (this will be the basis for the coding phase); this is where you start describing the "how" you should have left out of the requirements. For each module, summarize what the module needs to do; focus on the interfaces, and only enough internal detail such that coding decisions do not impact the interfaces.

Write a verification design document (similar to the design document, covering the verification models, tests, etc.) Make sure your verification does not include inspecting waveforms to see if a test passed, or comparing against a set of "golden waveforms". All simulations should indicate in a log file whether or not each test passed.

Then, and only then, start coding your design. Start coding your simulation environment. Then start testing your design (per your verification plan). Synthesize, place and route your design and verify timing and utilization requirements.

When you are finished with the first generation of all of the above, write a design analysis report, summarizing and referencing the evidence from verification (simulation and analysis) that all of your requirements have been satisfied. Every item in the verification matrix above should be covered in the verification report.

Rinse and repeat for successive generations of the product.

Throughout all of the above, employ version control on all code, scripts and documents. Emply issue-tracking tools to manage resolution of all defects found during verification, including necessary changes to documents, scripts, RTL and testbench code. This may seem like overkill for a one-man project. But you most likely will not be working professionally on one-man projects.

At the end of the project, write a project report. Include schedule performance (be honest!), and include "executive summaries" of the design analysis report(s), issue tracking metrics (especially graphs over time showing open and closed defects

Your probably thinking; "Wow, that's a lot of writing and not a lot of coding!" Your right, designing (especially with large projects) is about a lot more than coding.

Naturally, to complete all of this in a reasonable time, the product itself will probably have to be pretty small/simple. But going through the process, and being able to talk about it with with a prospective employer during an interview, will impress a prosepective employer. By demonstrating that you have thought and planned all of this out, and then executed it, you will be demonstrating to your prospective employer that you have at least an bit of an understanding of what it takes to develop FPGAs professionally. Keep in mind that your prospective employer will likely have their own process, tools, documentation standards, etc. (i.e. their own process standards) that may not match yours that closely, but the basic elements will be pretty similar, and your mastery of your own well thought out process will prepare you to master theirs.

Andy