Me and Variables Again !!!

Discussion in 'VHDL' started by LC, Jan 11, 2010.

  1. LC

    LC Guest

    Hi,

    Last time I posted about this your collective help was great
    and educated me well into the use of variables versus signals
    Albeit it looks that I'm destined to have issues about
    that.

    I have this part of code that generates pulses at the end
    of write on a serial bus. It generates one "ser_valid" pulse
    each transfer in addition it generates a "trig_soft" pulse
    if the system is at a specific mode.

    ---

    If sv_sr is a SIGNAL all works just fine.

    If sv_sr is a VARIABLE the <number 1> works just
    the same but the <number 2> doesn't (trig_soft remains at '0', always)

    !!! Scratched my head and gave up...
    WHY why why !!?!

    (needless to say that the work progressed using a SIGNAL
    but my mind is not in peace ;-)

    ---

    soft_trigger: PROCESS (clock)

    BEGIN
    IF (clock='1' AND clock'EVENT) THEN

    sv_sr <= sv_sr(0)&sld; -- commented if Var.
    -- sv_sr := sv_sr(0)&sld; -- commented if Sig.

    IF (sv_sr="10") -- number 1
    THEN ser_valid <='1';
    ELSE ser_valid <='0';
    END IF;

    IF (sv_sr="10" AND mode=SOFT_TRG) -- number 2
    THEN trig_soft <='1';
    ELSE trig_soft <='0';
    END IF;

    END IF;

    END PROCESS soft_trigger;

    ---


    Many thanks.


    Luis C.
    LC, Jan 11, 2010
    #1
    1. Advertising

  2. LC

    joris

    Joined:
    Jan 29, 2009
    Messages:
    152
    What does 'mode' depend on ?
    joris, Jan 11, 2010
    #2
    1. Advertising

  3. LC

    Andy Guest

    To clarify what Alan wrote, the two versions (signal and variable)
    would work identically if both the variable and signal assignment are
    moved to the end of the process. Moving the signal assignment has no
    affect, except that when it is changed to a variable assignment, the
    updated value is not seen until the next clock cycle, just as if it
    had been a signal.

    Another way to look at this whole thing is that it is not so much
    where/when the assignment to a variable occurs, but where/when the
    subsequent references to (reads of) that variable occur. In the above,
    you would not so much be moving the assignment statements to the end,
    but moving the variable references to the beginning, such that they
    return the value from the previous clock cycle (if and only if you
    need a register to get the clock-cyclic behavior you need). Multiple
    references to the same variable can create both combinatorial and
    registered logic, based on where/when those references occur relative
    to the assignment(s).

    Andy
    Andy, Jan 11, 2010
    #3
  4. LC

    LC Guest

    Andy wrote:
    > To clarify what Alan wrote, the two versions (signal and variable)
    > would work identically if both the variable and signal assignment are
    > moved to the end of the process. Moving the signal assignment has no
    > affect, except that when it is changed to a variable assignment, the
    > updated value is not seen until the next clock cycle, just as if it
    > had been a signal.
    >
    > Another way to look at this whole thing is that it is not so much
    > where/when the assignment to a variable occurs, but where/when the
    > subsequent references to (reads of) that variable occur. In the above,
    > you would not so much be moving the assignment statements to the end,
    > but moving the variable references to the beginning, such that they
    > return the value from the previous clock cycle (if and only if you
    > need a register to get the clock-cyclic behavior you need). Multiple
    > references to the same variable can create both combinatorial and
    > registered logic, based on where/when those references occur relative
    > to the assignment(s).
    >
    > Andy
    >


    Many Thanks,
    I think I understood most of what you and Alain said.
    But I'm still in pain ;-) as I did not get to the
    bottom of this particular piece of code.

    Lets just deal with the variable use scenario.

    in my code there is only one assignment of a value
    and it is in the beginning

    and then two reads of the variable "sv_sr" are
    done one after the other

    no other assignments or anything else in between.


    why at read nr1 it has one value

    and at read nr2 it has another ?



    Please be patient with me :)


    Luis C.
    LC, Jan 12, 2010
    #4
  5. LC

    LC Guest

    >
    > I know this will sound rude :) but it can't have a different value at
    > both places, the value must be the same. You can prove it by writing the
    > value out e.g.
    >
    > use std.textio.all;
    > use ieee.std_logic_textio.all;
    >
    > -- rest of entity and architecture
    >
    > soft_trigger: PROCESS (clock)
    > variable L : LINE;
    > BEGIN
    > IF (clock='1' AND clock'EVENT) THEN
    >
    > -- sv_sr <= sv_sr(0)&sld; -- commented if Var.
    >
    > write(L, string'("nr1 = "));
    > write(L, sv_sr);
    > IF (sv_sr="10") -- number 1
    > THEN ser_valid <='1';
    > ELSE ser_valid <='0';
    > END IF;
    >
    > write(L, string'(" nr2 = "));
    > write(L, sv_sr);
    > writeline(OUTPUT, L);
    > IF (sv_sr="10" AND mode=SOFT_TRG) -- number 2
    > THEN trig_soft <='1';
    > ELSE trig_soft <='0';
    > END IF;
    > sv_sr := sv_sr(0)&sld; -- commented if Sig.
    >
    > END IF;
    >
    > END PROCESS soft_trigger;
    >>
    >> Please be patient with me :)
    >>
    >>

    > I guess the value of mode is significant...
    >
    > Alan
    >


    Alain, many thanks for your help.

    I know for sure that if sv_sr is a signal the NR2 starts
    to work as expected and there was nothing else changed
    anywhere in the code.

    and

    you must be right saying that value should be the
    same in both NR1 and NR2 (no doubt about, now...I've
    seen and I believe, tks :) )

    and

    by the time sv_sr equals "10", mode was already stable
    and equal SOFT_TRG ages ago (so shows the simulator)

    so this become an interesting puzzle !!!


    crappy tools !!??!!! maybe.

    yeap... good idea, I'll try this bit of code with a different set of tools.


    Again, tks for helping.

    Luis C.
    LC, Jan 12, 2010
    #5
  6. LC

    Andy Guest

    On Jan 12, 7:12 am, LC <> wrote:
    > > I know this will sound rude :) but it can't have a different value at
    > > both places, the value must be the same. You can prove it by writing the
    > > value out e.g.

    >
    > > use std.textio.all;
    > > use ieee.std_logic_textio.all;

    >
    > > -- rest of entity and architecture

    >
    > > soft_trigger:    PROCESS (clock)
    > >   variable L : LINE;
    > > BEGIN
    > >     IF (clock='1' AND clock'EVENT) THEN

    >
    > > --        sv_sr <= sv_sr(0)&sld;  -- commented if Var.

    >
    > >         write(L, string'("nr1 = "));
    > >         write(L, sv_sr);
    > >         IF (sv_sr="10")                -- number 1
    > >             THEN    ser_valid <='1';
    > >             ELSE    ser_valid <='0';
    > >         END IF;

    >
    > >         write(L, string'(" nr2 = "));
    > >         write(L, sv_sr);
    > >         writeline(OUTPUT, L);
    > >         IF (sv_sr="10" AND mode=SOFT_TRG)     -- number 2
    > >             THEN    trig_soft <='1';
    > >             ELSE    trig_soft <='0';
    > >         END IF;
    > >         sv_sr := sv_sr(0)&sld;    -- commented if Sig.

    >
    > >     END IF;

    >
    > > END PROCESS soft_trigger;

    >
    > >> Please be patient with me :)

    >
    > > I guess the value of mode is significant...

    >
    > > Alan

    >
    > Alain, many thanks for your help.
    >
    > I know for sure that if sv_sr is a signal the NR2 starts
    > to work as expected and there was nothing else changed
    > anywhere in the code.
    >
    > and
    >
    > you must be right saying that value should be the
    > same in both NR1 and NR2 (no doubt about, now...I've
    > seen and I believe, tks :) )
    >
    > and
    >
    > by the time sv_sr equals "10", mode was already stable
    > and equal SOFT_TRG ages ago (so shows the simulator)
    >
    > so this become an interesting puzzle !!!
    >
    > crappy tools !!??!!! maybe.
    >
    > yeap... good idea, I'll try this bit of code with a different set of tools.
    >
    > Again, tks for helping.
    >
    > Luis C.- Hide quoted text -
    >
    > - Show quoted text -


    Is this misbehavior observable in HW, or in gate-level/full-timing
    simulation, and/or in RTL simulation? If either or both of the 1st
    two, I would suspect an improperly synchronized input (sdl or mode) or
    a timing problem (how fast is your clock?). Using the variable
    (depending on where you assign and read it) may eliminate a register
    that is created by the signal version, and that register may be
    correcting your synchronization (of sdl). If the 3rd is happening,
    you have a tool problem in your simulator, or your code is not exactly
    as posted. You could try nesting the 2nd if-then inside the first, and
    get rid of the 2nd comparison to "10", but this should not make any
    difference.

    Andy
    Andy, Jan 12, 2010
    #6
  7. LC

    LC Guest

    Andy wrote:
    >
    > Is this misbehavior observable in HW, or in gate-level/full-timing
    > simulation, and/or in RTL simulation? If either or both of the 1st
    > two, I would suspect an improperly synchronized input (sdl or mode) or
    > a timing problem (how fast is your clock?). Using the variable
    > (depending on where you assign and read it) may eliminate a register
    > that is created by the signal version, and that register may be
    > correcting your synchronization (of sdl). If the 3rd is happening,
    > you have a tool problem in your simulator, or your code is not exactly
    > as posted. You could try nesting the 2nd if-then inside the first, and
    > get rid of the 2nd comparison to "10", but this should not make any
    > difference.
    >
    > Andy


    Hi Andy,

    This happens in gate-level/full-timing simulation.

    After some experimentation I have now an new set
    of interesting info, and specifically one that
    tells a lot :)
    Behaviour changed to normal some fits after when I changed
    something totally unrelated to this that changed dramatically
    the FPGA fit... and stayed behaving well from that moment on.

    (ask me if I trust it now !!! :)

    Clock is 200MHz but the SCK,SDA and SLD run at 5MHz or less
    hence my comment of mode and etc being stable for ages.
    However since mode was clocked into a register that might
    be related with the issue.
    Funny enough, as mode is a two bit signal I tried it
    through all individual 4 combinations "00" "01" "10" and "11"
    and it failed all so was not the value of mode that was wrong
    but the logic generated that was invalid and returned always
    false...

    this got to be very wrong.

    now I can't reproduce the problem anymore, unless I use that
    specific old_version from two days ago ;-)

    ---

    While I had the abnormal behavior moving the variable
    assignment to the bottom (as suggested) made no difference.
    and nesting the two IFs did not work as well.

    ---

    This was quite entertaining... :-(
    As I was imagining a coding fault from me
    the usual and most probable !


    Thanks for your help, it was very helpful
    after all, and I learned a lot.

    Luis C.

    p.s.(privately I can tell you what fpga family, vendor and tool chain
    I was using if you are interested to know.)
    LC, Jan 13, 2010
    #7
  8. LC

    Andy Guest

    Yep, synchronization strikes again! That, and it looks like you may
    have had some timing issues which should have shown up in static
    timing analysis, assuming you had the constraints set properly.

    You must only sample an asynchronous multi-bit value when you KNOW
    that all bits are valid. Sometimes a separate flag is available to
    tell you that, other times you need to get creative and look at all
    the bits to see where they are stable, and sample there. In other
    words, a stable value should last 200 ns in your case. If you can't
    determine the middle of that window from the source clock, then edge
    detect each of the bits at 200 MHz, and wait until all have been
    stable for 100 ns to clock them all into your fast clock domain.

    Andy
    Andy, Jan 13, 2010
    #8
    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. amit
    Replies:
    0
    Views:
    375
  2. che
    Replies:
    2
    Views:
    478
  3. abcd

    Importing again and again

    abcd, Jun 8, 2006, in forum: Python
    Replies:
    9
    Views:
    317
    Maric Michaud
    Jun 9, 2006
  4. Ò»Ê×Ê«

    A design problem I met again and again.

    Ò»Ê×Ê«, Apr 1, 2009, in forum: Python
    Replies:
    24
    Views:
    695
    Dennis Lee Bieber
    Apr 4, 2009
  5. Alexander Burger

    jsf 2.0 datatable reload again and again

    Alexander Burger, Sep 23, 2010, in forum: Java
    Replies:
    14
    Views:
    4,230
    Arved Sandstrom
    Sep 26, 2010
Loading...

Share This Page