trying to understand someone else's VHDL code

J

jamesd.snyder

Hi all,

I'm looking at another designer's(no longer with the company) state
machine code and this code is contained within one state:

when Start_CNV =>
i_shft_a_en <= '0';
SHIFT_A_EN <= i_shft_a_en;

My general understanding is that within a process, signal assignments
do not take place until the process completes execution. Is this
always the case? Is that the case here? Would SHIFT_A_EN equal '0'
or the value of i_shft_a_en before it was '0'? Why not make the
assignment directly to the output port SHIFT_A_EN? Is it just better
practice to use the internal signal as a buffer?

Is the above method of coding common? This method occurs multiple
times throughout the code I'm reviewing.

Also, is the 'i_' prefix a known naming convention? Is it to say the
signal is internal? What about 'd_'? Is this also a naming
convention?

Thanks for any input,
Jim
 
K

KJ

Hi all,

I'm looking at another designer's(no longer with the company) state
machine code and this code is contained within one state:

when Start_CNV =>
i_shft_a_en <= '0';
SHIFT_A_EN <= i_shft_a_en;

My general understanding is that within a process, signal assignments
do not take place until the process completes execution.

You're correct. The other time it updates signals is when it suspends
via a 'wait' statement.

Is this
always the case? Yes.

Is that the case here? Yes.

Would SHIFT_A_EN equal '0'
or the value of i_shft_a_en before it was '0'?
It would take on the value of i_shft_a_en.
Why not make the
assignment directly to the output port SHIFT_A_EN?
Maybe the designer is counting on the additional delay. Without
knowing the design one couldn't say for sure that making SHIFT_A_EN
change earlier by doing as you suggest wouldn't break something else.
Is it just better
practice to use the internal signal as a buffer?
That's not the case here.
Is the above method of coding common? This method occurs multiple
times throughout the code I'm reviewing.
Not sure what 'method' you see. It might just be the way the original
designer liked to do things.
Also, is the 'i_' prefix a known naming convention? Is it to say the
signal is internal? What about 'd_'? Is this also a naming
convention?
Sometimes 'i_' is used for 'input' and 'o_' for 'output'. That way,
you can just look at the signal name and know if it is an input or an
output. Some people use that convention, I don't. What the original
designer intended with 'i_' and 'd_' is unknown.
Thanks for any input,
Jim

You're welcome.

KJ
 
M

Mike Treseler

I'm looking at another designer's(no longer with the company) state
machine code and this code is contained within one state:

when Start_CNV =>
i_shft_a_en <= '0';
SHIFT_A_EN <= i_shft_a_en;

My general understanding is that within a process, signal assignments
do not take place until the process completes execution. Is this
always the case?

Yes. At the end of the process,
i_shft_a_en changes to '0' and
SHIFT_A_EN changes to the *previous* value of i_shft_a_en;
Is that the case here?
Yes.

Would SHIFT_A_EN equal '0'
Maybe

or the value of i_shft_a_en before it was '0'?

Yes, if you mean the previous value.
Why not make the
assignment directly to the output port SHIFT_A_EN?

Sim it and you will see.
Is it just better
practice to use the internal signal as a buffer?

I think it is better practice to use variables
in a synchronous process and eliminate all such confusion.
Is the above method of coding common?
Unfortunately.

This method occurs multiple
times throughout the code I'm reviewing.

If the code is working, just hold your nose.

If you have to make a significant change,
write a testbench for the old code to document its operation,
then recode the whole thing in a style you
can understand.
Also, is the 'i_' prefix a known naming convention? Is it to say the
signal is internal? What about 'd_'? Is this also a naming
convention?

It is the author's naming convention.
I prefer suffixes:

_c constant
_t type
_s signal
_v variable
port (no suffix)

If I use variables in a synchronous process,
I don't need to worry about
D vs Q or
next_state vs state.

I just describe Q_v and state_v.

-- Mike Treseler
 
A

Andy

Yes. At the end of the process,
i_shft_a_en changes to '0' and
SHIFT_A_EN changes to the *previous* value of i_shft_a_en;


Yes, if you mean the previous value.


Sim it and you will see.


I think it is better practice to use variables
in a synchronous process and eliminate all such confusion.


If the code is working, just hold your nose.

If you have to make a significant change,
write a testbench for the old code to document its operation,
then recode the whole thing in a style you
can understand.


It is the author's naming convention.
I prefer suffixes:

_c constant
_t type
_s signal
_v variable
port (no suffix)

If I use variables in a synchronous process,
I don't need to worry about
D vs Q or
next_state vs state.

I just describe Q_v and state_v.

-- Mike Treseler

Like Mike, I prefer to use variables. They execute just like they read
(like SW). Signals update when a process suspends (on a wait
statement, or at the bottom of the process, waiting for something in
the sensitivity list to trigger again).

Output ports are often buffered with an internal signal/variable so
that the contents of the internal signal/variable can be read back and
used internally (output ports cannot be read until the latest version
of the standard has been adopted/implemented).

Andy
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top