Negative spykes on all internal signals in EP4CE15E22C7N

[Altera_Forum]

Hello. 

I use the EP4CE15E22C7N device. (E144 package). The only clock connected is 50MHz, 3.3V to one of the clk inputs. The VCCIO connected to clean 3.3VDC, the VCCINT and VCCPLL to clean 1.2VDC and VCCA to 2.5V.  When i download the design and looking at internal signals with SignalTap, i see that all internal signals, when they are in '1' state (i even created an internal dummy signal whic isn't dependent on reset or clock), getting one-sample-clock-wide negative spikes. When the signal is at '0' state, it doesn't affected.  I over-checked all the decoupling capacitors and DC supply quality and they are good. I can't see any chance of electric contention on the I/O.  I had checked the exposure pad (at the bottom) with XRAY. I can see that there is partial soldering paste there (about 50% coverage, maybe there wasn't enough solder paste at production stage...), but for my opinion, even 50% coverage is enough, doesn't it?  Can anyone suggest another idea how these spikes could be created?

[Altera_Forum]

As a simple test, if you reload the Signal Tap recording with the "Read Data" button, do the spikes appear in the same position? If not, it's rather a JTAG signal quality problem than a real spike.

[Altera_Forum]

When i take to SignalTap a counter w/negative logic Sync Reset input and feed it with a constant '1' (created using the noprune attribute) i can see that when SignalTap shows negative spike, in some cases the counter resets, so it looks like the spike is real...

[Altera_Forum]

--- Quote Start ---  When i take to SignalTap a counter w/negative logic Sync Reset input and feed it with a constant '1' (created using the noprune attribute) i can see that when SignalTap shows negative spike, in some cases the counter resets, so it looks like the spike is real...  --- Quote End ---    Hi,  did you see a break down in your core voltage or I/O voltage, when the design is running ?  Kind regards  GPK

[Altera_Forum]

No, i didn't see anything like that. More than that - i created very tinny design for test and neutralized all the other possible sources of GND bouncing but the number of spikes remained the unchanged....

[Altera_Forum]

--- Quote Start ---  No, i didn't see anything like that. More than that - i created very tinny design for test and neutralized all the other possible sources of GND bouncing but the number of spikes remained the unchanged....  --- Quote End ---    Hi,  what kind of board are you using ? Do you have a second board available ?  Kind regards  GPK

[Altera_Forum]

its really very simple board. The FPGA just connected to serial FLASH for future + JTAG for debug. It has single 50MHz external oscillator. 

The other IO's are are for management of analog ADCs, DACs AMUXes  I got the same behavior on 3 different boards.  I just found something strange in the HDL evaluation board at page 6 http://www.hdl.co.jp/en/spc/acm/acm-023/acm023r1-man-en-v10.pdf they write that the JTAG-P2 is connected to 3.3V (the VCCIO), but ALTERA, in their manual write that it should be 2.5V... I begin to think that maybe, nevertheless the problem is in the JTAG interface despite of that i had checked this.... Tomorrow i'll get the boards again and re-check this issue again...

[Altera_Forum]

Oooops... 

Sorry, i meant JTAG PIN4, not PIN2. PIN2 is GND

[Altera_Forum]

--- Quote Start ---  I just found something strange in the HDL evaluation board at page 6 http://www.hdl.co.jp/en/spc/acm/acm-...man-en-v10.pdf  they write that the JTAG-P2 is connected to 3.3V (the VCCIO), but ALTERA, in their manual write that it should be 2.5V...  --- Quote End ---   A JTAG voltage of 2.5V is suggested to reduce the absolute voltage level of possible overshoots at the FPGA pins. Nevertheless, all recent FPGA families can still work with 3.3V JTAG supply. The point can't explain your observations, I think.  As far as I understood, all results have been obtained through SignalTap. Did you ever feed a generated signal to an output pin and checked it with an oscilloscope? Did you verify, that the clock frequency is actually 50 MHz? Is the design operated from the input clock or a PLL? In the latter case, did you check, if the PLL is permanently locked by sending the locked signal to a pin? Are you sure, that your design state doesn't possibly depend on floating FPGA inputs?  P.S.: Assuming, there may be an issue with JTAG or SignalTap operation, you should perform the hardware check with and without SignalTap activities.

[Altera_Forum]

The spykes i see in SignalTap are 1 sample wide, so i assume that if there are phisical spiles, there are very narrow and maybe my oscilloscope with 200MHz bandwidth isn't enough to catch them. 

Maybe ill implement a logic which detects spykes and producing an error output if there is one...  Yes, i had verify that the oscillator is 50MHz, I also involved PLL in 1:1 configuration with same results. The "locked" signal was '1' (permanently), but i seen the same one-sample spykes on it also as on all other signals. If PLL looses its lock, it goes to "0" for much longer period, isn't it?  I had created an internal signal which is constant '1' value and doesn't depend on anything, even not on reset. and i still see spykes on it...  I must say that this issue looks very strange to me.... this is the 1'st time i use Cyclone IV device... In the past, with other Cyclone, Stratix and Aria devices i didn't got anything like it...

[Altera_Forum]

OMG !!!!! 

I had found my old good ByteBlaster and with it everything looks good and clean!!!  the spykes had been seen with TerAsic USB Blaster i just ordered... They claim that it is 100% compatible with ALTERA USB Blaster...

[Altera_Forum]

OMG, THE TERASIC USB BLASTER MADE IT.... 

 i found my old and good ByteBlaster and checked again.... NO SPIKES, everything is nice and clean....