VHDL Coding Style Guide

[Bert Cuzeau]

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

 

[Mike Treseler]

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

 

[Bert Cuzeau]

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

 

[Mike Treseler]

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

 

[KCL]

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$626a14ce@news.free.fr...

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$8fcfb975@news.wanadoo.fr...

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$626a14ce@news.free.fr...
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

 

[Mike Treseler]

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

 

[info_]

Mohammed A khader wrote:

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

Aka Shift Register.
This doesn't change the fact that you _must_ reset ALL the flipflops if you write
them in the same synchronous process. This IS a very important rule. (some -most-
synthesis tools issue warnings anyway)
However, it's "legal" not to, just very wrong design-wise.
In case of doubt, I suggest you take a look at the post-synthesis RTL view, so you
will understand the issue without having to take my word for it.

Again sorry for mis interpreting the word "forbidden". For me
forbidden means "not alllowed". But I dont know what do u mean by
fobidden.

My fault !
These are things I don't allow in our designs.
Instead of "forbidden" I should have written "forbidden if you adopt these rules".
Or maybe "ruled out" ? (I'm not a native writer)

In VHDL (and Verilog), you can code bad descriptions that won't work well or will
fail, or won't work at all, that are entirely legal.
Following the rules is not a garanty, it's just -imho- a safer path.

.... multiple wait statements ..

AKA "Behavioral Synthesis style".
It's best when used with a "true" behavioral synthesis tool (RIP).

Thx for the comments.

Bert

 

[Walter Dvorak]

Bert Cuzeau <_no_spa_m_info_no_underscore_@alse-fr___.com> wrote:
nice ruleset and mostly useable. but i'm wondering if rule
C_36 is a good option:

C_36: RTL : It is not allowed to initialize signals at their
declaration. It is not allowed to initialize variables at their
declaration in processes.

(in combination with rule C_13)


In my opinion this is not a good idea for (newer) FPGA
devices and can cause some troubles. Because the propagation
delay on dedicated reset nets over the hole device could be
longer than the time for one (master) clock cycle. And this
could result in a strange behaviour. For example state machines
that "start up" in an illegal state after the async reset
release.

Second, on some FPGAs it is not possible to clear/set
all memories by an async reset signal. For example xilinx
blockrams and some type of compact shift registers (SLR).

In my opinion and this may apply only for FPGAs, a
global reset should be avoided in FPGA designs. An async reset
could make sense local for some processes but not as a global
reset signal to get back to a defined init state. Signals
(and of course variables) on RTL should be initialize at their
declaration, so that the synthesize tool can generate the
correct init value for the configuration data.

if a global restart of the FPGA device with known
start values is necessary, the complete configuration data
stream should be reloaded into the FPGA like at power up.

WD
--

 

[info_]

Hi Walter,

Thanks for the review.

I still think it's a terrible idea to initalize signals at declaration.
Signal creation and t=0 only makes sense in a simulation environment, this is not
synthesizable. Plus it's a "safe" way to hide initialization problems and have a
design which simulates perfectly but fails on the field.
So, for me, C36 is a design-error class of rule.

As of global reset and use of hard reset in applications, it is a design choice.
But fyi, Quartus does correctly check the reset during static timing analysis.

I have seen many problems with designs that were supposed to power up in the "right
state". I don't think an Asic would be accepted without a reset.
Last, you may code a reset and not use it. But you need to understand your FPGA
architecture and synthesis and technology mapping tools and check what they do behind
your back (not gate push back for example can play havoc). And not all FPGAs are
equal either (I remember some old Actel families...).

But, again, experts dealing with extreme conditions all have their own tricks and
techniques, and the basic rules are there to be bent -with legitimate and proven
reasons-. I will try to emphasize this even more in the next release of the rules !
Thanks for your input.

However, I do not agree on bending C36. Other opinions are welcome.

Bert

 

[Mike Treseler]

Walter Dvorak wrote:

C_36: RTL : It is not allowed to initialize signals at their
declaration. It is not allowed to initialize variables at their
declaration in processes. (in combination with rule C_13)
In my opinion this is not a good idea for (newer) FPGA
devices and can cause some troubles.

Initialization by declaration is ignored for
synthesis and therefore has no effect on
a design's start up behavior.

I prefer to allow simulation to verify that the the 'U's get
assigned before they are used, rather than forcing the
expected values at time zero.

Objects like block RAM, that lack a reset input,
ought to be isolated (C_51) and inferred from a
code template whenever possible.

-- Mike Treseler

 

[Walter Dvorak]

Mike Treseler <miketreseler@yahoo.com> wrote:

Initialization by declaration is ignored for
synthesis and therefore has no effect on
a design's start up behavior.

Sorry, but thats not correct in general for up to date
synthesize tools. You could be right if you refer the early days
of VHDL synthesis, mainly used for ASIC designs.

For example: xilinx XST version 6.2.x or 6.3.x and (unchecked)
7.1.x (ISE, webpack, ...) will do initializiation by declaration as
expected and is not ignored. Please check it be yourself if you
dont believe me.

Attached some simple VHDL code fragments 1 und 2. They have
the same start up values for the generated FFs, synethezsized with
XST 6.2.x. (could be easily checked in the netlist or with the
"FPGA editor", supplied from xilinx within the ISE package)

WD


***

"classic" RTL code fragment 1 with timing problematic async
reset signal on newer FPGAs with high clock rates:

signal my_signal_A : std_logic;
signal my_signal_B : std_logic;
[...]

my_sample_A_proc : process (clk, reset)

begin
if (reset = '1') then
my_signal_A <= '0';
my_signal_B <= '1';
elsif (rising_edge(clk)) then
my_signal_A <= not(my_signal_A);
my_signal_B <= not(my_signal_B);
end if;
end process;

***

RTL code fragment 2 with sync reset. preferred for
(newer) FPGAs designs with up-to-date synthesize tools:

signal my_signal_A : std_logic := '0'; -- init value of FF A will be 0
signal my_signal_B : std_logic := '1'; -- init value of FF B will be 1
[...]

my_sample_B_proc : process (clk)

begin
if (rising_edge(clk)) then
if (reset = '1') then
my_signal_A <= '0';
my_signal_B <= '1';
else
my_signal_A <= not(my_signal_A);
my_signal_B <= not(my_signal_B);
end if;
end if;
end process;

--

 

[Walter Dvorak]

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

I have seen many problems with designs that were supposed to power up
in the "right state". I don't think an Asic would be accepted without
a reset.

I agree. That's the reason, why i would like to refer
FPGA designs only for this point and not ASIC design or in general. Of
course, not all FPGAs are the same, designs and requirements are
different and synthesize tools have different capabilities.

Last, you may code a reset and not use it.

Of course, but why? if the synth tool is able to get the
correct start up values for all FFs from the signal declarations,
it is not necessary to code around with signals that are never
used.

But you need to understand your FPGA
architecture and synthesis and technology mapping tools and check what
they do behind your back

Yes, this is an absolutely must. Maybe it make sense to add
this point to the rule set...

WD
--

 

[info_]

Hi Walter,

Thanks a lot indeed for bringing this interesting subject !

I noticed a while ago that some synthesis tools made attempts in implementing signal
initialization at declaration, and I didn't like the idea very much.

You mention ISE, and it is among those who try (and, to some extend, succeed).
However, I just checked and it missed the tristate ! So, for me, it's still a no-go.

I've written a complete test so that anyone can try with any technology and any
synthesis tool and take an educated decision... (and let me know !)

Anyway, it's a too potentially dangerous practice, and I know that this fails with
some synthesizers, P&R, and FPGAs, so I will keep my rule set unchanged, and once
again mention that, with good reasons and experience, any rule (almost) can be bent.
For example, we don't deliver code to our customers which isn't ASIC-friendly (as
much as possible), so this tule is enforced.

I will change the rule when :
- it will be normalized in 1076.6 (is it ? I didn't check the future version)
- all synthesis tools will pass this test
- all tech mappers will pass this test
- all physical synthesis tools will keep the functioanlity
- all FPGAs will implement this flawlessly
- it will be considered as ASIC-friendly code.
until then I will consider this practice as an exception which requires justification
and verification.

Here comes the test. ISE fails at Q4 (tristate) but does a good job on the rest.
If anyone tests other tools and technologies, please send me the results !
(i_n_f_o at alse-fr with no underscore. Add dot com indeed)

Bert Cuzeau

--------------
-- SigInit.vhd
-- ---------------------------------------------
-- Testing Initialized Signals implementation
-- ---------------------------------------------
-- (c) ALSE http://www.alse-fr.com
-- Author : Bert Cuzeau
-- THIS STYLE IS NOT RECOMMENDED !
-- You may use this to check your FPGA technology and tools.

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

-- ---------------------------------------
Entity SigInit is
-- ---------------------------------------
Port ( Clk : In std_logic;
--Rst : In std_logic; -- not anymore
En : In std_logic;
Din : in std_logic;
Q : Out std_logic_vector (8 downto 0) );
end ;

-- ---------------------------------------
Architecture questionable of SigInit is
-- ---------------------------------------

type State_t is (A, B, C, Idle, Dead);

-- Things NOT to do IMO !!! >>>>>
signal InitZ : std_logic := 'Z';
signal Init0 : std_logic := '0';
signal Init1 : std_logic := '1';
signal Initd : std_logic := '-';
signal count : unsigned(3 downto 0) := "1010";
signal Bool : boolean; -- initialized to false at t=0.
signal Bool2 : boolean; -- initialized to false at t=0.

signal State : State_T := Idle;
signal Q5 : std_logic := '1';
signal Q6 : std_logic := '0';
-- <<<<<
signal Q7 : std_logic;

begin
------

process (Clk)
begin
if rising_edge (Clk) then
if En='1' then
case State is
when A => State <= B;
when B => State <= C;
when C => if not Bool then State <= Idle; end if;
when Idle => State <= A; Q6 <= not Q6;
When Dead => null;
end case;
end if;
end if;
end process;

process (Clk)
begin
if rising_edge (Clk) then
if Bool then
Bool <= not Bool;
Q7 <= not Q7; -- should be undriven
Bool2 <= not Bool; -- shoudl generate no logic
end if;
end if;
end process;

process (Clk)
begin
if rising_edge (Clk) then
if not Bool then
Q5 <= not Q5; -- should toggle
Q(8) <= Initd; -- could be anything after synthesis : 0 or 1 or nothing or ...
end if;
end if;
end process;

process (Clk)
begin
if rising_edge (Clk) then
count <= count + 1;
end if;
end process;

Q(3 downto 0) <= std_logic_vector(count);
Q(4) <= InitZ; -- should be a tristated output !
Q(5) <= Q5;
Q(6) <= Q6 and Init1; -- expect toggling at F/8
Q(7) <= Init1; -- expected 1

end questionable;

------test Bench-----------------------------
-- synopsys translate_off
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use IEEE.math_real.all;
entity TB_SigInit is end;
architecture test of TB_SigInit is
constant Period : time := 400 ns; -- 1st rising edge must be away from timesim
internal reset
signal Qrtl,Qpost : std_logic_vector(8 downto 0);
signal Clk,En,Din : std_logic := '0'; -- here we can initialize signals
signal Done : boolean;
begin
UUT1: entity work.SigInit(BAD) port map (Clk,En,Din,Qrtl);
-- change arch name below to timesim model
UUT2: entity work.SigInit(Structure) port map (Clk,En,Din,Qpost);
Clk <= '0' when Done else not Clk after Period / 2;
En <= '1' after 5 * Period;
Done <= true after 32 * Period;
assert not(falling_edge(Clk) and Qrtl(3 downto 0)/=Qpost(3 downto 0))
report "Q3..0: RTL vs Simulation mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(4)/=Qpost(4))
report "Q4: RTL vs Gates mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(5)/=Qpost(5))
report "Q5: RTL vs Gates mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(6)/=Qpost(6))
report "Q6: RTL vs Gates mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(7)/=Qpost(7))
report "Q7: RTL vs Gates mismatch!" severity error;
end test;
----- Simu.do --------
-- vlib work
-- vcom -93 siginit_timesim.vhd
-- vcom -93 siginit.vhd
-- #vcom -93 tb_siginit.vhd
-- vsim -noglitch -sdftyp /uut2=siginit_timesim.sdf tb_siginit
-- add wave clk
-- add wave en
-- add wave din
-- add wave uut1/state
-- add wave qrtl
-- add wave qpost
-- run -a
-- ---------------------------------------------

 

[info_]

Hi Walter,

Thanks a lot indeed for bringing this interesting subject !

I noticed a while ago that some synthesis tools made attempts in implementing signal
initialization at declaration, and I didn't like the idea very much.

You mention ISE, and it is among those who try (and, to some extend, succeed).
However, I just checked and it missed the tristate ! So, for me, it's still a no-go.

I've written a complete test so that anyone can try with any technology and any
synthesis tool and take an educated decision... (and let me know !)

Anyway, it's a too potentially dangerous practice, and I know that this fails with
some synthesizers, P&R, and FPGAs, so I will keep my rule set unchanged, and once
again mention that, with good reasons and experience, any rule (almost) can be bent.
For example, we don't deliver code to our customers which isn't ASIC-friendly (as
much as possible), so this tule is enforced.

I will change the rule when :
- it will be normalized in 1076.6 (is it ? I didn't check the future version)
- all synthesis tools will pass this test
- all tech mappers will pass this test
- all physical synthesis tools will keep the functioanlity
- all FPGAs will implement this flawlessly
- it will be considered as ASIC-friendly code.
until then I will consider this practice as an exception which requires justification
and verification.

Here comes the test. ISE fails at Q4 (tristate) but does a good job on the rest.
If anyone tests other tools and technologies, please send me the results !
(i_n_f_o at alse-fr with no underscore. Add dot com indeed)

Bert Cuzeau

--------------
-- SigInit.vhd
-- ---------------------------------------------
-- Testing Initialized Signals implementation
-- ---------------------------------------------
-- (c) ALSE http://www.alse-fr.com
-- Author : Bert Cuzeau
-- THIS STYLE IS NOT RECOMMENDED !
-- You may use this to check your FPGA technology and tools.

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

-- ---------------------------------------
Entity SigInit is
-- ---------------------------------------
Port ( Clk : In std_logic;
--Rst : In std_logic; -- not anymore
En : In std_logic;
Din : in std_logic;
Q : Out std_logic_vector (8 downto 0) );
end ;

-- ---------------------------------------
Architecture questionable of SigInit is
-- ---------------------------------------

type State_t is (A, B, C, Idle, Dead);

-- Things NOT to do IMO !!! >>>>>
signal InitZ : std_logic := 'Z';
signal Init0 : std_logic := '0';
signal Init1 : std_logic := '1';
signal Initd : std_logic := '-';
signal count : unsigned(3 downto 0) := "1010";
signal Bool : boolean; -- initialized to false at t=0.
signal Bool2 : boolean; -- initialized to false at t=0.

signal State : State_T := Idle;
signal Q5 : std_logic := '1';
signal Q6 : std_logic := '0';
-- <<<<<
signal Q7 : std_logic;

begin
------

process (Clk)
begin
if rising_edge (Clk) then
if En='1' then
case State is
when A => State <= B;
when B => State <= C;
when C => if not Bool then State <= Idle; end if;
when Idle => State <= A; Q6 <= not Q6;
When Dead => null;
end case;
end if;
end if;
end process;

process (Clk)
begin
if rising_edge (Clk) then
if Bool then
Bool <= not Bool;
Q7 <= not Q7; -- should be undriven
Bool2 <= not Bool; -- shoudl generate no logic
end if;
end if;
end process;

process (Clk)
begin
if rising_edge (Clk) then
if not Bool then
Q5 <= not Q5; -- should toggle
Q(8) <= Initd; -- could be anything after synthesis : 0 or 1 or nothing or ...
end if;
end if;
end process;

process (Clk)
begin
if rising_edge (Clk) then
count <= count + 1;
end if;
end process;

Q(3 downto 0) <= std_logic_vector(count);
Q(4) <= InitZ; -- should be a tristated output !
Q(5) <= Q5;
Q(6) <= Q6 and Init1; -- expect toggling at F/8
Q(7) <= Init1; -- expected 1

end questionable;

------test Bench-----------------------------
-- synopsys translate_off
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use IEEE.math_real.all;
entity TB_SigInit is end;
architecture test of TB_SigInit is
constant Period : time := 400 ns; -- 1st rising edge must be away from timesim
internal reset
signal Qrtl,Qpost : std_logic_vector(8 downto 0);
signal Clk,En,Din : std_logic := '0'; -- here we can initialize signals
signal Done : boolean;
begin
UUT1: entity work.SigInit(BAD) port map (Clk,En,Din,Qrtl);
-- change arch name below to timesim model
UUT2: entity work.SigInit(Structure) port map (Clk,En,Din,Qpost);
Clk <= '0' when Done else not Clk after Period / 2;
En <= '1' after 5 * Period;
Done <= true after 32 * Period;
assert not(falling_edge(Clk) and Qrtl(3 downto 0)/=Qpost(3 downto 0))
report "Q3..0: RTL vs Simulation mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(4)/=Qpost(4))
report "Q4: RTL vs Gates mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(5)/=Qpost(5))
report "Q5: RTL vs Gates mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(6)/=Qpost(6))
report "Q6: RTL vs Gates mismatch!" severity error;
assert not(falling_edge(Clk) and Qrtl(7)/=Qpost(7))
report "Q7: RTL vs Gates mismatch!" severity error;
end test;
----- Simu.do --------
-- vlib work
-- vcom -93 siginit_timesim.vhd
-- vcom -93 siginit.vhd
-- #vcom -93 tb_siginit.vhd
-- vsim -noglitch -sdftyp /uut2=siginit_timesim.sdf tb_siginit
-- add wave clk
-- add wave en
-- add wave din
-- add wave uut1/state
-- add wave qrtl
-- add wave qpost
-- run -a
-- ---------------------------------------------

 

[Mike Treseler]

info_ wrote:

Hi Walter,

Thanks a lot indeed for bringing this interesting subject !
If anyone tests other tools and technologies, please send me the results !

See warnings below for leo and quartus.
-- Mike Treseler

-----------------------------
Here's what leo 2004 says
see: http://home.comcast.net/~mike_treseler/no_reset_leo.pdf

-- Loading architecture questionable of SigInit into library work
"H:/vhdl/play/no_reset.vhd",line 73: Warning, signal Init0 is never used.
"H:/vhdl/play/no_reset.vhd",line 78: Warning, signal Bool2 is never used.
"H:/vhdl/play/no_reset.vhd",line 61: Warning, input Din is never used.
-- Compiling root entity SigInit(questionable)
"H:/vhdl/play/no_reset.vhd",line 76: Warning, initial value for count is
ignored for synthesis.
"H:/vhdl/play/no_reset.vhd",line 80: Warning, initial value for State is
ignored for synthesis.
"H:/vhdl/play/no_reset.vhd",line 81: Warning, initial value for Q5 is
ignored for synthesis.
"H:/vhdl/play/no_reset.vhd",line 82: Warning, initial value for Q6 is
ignored for synthesis.
-- Pre Optimizing Design .work.SigInit.questionable
-- Boundary optimization.
"H:/vhdl/play/no_reset.vhd", line 128:Info, Inferred counter instance
'Q' of type 'counter_up_clock_4'
Info: Finished reading design
->_gc_run
-- Run Started On Mon Mar 28 11:46:06 Pacific Daylight Time 2005
--
Info: setting tristate_map to TRUE
Info: setting modgen_select to small
-- optimize -target stratix -effort quick -chip -area -hierarchy=auto
Using default wire table: stratix_default
-- Start optimization for design .work.SigInit.questionable
Using default wire table: stratix_default
Warning, port Q(8) is connected to a disabled tristate, possibly
unconnected port in design.
Warning, port Q(4) is connected to a disabled tristate, possibly
unconnected port in design.
------------------------------------------

Here's what quartus 4.2 says about it.
See
http://home.comcast.net/~mike_treseler/no_reset.pdf

Info: Running Quartus II Analysis & Synthesis
Info: Version 4.2 Build 157 12/07/2004 SJ Full Version
Info: Processing started: Mon Mar 28 12:01:06 2005
Info: Command: quartus_map --import_settings_files=on
--export_settings_files=off no_reset -c SigInit
Info: Found 2 design units, including 1 entities, in source file
.../no_reset.vhd
Info: Found design unit 1: SigInit-questionable
Info: Found entity 1: SigInit
Warning: VHDL Signal Declaration warning at no_reset.vhd(72): used
explicit default value for signal "InitZ" because signal was never
assigned a value
Warning: VHDL Signal Declaration warning at no_reset.vhd(74): used
explicit default value for signal "Init1" because signal was never
assigned a value
Warning: VHDL Signal Declaration warning at no_reset.vhd(75): used
explicit default value for signal "Initd" because signal was never
assigned a value
Warning: VHDL Signal Declaration warning at no_reset.vhd(76): ignored
default value for signal "count"
Warning: VHDL Signal Declaration warning at no_reset.vhd(80): ignored
default value for signal "State"
Warning: VHDL Signal Declaration warning at no_reset.vhd(81): ignored
default value for signal "Q5"
Warning: VHDL Signal Declaration warning at no_reset.vhd(82): ignored
default value for signal "Q6"
Warning: Reduced register "Bool" with stuck data_in port to stuck value GND
Info: State machine "|SigInit|State" contains 5 states and 0 state bits
Info: Selected Auto state machine encoding method for state machine
"|SigInit|State"
Info: Encoding result for state machine "|SigInit|State"
Info: Completed encoding using 5 state bits
Info: Encoded state bit "State.dead"
Info: Encoded state bit "State.idle"
Info: Encoded state bit "State.c"
Info: Encoded state bit "State.b"
Info: Encoded state bit "State.a"
Info: State "|SigInit|State.a" uses code string "00000"
Info: State "|SigInit|State.b" uses code string "00011"
Info: State "|SigInit|State.c" uses code string "00101"
Info: State "|SigInit|State.idle" uses code string "01001"
Info: State "|SigInit|State.dead" uses code string "10001"
Warning: Reduced register "State.dead" with stuck data_in port to stuck
value GND
Info: Inferred 1 megafunctions from design logic
Info: Inferred lpm_counter megafunction (LPM_WIDTH=4) from the
following logic: "count[0]~4"
Info: Found 1 design units, including 1 entities, in source file
d:/altera/quartus42/libraries/megafunctions/lpm_counter.tdf
Info: Found entity 1: lpm_counter
Info: Found 1 design units, including 1 entities, in source file
db/cntr_et6.tdf
Info: Found entity 1: cntr_et6
Warning: TRI or OPNDRN buffers permanently disabled
Warning: Node "Q~1"
Warning: Output pins are stuck at VCC or GND
Warning: Pin "Q[8]" stuck at GND
Warning: Pin "Q[7]" stuck at VCC
Warning: Design contains 1 input pin(s) that do not drive logic
Warning: No output dependent on input pin "Din"
Info: Implemented 23 device resources after synthesis - the final
resource count might be different
Info: Implemented 3 input pins
Info: Implemented 9 output pins
Info: Implemented 11 logic cells
Info: Quartus II Analysis & Synthesis was successful. 0 errors, 16 warnings
Info: Processing ended: Mon Mar 28 12:01:17 2005
Info: Elapsed time: 00:00:13

 

[info_]

Thanks Mike,

Precision synthesis seems to do a very good job.

XST just goofs on the disabled tristate (but says so).
(and it seems it's another XST bug)

Synplify was reported to do fine too.

I still stick to my rule
But I sure will elaborate about this in the next release of the rule set !

Thx everybody for participating.

Bert Cuzeau

 

[Mike Treseler]

Walter Dvorak wrote:

Sorry, but thats not correct in general for up to date
synthesize tools. You could be right if you refer the early days
of VHDL synthesis, mainly used for ASIC designs.

I use Leo and Quartus for synthesis,
and the latest versions can not do this trick yet.
I think having this option would be a good
thing for FPGAs since they do their own reset during download.

On the other hand, the resources for distributing
a user reset are also available on FPGAs
and I might hesitate to give up the option
of reseting the device without doing
a complete download.


-- Mike Treseler

 

[info_]

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