VHDL - CASE related question

--- Quote Start ---

will the state signal be changed

--- Quote End ---

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

--- Quote Start ---

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

--- Quote End ---

Unlimited.

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

--- Quote Start ---

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.

--- Quote End ---

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.

--- Quote Start ---

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.

--- Quote End ---

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.

--- Quote Start ---

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.

--- Quote End ---

That cleared it up Tricky.

Thank you very much.

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.

--- Quote Start ---

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.

--- Quote End ---

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.

--- Quote Start ---

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.

--- Quote End ---

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.

Completely agree with Tricky.

Altera gives on website guidelines and coding style like http://www.altera.com/literature/hb/qts/qts_qii51007.pdf?gsa_pos=3&wt.oss_r=1&wt.oss=vhdl%20guidelines

--- Quote Start ---

LIBRARY ieee;

USE ieee.STD_LOGIC_1164.all;

--- Quote End ---

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.

--- Quote Start ---

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

--- Quote End ---

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.

Thank you very mcuh Tricky, mmTsuchi.

Looks like a have long way to go.

One thing that I can't understand is,

A GENERATE block and a PROCESS block, 'how many' instructions can a FPGA perform? It ofcourse depends on the model, but as a programmer, how would you know that a block of code can be executed within a clock cycle? Or is it not like that? Is possible for a block of PROCESS to take several clock cycles to execute completely?

Thank you.