|
Coding Styles
There is no single naming convention used in the design community.
Naming conventions are used to maintain the standards across the design
group so that the code written is easily understandable and the designer
can adhere to a set of rules which enhances the code readability. So everyone
can have their own set of meaningful rules framed up to their conventions.
A typical set of rules is shown below.
1. Signal Naming Conventions
-
Signal names can contain mixed case letters and numbers as
well. Use of underscores is not permitted.
-
The first character indeed has to be an alphabet.
-
First three characters should indicate or convey the name
of the driving module.
-
Control unit - "ctl"
-
Arithmetic logic unit - "alu"
-
Multiply Accumulate unit - "mac"
-
Data Address Generator - "dag"
-
Signal name should also indicate whether it is a active high
/ Positive Logic (P) signal or a active low / Negetive Logic signal (N).
-
Signal name should indicate whether it is a global signal(G)
or a local signal(L).
-
Signal name should tell whether it is a bus(B), wire(W) or
clock(C).
-
Later the signal name should tell what it is intended to
be.
A few examples bound with the above conventions can be,
-
"aluPGBaugend" - What we understand by this is
that the driving module is the ALU, it is an active high global signal,
it is a bus and it is one of the operands to the ALU.
-
"macNGWoverflow" - This tells us that the driving module
is the MAC, it is an active low global signal, it is a wire and it is intended
to modify the overflow flag of status reg whenever a overflow occurs in
the MAC.
2. Conventions for variables
and constatnts
-
Variable names can contain mixed case letters, numbers as
well as underscores.
-
All constant names should be in upper case letters only.
But it can also have numbers and underscores.
-
Variable and Constant names should exactly mean what they
are supposed to do / behave.
-
Generic Names will also be in Upper Case similar to the Constants.
3. Other Conventions
-
Entity names should contain lower case letters only and they
should not exceed 10 characters.
-
Architecture names should be "behavioural" for behavioural
description, "structural" for structural description.......
-
In case of multiple architectures for same entity and both
being behavioural or structural, designer can associate a suffix
with the basic name.
-
All register names should begin with the actual register
name and terminate with a 3 letter suffix "REG".
-
All Processes, Blocks and Configurations can have Mixed Case
Meaningful Names, preferably within 8 characters.
-
All Functions / Procedures can have lowercase Names
having at the most 12 characters.
-
As far as possible try to use Generics.
-
Use good amount of meaningful constants, so that it increases
the code readability.
-
Before starting with coding, having the Block diagram of
what is being done is good since it expects a thorough understanding of
the module by you, which inturn eases and cuts off your coding time / efforts.
4. Headers and Footers
As a matter of well
documenting the source code, it is necessary to capture all the details
involved with the file. So the source code should contain a Header and
a Revision List (to capture modification details).
The Header Contains
the Following details.
-
The Name of the Module.
-
The File Name
-
The Dependent Library.
-
The Description of the Module
-
The Simulator used, its Version and the Platform.
-
The Synthesis tool used, its Version and the Platform.
-
The Author's Name and Email address.
The Revision List will Contain the following details.
-
The Revision Number
-
Date of Change.
-
Modifier's Name and Email address.
-
Description of Change.
Example Header
-------------------------------------------------------------------------------------------
-- Module
: MAC (Multiply Accumulate Unit)
-- File
: mac.vhd
-- Library
: ieee,.......
-- Description
: It is a general PurposeMultiply Accumulate Unit capable of ?.
-- Simulator
: Modelsim 5.2 / Windows 95
-- Synthesizer
: Synplify / Windows95
-- Author / Designer : Harish Y S (harish@opencores.org)
-------------------------------------------------------------------------------------------
Example Revision List
-------------------------------------------------------------------------------------------
-- Revision Number : 1
-- Date of Change : 20th March 2000
-- Modifier : Harish Y S (harish@opencores.org)
-- Description : Initial Design
-------------------------------------------------------------------------------------------
-- Revision Number : 2
-- Date of Change : dd mm yyyy
-- Modifier : XYZ (email)
-- Description : Modified the ????.to improve ????..
-------------------------------------------------------------------------------------------
Any positive Criticism is Welcome
mailto: Harish Y S (harish@opencores.org)
|