VHDL Coding Style Guide

Hello,

A (new) draft of my (old) VHDL Coding Rules is available at :

http://www.alse-fr.com/archive/VHDL_Coding_eng.pdf

"Power users" may have adopted different rules, or would
discard some. You can send feedback at "info" at the website above.

Best regards,

Bert Cuzeau

Bert Cuzeau

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.

Mohammed A khader

Mohammed A khader wrote:

> 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.

The FIFO pointer and flag registers need a reset
to make the buffer status empty and not full.
Reading an empty FIFO is an error, so
propagating a reset value through
the buffer is not necessary.

I agree with your other points, but a style
guide is about preferences.
It's OK to have your own.

> 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 !

The number of processes makes
no difference to Leonardo, Synplicity or Quartus.
You can write your entire design entity as a single
synchronous process if you so desire.

But I read C_39 as a preference for processes
over parallel statements for combinational descriptions.

-- Mike Treseler

Mike Treseler

Mohammed A khader wrote:
> 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 .

Yes, necessarily !
Otherwise, this means you want "not Rst" as a clock enable...
A _very_ common mistake, hence the rule.

> 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,
and I don't see any possible advantage in this.
And the rule, as it is (no wait etc...), is simple to understand and to
enforce(especially by automatic checking tools like VNcheck)

> But multiple wait satements in a process
> would create implicit state machine which is not recommended for RTL.

Interesting !
In fact, you may discover than many synthesis tools (like Synplify)
actually like this multiple waits style and code the implicit state
machine for you !!!
(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).


> C_29) RTL : forbidden types = integer, bit, std_ulogic, real, time, ...
>
> Sometimes integer,
NO WAY !
integer _range_ may be accepted (accepting the automatic init).
"integer" alone is not acceptable.

> bit

????

I see boolean as acceptable (like integer range), but I don't see why an
electronician would use "bit" since 1164 was invented jsut for us.
A logician will like "bit".

> std_ulogic are very useful and now tools
> are quite intellegent to map better hardware when integer value is
> contrained properly.

Where did you get this information that type "bit" was more efficiently
implemented than std_logic ?
In fact, it's quite the contrary :
How do you code s <= '-' with type bit ???

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)

> 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.

I stick to this rule. But this rule does not rule out _functions_ for
RTL, which are really useful and quite well supported by modern
synthesis tools (though a few tools may still frown at recursion).
I could change my mind, so I'm really interested in seeing some of your
_RTL_ code taking advantage of procedures.
Procedures are a must for _simulation_ code though.

> 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 !

Check again ! Or better : try and see. Don't rely on hearsay, or on what
some books may say.
And it might be the other way around under some special circumstances
(facilitating resource sharing).

I've seen so many errors in combinational processes (just browse this
newsgroup and see how many "problems" would have been avoided without
combinational processes) that even if there were some synthesis
advantage (and there is none), I would still keep this rule.


> 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.

Because when I see a signal named "Reset", I don't expect to have to
force it to '0' to activate it. At least, it should be named nReset, or
Reset_n...
Why do you like Reset active low (and why no other signal) ?
And why not active low Enables ? etc...
I have seen Asic respins due to incorrect reset polarity.

Assembling entities with some active-high reset and some
active low reset inputs is also error-prone (especially when all the
reset inputs are named Reset or Rst regardless of their active level).

I wrote these rules to make everyone's life simpler, not harder.


--- Thanks for your time reviewing the rules and for your comments and
questions !

Bert

Bert Cuzeau

Mike Treseler wrote:

> But I read C_39 as a preference for processes
> over parallel statements for combinational descriptions.

Hi Mike,

It's sometimes hard to describe preferences and the reasons behind them
in rules

My actual preference is in fact :

* continuous assignements for simple logic :
not, simple and/or, and indeed tristates/open collector.

* complex combinational logic is imo better when split over several
statements (easier to modify, understand, debug -breakpoints !-, cover,
assert, etc....)
But since I hate comb. processes (at least until we get the wild card
sensitivity list as in Vlg2001 or comb_process as in SystemVlg), this
ends up in this rule

And you're definitely right about preferences !
A VHDL expert may legitimately adopt other rules, but I think before
having acquired many years of experience, it's probably safer to follow
these rules rather not.
If they can help a little bit, that's my purpose behind publishing them.

Bert

Bert Cuzeau

Bert Cuzeau wrote:

