[m26k9]

Hello,

This is probably a very fundamental question but I'm a little confused as I am new to this.

In VHDL (I'm sure it the same for others too), if I have such a PROCESS:


PROCESS(clk)
if RISING_EDGE(clk)

CASE state IS
WHEN stateA THEN
state <= stateB;
a <= x"0111";
........

WHEN stateB THEN
state <= stateC;
b <= "0101";

....
....
....

END CASE
END IF

In this, if the state=stateA when it the CASE statement was started, will the state signal be changed fom stateA->stateB-> and so on in each CASE statement when the execution flow down through the CASE statement?? If so, how many statements will excute during that clock period? Is there a limit? or only ONE statement will be exceuted in the clock period?


If only one statement will be excuted, within each statement, how many assignment operators can be performed within that CASE statement?? Is there a limitation?

Thank you very much.

P.S: If anybody knows a good text for learning this typ of issues please let me know.

[FvM]

will the state signal be changed

No, according to general VHDL rules for sequential processes. All assignments get valid after the process ends.

how many assignment operators can be performed within that CASE statement??

Unlimited.

In addition, in process, you can have multiple assignments to a signal. The last wins.

[m26k9]

Originally Posted by FvM

No, according to general VHDL rules for sequential processes. All assignments get valid after the process ends.
Unlimited.

In addition, in process, you can have multiple assignments to a signal. The last wins.

Thank you very much that very quick reply FvM.

So only the first CASE statement that 'matches' will be excuted and the assignenments will happen after the process? Is this only for signals or variables also? What is I compare the state of a variable (is it possible?), instead of a signal.. in that case I think the value will be updates instantly.. so does it mean the CASE statements will be executed one after other in a signal clock?

Thank you.

[Tricky]

Originally Posted by m26k9

Thank you very much that very quick reply FvM.

So only the first CASE statement that 'matches' will be excuted and the assignenments will happen after the process? Is this only for signals or variables also? What is I compare the state of a variable (is it possible?), instead of a signal.. in that case I think the value will be updates instantly.. so does it mean the CASE statements will be executed one after other in a signal clock?

Thank you.

The important point with case is that only 1 case ever matches because each case has to be mutually exclusive. Whether it's a variable or signal is irrelavent. The important point is that the process is sensitive to clk only, so the whole process (and hence the case statement) is only executed on a rising edge of the clock, never between clock edges, so the case statement is only executed once. The signals are updated when the process ends and the variables are updated immediatly. If on the other hand the process was sensitive to state, you'd get yourself in an infinite loop:

process(state)
begin
  case state is
    when state_a =>
      state <= state_b;
    when state_b =>
      state <= state_a;
  end case;
end process;

With this process, because the process is triggered every time state changes, you're going to be swapping state once per delta cycle, and a simulator would halt after it hits it's iteration limit.

[m26k9]

Originally Posted by Tricky

The important point with case is that only 1 case ever matches because each case has to be mutually exclusive. Whether it's a variable or signal is irrelavent. The important point is that the process is sensitive to clk only, so the whole process (and hence the case statement) is only executed on a rising edge of the clock, never between clock edges, so the case statement is only executed once. The signals are updated when the process ends and the variables are updated immediatly. If on the other hand the process was sensitive to state, you'd get yourself in an infinite loop:

process(state)
begin
  case state is
    when state_a =>
      state <= state_b;
    when state_b =>
      state <= state_a;
  end case;
end process;

With this process, because the process is triggered every time state changes, you're going to be swapping state once per delta cycle, and a simulator would halt after it hits it's iteration limit.

That cleared it up Tricky.
Thank you very much.

[mmTsuchi]

Hi, if you are using QUARTUS II,
you will have VHDL templates for FSM (Finite State Machine). Find them in Quartus menu when editing VHDL file.

Remember : VHDL is NOT a programming langage, VHDL is a description langage
You don't write VHDL as you write programs.

[m26k9]

Originally Posted by mmTsuchi

Hi, if you are using QUARTUS II,
you will have VHDL templates for FSM (Finite State Machine). Find them in Quartus menu when editing VHDL file.

Remember : VHDL is NOT a programming langage, VHDL is a description langage
You don't write VHDL as you write programs.

Thank you mmTsuchi.
I am using Quartus II. Did not know about the templates. Thank you for that.

About that VHDL is a not a programming language, I can understand that it is different from C++/Java/etc., in the sense that it is concurrent, synchronous, etc., but is there something important you need to keep in mind when writing VHDL? For someone new to VHDL and coming from a C++/Java background.

Thank you.

[Tricky]

Originally Posted by m26k9

About that VHDL is a not a programming language, I can understand that it is different from C++/Java/etc., in the sense that it is concurrent, synchronous, etc., but is there something important you need to keep in mind when writing VHDL? For someone new to VHDL and coming from a C++/Java background.

Thank you.

before even typing 1 letter of VHDL, first think about the circuit you want to create. As VHDL is a description language, not a programming language, you are only ever describing a circuit you already know.

What confuses people is that you can do alot in VHDL that is very C++ like, but actually wont do anything for you when you compile it - alot of this functionality is there only for testing and modelling purposes (for example, I have functions that can read/write bitmap files) but is in no way synthesizable.

If you keep to the first rule - you'll improve your VHDL massivly.

[mmTsuchi]

Completely agree with Tricky.

Altera gives on website guidelines and coding style like http://www.altera.com/literature/hb/... 20guidelines

LIBRARY ieee;
USE ieee.STD_LOGIC_1164.all;

I recommend to use only std_(u)logic, std_(u)ogic_vector(... downto ...) for ports of an entity.

Be aware of what is synthesizable or not (like "after 25 ns", file operations...)
...

Think about circuit and describe it in VHDL.

[Tricky]

Originally Posted by mmTsuchi

I recommend to use only std_(u)logic, std_(u)ogic_vector(... downto ...) for ports of an entity.

Personally, Id recommend having ports on entities of the type that best reflects what it is. Its so annoying have to do type conversions all the time when 2 connected entites are using integers and signed/unsigned types internally. At the top level you will need to use std_logic(_vector) or signed/unsigned though because you have to constrain individual bits to single pins. But internally, use whatever best reflects what the signal actually is.

Types Ive used fine for ports on entities (not top level)

Std_(u)logic(_vector)
signed
unsigned
boolean
integer/natural/positve (remember to constrain them else you'll have lots of spare bits)
sfixed/ufixed
records containing any of the above
arrays of any of the above

Records come into play when you're trying to encapsulate stuff, especially registers.

also, ennumerated types should be fine as port connections.

In addition, memories can be infered from most of the above.