The only question mark is to whether to call it errata to the model or erra ta to the documentation? In the LT group it has been pointed out to me tha t all the digital devices work the way the designer intended if not the way they documented. So errata to the documentation perhaps?
I believe Joerg was dealing with issues of the set/reset input polarities n ot being well documented not too long ago. My issue concerns the behavior when both async inputs are asserted simultaneously. The wiki says the DFLO P behaves like the SRFLOP.
Dflop (CLR takes precedence over PRE, also a start up state may be set ? ?? see SRflop)
The SRFLOP is documented as...
The R (reset) input takes precedence over the S (set) input.
While that is true for the SRFLOP the DFLOP works very differently. You mi ght expect the result to only depend on the two inputs (this are async inpu ts after all) the outputs depend on the state of the FF or in other words, the order of assertion of the two inputs. So assert clear and you get what you expect. Assert set along with it and it does nothing. Assert set by itself and you get what you expect. Assert clear along with it and it doe s nothing.
Neither has priority over the other. The outputs don't go to a defined sta te like most commercial products (both Q and Qn high for example). The sec ond asserted async input is disabled.
Very odd and very undocumented.
I'm talking to people in the LTspice group to make sure I didn't botch the simulation and how the docs might be updated. Seems they've locked out use rs because of excessive spam.