FPGA quiz: what can be wrong

OK, let me try. Is the six-letter word GLITCH by any chance?

/Mikhail

NO its not so trivial!

This sounds like a "problem" on the way you use the IO-Buffer to me. I expect you did nothing like using the wrong IO-Standard (e.g. Lvds instead of TTL) and use an IO-Standard useful to drive a LED. Do you have problems with SSO or Groundbounce?

Or is it a problem with the IO-Buffer containing a bit more logic than the vhdl-model, so you have some influence from clamping diode or something like that? (I have no clue if there is a possibility for such a behavior without strong technology dependancy)

bye Thomas

NO NO NO not any problem with IO buffer

You didn't really drive a '1' at the input but just left the input floating, so that the led output had influence on was was "sampled" by the input buffer (EM or small change in the threshold making it switch).

Sylvain

no, the issue is not related to any open or floating inputs or any EMI effects

Antti

Antti schrieb:

Hi Antti, so there's an extra MCU involved. Who could guess that from your original posting. And you could solve the issue by changing the code in the MCU. Well now it makes sense that everything with the VHDL and FPGA and even the PCB and power is ok.

So let me give a try on a 6 letter word: ENABLE

By some chance your 1 sec Signal (or some other signal from the cpu that is synchronous to this one) is continously enabling (and disabling) the big Logic, causing the test signal to blink with the same frequency.

Eilert

Hi morning

we are getting little closer

ENABLE is not the word, but first letter is the same :)

the 1 second signal doesnt actually enable or disable the logic in the FPGA the logic remains functional, no matter the signal value

the MCU was really generating a "test debug led blink signal" and i expected that signal to work as such, but it had this described side- effect, of controlling another output depending on the out value of that port.

Antti

If an MCU is involved, and if the issue has been fixed by changing a single bit in the MCU 'code' (I suppose you mean the binary firmware once compiled), this might change the problem quite a lot. Just a wild guess at the 'magic 6-letter word staring with E', does the AVR EEPROM save fuse (EESAVE) play a role ? Did you forget to clear or rewrite the EEPROM which resulted in a different system behavior ?

Laurent Pinchart

ROTFL the guesses are getting better and better.

I happen to have written the first ever released commercial AVR compiler ever (it was on market 30 days after first AT90S1200 was ever sold), the 1 bit error is in AVR program compiled with this compiler (AVR Basic compiler) and no, if the problem is not caused by an BUG in the compiler ;)

OK, here is the code in AVR basic that executes on the ATmega8

// CODE WITH ERROR, //LED1 and LED2 blink if some_signal=1, //LED2 blinks, LED1 off whne some_signal=0 loop: sendbyte($40); // set LED2 ON wait_1sec; sendbyte($00); // set LED2 OFF wait_1sec; goto loop

// FIXED CODE, // LED2 blinks, LED1 is controlled by state of some_signal loop: sendbyte($40); // set LED2 ON wait_1sec; sendbyte($10); // set LED2 OFF wait_1sec; goto loop

as you see the "fix" is exactly 1 bit !!!

Antti here and in other place signal-wire-label-function names are changed from the original ones

So the fixed one creates a balanced signal, whilst error is single ended. The fixed one also has at least one bit high on the port.

You have not identified which of these port bits map to CLK and LED operations.

-jg

Are all the pins involved 'normal' I/O pins, without any shared functionality such as JTAG - if so, what kind of pins? Does sendbyte control 8 separate i/o pins / does sendbyte have any side-effects?

Doug

Hi,

Are all the i/o pins involved "normal" pins without any shared/special functionality such as JTAG, CLK etc? If so, what? Does sendbyte control 8 separate i/o pins? Are they all configured as inputs? Does sendbyte have any side-effects? How's the wiring between AVR and FPGA in all related signals?

6-letter magic e-word suggestions: Encode, Energy, EXTEST.

-Doug

and we have a WINNER, please contact me in private you will get an FPGA miniconsole from the first production batch.

the magic word is EXTEST

and all others please stand by, I may have some second prizes to offer as well, and I will post here some longer explanation how this "issue" happened in the first place.

and yes the explanation is very plausible, the blink_one_led was connected to port named UIREG6 of the UJTAG primitive of Actel ProAsic3 FPGA

0x40 was used by the MCU to set the UIREG6 to high, it made the LED2 on. now the LED off should have been 0x10 (or some other value in range 16-127) to keep the IR register content in "user instruction" range, but I accidentitally just cleared bit 6, so the instruction i sent for LED2 off as 0x00 - EXTEST

so that explains it all. no mystery. nothing wrong, expect small human error in some coding.

Antti

The LED output drivers are bidirectional, and bit 6 is the active-low output enable for both LEDs. Two other bits are the active-high data bits for the 2 LEDs (bit4 is LED1).

Bad code: $40 -> outputs disabled, both LEDs turn on via an IOB pullup $00 -> outputs enabled, data bits 0, both LEDs off ie. both LEDs flash Good code: $40 -> outputs disabled, both LEDs turn on via an IOB pullup $10 -> outputs enabled, LED1 on because bit 4 is 1, LED2 off because bitX is 0

?

Antti,

Firstly I don't quite understand what the whole story had to do with FPGA, and secondly I among others asked you if the special purpose FPGA pins were involved and you said "no". IMHO, the UIREG6 port of the UJTAG primitive qualifies as such a pin...

/Mikhail

Let's just hope Antti is not let anywhere near setting Exam or Interview questions any time soon ! :)

-jg