Re: I hate VHDL!!!

Discussion in 'VHDL' started by Tom Verbeure, Jul 19, 2004.

  1. Tom  Verbeure

    Tom Verbeure Guest

    Weng,

    > I have posed my long 'if..elsif..endif' statement on the google with
    > clear compilation results to prove that 'if..elsif..endif' statement
    > is not only code inefficient in theory, but also in practice.


    how did you do the 'manual' optimization? Did you dive into the
    schematic of it or did you use the manual 'or' of the vector, which is
    a fairly trivial change...

    Tom
     
    Tom Verbeure, Jul 19, 2004
    #1
    1. Advertising

  2. Jim,
    >> Another question is why VHDL committee is so adamant not to

    introduce
    >> conditional statements widely used in C, C++.

    > Perhaps we might need something more powerful.
    > No time right now. I will follow up on this later.


    My advice is, if C/C++ has been using them, not to invent new wheels
    for it.


    >> For now, why not use CPP?


    I had written a very good C program to handle it so nice that I have
    been using them everyday!!! I couldn't put the source code on this
    website, because it is my company's property eventhough I wrote it.
    For a good language, it must include #define... statements without any
    doubt to facilitate programming when projects become larger than ever
    and the momentum is huge.

    I would say it would have been better if I had wrote it 4 years ago.
    Without it I cannot finish current two projects.

    Here is another point your committee should pay attention to:
    sensitivity list!

    They are garbage, no body needs it. Why don't you propose to change
    it? We have to wait for another 20 years?

    Here is an example: 57 signals! You may think how much times I spent
    not to miss anyone.

    SDRAMStateB : process(SDRAMState, nRESETGlobal, ExpireCountTimeOut,
    FrequencyStatus,
    MTInSDRAMWrite, MTInSDRAMRead, WriteFIFOEmpty, TAddressClock,
    Fail5V_3V,
    ActiveExpireRead, RefreshState, MReadFIFOHit, nPowerReady_R,
    FlashTimer14Hz,
    CommandBitOut, CKE_O, CommandBitIn, ReadStatus, ActiveExpireWrite,
    TReadSDRAMState,
    WriteFIFOAllByte_0_1, DQ_R1_SyndromeOK, TReadSDRAMIdle, IState,
    TState,
    NextBankNotPreActive, ReadFIFOPreFull, WriteNewPage,
    WriteFIFOWriteEnable,
    ReadNewPage, SendBurstRead_B, ActiveState, ChipReady, Wait8ms,
    WriteFIFOInjectWrite, BankState, WriteFIFOByteEnable,
    ClearSendBurstRead_B,
    AutoRefresh0State, AutoRefresh1State, TReadSDRAMWait0,
    TReadSDRAMHit_S0,
    AutoRefresh2State, AutoRefresh3State, TReadFIFOHit, RowChipPtr,
    TWriteSDRAMHit_S0,
    RefreshCountCout, nC_BE_R0, TWriteSDRAMState, CSRModeReg,
    ReadDataAtDQ_R0,
    DMAState, DMADirection, InBurstRead, DMAPreReadSDRAMStart,
    DMAReadDataReady)

    The above 3 things: 'orif', '#define..' statement and process(*) are
    small things, but has huge consequences: Your committee should pay
    more attention to the real problems, be effective!

    Weng
     
    Weng Tianxiang, Jul 21, 2004
    #2
    1. Advertising

  3. Tom  Verbeure

    Jim Lewis Guest

    Weng,
    > Here is another point your committee should pay attention to:
    > sensitivity list!
    >
    > Why don't you propose to change it?


    Already did. See the fast track proposals at:
    http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/proposals.html

    See FT-19
    It would be better if you would educate yourself about
    what the working group is currently doing before
    mouthing off like this.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Jul 25, 2004
    #3
  4. Hi,

    Weng Tianxiang wrote:

    >Jim,
    >
    >
    >>>Another question is why VHDL committee is so adamant not to
    >>>
    >>>

    >introduce
    >
    >
    >>>conditional statements widely used in C, C++.
    >>>
    >>>

    >>Perhaps we might need something more powerful.
    >>No time right now. I will follow up on this later.
    >>
    >>

    >
    >My advice is, if C/C++ has been using them, not to invent new wheels
    >for it.
    >
    >
    >

    If you discuss with lot of programmer, they can said you that lot of
    them dislike C/C++
    Lot of programmer preferred java, or other language. It seems that C/C++
    is not well suited for new applications under development.

    >
    >
    >>>For now, why not use CPP?
    >>>
    >>>

    >
    >I had written a very good C program to handle it so nice that I have
    >been using them everyday!!! I couldn't put the source code on this
    >website, because it is my company's property eventhough I wrote it.
    >For a good language, it must include #define... statements without any
    >doubt to facilitate programming when projects become larger than ever
    >and the momentum is huge.
    >
    >

    #define and other statement #... are preprocessing instruction, then
    they are now influence on following steps.

    Do you know that usage of #define and other preprocessing command can
    give some problems with usage of formal verification ?
    Because they can introduce some implicit behaviors, but formal
    verification is better with explicit behaviors.

    ><snip>
    >
    >Here is an example: 57 signals! You may think how much times I spent
    >not to miss anyone.
    >
    >SDRAMStateB : process(SDRAMState, nRESETGlobal, ExpireCountTimeOut,
    >FrequencyStatus,
    > MTInSDRAMWrite, MTInSDRAMRead, WriteFIFOEmpty, TAddressClock,
    >Fail5V_3V,
    > ActiveExpireRead, RefreshState, MReadFIFOHit, nPowerReady_R,
    >FlashTimer14Hz,
    > CommandBitOut, CKE_O, CommandBitIn, ReadStatus, ActiveExpireWrite,
    >TReadSDRAMState,
    > WriteFIFOAllByte_0_1, DQ_R1_SyndromeOK, TReadSDRAMIdle, IState,
    >TState,
    > NextBankNotPreActive, ReadFIFOPreFull, WriteNewPage,
    >WriteFIFOWriteEnable,
    > ReadNewPage, SendBurstRead_B, ActiveState, ChipReady, Wait8ms,
    > WriteFIFOInjectWrite, BankState, WriteFIFOByteEnable,
    >ClearSendBurstRead_B,
    > AutoRefresh0State, AutoRefresh1State, TReadSDRAMWait0,
    >TReadSDRAMHit_S0,
    > AutoRefresh2State, AutoRefresh3State, TReadFIFOHit, RowChipPtr,
    >TWriteSDRAMHit_S0,
    > RefreshCountCout, nC_BE_R0, TWriteSDRAMState, CSRModeReg,
    >ReadDataAtDQ_R0,
    > DMAState, DMADirection, InBurstRead, DMAPreReadSDRAMStart,
    >DMAReadDataReady)
    >
    >

    Do you know that you can some useful editor that can help you to write
    your code ? as (X)emacs and its vhdl-mode ;-)
    In the vhdl-mode, you have an automatic function that refresh you the
    sensitivity list of a process (Ctrl-C+Ctrl-u+Ctrl-s) or all sensitivity
    lists of the buffer (Ctrl-C+Ctrl-u+Meta-s).
    This is a freeware tool, that you can easily include in your development
    flow at low cost. It seems that Xemacs has been ported under all
    classical platforms (windows, mac, unix/linux).

    But it is a little curious for me to find a so big list of sensitivity,
    because I remember that some fpga design rules limit the size of
    sensitivity list to 20 or 30 signals (perhaps change since 1998).

    >The above 3 things: 'orif', '#define..' statement and process(*) are
    >

    process (*) is an aberration. Yes it can be help you to write quickly
    your code; but all your simulation and synthesizer tools will go to do
    lot of unnecessary work.
    And that work against your orif proposal at the end.

    The process (*) includes all signals of the design into the sensitivity
    list of the process. If you have the following code:

    c <= a and b;

    myProcess : process (*)
    if (resetn='0') then
    d <= '0';
    elsif (clk'event and clk='1') then
    d <= e;
    endif;

    The process myProcess must be evaluated on each modification of 'a', 'b'
    and 'c', event if 'e', 'clk' or 'resetn' are independent of 'a','b' and 'c'

    The introduction of (*) as sensitivity list require the modification of
    section 12.6 of the ieee 1076 into a very complex mechanism.

    Last point, without an explicit sensitivity list, you can hide some
    connectivity error, that can be very hard to find.
    Take as example a design with very similar syntax of signals or
    variables as reset and resetn.
    Or a design with a signal and a variable with the same syntax. In the
    process the variable is taken if the signal is not in the sensitivity
    list, otherwise it is an error.

    The solution proposed by Jim Lewis is better.

    >small things, but has huge consequences: Your committee should pay
    >more attention to the real problems, be effective!
    >
    >

    The design is not the only phase that use the vhdl. When you make a
    proposal, you need evaluate its impact on all the design and
    verification flow that handle vhdl.
    Your 'real' problem can be come from other source that vhdl language.
    Example: the design rule that limit the number of signal into a
    sensitivity list is not given by language, but by eda tools themselves.

    >Weng
    >
    >

    JaI
     
    Just an Illusion, Jul 26, 2004
    #4
  5. Modify process_statement definition in clause 9.2 to:
    process_statement ::=
    [ process_label : ]
    [ postponed ] process_kind [ is ]
    process_declarative_part
    begin
    process_statement_part
    end [ postponed ] process [ process_label ] ;


    Add definition for process_sensitivity in clause 9.2:
    process_kind ::=
    process [ ( sensitivity_list ) ]
    | process_comb
    | process_latch
    | process_ff

    It should be better like this way:
    Add definition for process_sensitivity in clause 9.2:
    process_kind ::=
    process [ ( sensitivity_list ) ]
    | process [ ( * ) ]

    No any langauge I have known in the world uses keywords that contain
    '_'. I really don't know why you want ot invent new wheels. process(*)
    is introduced by Verilog, it is a very good idea!

    Weng
     
    Weng Tianxiang, Jul 26, 2004
    #5
  6. JaI,
    > process (*) is an aberration. Yes it can be help you to write quickly
    > your code; but all your simulation and synthesizer tools will go to do
    > lot of unnecessary work.
    > And that work against your orif proposal at the end.


    > The process (*) includes all signals of the design into the sensitivity
    > list of the process. If you have the following code:


    > c <= a and b;


    > myProcess : process (*)
    > if (resetn='0') then
    > d <= '0';
    > elsif (clk'event and clk='1') then
    > d <= e;
    > endif;


    > The process myProcess must be evaluated on each modification of 'a', 'b'
    > and 'c', event if 'e', 'clk' or 'resetn' are independent of 'a','b' and 'c'


    You disagree with your opinion.

    I guess that why sensitivity list was introduced into VHDL/Verilog 25
    years ago was the consideration to the memory size limit and software
    handling limit. At 25 years ago, it was very difficult to pick up the
    sensitivity list by software.

    Now situations are totally different from 25 years ago. Do we need to
    differentiate 3 cases: dff, comp or latch? Software cannot do that? My
    deep believe that software can do it now at easy and as much better
    and faster than any experienced programmers to pick up any signals
    for sensitivity.

    Weng
     
    Weng Tianxiang, Jul 27, 2004
    #6
  7. Hi Weng,

    Weng Tianxiang wrote:

    >JaI,
    >
    >
    >>process (*) is an aberration. Yes it can be help you to write quickly
    >>your code; but all your simulation and synthesizer tools will go to do
    >>lot of unnecessary work.
    >>And that work against your orif proposal at the end.
    >>
    >>

    >
    >
    >
    >>The process (*) includes all signals of the design into the sensitivity
    >>list of the process. If you have the following code:
    >>
    >>

    >
    >
    >
    >>c <= a and b;
    >>
    >>

    >
    >
    >
    >>myProcess : process (*)
    >>if (resetn='0') then
    >> d <= '0';
    >>elsif (clk'event and clk='1') then
    >> d <= e;
    >>endif;
    >>
    >>

    >
    >
    >
    >>The process myProcess must be evaluated on each modification of 'a', 'b'
    >>and 'c', event if 'e', 'clk' or 'resetn' are independent of 'a','b' and 'c'
    >>
    >>

    >
    >You disagree with your opinion.
    >
    >I guess that why sensitivity list was introduced into VHDL/Verilog 25
    >years ago was the consideration to the memory size limit and software
    >handling limit. At 25 years ago, it was very difficult to pick up the
    >sensitivity list by software.
    >
    >Now situations are totally different from 25 years ago. Do we need to
    >differentiate 3 cases: dff, comp or latch? Software cannot do that? My
    >deep believe that software can do it now at easy and as much better
    >and faster than any experienced programmers to pick up any signals
    >for sensitivity.
    >
    >

    I don't know history of sensitivity list, but usage of (*) as sensitive
    list can change your expected result

    Take codes:

    NotLatch : process (g)
    begin
    if (g='1') then
    q<=d;
    end if;
    end process;

    IsLatch : process (*)
    begin
    if (g='1') then
    q<=d;
    end if;
    end process;

    The both are similar, but according to section 12.6 of the lrm, the
    first process is a flip-flop and the second (according to verilog
    sensitivity notation) must be a d-latch.

    You have an other problem, the interpretation queue ordering for the
    following code:

    process (*)
    begin
    if (g='1') then
    a<= not b;
    b<=a;
    endif;
    end process;

    According to verilog notation, it must be equivalent to:
    process (g,a,b)
    begin
    if (g='1') then
    a<= not b;
    b<=a;
    end if;
    end process;

    But in that case, you have a problem according to section 12.6 of the lrm.
    If you have only (g) in sensitivity list, you are safe.

    That is an example of danger with (*)

    >Weng
    >
    >

    JaI
     
    Just an Illusion, Jul 27, 2004
    #7
  8. Hi Weng,

    Weng Tianxiang wrote:

    ><snip>
    >No any langauge I have known in the world uses keywords that contain
    >'_'. I really don't know why you want ot invent new wheels. process(*)
    >is introduced by Verilog, it is a very good idea!
    >
    >

    *joke* So you know a very small of them ;-) *end of joke*
    For your information ansi C have reserved keyword with '_', they are
    macro as __DATE__, __TIME__, __FILE__, __LINE__, __STDC__ and specific
    function as __stdcall, __inline, etc.
    You have Verilog with some compiler directive and PLI functions.
    In VHDL throught use of VITAL library (ieee 1076.4)

    You ceratinly can find some other examples, but the three languages are
    the must common used be us.

    >Weng
    >
    >

    JaI
     
    Just an Illusion, Jul 27, 2004
    #8
  9. Tom  Verbeure

    ALuPin Guest

    Hi Weng Tianxiang,

    don't you think that it is sufficient now?

    It is time for your subject name to "disappear" ,o)

    Kind regards
     
    ALuPin, Jul 27, 2004
    #9
  10. Tom  Verbeure

    Wallclimber Guest

    > Take codes:
    >
    > NotLatch : process (g)
    > begin
    > if (g='1') then
    > q<=d;
    > end if;
    > end process;
    >
    > IsLatch : process (*)
    > begin
    > if (g='1') then
    > q<=d;
    > end if;
    > end process;
    >
    > The both are similar, but according to section 12.6 of the lrm, the
    > first process is a flip-flop and the second (according to verilog
    > sensitivity notation) must be a d-latch.


    You either have a very creative way of reading the specification or
    you're reading a different document. Section 12.6 is called "Execution
    of a model". Except for some instance names in code examples in the
    first 22 pages, the LRM doesn't even use the word 'latch'.

    Jim,
    I have to side with Weng here. Simply define the '*' in process(*) as
    an expansion of all signals that are read in the process. If this is
    not what the writer want, just use the old method... This is most in
    line with the original intention of VHDL where you describe a
    simulation behavior without targetting specific synthesis behavior.

    Tom
     
    Wallclimber, Jul 27, 2004
    #10
  11. Hi Wallclimber,

    Wallclimber wrote:

    >>Take codes:
    >>
    >>NotLatch : process (g)
    >>begin
    >> if (g='1') then
    >> q<=d;
    >> end if;
    >>end process;
    >>
    >>IsLatch : process (*)
    >>begin
    >> if (g='1') then
    >> q<=d;
    >> end if;
    >>end process;
    >>
    >>The both are similar, but according to section 12.6 of the lrm, the
    >>first process is a flip-flop and the second (according to verilog
    >>sensitivity notation) must be a d-latch.
    >>
    >>

    >
    >You either have a very creative way of reading the specification or
    >you're reading a different document. Section 12.6 is called "Execution
    >of a model". Except for some instance names in code examples in the
    >first 22 pages, the LRM doesn't even use the word 'latch'.
    >
    >

    You are right, okay I change my words:
    First is a register that is wake up by any event on 'g' that make change
    it's value from 1 to another (that is not 1), that is a 'flip-flop'
    Second is a register that is wake up by any event on 'g' or 'd', that is
    a register which is drive by state (not edge).

    >Jim,
    >I have to side with Weng here. Simply define the '*' in process(*) as
    >an expansion of all signals that are read in the process. If this is
    >not what the writer want, just use the old method... This is most in
    >line with the original intention of VHDL where you describe a
    >simulation behavior without targetting specific synthesis behavior.
    >
    >

    The semantic (I dislike this word, because lot of people use this term
    only to justify their opposition) of * is not what you proposed, the *
    semantic is equivalent to include any signals of the design, not only
    signals of the process.

    To me, I think than (*) is very dangerous.

    I'll take a (real) example, I have the following code:

    clk_inv <= not clk;

    process (clk, resetn)
    begin
    if (resetn='0') then
    q <= '0';
    elsif (clk_inv'event and clk_inv='1') then
    q <= d;
    end if;
    end process;

    This code don't give specific error in simulation, except than
    compilation, linting tool or rule-checker must generate a warning at least.

    This error, on sensitivity list, come from a copy-paste without refresh
    of sensitivity list; in that case the modification from clk to clk_inv
    is normal (and the sensitivity list must be updated accordingly).
    Now take the example and imagine the same case but with a typo error on
    clk name, which is an other existing signal of the design.
    If the sensitivity list is (*), I have no way to flag the typo error.
    And possibly no tests fail, except perhaps in very hard to find corner
    case (if both signal have similar behavior, except under very specific
    cases).
    After ASIC synthesis, you can have some timing problem due to not well
    balanced clock tree.
    Discovering error at this stage, it is very consuming of time and money;
    all of this because you have don't put explicite sensitivity list, than
    a linting tool, a rule-checker or the compiler can flag you in few minutes.

    You have similar remark for Jim proposal, but in that case you use an
    explicite structure which must be intrepreted as edge or state register.

    >Tom
    >
    >

    JaI
     
    Just an Illusion, Jul 28, 2004
    #11
  12. Tom  Verbeure

    Jim Lewis Guest

    Weng,
    > ... process(*)
    > is introduced by Verilog, it is a very good idea!


    Ironically SystemVerilog is moving on to:
    always_comb, always_latch, and always_ff

    So here for once we get to copy from Verilog and
    take advantage of their lessons learned.

    For RTL design, the added keywords carry the intent of the
    sensitivity list without making you type it. You will not
    get this with "(*)".

    For example, in addition to meaning "(*)" _comb indicates
    the process only creates combinational logic. If you
    inadvertently create latches (the #1 or #2 problem in a
    statemachines), then the synthesis tool is to produce and
    error and not create any hardware.

    Regards,
    Jim


    > Modify process_statement definition in clause 9.2 to:
    > process_statement ::=
    > [ process_label : ]
    > [ postponed ] process_kind [ is ]
    > process_declarative_part
    > begin
    > process_statement_part
    > end [ postponed ] process [ process_label ] ;
    >
    >
    > Add definition for process_sensitivity in clause 9.2:
    > process_kind ::=
    > process [ ( sensitivity_list ) ]
    > | process_comb
    > | process_latch
    > | process_ff
    >
    > It should be better like this way:
    > Add definition for process_sensitivity in clause 9.2:
    > process_kind ::=
    > process [ ( sensitivity_list ) ]
    > | process [ ( * ) ]
    >
    > No any langauge I have known in the world uses keywords that contain
    > '_'. I really don't know why you want ot invent new wheels. process(*)
    > is introduced by Verilog, it is a very good idea!
    >
    > Weng



    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Jul 31, 2004
    #12
    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. Weng Tianxiang

    I hate VHDL!!!

    Weng Tianxiang, Jun 3, 2004, in forum: VHDL
    Replies:
    51
    Views:
    5,150
    roller
    Jun 19, 2004
  2. Jim Lewis

    Re: I hate VHDL!!!

    Jim Lewis, Jun 25, 2004, in forum: VHDL
    Replies:
    14
    Views:
    1,156
    Just an Illusion
    Jul 5, 2004
  3. Just an Illusion

    Re: I hate VHDL!!!

    Just an Illusion, Jun 25, 2004, in forum: VHDL
    Replies:
    7
    Views:
    709
    Jim Lewis
    Jul 17, 2004
  4. Tom  Verbeure

    Re: I hate VHDL!!!

    Tom Verbeure, Jul 28, 2004, in forum: VHDL
    Replies:
    3
    Views:
    563
    Wallclimber
    Jul 29, 2004
  5. afd
    Replies:
    1
    Views:
    8,414
    Colin Paul Gloster
    Mar 23, 2007
Loading...

Share This Page