Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20704 Discussions

SignalTap II questions

Altera_Forum
Honored Contributor II
1,216 Views

Hi, 

I have 2 questions regarding SignalTap: 

1. Sometimes I see 2 active states in a state machine - how is it possible? I assume that it means that there is a bug, what kind of bug can cause that? 

 

2. I'm trying to sample input pins by defining them as triggers but SignalTap doesn't seem to be able to sample them. If I use something else as trigger I'm able to see those pins change states. How can I fix that? 

 

Thanks in advance
0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
428 Views

What type of USB blaster and operating system are you using? I have this trouble with some alternative blasters and when running the Jtag server under Linux. Switching to a real Altera blaster and/or Windows solves the problem.

0 Kudos
Altera_Forum
Honored Contributor II
428 Views

Hi, 

I'm using Altera's USB Blaster II and Windows 7 64 bit.  

I think that its a real bug (I mean question# 1) and not a SignalTap issue because it usually happens when the FPGA isn't functioning properly so I assume that there is something wrong with my state machine. The question is what kind of bug can cause that? 

 

Thanks
0 Kudos
Altera_Forum
Honored Contributor II
428 Views

Okay. Just needed to clear out any problems due to the blaster itself, because I lost a lot of time on this bug ;) 

It depends a lot on your code. A solution could be to run it in a simulator, and add a breakpoint on an "other" case that would detect unexpected values for your state variables, and hopefully from there reconstruct what was happening before.
0 Kudos
Altera_Forum
Honored Contributor II
428 Views

Is your design properly constrained and does it meet all timing requirements?

0 Kudos
Altera_Forum
Honored Contributor II
428 Views

I was able to make things better by reducing the frequency of the main clock (it is much faster then the input signals that are being sampled). I can still see the problem sometimes though.  

I'm working on properly constraining the design (I'm not an expert). My basic clock is much faster than the input signals and the device utilization is very low, isn't that enough to put me on the safe side of the timing issues?
0 Kudos
Altera_Forum
Honored Contributor II
428 Views

You have fewer chances of getting timing problems when you reduce the clock frequency, but you could still have some (and even at low frequencies, you can have hold problems). 

Are your input signals synchronized with the clock? If not, then you need to add synchronization stages on the FPGA inputs, to avoid metastability issues that could put your state machine in an unknown state. 

Check also that the signal that resets your state machine is synchronously released with the state machine's clock.
0 Kudos
Altera_Forum
Honored Contributor II
428 Views

The input signals aren't synched with my clock. I'm sampling them by using a flip-flop and detecting rising/falling edges. What so you mean by "synchronization stages"? Is it wrong to use flip-flops for that?

0 Kudos
Altera_Forum
Honored Contributor II
428 Views

With unsynchronized inputs, you can run into metastability problems. If your input signal changes to close to the clock edge and it doesn't follow the setup/hold requirements, then the flip/flop may oscillate between two states, which can have bad consequences on the rest of the design (including unwanted states). 

The solution to the problem is to register all the input signals with several flip/flops in series. 2 or 3 stages are usually enough. 

 

Check also that the clock you use in signaltap is the same than the one that's running your state machine (or at least synchronized with it). If not you could miss the synchronization between all the signals you are measuring.
0 Kudos
Altera_Forum
Honored Contributor II
428 Views

I added 3 flip-flops instead the 1 I used earlier and it seem to have solved the problem. Thank you.

0 Kudos
Reply