Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Me and Variables Again !!!

Reply
Thread Tools

Me and Variables Again !!!

 
 
LC
Guest
Posts: n/a
 
      01-11-2010
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.
 
Reply With Quote
 
 
 
 
joris joris is offline
Senior Member
Join Date: Jan 2009
Posts: 152
 
      01-11-2010
What does 'mode' depend on ?
 
Reply With Quote
 
 
 
 
Andy
Guest
Posts: n/a
 
      01-11-2010
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

 
Reply With Quote
 
LC
Guest
Posts: n/a
 
      01-12-2010
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.


 
Reply With Quote
 
LC
Guest
Posts: n/a
 
      01-12-2010
>
> 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.

 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      01-12-2010
On Jan 12, 7:12*am, LC <(E-Mail Removed)> 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
 
Reply With Quote
 
LC
Guest
Posts: n/a
 
      01-13-2010
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.)
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      01-13-2010
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Put variables into member variables or function variables? tjumail@gmail.com C++ 9 03-23-2008 04:03 PM
Importing again and again abcd Python 9 06-09-2006 08:33 AM
HttpSession gets generated again and again!! PLEASE HELP ME!!!! che Java 2 10-10-2005 10:20 PM
Olympus digicam losing date/time settings again and again TommyC Digital Photography 7 05-31-2004 06:37 PM
jserve booting again and again amit Java 0 10-02-2003 04:26 PM



Advertisments