Preparing for FPGA Design Review

peepo

a concise and intelligible report from Brian Smith to NASA including:

Document your code properly.  Inline documentation will
help you later, and will help the next engineer if a
personnel change is made in the middle of the Project.

Write the purpose of each procedure or function.

If you are using any tricks to achieve the design, use inline
comments to explain why and how.

...

Chase down all warnings and errors reported by simulator.

Understand why they are there.

Document any decision to ignore them

...

Review all logs from vendor tools for errors, warnings,
and notes.  

Clear the error/warning conditions and re-run until clean, or
document
why you are ignoring them

https://nepp.nasa.gov/mapld_2008/presentations/i/02%20-%20Smith_Brian_mapld08_pres_2.pdf

anyone care to add similar?

mjones

Thanks for sharing peepo.  Indeed synthesizing code into hardware has many more pitfalls and requires more attentions to the coding/synthesis process that that of software (generally speaking).  

A good podcast I just finished listening to from embedded.fm which has a lot of talk about coding standards/testing processes.  Software related but generally applies to RTL as well.  Bottom line "keep it simple" and "make it clean".  

http://embedded.fm/episodes/2015/3/25/dont-be-clever