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