Peter said:
What seems to be the problem?
Before and during configuration all Xilinx FPGA outputs are tristated.
During configuration, the 3-state-controlling flip-flop can and should
be asynchronously held reset.
Yes....and it is done so automagically by the FPGA...thank you.
It is only after the clock has started and the application runs that
the output can become active, if the user wants that to happen.
Where is the touchy problem?
No problem. My point is I'm looking for the actual application that
really does require specified reset behaviour PRIOR to the clock
starting.
Just to support Bob:
A 64-mA output sinks 64 mA at 0.4 V. And that is guaranteed worst case.
At nominal conditions it may behave not as an 8 Ohm, but rather as a 3
to 4 Ohm resistor. Easy to smoke in a multiple-contention case.
Easy to smoke only if the condition persists for a 'long' time, where
the definition of 'long' is likely getting smaller as time goes by
since geometries shrink every few years and devices become less and
less tolerant of abuse. So how long is 'long' for your representative
Virtex-5 to smoke under the conditions you mentioned above?
Also, I think you're bolstering my point not Bob's. Bob's point was
that if the tri-state control is the output of a flip flop and you have
to wait for the clock in order to set the state of that flip flop then
you can have bus contention....I agree....however, using a device that
tri-states the outputs before and during configuration and clears the
flip flops you shouldn't have that contention because the output of
that flip flop won't be some unknown, it can be designed to be shut off
coming out of configuration and when the clock arrives, it arrives.
With older technology parts that may not have cleared the flops for you
the contention would only exist if reset was designed to be released
prior to clock and then only for the probably few milliseconds until
the clock actually started. But the older technology parts could also
take the abuse for that period of time and the design error (IMO) was
the releasing of reset prior to clock starting anyway. As an example,
take the PCI bus; reset is async to the clock but reset will not be
de-asserted until after the clock has been running for some nominal
number of cycles. Even the motor control example that was posted on
this thread was backed off a bit with the realization that there is
outside logic that checks first to see if things are 'OK' before
actually turning on the motors.
In any case, nobody has articulated yet the application that really
does require specified reset behaviour PRIOR to the clock starting thus
requiring use of the async reset (with the exception of the reset
signal synchronizer flip flop itself).
I think I'll quit on this thread (and in the future when it comes
up....hey stop the applause out there). If someone can actually
demonstrate such an application I'll be happy to hear about it until
then I'll just assume that such an application still might exist even
if it after several prods from the group they have yet to produce a
good example.
KJ