> A VHDL expert may legitimately adopt other rules, but I think before
> having acquired many years of experience, it's probably safer to follow
> these rules rather not.
> If they can help a little bit, that's my purpose behind publishing them.

Thanks for posting your style sheet.
I know how much time it takes
to get ideas into a format understandable by others.
This is an excellent starting point for logic designers.
I do think that C_33 and C_37 are negotiable for
those more experienced with simulation and synthesis.

-- Mike Treseler

Mike Treseler

Bonjour,

Je me permets de vous contacter car je suis diplomé en electronique et je
recherche un premier emploi dans la conception de FPGA. Comme vous faites de
la formation pour le développement sur FPGA Altera, je me demandais si vous
pouviez m'indiquer des sociétés parmi vos clients qui pourrait recruter dans
le développement FPGA.

Je vous remercie par avance pour votre réponse.

Cordialement,

Alexis GABIN.

PS: pour les règles de codages celles utilisées chez THALES sont assez
similaires



"Bert Cuzeau" <_no_spa_m_info_no_underscore_@alse-fr___.com> a écrit dans le
message de news: 4242d512$0$5161$...
> Hello,
>
> A (new) draft of my (old) VHDL Coding Rules is available at :
>
> http://www.alse-fr.com/archive/VHDL_Coding_eng.pdf
>
> "Power users" may have adopted different rules, or would
> discard some. You can send feedback at "info" at the website above.
>
> Best regards,
>
> Bert Cuzeau
>

KCL

oups sorry , I'd made a mistake it was just for bert cuzeau.


"KCL" <kclo4_NO_SPAM_@free.fr> a écrit dans le message de news:
424472a3$0$25047$...
> Bonjour,
>
> Je me permets de vous contacter car je suis diplomé en electronique et je
> recherche un premier emploi dans la conception de FPGA. Comme vous faites
> de la formation pour le développement sur FPGA Altera, je me demandais si
> vous pouviez m'indiquer des sociétés parmi vos clients qui pourrait
> recruter dans le développement FPGA.
>
> Je vous remercie par avance pour votre réponse.
>
> Cordialement,
>
> Alexis GABIN.
>
> PS: pour les règles de codages celles utilisées chez THALES sont assez
> similaires
>
>
>
> "Bert Cuzeau" <_no_spa_m_info_no_underscore_@alse-fr___.com> a écrit dans
> le message de news: 4242d512$0$5161$...
>> Hello,
>>
>> A (new) draft of my (old) VHDL Coding Rules is available at :
>>
>> http://www.alse-fr.com/archive/VHDL_Coding_eng.pdf
>>
>> "Power users" may have adopted different rules, or would
>> discard some. You can send feedback at "info" at the website above.
>>
>> Best regards,
>>
>> Bert Cuzeau
>>
>
>

KCL

Bert Cuzeau wrote:

> I could change my mind, so I'm really interested in seeing some of your
> _RTL_ code taking advantage of procedures.

Have a look at this RTL:
http://home.comcast.net/~mike_treseler/uart.vhd

and this testbench:
http://home.comcast.net/~mike_treseler/test_uart.vhd

-- Mike Treseler

Mike Treseler

Mike Treseler wrote:
> Bert Cuzeau wrote:
>
>> I could change my mind, so I'm really interested in seeing some of
>> your _RTL_ code taking advantage of procedures.
>
>
> Have a look at this RTL:
> http://home.comcast.net/~mike_treseler/uart.vhd
>
> and this testbench:
> http://home.comcast.net/~mike_treseler/test_uart.vhd
>
> -- Mike Treseler

Hi Mike,

For sure, people with your experience don't need my rules
and won't care

Your RTL procedures example is indeed a valid one.

However, I wouldn't use RTL subroutines for personal taste (read laziness).
I acknowledge that it's a neat way to organize the code, but I do
not see the usual advantage of subroutines which is factoring,
and I try to write as few code as I can (I'm lazy, as I said).
Sure, it's a very personal taste issue here

If I remember correctly, SpeedChart did exactly this when generating
FSM code. (Speedchart was the only graphical FSM tool which generated
code that was -imo- really good and correctly inferred all the subtleties.
And that was nearly 10 years ago. To be honest, I haven't looked lately
at generated code from the recent tools).
And who remembers SpeedChart anyway ?

I admire the individuals who, like you, patiently spend a lot of
time here helping others. While teaching, I always mention this
newsgroup as a great source !

Cheers,

Bert

info_