Strange behaviour of a design

I am working now for some days on a strange behaviour of a fpga.
The design is complete synchron.
I have the problem that when I change in a state machine a signal,
then the design doesn't function any more.
The problem is a can not locate where it come from, because when I
add
some debug information the design works again.
In Simulation I can't see something wrong.

Has anybody an idea what could be wrong?

On Aug 29, 6:08 am, markus.j...@de.bosch.com wrote:
> I am working now for some days on a strange behaviour of a fpga.
> The design is complete synchron.
> I have the problem that when I change in a state machine a signal,
> then the design doesn't function any more.
> The problem is a can not locate where it come from, because when I
> add
> some debug information the design works again.
> In Simulation I can't see something wrong.
>
> Has anybody an idea what could be wrong?

1. An input signal that is not synchronized to the state machine
clock. -- Make sure all state machine inputs are properly synchronized
to the clock.
2. Violating setup/hold times.  -- Do static timing analysis

KJ

On Aug 29, 8:19 am, KJ <Kevin.Jenni...@Unisys.com> wrote:
> On Aug 29, 6:08 am, markus.j...@de.bosch.com wrote:
>
> > I am working now for some days on a strange behaviour of a fpga.
> > The design is complete synchron.
> > I have the problem that when I change in a state machine a signal,
> > then the design doesn't function any more.
> > The problem is a can not locate where it come from, because when I
> > add
> > some debug information the design works again.
> > In Simulation I can't see something wrong.
>
> > Has anybody an idea what could be wrong?
>
> 1. An input signal that is not synchronized to the state machine
> clock. -- Make sure all state machine inputs are properly synchronized
> to the clock.

This is less likely if the design works when you add debug
unless you added a synchronizing stage along with the debug
logic.

> 2. Violating setup/hold times.  -- Do static timing analysis
>

This is important.  Run timing analysis with "Report Uncovered Paths"
checked.  Very often designs that magically fix themselves on re-build
have an error due to unconstrained or improperly constrained paths.

Also if you don't immediately find a problem looking at the static
timing report, you can try post P&R simulation with the failing
design.

> KJ

<markus.jank@de.bosch.com> wrote in message 
news:1188382135.257124.155580@r29g2000hsg.googlegroups.com...
>
> I have the problem that when I change in a state machine a signal,

Clarify please what kind of signal and how you change it.

> then the design doesn't function any more.

Again, what exactly do you mean here?

You can try using directed routing when adding your debugging stuff (again, 
what is it?) to preserve the failing path(s).

/Mikhail

Good Morning,

thanks for your answers. I will try to do some timing verification
again.
But first here are the answers to your questions.

"Clarify please what kind of signal and how you change it."
=> I tried to insert status bits to make the states of the
     FSM visible with the oscilloscope.
=> Or use direct the states (coding by hand) to debug
     the FSM.

"...then the design doesn't function any more."
=> it seems that the state machine does not start. The start condition
depends only on one
input signal. This input signal is generated with a write with the DSP
to a register. With this
write a pulse of one clock cycle is generated that triggers the FSM.
The DSP is connected to the
FPGA with a synchronous interface.

What does it mean to "use direct routing"? How can I do that?
I did a lot post P&R simulations, but I can't see the error.

Markus

On Aug 30, 1:45 am, markus.j...@de.bosch.com wrote:
> Good Morning,
>
> thanks for your answers. I will try to do some timing verification
> again.
> But first here are the answers to your questions.
>
> "Clarify please what kind of signal and how you change it."
> => I tried to insert status bits to make the states of the
>      FSM visible with the oscilloscope.
> => Or use direct the states (coding by hand) to debug
>      the FSM.
>
> "...then the design doesn't function any more."
> => it seems that the state machine does not start. The start condition
> depends only on one
> input signal. This input signal is generated with a write with the DSP
> to a register. With this
> write a pulse of one clock cycle is generated that triggers the FSM.
> The DSP is connected to the
> FPGA with a synchronous interface.
>
> What does it mean to "use direct routing"? How can I do that?
> I did a lot post P&R simulations, but I can't see the error.
>
> Markus


You haven't mentioned which part and tools you're using.  Xilinx?
Altera?  The DSP is off-chip?  Perhaps the "synchronous interface"
isn't meeting input setup and hold requirements?

Another thought is FSM implementation.  In Xilinx tools you have
to work very hard to force the implementation to use anything other
than one-hot encoding.  This has the unfortunate habit of going
"zero-hot" when inputs are not properly synchronized.  Bringing
the state bit out to debug pins could possibly cause the FSM
encoding to change, masking your problem.

HTH,
Gabor

Hello,

I am working with xilinx (Spartan 2E). The DSP is off chip.

I hope I found the problem today. You are right. It was
a timing issue. I have an Input to the state machine that doesn't met
the timing
requirements.

It is a ready signal that is generated from a device.
After the read strobe the device asserts a ready signal. I
doublechecked the
timing of this pin again and found out that it is difficult to met
timing from
the clock cycle (where read strobe goes low) to the max delay of the
activated
ready signal within a clock cycle. I thought the ready signal is
stable long befor the next
rising clock edge occurs (bit it isn'nt).

Now I do synchronisation and put some sync states in the state machine
to get a
synchronous ready signal.

I let you know about the result.

Thanks a lot for your help.

On Aug 30, 2:44 pm, markus.j...@gmx.de wrote:
> Hello,
>
> I am working with xilinx (Spartan 2E). The DSP is off chip.
>
> I hope I found the problem today. You are right. It was
> a timing issue. I have an Input to the state machine that doesn't met
> the timing
> requirements.
>
> It is a ready signal that is generated from a device.
> After the read strobe the device asserts a ready signal. I
> doublechecked the
> timing of this pin again and found out that it is difficult to met
> timing from
> the clock cycle (where read strobe goes low) to the max delay of the
> activated
> ready signal within a clock cycle. I thought the ready signal is
> stable long befor the next
> rising clock edge occurs (bit it isn'nt).
>
> Now I do synchronisation and put some sync states in the state machine
> to get a
> synchronous ready signal.
>
> I let you know about the result.
>
> Thanks a lot for your help.

Hi,

Just out of curiosity, what do you mean by _sync states_? (I'm a noob
as you can probably see, but at least I'm curious.... )


Kunal

Hi,

Really sorry for not snipping stuff off......

Kunal

@Kunal
I do synchronisation with the async. signal. Therefore I have to wait
at least two clock cycles after the falling edge of the read strobe.
That is the delay that comes with the synchronisation. So I added two
wait states in the FSM.

I found also a other solution to met the timing requirement. I have to
reduce the clock to output delay of the strobe signal. That can be
achieved by putting the output d-Flip Flop in the IOB.

At the moment the solution with the synchronisation works.