UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer ebti07
Observer
544 Views
Registered: ‎10-15-2018

VHDL Coding Guidelines

Hey,

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.

https://forums.xilinx.com/t5/General-Technical-Discussion/coding-style-guidelines-for-vhdl/m-p/695830

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.

0 Kudos
3 Replies
Xilinx Employee
Xilinx Employee
533 Views
Registered: ‎02-27-2019

回复: VHDL Coding Guidelines

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.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Observer ebti07
Observer
528 Views
Registered: ‎10-15-2018

回复: VHDL Coding Guidelines

Hey @yangc 

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

Regards

0 Kudos
Scholar richardhead
Scholar
516 Views
Registered: ‎08-01-2012

回复: VHDL Coding Guidelines

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.

0 Kudos