VHDL Coding Style Guide

Discussion in 'VHDL' started by Bert Cuzeau, Mar 24, 2005.

  1. Bert Cuzeau

    Bert Cuzeau Guest

    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, Mar 24, 2005
    #1
    1. Advertising

  2. 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, Mar 25, 2005
    #2
    1. Advertising

  3. 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, Mar 25, 2005
    #3
  4. Bert Cuzeau

    Bert Cuzeau Guest

    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, Mar 25, 2005
    #4
  5. Bert Cuzeau

    Bert Cuzeau Guest

    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, Mar 25, 2005
    #5
  6. 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, Mar 25, 2005
    #6
  7. Bert Cuzeau

    KCL Guest

    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, Mar 25, 2005
    #7
  8. Bert Cuzeau

    KCL Guest

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


    "KCL" <> 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, Mar 25, 2005
    #8
  9. Mike Treseler, Mar 25, 2005
    #9
  10. Bert Cuzeau

    info_ Guest

    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_, Mar 26, 2005
    #10
  11. 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.


    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,


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


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


    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


    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.
    Mohammed A khader, Mar 26, 2005
    #11
  12. Bert Cuzeau

    info_ Guest

    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
    info_, Mar 26, 2005
    #12
  13. Bert Cuzeau <_no_spa_m_info_no_underscore_@alse-fr___.com> wrote:
    > A (new) draft of my (old) VHDL Coding Rules is available [...]


    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
    --
    Walter Dvorak, Mar 27, 2005
    #13
  14. 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
    Mike Treseler, Mar 27, 2005
    #14
  15. Bert Cuzeau

    info_ Guest

    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
    info_, Mar 27, 2005
    #15
  16. Mike Treseler <> 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, Mar 27, 2005
    #16
  17. 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
    --
    Walter Dvorak, Mar 27, 2005
    #17
  18. Bert Cuzeau

    info_ Guest

    Signals Init ar decl

    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_, Mar 27, 2005
    #18
  19. Bert Cuzeau

    info_ Guest

    Signals Init ar decl

    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_, Mar 27, 2005
    #19
  20. Re: Signals Init ar decl

    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
    Mike Treseler, Mar 28, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. calmar
    Replies:
    11
    Views:
    777
    calmar
    Feb 21, 2006
  2. afd
    Replies:
    1
    Views:
    8,299
    Colin Paul Gloster
    Mar 23, 2007
  3. Amal
    Replies:
    1
    Views:
    1,745
    vipinlal
    Mar 4, 2010
  4. svleest
    Replies:
    0
    Views:
    844
    svleest
    Feb 25, 2011
  5. Ken Varn
    Replies:
    0
    Views:
    439
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page