plz help me

good VHDL code will synthesise into hardware. People that write good VHDL know roughly what the circuit will look like before they write any VHDL code. So a good understanding of digital logic is much more important than understanding VHDL.

People that write code that loooks like C are usually software programmers having a go at VHDL. THey usually do a lot of things that arnt synthesisable (like use loops), use variables alot and dont understand the circuit they're trying to create, hoping that the synthesisor will do the job for them.

If this is what's happening to you, I suggest, the next time you need to write any code, you draw your circuit on a piece of paper first. VHDL is a hardware DESCRIPTION language, so if you dont know the circuit, you cannot write the code.

Do you have any specific bit of code in mind?

Hi,

The other thing I've seen software people have trouble with is the inherently parallel nature of VHDL synchronous design. For example, in the VHDL code:

if rising_edge (clock) then
   a <= a + 1;
   if (a = 23) then
      a <= 0;
   end if;
end if;

it doesn't matter if the line that increments "a" is before or after the if statement. Everything happens at the same instant on the rising edge of clock based on the value of "a" calculated at the previous rising edge of clock.

Mark.

--- Quote Start ---

good VHDL code will synthesise into hardware. People that write good VHDL know roughly what the circuit will look like before they write any VHDL code. So a good understanding of digital logic is much more important than understanding VHDL.

People that write code that loooks like C are usually software programmers having a go at VHDL. THey usually do a lot of things that arnt synthesisable (like use loops), use variables alot and dont understand the circuit they're trying to create, hoping that the synthesisor will do the job for them.

If this is what's happening to you, I suggest, the next time you need to write any code, you draw your circuit on a piece of paper first. VHDL is a hardware DESCRIPTION language, so if you dont know the circuit, you cannot write the code.

Do you have any specific bit of code in mind?

--- Quote End ---

i think my code is so complicated.

thanks alot for ur suggestions

may u tell me how i can draw my circuit? i mean i dont know how i should describe it with circuit and hardware?

which source i should use to ?

--- Quote Start ---

Hi,

The other thing I've seen software people have trouble with is the inherently parallel nature of VHDL synchronous design. For example, in the VHDL code:

if rising_edge (clock) then
   a <= a + 1;
   if (a = 23) then
      a <= 0;
   end if;
end if;

it doesn't matter if the line that increments "a" is before or after the if statement. Everything happens at the same instant on the rising edge of clock based on the value of "a" calculated at the previous rising edge of clock.

Mark.

--- Quote End ---

Are you sure? The order of statements makes a difference here within a sequential process. Inserting increment statement after if condition means if condition is overwritten and will be ignored.

--- Quote Start ---

Are you sure? The order of statements makes a difference here within a sequential process.

--- Quote End ---

You're right and that was silly of me. I pared down something else and posted quickly. A real example would be:

if rising_edge (clk) then
  a <= a + 1;
  if (a = 23) then
    b <= '1';
  else
    b <= '0';
  end if;
end if;

where is doesn't matter if the increment is before or after the comparison - you get exactly the same behaviour either way.

Mark.

--- Quote Start ---

You're right and that was silly of me. I pared down something else and posted quickly. A real example would be:

if rising_edge (clk) then
  a <= a + 1;
  if (a = 23) then
    b <= '1';
  else
    b <= '0';
  end if;
end if;

where is doesn't matter if the increment is before or after the comparison - you get exactly the same behaviour either way.

Mark.

--- Quote End ---

That is right.

The way I explain it to myself is as follows:

Processes and combinatorial statements are all meant to infer parallel circuitry and so their relative order is irrelevant.

Statements within a sequential process or the order of conditions in a combinatorial statement will naturally affect priority.

processes allow two ways of defining priority. By "if else" ...etc when top condition takes priority(case statement has no priority). or By overwriting a default such as your first example when last assignment takes priority (and settled at compile time).

In your second example the order is irrelevant because the values are checked and updated at clock edge.