Re: I hate VHDL!!!

Discussion in 'VHDL' started by Jim Lewis, Jun 25, 2004.

  1. Jim Lewis

    Jim Lewis Guest

    Weng,
    > OK, at last Jim and JaI admit my equation is right.

    I did not actually say I agreed it is correct.
    I agreed that when you divulged there were additional
    conditions that made A and C mutually exclusive that
    the circuit would work the way you described.

    >>A1 <= A and B;
    >>C1 <= C and B;


    Note that under the conditions you describe, orif and elsif
    should synthesize equally well (because if the synthesis tool
    understands terms are mutually exclusive, then it does
    not need orif). Also note that you are relying on the
    synthesis tool to derive the mutual exclusion (otherwise
    the only thing it knows is that A1 and C1 are mutually
    exclusive).

    If you use "orif", and the synthesis tool cannot derive
    the mutual exclusion, then you are back to the tool
    understanding that A1 and C1 (because of the orif)
    being mutually exclusive, but not A and C.

    So what you have done for me is to demonstrate how difficult
    it is for people (yourself included) to full comprehend
    the implications of orif.


    > Tomorrow I will 'attack' Achilles heel of Jim's proposal assert()
    > to resolve mutually exclusive relations.

    Bring it on. You have yet to demonstrate any limitations.
    So far you have only further convinced me that assert is the
    better answer.

    It would also be helpful if you could post some reasonable
    sized examples which use orif.

    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, Jun 25, 2004
    #1
    1. Advertising

  2. Jim,
    > If you use "orif", and the synthesis tool cannot derive the mutual exclusion


    "orif" is used to TELL compiler that the relating conditions are
    mutually exclusive, no any doubt, do it and optimize the code for me.

    The most important reason why 'orif' is suggested is currently popular
    VHDL compilers are not as smart as we thought. I have used: Exemplar(1
    years ago) and Xilinx(6.01), neither of them can optimize code the way
    my paper suggested.

    So 'orif' is used as a method to tell compiler what to do.

    If 'orif' keyword is introduced, no matter how bad a VHDL compiler
    code optimization technology is, you will still be guaranteed that you
    get the most efficient implementation if 'orif' statements are widely
    & correctly used. You may have to wait another 20 years to get all
    VHDL compilers to do the smart job (at least in the last 20 years
    since VHDL was introduced, you haven't met a smart VHDL compilers.
    Why? it doesn't generate more money, but with risks.) After 'orif' is
    introduced, you immediately get the performance advantages without
    waiting for smart VHDL compilers.

    I will post another message focusing on Achilles heel of Jim's
    proposal assert() Monday.

    Weng
     
    Weng Tianxiang, Jun 26, 2004
    #2
    1. Advertising

  3. Jim,
    Now let me focus on yours assert() disadvantages.
    1. Your first usage of assert() is wrong!

    assert onehot(ASel & BSel & CSel & DSel) ... ;

    Ex2 : process
    begin
    wait until Clk='1' ;
    if ASel = '1' then
    Y <= A ;
    elsif BSel = '1' then
    Y <= B ;
    elsif CSel = '1' then
    Y <= C ;
    elsif DSel = '1' then
    Y <= D;
    end if ;
    end process ;

    It should look like this:
    Ex2 : process
    begin
    wait until Clk='1' ;
    assert onehot(ASel & BSel & CSel & DSel) <--- !!!
    if ASel = '1' then
    Y <= A ;
    elsif BSel = '1' then
    Y <= B ;
    elsif CSel = '1' then
    Y <= C ;
    elsif DSel = '1' then
    Y <= D;
    end if ;
    end process ;

    2. You must put an assert statement after clock edge statement to
    correctly detect and report an error.
    3. You must put an assert statement in a process() anywhere if 'orif'
    statements are used. Otherwise you cannot correctly detect and report
    an error.
    4. You must define a new name for any conditions in 'if' or 'elsif'
    statements that contain more than one signal before any assert
    statement can be called;
    5. If you are trying to let simulator to detect & report error
    condition without each special calling, you create an unprecedented
    language element that violates the principle rule of any languages:
    first declare it, then it is legally to be used.
    6. Your onehot name is misleading. Why? The following example tells
    that a condition can represent many states:
    type nCSStateType is (nCSIdle_S,
    nCS0_S, nCS1_S, nCS2_S, nCS3_S,
    nCS4_S, nCS5_S, nCS6_S, nCS7_S,
    nCS8_S, nCS9_S, nCS10_S, nCS11_S,
    nCS12_S, nCS13_S, nCS14_S, nCS15_S,
    nCS16_S, nCS17_S, nCS18_S, nCS19_S,
    nCS20_S, nCS21_S, nCS22_S, nCS23_S,
    nCS24_S, nCS25_S, nCS26_S, nCS27_S,
    nCS28_S, nCS29_S, nCS30_S, nCS31_S
    );

    signal nCSState : nCSStateType;
    if(nCSState /= nCSIdle_S)

    nCSState /= nCSIdle_S represents 32 states in the above state machine.
    it is a statement from my design.
    7. I have declared a new keyword 'exclusive' that is used to declare
    group of signals and state machines they are mutually exclusive. It is
    declared once, and it is valid globally, but in definition area.
    8. 'exclusive' and 'orif' provide two complementary methods to tell
    compiler the information of mutually exclusive. One is global in an
    entity, another local.
    9. You are the man to first suggest to introduce 'errels' after
    'orif'. I wrote your idea into my paper not because of its necessity,
    but with the purpose to soothe somebody's scare that if no error
    detection mechanism, my 'orif' idea may be too 'danger'. The real and
    easier solution is very simple:
    VHDL committee mandates 'if 'orif' or 'exclusive' statements are
    called, any simulation tools must report any conflicting error
    situations like the way currently commonly and widely used by any
    simulators when many sources drive one bit'.
    When many sources driver one bit, designers don't have to write
    special code to tell simulators to tell if they are wrong.
    Doing so will relieve all designers from writing all unnecessary
    assert or 'errels' to detect errors.

    Amy comments are welcome.

    Weng
     
    Weng Tianxiang, Jun 28, 2004
    #3
  4. Jim Lewis

    Jim Lewis Guest

    Weng,
    > 1. Your first usage of assert() is wrong!
    > 2. You must put an assert statement after clock edge statement to
    > correctly detect and report an error.


    I agree. The way this circuit works, the assertion must
    be re-written so that it only evaluates on the active
    edge of clock. Going in a process, like you
    show, is one possibility.

    The other possibility is to have an assertion that only
    evaluates its condition at the active edge of a particular
    clock. This capability will be part of VHDL when PSL is
    integrated (planned as part of VHDL-200X fast track).


    > 3. You must put an assert statement in a process() anywhere if 'orif'
    > statements are used. Otherwise you cannot correctly detect and report
    > an error.


    Disagree. See 2 above. The specification of onehot
    with a PSL clocked assertion is much more like your
    exclusive statement that you state below.

    Also note that most signals that I have worked with are
    always mutually exclusive, so checking for mutual exclusion
    in a particular branch of an if statement is not necessary.

    With assert, the mutual exclusion is specified once.

    With orif, mutual exclusion is specified each time you
    use the expression. If there are nested if statements,
    the mutual exclusion must be specified multiple times
    (most likely to occur in a statemachine).
    If the mutual exclusion is specified correctly
    9 out of 10 times in a nested if statement (accidently used
    elsif instead of orif one time), how will you
    detect the issue (not error because it is really only
    a logic simplification)?


    > 4. You must define a new name for any conditions in 'if' or 'elsif'
    > statements that contain more than one signal before any assert
    > statement can be called;

    Exactly. Show me a relevant example that you are
    concerned about. Here is one, CS is active and
    both Write and Read are asserted. Note however,
    this is a simple one to write with PSL.

    > 7. I have declared a new keyword 'exclusive' that is used to declare
    > group of signals and state machines they are mutually exclusive. It is
    > declared once, and it is valid globally, but in definition area.
    > 8. 'exclusive' and 'orif' provide two complementary methods to tell
    > compiler the information of mutually exclusive. One is global in an
    > entity, another local.
    > 9. You are the man to first suggest to introduce 'errels' after
    > 'orif'. I wrote your idea into my paper not because of its necessity,
    > but with the purpose to soothe somebody's scare that if no error
    > detection mechanism, my 'orif' idea may be too 'danger'. The real and
    > easier solution is very simple:
    > VHDL committee mandates 'if 'orif' or 'exclusive' statements are
    > called, any simulation tools must report any conflicting error
    > situations like the way currently commonly and widely used by any
    > simulators when many sources drive one bit'.
    > When many sources driver one bit, designers don't have to write
    > special code to tell simulators to tell if they are wrong.
    > Doing so will relieve all designers from writing all unnecessary
    > assert or 'errels' to detect errors.
    >
    > Amy comments are welcome.


    If exclusive makes errels not necessary, then "orif"
    contains redundant information and hence is not
    necessary.

    All restrictions imposed on checking onehot also
    apply to exclusive. Hence, with exclusive you must
    specify a clock. This makes it a reduced form of
    an assertion (what PSL provides).

    Hence, my advice is for you to learn PSL. It is planned
    to be integrated into VHDL in the next revision and
    will provide much greater functionality than your
    proposed exclusive.

    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, Jun 29, 2004
    #4
  5. Hi Weng,

    Weng Tianxiang wrote:
    <snip>

    >When many sources driver one bit, designers don't have to write
    >special code to tell simulators to tell if they are wrong.
    >

    In case of multidriving signal, you must be sure that only one value is
    given at a time (possible by many drivers, but the same).
    If not, a warning (possible an error) must be given, because if compiler
    conclude that two differents values can be set at same time, that can be
    because you have an error.

    If your proposal hide this, you can recover this problem in a later step
    of developpement; and in this case, it can be very hard to find the true
    origin. It is time consuming, and money cost.

    >Doing so will relieve all designers from writing all unnecessary
    >assert or 'errels' to detect errors.
    >
    >Amy comments are welcome.
    >
    >Weng
    >
    >
     
    Just an Illusion, Jun 29, 2004
    #5
  6. Hi Jim, Weng,

    > Hence, my advice is for you to learn PSL. It is planned
    > to be integrated into VHDL in the next revision and
    > will provide much greater functionality than your
    > proposed exclusive.



    psl is an assertion language to define formal properties.
    I don't think that psl can be use to drive simulation or synthesis. The
    psl must drive formal validation engines.

    Why psl can't be use for simulation ?
    In psl, you can write what is must be, but what you mustn't too.
    Simulation test only what the design can do, not more.
    If you put an assert (generally to trace an unexpected behavior), and if
    you find the trace in your simulation. It is because you have an error.
    Some time, you have no assert generation, because your test cases are
    not enough.

    Take the following example: you have a fifo of 1k element, this fifo
    have an error because it erase the begining of fifo data when the fifo
    is full, and an input is add.
    You use this fifo into a system, which require only 512 elements from
    the fifo. You can do all your simulations without any error (and any
    assert).
    Formal validation can point you the weak of the fifo, not simulation.

    Why psl can't be use for synthesis ?
    Some psl properties can be help for reduce a little some logic
    equations, but in general you describe some 'trace' or 'scenario' and
    that is not usefull for synthesis.
    Example:
    If you have a handshake protocol: {REQ,*,ACK} => after a request you
    must have an acknowledge

    Could you tell me how you can use this property to drive synthesizer ?

    Rgrds,
    JaI
     
    Just an Illusion, Jun 29, 2004
    #6
  7. Jim Lewis

    Jim Lewis Guest

    >> Hence, my advice is for you to learn PSL. It is planned
    >> to be integrated into VHDL in the next revision and
    >> will provide much greater functionality than your
    >> proposed exclusive.

    >
    >
    > psl is an assertion language to define formal properties.
    > I don't think that psl can be use to drive simulation or synthesis. The
    > psl must drive formal validation engines.

    Deja PSL.

    It is already part of simulators and some synthesis
    tools. It is not about what you can't do with
    something, it is about what you can do and the motivation
    for doing so.

    In simulation, PSL is being used both to signal when
    an error condition has occurred and help indicate
    where the issue is (ie: the agreed upon interface
    spec has been violated).

    In synthesis, we have attributes that
    allow us to express when two signals are mutually
    exclusive. This is nice, but the real problem
    is that nothing validates this claim. By making
    a limited number of assertions synthesizable
    (perhaps it is only onehot), then the claim can be
    verified in the simulator. I agree this has the
    limitation if I write incomplete tests, however,
    it is better than no testing at all. In addition,
    given a formal tool with enough capacity, by using
    PSL I can also prove it to be correct. If we make
    it so that all tools understand the same language
    (such as PSL) then we can minimize the chance
    of an error sneaking through.


    > Why psl can't be use for simulation ?
    > In psl, you can write what is must be, but what you mustn't too.
    > Simulation test only what the design can do, not more.
    > If you put an assert (generally to trace an unexpected behavior), and if
    > you find the trace in your simulation. It is because you have an error.
    > Some time, you have no assert generation, because your test cases are
    > not enough.

    And if you don't put in an assertion and the error never
    propagates to the outputs during the lifetime of your
    test, then what? If you check your simulation
    coverage you will probably find that you covered the
    case you were worried about.


    > Take the following example: you have a fifo of 1k element, this fifo
    > have an error because it erase the begining of fifo data when the fifo
    > is full, and an input is add.
    > You use this fifo into a system, which require only 512 elements from
    > the fifo. You can do all your simulations without any error (and any
    > assert).
    > Formal validation can point you the weak of the fifo, not simulation.

    Agreed. Some things are difficult to find in simulation.
    Hence the motivation to do formal.


    > Why psl can't be use for synthesis ?
    > Some psl properties can be help for reduce a little some logic
    > equations, but in general you describe some 'trace' or 'scenario' and
    > that is not usefull for synthesis.
    > Example:
    > If you have a handshake protocol: {REQ,*,ACK} => after a request you
    > must have an acknowledge

    Using your reasoning, no HDL can be used for synthesis
    because I can write some HDL code that is not
    synthesizable. However, this is not the case because we
    have defined "coding styles" that translate to the
    appropriate hardware structure.

    Priority vs. mutual exclusion is a problem encountered
    by any programming language when trying to describe/
    implement hardware. Using language elements or assertions
    to convey that code written with if then elsif, elsif, ...
    is really mutually exclusive can be result in a hardware
    savings with greater readability than code written otherwise.

    My expectation is that most assertions will be ignored by
    synthesis, but a few, such as one that conveys mutual
    exclusion will be synthesizable.

    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, Jun 29, 2004
    #7
  8. Jim Lewis

    Ken Smith Guest

    In article <>,
    Jim Lewis <> wrote:
    [...]
    >is that nothing validates this claim. By making
    >a limited number of assertions synthesizable
    >(perhaps it is only onehot), then the claim can be
    >verified in the simulator. I agree this has the
    >limitation if I write incomplete tests, however,


    I'm joining this argument late and am far from an expert but it seems to
    me that this is the hard way to get where we want to go. It seems simpler
    to me to be able to do something like this:

    process (SomeStd_logic_vector) begin
    if 1 = HowManyHigh(SomeStd_logic_vector) then
    -- prehaps nothing here
    else
    assert-it-is-broken;
    end if;
    end process;


    The Sim. can implement the real assert. The Synth can make everything a
    don't care in the asserted state. The advantage is that the language
    designers don't have to know about my "3.5 hot" state machine that I'm
    just about to patent but I can still test that it is going to work right.

    --
    --
    forging knowledge
     
    Ken Smith, Jun 29, 2004
    #8
  9. Jim,

    > By making a limited number of assertions synthesizable (perhaps it is only onehot)


    I don't really see where your assert() is simpler than my new keyword:
    'exclusive' with misleading name 'onehot'.

    You want to change non-synthesizable statement assert() to a statement
    sometimes synthesizable, and sometimes non-synthesizable with long
    typing
    'assert onehot(A1, A2, A3) report "failed" severity failure ;'

    and calling 'psl' language?

    Tell me what advantages of your assert() is over my keyword
    'exclusive'.

    If I am confused, I don't know how many would be consufed.

    exclusive (A1, A2, A3);

    In my paper, 'exclusive' is 2nd class of new keywords I suggested than
    'orif'. It is suggested to be used for among state machines and other
    non-derivative mutually exclusive signals.

    I will tell you why 'orif' is better than 'exclusive' in most of time
    in examples next time.

    Weng
     
    Weng Tianxiang, Jul 1, 2004
    #9
  10. Jim Lewis

    Jim Lewis Guest

    Weng,
    > Tell me what advantages of your assert() is over my keyword
    > 'exclusive'.
    >
    > If I am confused, I don't know how many would be consufed.
    >
    > exclusive (A1, A2, A3);
    >

    Semantically both are the same. Don't forget that you need
    to add syntax to tell exclusive to operate only at a specific
    edge of a specific clock.

    From a language designer perspective, PSL (assertions)
    are already being integrated (separate standard) with
    VHDL. EDA vendors are starting to support it.

    So it is a simple matter learning the syntax and using it
    rather than adding a new language feature. Note that
    anytime a new keyword is added to the language there
    is the possibility that the keyword will conflict with
    an identifier existing code.

    > I will tell you why 'orif' is better than 'exclusive'
    > in most of time in examples next time.

    A good long example would most helpful.

    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 1, 2004
    #10
  11. Jim,
    > Don't forget that you need to add syntax to tell exclusive to operate only at a specific edge of a specific clock.


    It is not true for 'exclusive' to indicate clock and its edges.

    1. When one declares that two signals are exclusive, they must be
    registered at the same clock, but not necessary at the same edge. So
    clock name is not needed; Under different clocks even two signals
    cannot be reliably compared, not mention their exclusive conditions.
    So it is a logic error if two signals registered under two different
    clocks are declared as mutually exclusive in 'exclusive'.

    2. If signals claimed in 'exclusive' are registered under different
    edges, it is OK when they are involved in any special edge.

    3. When signals claimed in 'exclusive' statements are involved in a
    'if..elsif..endif', the clock and its edge is clear.

    So when keyword 'exclusive' is used, clock and edge type are redundant
    information. There is no any need to include them. It is like to use
    '=' operator to compare two signals registered under two different
    clocks, it is legal, but most of time it is wrong. VHDL specs never
    prohibit '=' operator used for two 32-bit addresses registered under
    two different clocks.

    > Note that anytime a new keyword is added to the language there is the possibility that the keyword will conflict with an
    > identifier existing code.


    This is another wrong assumption with either 'exclusive' or 'orif'. If
    you put following 'exclusive' statement at the declare area, it is an
    error now! 'exclusive' equals to 'signal'!

    exclusive (A1, A2, A3);

    If you put 'orif' at 'elsif' places, no matter what you have declared,
    it is an error now!

    I would like to clear any misunderstanding of new keywords if any you
    still have.

    Weng
     
    Weng Tianxiang, Jul 2, 2004
    #11
  12. Jim Lewis

    Jim Lewis Guest

    Weng,
    > 1. When one declares that two signals are exclusive,
    > they must be registered at the same clock, ...


    Mutually exclusive RTL signals may overlap when they
    are changing if one has more delta cycles than another.
    Hence, somehow an eda tool must have a way to determine
    when this overlap is a failure and when this overlap
    is irrelevant. An easy way to do this is for the
    construct to specify the relevant edge of the
    clock.

    I suppose alternately you could expect the tool to
    do this. Of course this would mean it would need to
    trace from the logic to all the registers in the
    logic cone and check the constraint there. What
    if the register is in a separate logic block?


    >>Note that anytime a new keyword is added to the language there is the possibility that the keyword will conflict with an
    >>identifier existing code.

    >
    > This is another wrong assumption with either 'exclusive' or 'orif'.


    If someone currently has this in their code:
    signal exclusive : std_logic ;

    and I add exclusive as a keyword to the language,
    then their code will no longer compile and they
    must change their signal name.


    Still waiting patiently for your more extensive
    "orif" examples.

    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 2, 2004
    #12
  13. Jim,
    > Mutually exclusive RTL signals may overlap when
    > they are changing if one has more delta cycles
    > than another.


    Mutually exclusive case happen when
    1. with different clock marks;
    2. with one wire of different values;
    3. derivated from 'if..elsif..end' statements;
    4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
    Memory_2G, ...;

    In my mind, there is no boundary to check for mutually exclusive. If
    they have a overlap, it is not 'exclusive' error or 'orif' error, it
    is other factors and you cannot blame them like you cannot blame '='
    operator when your running frequency is not high enogh to cause
    overlap of two signals. As you know all signals involved must be
    setteld down before setup time ahead of clock edges and cannot change
    until hold time after clock edge.

    > If someone currently has this in their code:
    > signal exclusive : std_logic ;


    OK, no any problem for an existing design:

    signal exclusive : std_logic ;
    exclusive (A1, A2);

    The above two statements can be co-exist without any problem.
    The first 'exclusive' is declared as a signal, it can be used later as
    normal signal;
    The second 'exclusive' is a mutual exclusive declaration. It can be
    recognized by compiler without any confusion with first one if you
    have some knowledge of how compiler is built, especially when
    'exclusive' is added later into VHDL:
    the first one 'exclusive' is put into signal name list & see if there
    are any violations, the second is searched for in the keyword list, so
    they are at totally different list area, leading to two different
    reaction of compiler.

    Beyond declaration area, 'exclusive' will be recognized as signal name
    as usual without any special treatments.

    'orif' is at the same situation as above. They will be searched for in
    keyword list as 'elsif'.

    Weng
     
    Weng Tianxiang, Jul 2, 2004
    #13
  14. Jim Lewis

    Jim Lewis Guest

    Weng,
    >>Mutually exclusive RTL signals may overlap when
    >>they are changing if one has more delta cycles
    >>than another.

    >
    >
    > Mutually exclusive case happen when
    > 1. with different clock marks;
    > 2. with one wire of different values;
    > 3. derivated from 'if..elsif..end' statements;
    > 4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
    > Memory_2G, ...;
    >
    > In my mind, there is no boundary to check for mutually exclusive. If
    > they have a overlap, it is not 'exclusive' error or 'orif' error,


    For: exclusive (A1, A2);
    The key to the issue is when does exclusive check
    for mutual exclusion:
    1) On changes of A1 and A2
    2) When either A1 or A2 is read?
    3) At a specified condition


    #2 is problematic. When either A1 or A2 is read?
    What if they are read in a process that does
    not include clock? Do you propagate the check
    to the clock at which the cone of logic terminates?
    What should happen when A1 is read,
    but the cone of logic does not include A2, does
    the check for mutual exclusion get executed or not?
    Propagating the check can be very sophisticated and
    would be a capability beyond what current simulators
    do. A simplistic check (when A1 or A2 are read)
    can quickly devolve to #1. Also the check could be
    different for different implementations of the logic.

    Note I don't think the level of sophistication here
    is impossible to solve, but I do think that with
    simple extensions of the notation (and a very minor
    burden on the coder) that the problem can be easy
    to solve. Hence, I would rather add the little
    extra code myself and have the EDA vendors solve
    other problems.


    #1 is problematic. Consider the following example.
    Are Y1 and Y3 mutually exclusive?
    Y1 <= '1' when A = '1' else '0' ;
    Y2 <= '1' when A /= '1' else '0' ;
    Y3 <= Y2 ;

    In an RTL simulation, Y1 and Y2 are aligned in time and
    mutually exclusive. Y3 is delayed by a delta cycle from
    Y2 and hence it will have overlay with Y1 in time.
    Are Y1 and Y3 mutually exclusive? Going further, in
    gate implementations, it is common for rise and fall
    times to differ and as a result, it would not be
    uncommon for Y1 and Y2 to overlap.

    This overlap is ok when it is sampled by a clock because
    if A is synchonized to the same clock, then the overlap
    will not occur at the clock boundry.

    This overlap is usually not ok when Y1 and Y2 are used
    to drive competing tristate drivers:

    In Block 1:
    DataBus <= Block1Data when Y1 = '1' else (others => 'Z") ;

    In Block 2:
    DataBus <= Block2Data when Y2 = '1' else (others => 'Z") ;


    #3 is a potential solution. Extend the syntax to permit
    the condition under which to evaluate the mutual exclusion
    to be specified. Typically this would be a clock.
    If you were to extend exclusive to understand clock,
    then I think the solution would be more workable,
    however, it would be identical to capabilities
    provided by PSL. Note there is also OVL that may provide
    similar capabilities.


    So your suggestion is not being ignored, it is just
    being solved another way. This is the nature of
    standards efforts, you don't always get exactly what
    you had ideally wanted, but you usually get something
    that solves your problem.


    >>If someone currently has this in their code:
    >> signal exclusive : std_logic ;

    >
    >
    > OK, no any problem for an existing design:
    >
    > signal exclusive : std_logic ;
    > exclusive (A1, A2);
    >
    > The above two statements can be co-exist without any problem.

    The current VHDL language design does not permit this.
    To change this violate the spirit of VHDL.

    Going further, for vhdl-200x-mp effort, I will be writing
    an analysis of this issue. I would be interested
    to see a more extensive "orif" example as it would give
    me some insight to understand why you like "orif".
    Further arguments about the merits of exclusive or
    arguments about orif without examples are not going
    to help.

    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 2, 2004
    #14
  15. Hi Weng

    Weng Tianxiang wrote:

    ><snip>
    >
    >4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
    >Memory_2G, ...;
    >
    >
    >

    Sorry but example of read vs. write is not a good example, remember case
    of double access ram, where you can have a read and a write access
    simultaneously.
    More, lot of example have 2 different lines, one for read and another
    for write; even if only one must be active at a time.

    >Weng
    >
    >

    JaI
     
    Just an Illusion, Jul 5, 2004
    #15
    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,137
    roller
    Jun 19, 2004
  2. Just an Illusion

    Re: I hate VHDL!!!

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

    Re: I hate VHDL!!!

    Tom Verbeure, Jul 19, 2004, in forum: VHDL
    Replies:
    11
    Views:
    1,064
    Jim Lewis
    Jul 31, 2004
  4. Tom  Verbeure

    Re: I hate VHDL!!!

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

Share This Page