Detecting changes in entries

[Xin Xiao]

I have a system of cache memory-RAM implemented using two processes (the
cache memory is implemented as a finite state machine).

I would need to detect a change in one of the entries (ie the CPU provided a
new address to the cache), so that the cache start seeking in the directory,
and so on. If there's no new address, the cache should rest in one state.

What I'm doing now is

....

if CPU_d'event or CPU_a'event or CPU_RW'event then
NEXT_STATE <= ...;
end if;

But this is not synthesizable.

if I add another process like this:

process (CPU_d, CPU_a, CPU_RW)
begin
NEXT_STATE <= ...;
end process;

then the compiler complains because NEXT_STATE has two drivers (one in the
state-change process and another in the process I wrote above).

Maybe you have a simpler idea....

 

[Mike Treseler]

if CPU_d'event or CPU_a'event or CPU_RW'event then
NEXT_STATE <= ...;
end if;

But this is not synthesizable.

True. For synthesis you only get one clock per process.
All else is inputs and outputs.
If I wanted to compare a cpu address with a registered value,
I would check for a cpu handshake on every rising clock edge,
and only proceed if this strobe is active.

Here is an example process that looks at the
handshake inputs push and pop to trigger
updates to the output port q using the value
of the input port d, and its previous values.

http://home.comcast.net/~mike_treseler/stack.vhd

Notice that the clock is only used by the process
template. It is not referenced in the update
procedure.



-- Mike Treseler

 

[Xin Xiao]

Hi mike, thanks for your input. I was thinking and now I have a new signal
from the CPU, CPU_enable, that is, a signal that says "this is a valid
address and data, so process them". Inside my state-change process I added
CPU_enable to the sensitivity list and I do:

if CPU_enable = '1' then
NEXT_STATE <= SEEK_ADDRESS; -- Seek the address in the cache
end if;

Do you think it is a good idea?

 

[KJ]

Hi mike, thanks for your input. I was thinking and now I have a new signal
from the CPU, CPU_enable, that is, a signal that says "this is a valid
address and data, so process them". Inside my state-change process I added
CPU_enable to the sensitivity list and I do:

if CPU_enable = '1' then
NEXT_STATE <= SEEK_ADDRESS; -- Seek the address in the cache
end if;

Do you think it is a good idea?

