I would like to have a clear canalization to know the full story about it..
Perhaps you meant "canonization"?
This is perhaps the most mis-understood and ill-instructed concept of logicsynthesis: the synthesis of storage, and more practically, how to avoid synthesizing a latch, which is a type of storage element.
Generally speaking, anytime a signal or variable is required to retain its value from a previous execution of the process that assigns it, a storage element is synthesized to remember that value.
Whether the storage is synthesized as a register or a latch is based on theconditions under which the previous value was stored. It if was stored only upon the edge of another signal, then a register is synthesized to hold the value. If not, then a latch is synthesized to hold the value.
How can one avoid unintentionally synthesizing a latch? Avoid having to remember a previous value that was not stored on a clock edge. Within most clocked processes*, it is impossible to synthesize a latch, because storage within them always occurs on a clock edge.
That leaves combinatorial processes. If you can avoid combinatorial processes, then your chances of synthezising latches reduce to zero*.
If you need or desire to use combinatorial processes, the oft-stated adviceis to "add an else for every if". The problem is, this is neither necessary nor sufficient to avoid latches.
To avoid a latch in a combinatorial process, ensure that every execution path through the combinatorial process assigns a value to every signal or variable ever assigned by the process.
You could do that within else statements for every if statement, but that inspection for completeness during review is extremely difficult, because you still have to confirm that every signal/variable gets assigned at least somewhere for every possible path through the conditional statements.
A better approach for combinatorial processes is to provide default assignment statements for every signal and variable assigned by the process (note these assignments cannot simply assign a signal with its current value, or you defeat the whole purpose of avoiding latches.) Execute these default assignments right up front in the process, before any conditional statements could interfere with their execution.
When using variables exclusively for combinatorial logic within a clocked process, the same approach works to avoid inadvertently synthesizing a register from a variable (if that is forbidden in your organization or project).Just make sure every variable has a default assignemnt statement immediately folowing the "if rising_edge(clk) then" statement, but prior to any further conditional statements, and none of your variables will synthesize to aregister either.
Notice a pattern here? It doesn't matter what kind of storage element you are trying to avoid, the rules are the same.
*There's always a catch... Within clocked processes, it is possible to define combinatorial outputs that are functions of registers represented by local variables. These combinatorial output signal assignments are placed within the process, but after the "end if" for the clock edge detection (just before the "end process" statement.) In this region, if a signal is only sometimes assigned, a latch can also be synthesized. If you have conditional statements in this region, then also include default assignments at the beginning of this region. If you don't use these types of outputs, then you don't have to worry about it.
Andy