VHDL Coding Style Guide

Hi Tony,

Thanks for the good words about the Coding Rules. It takes time to shape
up, publish, fix and keep up-to-date this kind of documents, but I think
it's worth it. (I should have done so earlier)
---

We use now Tcl a LOT.
Having to teach the language did help ;-) but the ground isn't very
difficult, just surprising at first. In the Doulos course, we teach a
lot in three days, including the basics of Tk, event programming etc...
There are lots of good books and free ressources available.

With ModelSim, you can tie VHDL events to Tcl events, which opens
virtually unlimited possibilities. (I think I put on my Website a small
example to read the date/time info from VHDL).

However, I'm NOT at all a fan of Tcl for writing testbenches !
(controlling the stimuli and checking the outputs)

Stimuli and output checking should be done in HDL !

Scripts are wonderful for task automation, like for synthesis and P&R.
With Quartus, it's a breeze.
With Modelsim, you can do also fancy things with Tcl to manage your
project, interact with the user, like for selecting a test scenario or
calling other utilities to prepare or exploit simulation files, or even
interact with actual peripherals...

Considering that Tcl is easy to learn and free, and seeing the
productivity improvement it does procure, I think it's a good investment.

Thanks,

Bert

dutchgoldtony wrote:
Hi Bert,

I found your coding rules really helpful and concise and will be making
a few cahnges in the future to the way I do things in the future.
Just one question, do you know of any resources / tutorials on using
scripts, tcl or otherwise for synthesis and simulation.
I've only recently started using macro .do files but only for
controlling the test outputs.

Cheers,
Tony
Click to expand...
 
Precision Synthesis doesn't like signals initialized at declaration either.
(except for the tri-state that XST did mis !!!)

I've few doubts that DC or FPGA compiler would accept this, but
it would be nice if a chap could quickly check this.

So I'll definitely keep this rule & enforce it.
Advanced users will bend it at their own risks :)

Bert
 
"info_" <"info_"@\\nospam_no_underscore_alse-fr.com> writes:

Precision Synthesis doesn't like signals initialized at declaration either.
(except for the tri-state that XST did mis !!!)

I've few doubts that DC or FPGA compiler would accept this, but
it would be nice if a chap could quickly check this.
Click to expand...
DC will warn about decl time inits, and then ignore them.

Our internal guidelines is to use decl time inits for testbenches only.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
 
Neo wrote:
Bert,
I was wondering what are the differences when having all the instances
described in a case statement versus only describing legal ones and in
others declaring "null". I didnt see any points on this in your coding
style document. for example-
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when others => x <= val4;
end case;
end process;
Vs
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when "11" => x <= val4;
when others => null;
end case;
end process;
How does this affect synthesis?
Click to expand...
Hi Neo,

The probably even better idea is to code
when others => x <= (others=>'-'); -- if it's an array.

This way, if you remove a case in the list :
- the result is optimized at synthesis
- there is no feedback created
- the simulation will make it visible whenever you
are (incorrectly) trying to use the removed case :)

Bert
 
Hi Bert,

Your coding style is nice but I have few questions...

C_13) RTL : In the process above, every signal assigned inside
"rising_edge" must be
initialized in "if Rst".

Not necesarily . Suppose I have a FIFO wtih depth of 8 , then its
enough to Reset the first sequential element. Provided my
initialization phase take 8 clk cycles to propagate that reset value.

C_16) RTL : "wait" is forbidden.

Wait statemets are allowed at the start of the process.
check 1076.6 IEEE standard. But multiple wait satements in a process
would create implicit state machine which is not recommended for RTL.

C_29) RTL : forbidden types = integer, bit, std_ulogic, real, time, ...

Some times integer,bit and std_ulogic are very useful and now tools
are quite intellegent to map better hardware when integer value is
contrained properly. I agree with real and time.

C_37) RTL : Definitely avoid using procedures in RTL code.

procedures and fuctions have there own difference and advantages.
functions mimics operators and procedures to repeated logic. I dont
find any reson not to use procedures in RTL code.

C_39) RTL : Preferably code combinational logic inside sequential
processes.

I heard from many that synthesis tools could do much better if each
process is for specific logic. I am confused now !

C_49) RTL, BEH, SIM : Avoid active-low signals inside the design.
The internal logic should be active-high.

I always prefer Reset to be active-low (for internal and external).
May I know the reson for this.


Thanks a lot for your paper and comments.

-- Mohammed A Khader.
 
Hi Bert,

C_13) RTL : In the process above, every signal assigned inside
"rising_edge" must be
initialized in "if Rst".

Not necesarily . Suppose I have a FIFO wtih depth of 8 , then its
enough to Reset the first sequential element. Provided my
initialization phase take 8 clk cycles to propagate that reset value.
Click to expand...
I am sorry . I used a wrong terminology. By FIFO I mean a series of
filp-flops connected back to back (input of n+1 th fifo is fed from
output of n th fifo ).


C_16) RTL : "wait" is forbidden.

In this style guide, I don't pretend it's impossible or syntactically
illegal.
Ten years ago, some people coded "wait until clock='1'" for
a synchronous process, but it's definitely an obsolete style,
Click to expand...
Again sorry for mis interpreting the word "forbidden". For me
forbidden means "not alllowed". But I dont know what do u mean by
fobidden.

But multiple wait satements in a process
would create implicit state machine which is not recommended for
RTL.
(But I don't use or teach this, since it's tool-dependant, you don't
really have control over your FSM, and coding the reset is unfriendly
at
best imo).
Click to expand...
I never use multiple wait statements .. I clearly stated that "not
recommended for RTL".
I just want to give my views when it is used what could happen.


std_ulogic is another issue, probably already discussed
a lot in the past inside this newsgroup.
I don't use it and don't want to see it used in our designs.
(the only opposable "advantage" was to detect multiple drivers at
elaboration, but the disadvantages outweight this may times imo).
Click to expand...
I totally agree with you in this. I myself use std_logic instead of bit
or std_ulogic but again it is not "forbidden"(not allowed).

Because when I see a signal named "Reset", I don't expect to have to
force it to '0' to activate it
Click to expand...
This could not be the logical reson for using Reset as active high. I
my self dont know any strong reason for using active high or low. But I
used acitve low just for my test.

Thanks a lot again.


-- Mohammed A Khader.
 
Hi Bert,

I found your coding rules really helpful and concise and will be making
a few cahnges in the future to the way I do things in the future.
Just one question, do you know of any resources / tutorials on using
scripts, tcl or otherwise for synthesis and simulation.
I've only recently started using macro .do files but only for
controlling the test outputs.

Cheers,
Tony
 
Bert,
I was wondering what are the differences when having all the instances
described in a case statement versus only describing legal ones and in
others declaring "null". I didnt see any points on this in your coding
style document. for example-
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when others => x <= val4;
end case;
end process;
Vs
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when "11" => x <= val4;
when others => null;
end case;
end process;
How does this affect synthesis?
 
Hi Neo,

There is no effect on synthesis. Synthesis tool works on 0's and 1's
only ( Exceptions are (1) X's for dont care which are again
considered either 0's or 1's for optimizing logic (2) Z's are
considered as tri-state ). That is optimiztion algorithms expects
signals to be either 0's or 1's.

There is surely difference in simulation. if 'a' is a std_logic
signal then it can take any of 9 values , hence any combination other
then '0' and '1' would assign val4 to x for the fist case . For
second case it is null means nothing.

-- Mohammed.
 
My actual question should have been, when the valid case combinations
is less than possible ones. anyway, I got it.
thanks.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top