in one process you have the assignment

> flag<="0....0";

in another process you have the assignement

> flag<=next_flag;

I cannot believe that this works without complaints from your synthesis 
tool. Please show your real code, not just code-fragments which "look 
similar" to your real code.

Ed H. wrote:
> the next_state is S9 a second time but delay goes
> from the good value to 0 !

Your second process is not using a Clock, correct? Then you store delay 
in a latch, not in a flipflop. That is typically a bad idea. Use a 
flipflop if you want to keep information in an FPGA.

Ed H. wrote:
> So if i understand well, it's not possible to make two assigment of the
> same signal in two different process !

Correct: how should the hardware know, which of both is the valid 
assignment at any given point in time? Maybe in simulation the problem 
does not show up, as in simulation the processes are only executed, 
which may avoid the conflict of different drivers. But in hardware both 
drivers for the same signal would be conflicting permanently with each 
other. So if you try to implement in hardware you must get error 
messages.

Ed H. wrote:
> So i can't do this kind of
> assigment for data_wanted because my value will be stored in a latch ?

You can do: it is not impossible to store data in latches. But it is bad 
style, if gives (serious) warnings and can make severe problems, which 
are sometimes hard to identify and to understand in detail. So just 
don't do it. Store the signals in flip-flops: that's the right place.

If you still have problems with the value of "delay" in a flip-flop, 
then one can look deeper in your code and try to understand, where the 
zero is coming from.

As Lothar wrote: the two-process coding style can very quickly lead to 
latches (and to combinatorial loops). This two process style may be good 
for teaching and to understand, that the FSM has a combinatorial logic 
(described in one process) and a storage flip-flop (described in the 
other process). But once you understood this anyhow and you start to 
generate real code for real world problems, the one process coding style 
of the FSM is much more compact (no need to define every signal twice 
like "flag" and "new_flag") and you avoid all the problems of unintended 
latches and combinatorial loops.

Ups, sorry: this sentence makes no sense.

Achim S. wrote:
> Maybe in simulation the problem
> does not show up, as in simulation the processes are only executed,
> which may avoid the conflict of different drivers.

It should mean:

Maybe in Simulation the problem does nicht show up, as in simulation the 
processes are only executed according to their sensitivity list.....

Ed H. wrote:
> So, when i do my 2-process FSM, when i'm creating new_delay an delay, or
> new_counter and counter, i making flipflop,

In principle this works: data_wanted is stored in a flipflop, 
next_data_wanted "calculates" the input value for that flipflop.

But: you have to describe an assignment to next_data_wanted for every 
state Si in your combinatorial process. If you only assign 
next_data_wanted in some states  but make no assignment to it in others, 
then for the other states the value of next_data_wanted still has to be 
stored in a latch.

A default-assignment to next_data_wanted at the beginning of the 
combinatorial process will solve this problem. Put a
next_data_wanted <= data_wanted there. If you make an assignment to 
next_data_wanted in the actual state, then this is overwritten (e.g. by 
rom_out). If you are in another state and make no assignemt to it, the 
old value of data_wanted (stored in the flipflop) is reassigned.

Ed H. wrote:
> Just because my teachers taught me like
> that (with 2 process ) , so I'm a little scared to do it differently.

Ok, understood. As long as you write code for your teachers this may be 
ok. Once you write code for real life, you may change to the one process 
style ;-)

Ed H. wrote:
> If i understood correctly, every time, next_data_wanted take the value
> stored in the flip_flop of data_wanted, and , when i'm in a state using
> next_data_wanted, i'm overwriting next_data_wanted, and so data_wanted
> too (with my other process).

in that specific state you're overwriting next_data_wanted, i.e. the 
input of your flip-flop. And with the next rising clock-edge, the output 
of the flip-flop (data_wanted) takes the input value.

Ed H. wrote:
> and in my first example, i need to do the same thing for rom_counter and
> next_rom_counter if i don't want to assign next_rom_counter at every
> state !
> Is that correct ?

Sounds correct. And you need to do this for pretty much every signal. 
And this writing-overhead is one strong reason for using the one process 
style.