FPGA quiz: what can be wrong

yes, as long as some_signal is 1, LED1 blinks in sync and same polarity as LED2, no matter the frequency if the signal would be derived from human operated button then it would appear as button is connected to both LEDs

Antti

Reply to
Antti
Loading thread data ...

Don't you people have anything better to do? We all come across puzzling and time-consuming problems where we've made what seems to be a reasonable assumption but which turns out to be false. The lesson is sobering, but the sterile chase after another's problem is little more than self-indulgence.

As Gauss put it:(when others tempted him to become interested in Fermat's conjecture): "I confess that Fermat's Theorem as an isolated proposition has very little interest for me, because I could easily lay down a multitude of such propositions, which one could neither prove nor dispose of".

Reply to
MikeShepherd564

Does your exclusion of global tristate and powerdown pin assignment problems also extend to other global pins, such as reset?

Would the problem appear in a post-PAR gate level simulation of the design?

Is one of the signals clocked, and the other strictly combinatorial?

Brian

Reply to
Brian Davis

yes all global pins like reset, global tristate are excluded

the problem would appear in simulation given __proper__ stimuly _and_ technology dependant simulaton libraries but I am not sure if simulation libraries from any FPGA vendor are accurate enough for the problem to become visible

the issue would appear if only 2 outputs LED1 and LED2 are used no clocks connected to any FPGA IOB (only blink_one_second signal toggles)

Antti

Reply to
Antti

Sorry Mike

I did not expect so many replies ;) well, I th=EDnk there is something to learn in this, and hope you agree when the solution is revealed.

OK, some more hints: the "perfect answer" to the original quiz would be one single 6 letter word.

I do not expect someone to be guess it, but the possibilities of possible cause are getting low, the answer will soon be known so or so.

Antti

Reply to
Antti

Would the source and post p&r simulation exhibit the same behavior ?

Laurent Pinchart

Reply to
Laurent Pinchart

I must think more to answer properly ;)

a full simulation of the code with proper stimuly would simulate the same before and after P&R given the __needed__ accuracy of the technology dependand simulation libraries.

but, as said I do not know if the current FPGA vendor simulation libraries are accurate for the issue become visible. It is likely that the behaviour as observed can not be seen in simulation (no matter proper stimuli). if it comes visible in sims then P&R step would make no difference to the simulation behaviour as FPGA fabric delays, have NO influence on the behaviour at all

Antti

Reply to
Antti

So the post-map and post-p&r simulation would both exhibit the issue given proper vendor libraries, but source simulation (before synthesis) wouldn't, as it doesn't involve vendor libraries. Or does your design use vendor components in addition to pure VHDL code ?

Laurent Pinchart

Reply to
Laurent Pinchart

I must think more to answer properly ;)

a full simulation of the code with proper stimuly would simulate the same before and after P&R given the __needed__ accuracy of the technology dependand simulation libraries.

but, as said I do not know if the current FPGA vendor simulation libraries are accurate for the issue become visible. It is likely that the behaviour as observed can not be seen in simulation (no matter proper stimuli). if it comes visible in sims then P&R step would make no difference to the simulation behaviour as FPGA fabric delays, have NO influence on the behaviour at all

Antti

Reply to
Antti

I have indirectly answered this I think, given proper technology libraries the behaviour would appear in simulation. if proper simulation models are used it would appear before synthesis also. So it does indirectly say that there is vendor dependancy. and as also said the simulation models may be not accurate enough for the behaviour to become visible. I can not tell that for all vendors but for Xilinx as example last time I checked the model accuracy would not make the behaviour observable in simulations.

well the FPGA device in question is not a Xilinx device anyway.

Antti

Reply to
avrbasic

OK, what's the resistor's value, what's the LED's forward voltage, which buffer type is used (current limiting?), what's the VCC?

Unfortunately, I'll be away from my computer for quite a few hours, so I am probably out of this game...

/Mikhail

Reply to
MM

Something to do with the IO protection diodes?

Maybe even powering the device or at least an IO bank through the IO pins and those diodes, rather than through the supply pins?

Reply to
cs_posting

also not so bad suggestion. but now the FPGA is powered from power pins not via phantom IO protection diodes Antti

Reply to
Antti

NO NO NO the resistor value, LED or IOB characteristics have no influence at all.

I will also be away, so you may still get the "it" before others.

and mulitply winners will be accepted too, so if someone knows the magic 6 letter word, or can describe the reason-solution otherwise its ok to send private email. all those emails with correct answers that arrive in my mailbox before the public "revealing" of the issue will be accepted as winners (and get the FPGA miniconsole as price)

Antti

Reply to
avrbasic

Are you using some sort of DDR output flop?

Reply to
Jeff Cunningham

no

Reply to
Antti

Some pin-level (miss) operation could cause this.

- such as OE not handled correctly Behaviour does not match pin-keep errors, and a LED off on pos drive, means a LOW going dominant coupling

If the Logic IS internally correct, and the LEDs are 'dont care', and VccIOs are OK, then all that is left is an IO Cell / Pin Level strangeness.

I take it if you drive 20 leds, they would all exhibit this operation ?

- and that you did apply a fix, that cured it - and such Fix must be applied in SW, as you said the PCB/HW/FPGA are all OK ?

-jg

Reply to
Jim Granville

Jim,

logic is correct, Vccio ok, no pin cell level strangeness either. if I connect the signals that driver led1 and led2 to more LEDs then each of them would have similar behaviour as LED1/LED2 depenging what signal is driving them.

Antti

Reply to
Antti

(snip)

Is this VHDL specific? Would verilog do the same thing? (I know verilog much better than VHDL.)

-- glen

Reply to
glen herrmannsfeldt

You did not reply to where SW Fix was, but I see more information is given in c.a.e ?!

Seems like this is not a FPGA 'fault' at all, if code in a not-before-mentioned AVR can cure it ?

Antii : > I did originally posted to C.A.F. so sorry for copy to .embedded I > only do repost here as realized later that well, the FPGA is made to > look like working wrong by an Atmel AVR MCU. And the "problem" is > small piece of code that executes on ATmega8. In the matter of fact > its only 1 wrong bit in the Atmel code, by changing one bit in the > Atmel code the FPGA code would work as it is supposed to work.

So are we to presume this AVR is providing the stimulus signals, that route thru the working FPGA, and that some Port/RMW issue in the AVR is the culprit ?

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.