SparkyT wrote:
> Is it as simple as this?
You're on the right way...

I would also check wether the counter value is (nearby) 0 at that point. 
Because when not, then you have lost counts in the previous round. That 
may be a reason to raise an ERROR flag.

SparkyT wrote:
> Nearby zero(0) means what exactly?
That depends on what you would allow for an deviation. Usually it must 
be 0.

> check at the edges? (-2147483647 to +2147483647)
You will not be able to buy an encoder with somewhat 500000000 lines per 
revolution. So you will never ever reach the limit of an integer number.

> check when p is nearby 0? (p > X or p < -X, where X is 10? 100? 1000?)
Because my code does a quadruple evaluation all of the 4 edges in one 
"step" are counted. Usually the index pulse is 1 step wide, so at either 
"end" of the index pulse the counters value is up to 3 or down to -3.
So I would raise the error flag when the counter >3 or <-3 at the 
"begin" (=rising edge) of the index pulse.

1

        if ENA then

2

            if dr_INDEX = "01" then

3

                p <= 0;

4

                EQEP_ERR <= '0';

5

                if p>3 or p<-3 then

6

                    EQEP_ERR <= '1';

7

                end if;

8

            end if;

9

        end if;

SparkyT wrote:
> But if i clear the position count on the risedge of Index, and do the
> checks on the falledge of Index, then it looks ok.
Sounds very like the traditional latency error. Just dig inside your 
module and have a look for the pos_cnt that causes the error. Look at 
the dr_I at the same time...

> What do you think?
The problem is located outside the posted piece of code.

SparkyT wrote:
> I guess the err is triggered because value 37(in this specific sim) is
> used for the check(?)
No, its triggered because 25 in pos_cnt is more than 3 in this line:

1

if pos_cnt>3 or pos_cnt<-3 then

2

    err <= '1';

> i fail to understand how clearing the pos_cnt and checking it on the
> same edge of the index
As I said: latency.
You must dig in much deeper in the behaviour of signals in processes!
To say it simple: they do not change their value throughout the process. 
They keep their "start values" from the beginning of the process to the 
end of the process.
When you assign a new value to a signal them the signal does not change 
its value! The new value is just "memorized" until the end of the 
process. Then it is assigned to the signal.

So in your specific "problem" it looks like that:

1

if ENA_I then          -- Sim: ENA_I is 1

2

  if dr_I = "01" then  -- Sim: dr_I is 01

3

    pos_cnt <= 0;      -- kind of magic here: pos_cnt does not change its value as it is a signal!

4

                       -- the assinged value is not updated till the end of the process!  

5

      err <= '0';

6

      if pos_cnt>3 or pos_cnt<-3 then -- Sim: pos_cnt is still 25 here and throughout the whole process!

7

         err <= '1';  -- obviously we will end up here... :-(

This kind of behaviour is really nice, when you are used to it. But 
first you must "get the trick" somehow...  ;-)