trying to understand someone else's VHDL code

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

 

[KJ]

On Oct 24, 12:46 pm, jamesd.sny...@gmail.com wrote:

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

 

[Mike Treseler]

jamesd.snyder@gmail.com wrote:

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

 

[Andy]

On Oct 24, 12:46 pm, Mike Treseler <mike_trese...@comcast.net> wrote:

jamesd.sny...@gmail.com wrote:
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

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