Getting in to the industry

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

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.

Having worked with many impressive college new-hire FPGA developers during = my career, their main shortcoming is a lack of understanding how the develo= pment 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. =20

They often do not yet understand the value of well-defined requirements (es= pecially 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 imp= ortance on planning, designing and coding for maintainability. It's not jus= t about how few gates can run how fast.

Tools and techniques that are not often used in college projects include sc= ripting everything so that results can be reliably repeated (by you and oth= ers), as well as employing version control and change management (issue tra= cking) tools.

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

So, how can you prepare yourself?=20

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

Write the requirements for the product as if you were not going to be the o= ne developing (or verifying) it. Include a matrix that identifies which gen= erations of the product have to meet which requirements. Do not write requi= rements that prescribe how the product will do something; instead write req= uirements for what the product must do, with observable criteria.=20

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

Write an Interface Control Document that defines the external interfaces. T= his document should be heavily referenced by the design requirements.=20

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

Write a verification design document (similar to the design document, cover= ing the verification models, tests, etc.) Make sure your verification does = not include inspecting waveforms to see if a test passed, or comparing agai= nst a set of "golden waveforms". All simulations should indicate in a log f= ile 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 r= equirements.

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

Rinse and repeat for successive generations of the product.

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

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

Your probably thinking; "Wow, that's a lot of writing and not a lot of codi= ng!" 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 proces= s, and being able to talk about it with with a prospective employer during = an interview, will impress a prosepective employer. By demonstrating that y= ou 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 bi= t of an understanding of what it takes to develop FPGAs professionally. Kee= p in mind that your prospective employer will likely have their own process= , tools, documentation standards, etc. (i.e. their own process standards) t= hat 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 prepar= e you to master theirs.

Andy

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.

(especially verifiable ones), and want to rush into coding before the overall design is far enough along.

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.

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.

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.

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.

development plan for it, including more than one version or generation of the product. Include a summary schedule in your plan.

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.

verifying it) with a matrix that shows how each requirement is going to be verified (simulation, analysis, test, inspection, etc.)

document should be heavily referenced by the design requirements.

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.

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.

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

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.

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.

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

coding!" Your right, designing (especially with large projects) is about a lot more than coding.

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.