FPGA quiz: what can be wrong

Too bad.. :-/

You wrote earlier: "let say some_signal comes from external switch directly, and has no FPGA logic except routing."

Is the input "some_signal" pulled-up or down with enough strength to maintain this input stable when the external switch is open ?

Ok here is my plausible version of the story:

Your LED1 is weakly (marginally) forward biased when some_signal is high. The trace of LED2 is capacitively coupled with that of LED1. The duty cycle of blink_one_second is 1 sec. Now while LED2 is ON, a negative potential appears at the ground of LED2 (momentarily) with respect to the ground of LED1 causing a transient current to flow through LED1 until the "standing capacitance" between the two is charged and hence the blinking. When blink_one_second goes OFF, the operation is reset and LED1 goes OFF as well because the weak bias can't turn it ON without the extra kick of the capacitive coupling.

Too dramatic I know :).

That's as seen on a scope, at the pins ? That moves the issue to downstream of the FPGA .

Now you are contradicting yourself.

You have stated there is no coupling in code, and P&R/FPGA is OK The Visual operation is not as you described expecting, logically.

So, not working as logically described, means some errant coupling, or dependance. (it does not have to be inside the FPGA, just somewhere between your eyeballs, and the source code ! :)

I thought the quizz was to find the errant cause, but now you state "there is no ERRANT coupling" - does that mean you imagined it ?

-jg

it doesnt matter, consider both signals going to LED1, LED2 being proper nice signals with no spikes and no glitches. they do not carry undefined value at any time

Antti

you say it, too dramatic. the issue is much more "elegant" in solution

There's got to be some coupling somewhere. Is 'errant' coupling just bad VHDL code?

My guesses are

(1) the cathodes of LED1 and LED2 have a high-impedance connection to GND, possibly via an input structure on the FPGA (the LED1 input switch?). Of course, this means that there's a PCB error, and I think you said the PCB was Ok. This isn't enough to explain what you're seeing, but maybe you created an SCR in the input structure when you fried it, or

(2) you created some output pin coupling when you fried the chip, presumably through the Vcco protection diodes.

Evan

two

its

missing

debugging

it

Hi Jim,

the quizz is to find solution to the behaviour as described. no coupling in code, no P&R error, visual inspection as desribed. and no, I did not imagine it. I called my wife to stand by me and look the code and LED behaviour to out-rule the Human-factor and the possibility of problem in my eyes. her advice was also that is likely to be "bad damage FPGA IC" issue. but, that is not the case, the FPGA is not damaged.

Antti

no PCB error. I had one PCB only, so I quickly made another PCB where FPGA was not stressed and the second PCB had exact the same behaviour!!

I was not to belive my eyes, I was so sure it must be fried FPGA problem! it was not

NO DCM issue. the FPGA in question doesnt have DCM ;) but the PLL on that FPGA was not used at all Antti

Any answer on the Scope probe at the LED1,LED2 pins ?

-jg

sorry, scope would show the LED1, LED2 signals switching in sync with with some relatively small skew, perfect no glitch ouput signals

Antti

different FPGA production version ?

LAST try.

Your I/O driving LED1 is not buffered i.e. no keeper in ucf. So same input buffering one_second is actually driving LED1 because of the combinatorial path. The rest of the story is as I speculated earlier--- LED2 is coupling LED1 and only when LED2 is ON LED1 gets properly biased.

NO this issue could be re-created and it would re-appear as described on FPGA's from many (maybe all) FPGA vendors

it is some FPGA feature that causes it. the reason it happens (in the case described) is bound to one specific FPGA device family, but similar case is also thinkable and repeatable on other family and vendor FPGA with some minor changes (the VHDL code for other FPGA family would stay the same, essentially single wire)

Antti

eh, giving up SO EASY ??? NO NO NO the issue is not related the "output device LED" I only LEDs on FPGA pins as poor man FPGA debug tool, as the FPGA was

99% full, with maybe 9 cell free so I could not use any on-chip instrumentiation tools

Antti

Nothing wrong with the _VHDL_ - were all other files ok? Especially constraint files for I/O configuration - could you mis-configure the on-chip termination/pull-up/I/O standard/drain/hold etc to cause this? What's the FPGA?

Doug

yes

VHDL OK OK constraint files __all__ other FPGA files OK FPGA configured properly

Antti

Antti,

Does your synthesis tool think of "blink_one_second" as clock signal? Does it connect to the clk input at your IOB ?

If that would be true: does your tool think "some_signal" is syncronous to that clock signal?

j.

blink_one_second is not treated as clock signal it is not connected to special clk IOB FPGA tool does not think the signal are syncronous

as a matter fact the described behaviour could be re-created to produce described visual behaviour no matter what synthesis/P&R tool and FPGA device/family is being used.

Antti