Most likely not a good idea since (I'm assuming) that this process is not
clocked based on your description which means that the signal 'next_state'
will get synthesized as a transparent latch which is generally not a good
idea in FPGA designs since the timing requirements will be difficult to
guarantee. Use a synchronous design approach instead.

KJ

 

[Xin Xiao]

It's an state machine:

process (Clk, Reset)
begin
if (Reset = '1') then
STATE <= RESET_STATE;
elsif (rising_edge(Clk)) then
STATE <= NEXT_STATE;
end if;
end process;

process (STATE)
begin
case STATE is
when ....

end case;
end process;

I need that the state machine check the signal CPU_enable and go to state
SEEK if it is set to '1'. How can I do that?

 

[sudhi]

It's an state machine:

process (Clk, Reset)
 begin
  if (Reset = '1') then
   STATE <= RESET_STATE;
  elsif (rising_edge(Clk)) then
   STATE <= NEXT_STATE;
  end if;
 end process;

You can definitely do this

process (Clk, Reset)
begin
if (Reset = '1') then
STATE <= RESET_STATE;
elsif (rising_edge(Clk)) then
if enable = '1' then
STATE <= SEEK;
else
STATE <= NEXT_STATE;
end if;
end if;
end process;

but you may want to check any corner conditions with back to back
enables.

 

[Mike Treseler]

Hi mike, thanks for your input. I was thinking and now I have a new
signal from the CPU, CPU_enable, that is, a signal that says "this is a
valid address and data, so process them". Inside my state-change process
I added CPU_enable to the sensitivity list and I do:

if CPU_enable = '1' then
NEXT_STATE <= SEEK_ADDRESS; -- Seek the address in the cache
end if;

Do you think it is a good idea?

Adding an enable is a good idea.
Make sure the cpu and the fpga use
the same clock.

Consider running a simulation
to see if your idea works.

-- Mike Treseler

 

[Just an Illusion]

Hi,

The Sudhi solution is equivalent to a synchronous reset, but that can
drive some verification/validation problem if the 'enable' signal is a
DUT input or if the signal must be active on a reduce set of state.

For example, if the FSM States are (A, B, C, D, E, F) and if 'enable'
must be active only in state B, D, E and F.
The Sudhi syntax example isn't 'formal' and if you use any 'formal'
verification tools based on 'model checking' approach, you must have a
failure.

A typical problematic situation is like a 'race' situation if the
'STATE' processing time require more than one 'Clk' cycle.
See the following situation, if the SEEK state require 2 'Clk' cycle :
- Simulation Step 1 : rising_edge(Clk) & enable='1' => STATE <= SEEK
- Simulation Step 2 : enable='0' => NEXT_STATE <= B, STATE <= SEEK
- Simulation Step 3 : rising_edge(Clk) & enable='0' => STATE <= B *Error*

I think than the best solution is the definition of a 'waiting' state.
From this state, you go to the 'busy' states where you process to all
your activities (Seek state and others) and during all these states you
drive a 'busy' signal that go back to your CPU, in example thru a
dedicated 'state' register, and the signal CPU_enable doesn't falling
before the end of 'busy' state (falling of it). At the end of all 'busy'
activities you FSM go back to this 'waiting' state.


sudhi has wrote :

 

[KJ]

Hi,

The Sudhi solution is equivalent to a synchronous reset, but that can
drive some verification/validation problem if the 'enable' signal is a
DUT input or if the signal must be active on a reduce set of state.

For example, if the FSM States are (A, B, C, D, E, F) and if 'enable'
must be active only in state B, D, E and F.
The Sudhi syntax example isn't 'formal' and if you use any 'formal'
verification tools based on 'model checking' approach, you must have a
failure.

Just curious, what is not 'formal' about the posted code? Why would a
model checking report a failure and what is the failure?

A typical problematic situation is like a 'race' situation if the
'STATE' processing time require more than one 'Clk' cycle.

OK, but this gets caught by static timing analysis. A tool to perform
static timing analysis is embedded with every single FPGA/CPLD design
tool is worth using. Failure to use such a tool on a design is
something only to be attempted by those with lots of time on their
hands and who receive joy while investigating 'unusual' behaviors.

See the following situation, if the SEEK state require 2 'Clk' cycle :
- Simulation Step 1 : rising_edge(Clk) & enable='1' => STATE <= SEEK
- Simulation Step 2 : enable='0' => NEXT_STATE <= B, STATE <= SEEK
- Simulation Step 3 : rising_edge(Clk) & enable='0' => STATE <= B *Error*

Actually, since you were positing that it takes more than one clock
cycle to compute the next state, the next state might be anything
(i.e. you can't say with any certainty that it would be 'B').

I think than the best solution is the definition of a 'waiting' state.
 From this state, you go to the 'busy' states where you process to all
your activities (Seek state and others) and during all these states you
drive a 'busy' signal that go back to your CPU, in example thru a
dedicated 'state' register, and the signal CPU_enable doesn't falling
before the end of 'busy' state (falling of it). At the end of all 'busy'
activities you FSM go back to this 'waiting' state.

If it takes more than one clock cycle to compute the next state as you
claim than adding your new 'waiting' and 'busy' states won't improve
things at all since they will be just two more states...and your
position was that it could take longer than one clock cycle to compute
this next state.

The best solution is to simply perform static timing analysis and fix
all failures. If there are some paths that just really can't be
improved enough to fit within the clock cycle (but also don't
functionally need to for that particular design), then simply create
(or use an existing) clock enable, tell the timing analyzer which
selected signals are allowed to take more than one clock cycle and
move on.

Kevin Jennings