Transistor behavior
C Burch
up two issues that may indicate problems with the current transistor
behavior. Could somebody more familiar with transistor-level design
help me out?
A. The user attempted to build a standard NAND gate using transistors
- as diagrammed at http://en.wikipedia.org/wiki/File:CMOS_NAND.svg -
and found that he had to add a pull-up resistor between the two N-type
transistors in series. The need arises when the upper N-type
transistor's gate (A) is 1 and the lower N-type transistor's gate (B)
is 0. For the lower transistor, whose gate is 0, it places a floating
value onto its drain. Without a pull-up resistor, the upper transistor
(whose gate is 1) is supposed to transmit this floating value. But in
the current Logisim version, any floating value is "converted" into an
error value by the transistor, so an error output comes out of the
upper transistor, which then becomes the NAND gate's output when the
first input is 1 and the second is 0. Of course, that's not right, so
he added a pull-up resistor to pull the floating value up to 1, which
solves the problem.
But this may well show a problem with Logisim's transistor design. My
question: In a real transistor, if you have a high-impedance Z value
going into the source of a transistor, and the transistor's gate says
to transmit the value, will the drain be that same high-impedance
value, or will the transistor drive *something* strongly onto its
drain (and so the X value is a more appropriate)?
B. Having built a system of transistors corresponding to a NAND gate,
the user proceeded to attempt to build an S-R latch using two such
NAND systems. This ends up remaining with an output of X regardless of
what inputs you give it. This is unrelated to the previous issue, and
the problem is one of timing:
When a signal reaches a NAND system of transistors, it goes to the two
P-type transistors in parallel at the same time as the signal reaches
the N-type transistors. Suppose the B input changes from 0 to 1 while
A remains at 1. That is, the NAND input connected to the N-type
transistor whose source is ground changes from 0 to 1. The P-type
transistor now receiving a 1 cuts off sending anything to the NAND
system's output immediately, while the N-type transistor takes an
extra step to affect the NAND system's output (since its updated drain
must still travel through the upper N-type transistor to reach the
output). As a result, for just one step, the NAND system's output is
floating. Of course, its output becomes 0 in the next simulation step,
so the floating value doesn't persist for long.
But even this brief instant of a Z output is enough to break
everything: In this step, Z is sent into the other NAND system, which
of course becomes the gate input for that other system's transistors.
A Logisim transistor seeing a gate of Z drives X onto its drain. So
the other NAND system ends up driving X for its output, which of
course is fed back to the first NAND system, which becomes the gate
for some of its transistors, so those transistors start driving X as
the first NAND's output, and now we've reached a stable system where
all outputs are X.
This brings up two questions: First, should we hope for such a circuit
to work, or is the two-NAND S-R latch basically a convenient
simplified fiction propagated by textbooks? And second, is Logisim
correct that a transistor whose gate is Z should drive X onto its
drain regardless of its source?
-Carl
Ilia Lilov
here: http://en.wikipedia.org/wiki/File:NMOS_NAND.png (additional pull
resistor is needed again) and S-R latch using them. Circuit is
attached. Latch works fine, so two-NAND S-R latch isn't simplified
fiction (at least it possible to implement it in Logisim using current
transistor behavior).
As of second question, I think it is the same question as one about
gates output while input(s) is undefined. I remember we discussed it
thoroughly last summer, and your deciding argument was "it's Verilog
standard to emit error value for undefined inputs of gates". Should we
keep that standard for transistors too? What is the main purpose of
transistors in Logisim? If something is obstacle to play their role,
should we remove that obstacle? Is this using of transistors (S-R
latch) is important (common)? If yes, why not to change the behavior
to fix it...
Ilia.
C Burch
transistor works as follows:
If gate is 0, source is sent to drain for any of the four possible
source values (0, 1, X, or Z)
If gate is 1, drain is Z regardless of source (even if it is X)
If gate is Z, drain is X unless source is Z, in which case drain is Z
(but see below)
If gate is X, drain is X unless source is Z, in which case drain is Z
(but see below)
Actually, on further investigation, Verilog actually uses more than
four logic values here. In this case, the important additional values
are H and L, which I understand as a "weak" 1 and a "weak" 0: If a
wire is receiving H, it is treated in most cases as 1 - unless
something else is being driven on the wire, in which case the H is
effectively overtaken by the stronger signal. For a transistor, when
the gate is Z or X, the drain is actually H if source is 1, L if
source is 0, X if source is X, and Z if source is Z.
I've been hoping to insert support for H and L in a future version of
Logisim. But that would be a major change that we probably shouldn't
try to tackle in a minor release like 2.7.1, so I'm inclined to delay
trying to insert any support for H/L values for the moment.
So the issue is: Given that we're restricted to four-valued logic for
the moment, how should the transistor work? In particular, how should
a transistor work if its "gate" input is X or Z? If source is passed
directly through to drain in this case, then the two-NAND circuit
works (after being broken out of its initial oscillation). But there's
no reason to imagine that a transistor would decide to transmit its
value whenever the gate is X or Z; the more intuitive behavior would
be for the drain to be X whenever gate is X or Z (with perhaps an
exception for when source is Z).
-Carl
> --
> You received this message because you are subscribed to the Google Groups "Logisim Developers" group.
> To post to this group, send email to log...@googlegroups.com.
> To unsubscribe from this group, send email to logisim+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/logisim?hl=en.
>
>
Ilia Lilov
flip-flops in Logisim using transistors. So, my little work in the
attachment. All the gates (excluding XNOR - nothing new there)
implemented in CMOS and NMOS logic and they all work fine (14 circuits
totally). Although almost every gate needs additional pull resistor. I
found interesting regularity: neither of 2-input gates needs more then
one additional pull resistor regardless of complexity. I shown all the
additional resistors placed them horizontally.
Also I implemented six circuits for flip-flops which work fine in
Logisim while they are build of built-in gates. When they build of
transistors, only 3 of 12 circuits work and they all are in NMOS
logic.
So, if you will decide to apply changes to turn to work all these
circuits build of transistors, you will have the ground for testing.
As of some changes to transistor behavior which can be applied now
without rewriting many parts of code, why not to release some "branch"
(even not fragile) version? People who interested in building circuits
using transistors could try end test such branch version and may be
any new ideas will be suggested.
Ilia.
Ilia Lilov
transistor behavior; new version is attached. Another two flip-flop
circuits implemented using transistors work correctly now: S-R_NOR
(NMOS) and D_synchronous (NMOS).
Also, Carl, new "Locate Select" attribute in panel doesn't use strings
from std.properties now.
Ilia.
Ilia Lilov
counter made of transistors only in the attachment. It consists of 4
synchronous D flip-flops and simple control logic.
To make it working you have to press Ctrl+R & Ctrl+E iteratively (from
2 up to 10 times) until oscillations disappear. If noise for delays is
turned off, you can't do that. The circuit works at ~700 Hz on my
machine (or ~1200 Hz if noise to delays is disabled). However, if
noise is enabled and frequency is more than 4 Hz, with the lapse of
time circuit starts to count incorrectly. So, turn noise on to get
initial state and then turn it off to have right counting. :) The
circuit's working process seems quite fun and impressive.
Ilia.
C Burch
I'd recommend changing the "Iterations until oscillation" option to a
higher value when you know you have a circuit that works if only noise
were enabled. That way, the randomness has more of a chance to break
out of the oscillation before Logisim declares that it has detected
oscillation.
However, noise shouldn't be necessary for any circuit. This is known
to cause rare and unpredictable errors, and I don't know of any way of
avoiding these errors. So if you find a circuit that works only when
noise is enabled, I'm inclined to regard the circuit as not working.
The could be attributed to bad circuit design, or it could be due to
Logisim's design.
Without having analyzed the circuit much, I'd suggest that in this
case the problem is that the initial circuit state is indeterminate.
The solution I'd suggest would be an additional "initial" signal to
get it started. I've done that in the attached circuit, where I've
added a reset input that starts at 0 (for resetting the circuit), and
which you would set at 1 to enable the counting. This circuit does not
require any noise to be enabled.
Also, the clock rate shouldn't affect circuit behavior. If a circuit
truly works at 4 Hz, it should also truly work at 128 Hz. However,
when you run the clock more quickly, the processor will be busy all
the time, and several clock ticks may elapse before the screen
elapses. Thus, what you may *see* is the output jumping from 4 to 7.
But in reality, the output is actually going through 5 and 6, but
these outputs never get a chance to be displayed on the screen.
Moreover, a screen refresh could occur in the middle of a clock tick,
so you may find that in going from 7 to 8, the 1's bit is cleared
before the 4's bit is cleared, and so the output would switch very
briefly to 6 or 4 before it finally reaches 8.
If you find clock rate really makes a difference, then that would
reflect a bug in Logisim. You can't trust a visual inspection of the
circuit, though. You'd want some sort of circuit that maintains a
counter separate from the circuit you built and confirms your
circuit's output regularly matches the counter - until it starts
disagreeing. Or you could use the logging feature.
Ilia Lilov
obvious reason of oscillations.
Higher value for "iterations until oscillations" doesn't affect to the
number of pressing "Ctrl+R Ctrl+E" to get the circuit working in this
case. Again, your solution solves this trouble completely.
I've checked: clock rate doesn't affect circuit behavior. I noticed
mistakes with higher rates just because they have higher probability
to happen when more ticks happened.
Carl, I've noticed "Download" links from both pages:
http://sourceforge.net/search/?q=logisim and
http://sourceforge.net/projects/circuit/ reference to fragile (not
stable!) release by default! If I remember correctly, your idea was to
suggest generic release for new users.
Ilia.