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: 
Scholar ronnywebers
Scholar
1,821 Views
Registered: ‎10-10-2014

Xilinx naming conventions for HDL (VHDL, Verilog, ....)

I came accross the following Xilinx document - found on the web - and I'm wondering how up-to-date this still is with regard to Vivado (2017.4 is the latest release at the time of writing).

 

Xilinx Coding Style Guidelines

 

I read through the document, and I'm mainly interested in 'naming conventions' used by Xilinx, when creating their own IP, examples, ... There are also guidelines on synthesis & inference, but UG901 (Vivado Synthesis Guide) is probably more up-to-date and 'the reference' for Vivado. However, it does only slightly cover 'naming conventions', and I found this document to be more complete and interesting.

 

Q: Is the above document still applicable with regards to naming of variables, signals, procedures, clock, reset, ...? Or is there any updated version of this document?

 

 

 

 

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Tags (1)
5 Replies
Scholar jmcclusk
Scholar
1,809 Views
Registered: ‎02-24-2014

Re: Xilinx naming conventions for HDL (VHDL, Verilog, ....)

I just read through this, and it's definitely looking dated, despite some excellent advice which still remains absolutely true.   The two areas that I thought needed updating was the signal naming recommendations, and the FSM philosophy.

 

I have a few things I like to do in VHDL signal naming..

i.e.

 

  1. Port inputs have the prefix "i_"
  2. Port outputs have the prefix "o_"
  3. Port bi-directional pins have the prefix "io_"
  4. Signals in an architecture have the prefix "s_"
  5. Constants have the prefix "C_"
  6. Generics have the prefix "G_"
  7. typedefs have the prefix "t_"
  8. FSM states can have the prefix "fsm_"

Low level blocks with unconstrained ports are the bomb, and recursion should be encouraged, which is something barely tolerated now.

 

Anyway,  the guide has some good advice, but badly needs updating, since 2 and 3 process state machines are definitely something from the 90's.   I always just use 1 process these days.   It also lacks any advice on physical synthesis approaches, which is a serious topic now with Vivado.

 

 

Don't forget to close a thread when possible by accepting a post as a solution.
Tags (1)
Visitor scottypc3
Visitor
1,798 Views
Registered: ‎03-05-2018

Re: Xilinx naming conventions for HDL (VHDL, Verilog, ....)

It is beneficial to differentiate the types of signals one will generate in the code.  Differentiating between clocked and combinatorial signals is critical in many aspects of design and debug.  So here's my take at it:

 

4a. Clocked signals have a prefix "f_"

4b. Combinatorial signals have a prefix "c_"

4c. Wires have a prefix "w_"       -- Any connection that contains no logic changes.  i.e. Connecting two components

 

3. For bi-directional pins "b_"      -- Slightly easier to view than "io_" when filtering signals by prefix

5. Constants have "k_" instead of the stated "C_". 

9. Variables have the prefix "v_"

10. Active Low signals have a suffix of "_n"

Scholar richardhead
Scholar
1,774 Views
Registered: ‎08-01-2012

Re: Xilinx naming conventions for HDL (VHDL, Verilog, ....)

@ronnywebers Its a pretty standard style document Ive seen in many places, where rules generally dont get adhered to. Some people love using i_ and o_ , and some dont. Given it appears to be a xilinx internal document, and the port names I see on Xilinx IP, I dont think they stick to the rules much either!

 

Personally, I just stick with the mantra that it should be clear, with useful/clear signal names, with plenty of comments explaining why (not how) you have done things the way you have. I also like to align all my code "nicely" (column edit essential for this!)

 

@jmcclusk Low level blocks with unconstrained ports are the bomb

 

Indeed they are. Especially when you mix in VHDL 2008 with unconstrained arrays and record types. 

Although probably not so useful for synthesis, but definitely for simulation, are generic types, functions and packages. The LRM will even allow a package as a generic to anything (waiting for support from simulators on this one though - ER raised with Aldec!).  Add in external names and you can start building yourself a testbench that behaves like UVM with just a VHDL licence!

 

 

Scholar ronnywebers
Scholar
1,710 Views
Registered: ‎10-10-2014

Re: Xilinx naming conventions for HDL (VHDL, Verilog, ....)

thanks all for sharing your 'habits' :-) I'll leave this thread open for a while, still hoping someone from Xilinx comments on this post too.

 

Common sense is of course a good habit. Having these 'different' habbits here listed up, helps to construct an (minimal) own/company standard.

 

I know beforehand that it will not always be adhered to by everyone, but having 'a' standard is definitely more productive and will allow for easier code exchange than having no standard at all. 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Scholar richardhead
Scholar
1,704 Views
Registered: ‎08-01-2012

Re: Xilinx naming conventions for HDL (VHDL, Verilog, ....)

@ronnywebers

 

Just be mindful that too prescriptive a standard can just annoy people, and code reviews can often boil down to a check of whether the standard has been followed, rather than whether the design appears to meet the design intent. This is what we found when we proscribed a coding standard and mandatory code reviews.

 

After a while, we decided that as long as people were following the spirit of the rules, then it was easier to study if the code followed design intent. Also, if they are too prescriptive, it can sometimes prevent nicer ways to code as new features are supported, like 2008 features for example.

 

As with all rules, they are made to be broken.