Wake process - Quartus II

[pbartosz]

I have a sample code:

variable state : integer := 0;

process (wake)
begin
if state = 0 then
--some code;
state := 1;
wake <= not wake;
elsif state = 1 then
--some code;
end if;
end process;

In ModelSim simulation it works correct, but in Quartus II simulation
when process returns from state 0 it negates wake signal but process
doesn't start again.
What's the problem?
Any solution?

 

[Tricky]

I have a sample code:

variable state : integer := 0;

process (wake)
begin
  if state = 0 then
    --some code;
    state := 1;
    wake <= not wake;
  elsif state = 1 then
     --some code;
  end if;
end process;

In ModelSim simulation it works correct, but in Quartus II simulation
when process returns from state 0 it negates wake signal but process
doesn't start again.
What's the problem?
Any solution?

You shouldnt have a process that is sensitive to a signal inside the
process, as you end up building a combinatorial loop.

Think about the logic you are trying to describe, rather than trying
to write software. Processes never return from anything. They are
activiated whenever one of the signals in the sensitivity list
changes. I suspect that Quartus built different logic to the behaviour
you expected from modelsim because Quartus ignores sensitivity lists.

 

[Paul Uiterlinden]

I have a sample code:

variable state : integer := 0;

process (wake)
begin
if state = 0 then
--some code;
state := 1;
wake <= not wake;
elsif state = 1 then
--some code;
end if;
end process;

In ModelSim simulation it works correct, but in Quartus II simulation
when process returns from state 0 it negates wake signal but process
doesn't start again.
What's the problem?
Any solution?

Besides what Tricky already said, I see a problem with multiple drivers on
signal wake. Your process as described above forms the first driver on
wake. There has to be second driver (process) that you have not described
here. How else could wake ever be toggled to awake your process?

Multiple processes driving a signal won't work, unless describing some bus
system using tri-state buffers.

Your description is not synthesisable anyhow. You try to describe hardware
that is sensitive on both edges of wake.

 

[rickman]

I have a sample code:

variable state : integer := 0;

process (wake)
begin
if state = 0 then
--some code;
state := 1;
wake <= not wake;
elsif state = 1 then
--some code;
end if;
end process;

In ModelSim simulation it works correct, but in Quartus II simulation
when process returns from state 0 it negates wake signal but process
doesn't start again.
What's the problem?
Any solution?

Like the others have said, your design is flawed because it is not
synthesizable. I suggest you draw a block diagram of how you expect
the logic to look. Draw boxes for registers and circles or ovals for
logic with the equations or a description inside. Include some level
of detail such as register enables. Look up synthesis templates for
registers and copy that to your program for all of the registers.
Describe the logic in combinatorial processes or concurrent
statements. BTW, don't be afraid to label your processes. This can
help in analyzing simulations and synthesis.

Rick

 

[Andy]

I'm going to assume this is part of a testbench, and not
synthesizable.

We need a little more information...

What is wake doing? Is something else driving it too? What type is
wake (resolved)? How is wake initialized? What happens when the
initial value is "not"ed (e.g. not 'X' = 'X' which won't generate an
event to retrigger the process)

How do you know the process does not start again? What evidence of
that are you seeing?

Without any wait statements, that process will spend a lot of
execution cycles without advancing time (just advancing deltas) while
state is 0.

Andy