On Sat, 10 Mar 2012 19:18:31 -0800, John Larkin
wrote:

On Sat, 10 Mar 2012 18:30:33 -0600, John Fields
wrote:

On Mon, 05 Mar 2012 19:31:23 -0800, John Larkin
wrote:

On Mon, 05 Mar 2012 17:51:35 -0600, John Fields
wrote:

On Mon, 05 Mar 2012 09:33:16 -0800, John Larkin
wrote:


Consider this: the comparator output is low, so CE is true into U6.
U6 and U2 are happily counting clocks.

Suppose the U6 count is 0xF, and U2 is 0x4. U6 carry out is true (low)
into U2. The correct next count would be Ox0 and 0x5, which is 80
counts decimal.

Now let the comparator output go high, so U6 no longer sees a true
carry input. But it takes a while before the "don't count" Cout/Cin
signal propagates out of U6 into U2. Clock it then. U6 doesn't count,
but U2 does. The next state is U6 = 0xF, U2 = 0x5, 95 decimal, which
is bad wrong. Classic carry chain error. U9+U7 have the same issue.

---
True enough, but what you've missed is that what happens with U2 and
U6 when the comparator goes high doesn't matter, since the
comparator's going high generates a high-going pulse out of U3 which
loads the contents of U2 and U6, at that moment, into U9 and U7.

"At that moment?" Wrong yet again. The PE from U3 to U7/U9 is 1.4 us
wide, and it's an async DC jam load. When U6 and U2 count wrong, as
noted above, the bad count is settled after a typ delay of 200 ns
after the clock, and that's what gets loaded into U7/9.

---
Just because the PE is 1.4µs wide doesn't mean it takes 1.4µs to snag
the contents of the up counter before they change.

According to the data sheet, the setup time for the data on the jam
inputs is 12ns, and the hold time for PE is 35ns.

When the comparator's output goes high there's a 125ns delay through
U3, and that's when PE for U7 and U9 gets asserted.

Since the Q outputs of U2 and U6 haven't changed yet, the 12ns setup
time spec has been met, and after the 35ns hold time has passed, the
contents of U2 and U6 will have been loaded into U7 and U9.

Since you want the clock to go high when the comparator goes high, and
the delay from clock to Q is 200ns, then that means that the data
present on the outputs of U2 and U6 will be loaded into U7 and U9
160ns after the comparator goes high, which is 40ns before the data on
the outputs of u2 changes.

He
______________________
U6CI ____|
. 250 |_________________
U6CO ____._____|
. _________________
CP ____._____|
. .200 .____________
U2Qn ____.__________|
.125.___________________
U7PE ____.___|
. .35.________________
U7LOAD __.______|

---

It's a hairball. You don't get hazards like this in a clocked
synchronous system.

---
Apparently, what you've missed is that carry out is synchronous.

No, it's combinational. Look at the chip schematic.

---
It's only combinatorial when CARRY IN goes high and forces CARRY OUT
high regardless of the state of the clock.

When CARRY IN goes low, however, the counter counts synchronously and
when CARRY OUT is asserted also follows the edge of the clock,
synchronously.

On the 4510/4516 data sheet, under "FEATURES", we find that one is:
"Synchronous internal carry propagation."

Then, looking at the chip schematic, it appears that the external
clock, when not overridden by either RESET or PRESET ENABLE, is
supplied as an internal clock to the Tflop counter chain.

The chain's outputs are synchronous and are used to feed the Q outputs
of the chip as well as the inputs of the carry out generator.

Now, since the outputs of the Tflops are synchronous, the output of
the carry generator is also synchronous and will settle down before
the arrival of the next clock edge.

So, even though the logic between CARRY IN and CARRY OUT may be
combinatorial, it's driven synchronously, so its negative output will
always bear a fixed relationship, in time, to the positive going edge
of the external clock.

--
JF