05-27-2019 01:21 AM
I am hoping to get some VHDL coding style guidelines. I have find one coding guideline from Xilinx which seems very old and I find it odd that xilinx document doesn't have any published date and version. It is found in following answer.
After some discussions and forums, i came to realize that everybody has unique coding style guidelines learnt from their experience. I gathered some things from different forums, but it is far from complete.
Can you please provide me any guidelines that you use from literature? Do you have some guidelines that you made yourself?
Thanks for your time.
05-27-2019 02:09 AM
Hi @ebti07 ,
i came to realize that everybody has unique coding style guidelines learnt from their experience
I think a good way to form your coding style is to find a template and imitate it when you write the code. Vivado provides many templates in Language Templates ->VHDL. Comparing to Coding style , I think comments are more important when prople read your code .
Hope it can help you.
05-27-2019 02:22 AM
In my mind, language templates are useful for sytax. I am looking something like the guidelines (i have seen in forums specific to coding style). Some of these are provided below, can you add something in it or refer something like it.
Always name processes, entity instantiations and generate statements. Recommended to use the prefixes P_ E_ and G_ respectively
Always use i_, o_ or b_ prefixes for module ports to indicate whether they are inputs, outputs or bidirectional ports. Conversely, do not use these prefixes on internal signals that are not ports.
Don't abbreviate signal/variable/entity/instantiation names unnecessarily!
Always use synchronous resets. It's better to use a little more resources than to have an unreliable design
Use entity name as Filename to help with tags
VHDL is case insensitive but use CAPS for constants, lower case for everything else to help with readability.
Some common suffixes : _n to indicate active low, _d for delayed version of a signal [_d1, _d2...], _m for advanced version of a signal (useful for delay alignment), _en for enables.
Use numeric_std instead of std_logic_unsigned
05-27-2019 02:49 AM
As you have already said, coding guidelines are very subjective. Having worked in places with and without formal rules, generally people stick to their own style. But these are the general points that have worked for me and should be applied to all code:
- Comment and document your code. Comments should be about "why" you did something, not "how". The code should explain the "how" if it is well written.
- Give things sensible names
- Be consistant. If you're modifying someone elses code - keep to their style
I no longer fussed about the numeric_std/std_logic_unsigned argument. As long as the above 3 are kept, it shouldnt matter (VHDL2008 adds numeric_std_unsigned which is basically the same anyway).
And a fix for you:
"Always use synchronous resets. It's better to use a little more resources than to have an unreliable design"
This should be: Always use the reset appropriate for the technology you're using.
- Xilinx do provide sync reset on flops, but routing is in short support. Only reset something if it really needs it - reset control logic, dont both with data-path.
- Older Altera devices (10 series and before) have async resets on all flops and no sync. They have plenty of routing and will put the reset on a clock net to ensure low skew and a high fanout. The advice is async assertion, sync de-assertion. Sync reset is emulated with extra logic and can harm timing.
- If in doubt - stick with sync reset
On the subject of reset, be careful how you reset - the "standard" layout of process can mean you accidently connect sync reset to the clock enable of any register you accidently missed from the sync reset:
process(clk) begin if rising_edge(clk) then if reset then a <= '0'; else a <= ip_a; b <= ip_b; end if; end if; end process;
Here, b cannot be assigned to ip_b during reset so reset becomes a clk_en on the b reg. This style prevents mixing reset and non-reset logic in the same process.
The alternative style is to put reset at the end of the process, because in VHDL the last assignment wins.
process(clk) begin if rising_edge(clk) then a <= ip_a; b <= ip_b; if reset then a <= '0'; end if; end if; end process;
I have, too often, found the former style with paths failing timing because someone left a signal out of the reset list. Remember reset will have a high fanout. I wish more people would use the latter style.