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!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎06-24-2008

Signal naming conventions/style

Hey everyone,


I was wondering what coding styles people here use for naming signals (vhdl if it matters).


I have looked around and found a few different ones on university websites but was curious as to what people use.  The only thing I have really adopted so far was using _reg for storage elements and _next suffixes for the value to be saved on the next clock cycle.  I dont really have a way to differentiate ports vs signals or counters.  Some of the conventions I have looked at seemed excessive so I just wanted to know what everyone found useful through their experiences.



0 Kudos
5 Replies
Registered: ‎08-14-2007

Re: Signal naming conventions/style

I think whatever you use, it helps to be consistent.  If you are working with other engineers

on a common project you should use the accepted style regardless of your personal



I use Verilog myself, so there are some things like making the bus width a part of the

name that are helpful in Verilog, but redundant in VHDL.  Also be careful with case

(upper vs. lower) if you think you may end up with mixed language projects in the

future.  Verilog is case-sensitive, VHDL is not.


I use upper case for IOB pad signals.  I use the name from the schematics and

generate the LOC constraints directly from the board netlist to avoid errors.  All

internal signals (regs, wires, variables) are lower case.   I don't distinugish between

regs and wires in the signal name.


For module ports I use _in, _out, or _io suffixes to indicate direction.  Again in

Verilog the instantiation template doesn't show the port sizes so it is also

useful to add the bus width to module port names.


Try to make the name as descriptive as possible, but don't even think

for a moment that VHDL is "self-documenting".  ALWAYS put a comment

near the signal or variable definition to describe its purpose.  Sometime

when you need to modify code you wrote three years earlier you will

be glad for those comments.  Also liberally comment your behavioral

code, even if you think its function is obvious when you are writing it.


There are also conventions like _n for active low signals, but I generally

stay away from active low for internal signals.  Unnecessary inverters

will be optimised away during synthesis, and you will find you make

fewer logic errors when everything is active high.


As I said before the most important thing is to be consistent, at least within a project

so you can save time later on if you need to go through the code or if someone

else needs to update or review it.




-- Gabor
Advisor evgenis1
Registered: ‎12-03-2007

Re: Signal naming conventions/style

If you look at open source projects (e.g. Opencores.org) or Xilinx CoreGen-generated code, it's all lower-case and underscores. Some use ###_q to denote a register and ###_c to denote a combinational logic.




Tags (2)
0 Kudos
Registered: ‎09-11-2007

Re: Signal naming conventions/style

In the 10.1 "Synthesis and Simulation Design Guide", Xilinx says:


General Naming Rules for Signals and Instances

Xilinx recommends that you observe the following general naming rules:

Do not use reserved words for signal or instance names.

Do not exceed 16 characters for the length of signal and instance names, whenever


Create signal and instance names that reflect their connection or purpose.

Do not use mixed case for any particular name or keyword. Use either all capitals, or

all lowercase.

Recommendations for VHDL and Verilog Capitalization

Xilinx recommends that you observe the guidelines shown in Table 3-1, “HDL and Verilog

Capitalization,” when naming signals and instances in VHDL and Verilog.

Table 3-1: HDL and Verilog Capitalization 

lower case UPPER CASE Mixed Case

library names USER PORTS Comments




entity names PARAMETERS

user component names GENERICS

internal signals


Hmmm, that table looks like crap - oh well.

0 Kudos
Registered: ‎02-25-2008

Re: Signal naming conventions/style

I'll bite. First: I really hate READING EVERYTHING IN UPPER CASE.


All VHDL keywords, etc, are lower case.


All processes, generate blocks, loops, etc get labels.


All constants, generics and enumerations are UPPER case.


All signals and variables have a two- or three-letter lower-case prefix indicating the major function to which they belong. So signals associated with an SPI ADC might be called adcSClk, adcMOSI, etc.


I like to mix-n-match case in signal and variable names, mainly for clarity, and the names should be indicative of their function. For example, it should be obvious what iLoadTxShiftReg does. Clocks always have Clk in the signal name: gSysClk is my standard global clock.


Signals that are internal to a module have an i prefix. So a counter might be called iBitCnt, and a state-machine state register might be called iState.


Any signal that is active-low has a _l suffix, perhaps adcCS_l.


I make no distinction between register outputs and combinatorial logic outputs (what's the point, really?).


If a signal needs to be synchronized to a clock, like perhaps an input port, the sync'ed signal gets an _s suffix, for example, adcIRQ_s.


If I need to delay a signal, for example when needed for edge detectors, the delayed signal gets an _d suffix. The resulting one-clock-wide edge-detected strobe is given either an _fe suffix for falling edge or _re for rising edge.


Pretty simple, and of course I violate my own rules all the time.



Message Edited by bassman59 on 06-24-2009 10:13 AM
----------------------------Yes, I do this for a living.
Registered: ‎06-24-2008

Re: Signal naming conventions/style

Thanks for the responses!  I will definitely keep them in mind as I'm trying to improve my own style.


0 Kudos