On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

[snip]

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

Nope. Jim has no opinion, since I am not a logic designer and never
claimed to be.

I do approve of Fields jerking you around, though it's getting
tiresome. You are indeed suffering from brachycephalic rectumitis
(otherwise known as "with big head up butt" :-), and seem hell-bent to
dominate this group, preventing all real circuit discussion...
claiming nothing can work but what you scribble (and fail to prove).

So I'm contemplating pulling a Woodgate and giving only advice on the
LTspice group where it'll be appreciated.

================================================== =============
|| ||
|| I'll also be available, when time allows, to help people ||
|| who wish to contact me privately... use the "Envelope" ||
|| symbol on my website. ||
|| ||
================================================== =============

You are treating the PE inputs of the counters as if they are edge
triggered. They are not. If you assert PE for 1.4 microseconds, what
gets jammed into U7/U9 is what's at their inputs at the *end* of the
1.4 usec. As I've shown, that can be wrong. You ended your timing
diagram *before* the hazard. You are hiding from the hazards because
you don't want to see them. Jim approves.

See! You even go out of your way to prove that you are fully infected
with brachycephalic rectumitis (otherwise known as "with big head up
butt" :-)

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

On Sun, 11 Mar 2012 12:59:31 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 12:47:30 +0100, "petrus bitbyter"
wrote:


"John Fields" schreef in bericht
. ..
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.

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.


--
JF

This counter is an example of a so called Mealy machine which means that at
least one of the outputs depends on both the current state an one or more
input signals. The carry_out is such an output. It depends on the current
state, the carry_in and the up/down. So as long as these last two signals
are synchronous, the carry_out signal will be synchronous as well, otherwise
you have to make sure that the inputs are stable some setup time before the
next active clock edge. If not, the counter may fail to count correctly.

petrus bitbyter


Cin to U6 and U9 are both asynchronous, which makes their carry outs
async too, so there are hazards.

There's no reason to create hazards like this.

---
Clearly, you don't understand the 4516's carry circuitry, and are
making a fool of yourself by pretending you do by tilting at
windmills.

--
JF

On Sun, 11 Mar 2012 15:37:45 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 12:59:31 -0700, John Larkin
wrote:

[snip]


Cin to U6 and U9 are both asynchronous, which makes their carry outs
async too, so there are hazards.

There's no reason to create hazards like this.

---
Clearly, you don't understand the 4516's carry circuitry, and are
making a fool of yourself by pretending you do by tilting at
windmills.

Otherwise known as brachycephalic rectumitis :-)

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

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
m 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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

You are treating the PE inputs of the counters as if they are edge
triggered. They are not. If you assert PE for 1.4 microseconds, what
gets jammed into U7/U9 is what's at their inputs at the *end* of the
1.4 usec. As I've shown, that can be wrong. You ended your timing
diagram *before* the hazard. You are hiding from the hazards because
you don't want to see them. Jim approves.

---
Jim this and Jim that?

Sounds to me like you've met more than your match and are going
through death throes trying to deny it.

As far as the rest of it goes, a simple perusal of the schematic, the
timing diagram, and the data sheet would convince an honest pilgrim of
his errors.

That lets you off the hook, of course.

--
JF

On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

[snip]

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

Nope. Jim has no opinion, since I am not a logic designer and never
claimed to be.

I do approve of Fields jerking you around, though it's getting
tiresome. You are indeed suffering from brachycephalic rectumitis
(otherwise known as "with big head up butt" :-),


You and JF constantly mention things anal and penile. Enjoy!


--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

[snip]

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

Nope. Jim has no opinion, since I am not a logic designer and never
claimed to be.

I do approve of Fields jerking you around, though it's getting
tiresome. You are indeed suffering from brachycephalic rectumitis
(otherwise known as "with big head up butt" :-),


You and JF constantly mention things anal and penile. Enjoy!

I _do_ enjoy you being caught with your head up your own butt, but you
no longer exist. Bye.

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

On Sun, 11 Mar 2012 15:52:21 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

You are treating the PE inputs of the counters as if they are edge
triggered. They are not. If you assert PE for 1.4 microseconds, what
gets jammed into U7/U9 is what's at their inputs at the *end* of the
1.4 usec. As I've shown, that can be wrong. You ended your timing
diagram *before* the hazard. You are hiding from the hazards because
you don't want to see them. Jim approves.

---
Jim this and Jim that?

Sounds to me like you've met more than your match and are going
through death throes trying to deny it.

Match? He refuses to discuss digital logic, either because it's too
hard for him to understand, or out of loyalty to you.

What weird old hens you guys are.


--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

[snip]

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

Nope. Jim has no opinion, since I am not a logic designer and never
claimed to be.

I do approve of Fields jerking you around, though it's getting
tiresome. You are indeed suffering from brachycephalic rectumitis
(otherwise known as "with big head up butt" :-),


You and JF constantly mention things anal and penile. Enjoy!

---
When we talk about little pricks like you who are such big assholes,
how can it be avoided?

--
JF

On Sun, 11 Mar 2012 15:37:45 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 12:59:31 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 12:47:30 +0100, "petrus bitbyter"
wrote:


"John Fields" schreef in bericht
...
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
m 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.

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.


--
JF

This counter is an example of a so called Mealy machine which means that at
least one of the outputs depends on both the current state an one or more
input signals. The carry_out is such an output. It depends on the current
state, the carry_in and the up/down. So as long as these last two signals
are synchronous, the carry_out signal will be synchronous as well, otherwise
you have to make sure that the inputs are stable some setup time before the
next active clock edge. If not, the counter may fail to count correctly.

petrus bitbyter


Cin to U6 and U9 are both asynchronous, which makes their carry outs
async too, so there are hazards.

There's no reason to create hazards like this.

---
Clearly, you don't understand the 4516's carry circuitry, and are
making a fool of yourself by pretending you do by tilting at
windmills.

Look at the 4516 internal logic diagram. Cin contributes,
asynchronously, to Cout, and to the various logic that generates the
next-state T inputs of the flops. It has one prop delay into the T
input of the first flop, and *three* PDs into the rest of the flops.
Change Cin at just the right time relative to the clock, tease all
those internal gate delays, and you can totally befuddle the next
counter state. The data sheet warns you to not do this. And, as I've
shown, you can screw up the carry from one counter chip to the next.

Why are you fighting against doing safe logic design?


--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

On Sun, 11 Mar 2012 16:24:34 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

[snip]

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

Nope. Jim has no opinion, since I am not a logic designer and never
claimed to be.

I do approve of Fields jerking you around, though it's getting
tiresome. You are indeed suffering from brachycephalic rectumitis
(otherwise known as "with big head up butt" :-),


You and JF constantly mention things anal and penile. Enjoy!

---
When we talk about little pricks like you who are such big assholes,
how can it be avoided?

There you go again.


--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

On Sun, 11 Mar 2012 14:30:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 15:37:45 -0500, John Fields
wrote:

Clearly, you don't understand the 4516's carry circuitry, and are
making a fool of yourself by pretending you do by tilting at
windmills.

Look at the 4516 internal logic diagram. Cin contributes,
asynchronously, to Cout, and to the various logic that generates the
next-state T inputs of the flops. It has one prop delay into the T
input of the first flop, and *three* PDs into the rest of the flops.
Change Cin at just the right time relative to the clock, tease all
those internal gate delays, and you can totally befuddle the next
counter state. The data sheet warns you to not do this. And, as I've
shown, you can screw up the carry from one counter chip to the next.

---
Blather.

You've shown nothing but stupidity by adhering to statements you've
made which have been proven to be untrue.

You really don't know what you're talking about, as evidenced by your
recent posts in this thread, and even though you'll soldier on,
chanting your ever deceitful mantra, you've been found out.
---

Why are you fighting against doing safe logic design?

---
You presume to know, and therefore dictate what's safe and what isn't,
but the fact remains that you're a coward who's afraid to venture
outside of the comfort zone of his paint-by-number world, and
willfully maligns criticism.

--
JF

On Sun, 11 Mar 2012 14:31:05 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 16:24:34 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

[snip]

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

Nope. Jim has no opinion, since I am not a logic designer and never
claimed to be.

I do approve of Fields jerking you around, though it's getting
tiresome. You are indeed suffering from brachycephalic rectumitis
(otherwise known as "with big head up butt" :-),


You and JF constantly mention things anal and penile. Enjoy!

---
When we talk about little pricks like you who are such big assholes,
how can it be avoided?

There you go again.

---
And why shouldn't I?
--
JF

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

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
m 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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

You are treating the PE inputs of the counters as if they are edge
triggered. They are not.

---
Since all logic switches when a certain input _voltage_ level is
exceeded, edge triggering is a myth.
---

If you assert PE for 1.4 microseconds, what
gets jammed into U7/U9 is what's at their inputs at the *end* of the
1.4 usec.

---
1. Disconnect U7P4 from 0V, connect it to Vcc and run the sim.
2. Probe U7PE
3. When PE goes high, zoom in on the pulse and probe U7Q4.
4. How soon after the _beginning_ of PE does Q4 go high?
5. What happens to Q4 when PE goes low?
---

As I've shown, that can be wrong.

---
How so?
---

You ended your timing diagram *before* the hazard.

---
As demonstrated, since it's the _leading_ edge of PE which does the
broadside load, there _is_ no hazard.
---

You are hiding from the hazards because you don't want to see them.

---
You're either making up "hazards" because you don't want to admit that
you were wrong, or because you're too stupid - or blinded by your
colossal stubbornness - to see that they don't exist.

Which is it?

--
JF

On Mon, 12 Mar 2012 09:13:29 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 14:01:09 -0500, John Fields
wrote:

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.

You have broken the synchronous nature of the carry chain - and of the
counter's internal logic - by feeding U6 carry in from the
asynchronous comparator output, splattering asynchronous levels all
over the place. You are doing this just to be peverse, to prove
somehow that hairball logic is a good thing. Jim approves.

You are treating the PE inputs of the counters as if they are edge
triggered. They are not.

---
Since all logic switches when a certain input _voltage_ level is
exceeded, edge triggering is a myth.
---

If you assert PE for 1.4 microseconds, what
gets jammed into U7/U9 is what's at their inputs at the *end* of the
1.4 usec.

---
1. Disconnect U7P4 from 0V, connect it to Vcc and run the sim.
2. Probe U7PE
3. When PE goes high, zoom in on the pulse and probe U7Q4.
4. How soon after the _beginning_ of PE does Q4 go high?
5. What happens to Q4 when PE goes low?
---

As I've shown, that can be wrong.

---
How so?
---

You ended your timing diagram *before* the hazard.

---
As demonstrated, since it's the _leading_ edge of PE which does the
broadside load, there _is_ no hazard.
---

You are hiding from the hazards because you don't want to see them.

---
You're either making up "hazards" because you don't want to admit that
you were wrong, or because you're too stupid - or blinded by your
colossal stubbornness - to see that they don't exist.

The people who wrote the CD4516 data sheet put the setup time
requirements there because they matter.



Which is it?

Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.




--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

On Sun, 11 Mar 2012 14:18:22 -0700, John Larkin
wrote:

On Sun, 11 Mar 2012 15:52:21 -0500, John Fields
wrote:

Jim this and Jim that?

Sounds to me like you've met more than your match and are going
through death throes trying to deny it.

Match? He refuses to discuss digital logic, either because it's too
hard for him to understand, or out of loyalty to you.

---
He's already stated that he's not a logic designer, so his decision to
not discuss digital logic is hardly surprising.

Of course, being as malignant as you are, you have to make up all
sorts of negative attributes and ascribe them to people you can't
control in order to try to discredit them and make it seem like
they're beneath you.
---

What weird old hens you guys are.

---
Actually, I kind of like that, the eggs being my helpful posts on
USENET and the pecks my critiques.

--
JF

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 09:13:29 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:


You are hiding from the hazards because you don't want to see them.

---
You're either making up "hazards" because you don't want to admit that
you were wrong, or because you're too stupid - or blinded by your
colossal stubbornness - to see that they don't exist.
Which is it?
---

The people who wrote the CD4516 data sheet put the setup time
requirements there because they matter.

---
Really?

Knowing that, you should have realized that the setup time requirement
states how long data on the jam inputs has to be stable before the
leading edge of PE enters the chip.

The PE hold time requirement also matters, and is the amount of time
PE must remain true to successfully load the data at the jam inputs
into the Tflops.

That's all been previously discussed, and the timing diagram I posted
earlier clearly shows that there's no problem with loading the data
from the up-counter into the down-counter before the data on the
up-counter outputs changes.

So, I wonder, why are you dancing about spouting irrelevancies when
you could just ask for as much rope as you need?
---

Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?


--
JF

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 09:13:29 -0500, John Fields
wrote:

On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote:


You are hiding from the hazards because you don't want to see them.

---
You're either making up "hazards" because you don't want to admit that
you were wrong, or because you're too stupid - or blinded by your
colossal stubbornness - to see that they don't exist.
Which is it?
---

The people who wrote the CD4516 data sheet put the setup time
requirements there because they matter.

---
Really?

Knowing that, you should have realized that the setup time requirement
states how long data on the jam inputs has to be stable before the
leading edge of PE enters the chip.

The PE hold time requirement also matters, and is the amount of time
PE must remain true to successfully load the data at the jam inputs
into the Tflops.

That's all been previously discussed, and the timing diagram I posted
earlier clearly shows that there's no problem with loading the data
from the up-counter into the down-counter before the data on the
up-counter outputs changes.

So, I wonder, why are you dancing about spouting irrelevancies when
you could just ask for as much rope as you need?
---

Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious. I already have a much better,
3-part ZCD circuit that works without hazards.


--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:


Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious.

---
If it's so obvious you should have been able to prove me wrong by now
but, instead, you've taken a couple of pratfalls yourself and are
afraid to build and test the circuit for fear that it'll vindicate my
approach and prove you wrong once again.

So, instead of taking the high road and practicing what you preach,
you revert to name-calling.

Typical Larkinese side-step.
---

I already have a much better, 3-part ZCD circuit that works without hazards.

---
Let's see a sim.

--
JF

On Mon, 12 Mar 2012 10:54:35 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:


Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious.

---
If it's so obvious you should have been able to prove me wrong by now
but, instead, you've taken a couple of pratfalls yourself and are
afraid to build and test the circuit for fear that it'll vindicate my
approach and prove you wrong once again.

So, instead of taking the high road and practicing what you preach,
you revert to name-calling.

Typical Larkinese side-step.
---

I already have a much better, 3-part ZCD circuit that works without hazards.

---
Let's see a sim.

It's been posted, in a couple of variants, in s.e.d.

Since you will never believe me about async logic hazards, you might
google


logic race hazard

metastability

setup hold violation

asynchronous logic hazards


but you won't.






--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:54:35 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:


Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious.

---
If it's so obvious you should have been able to prove me wrong by now
but, instead, you've taken a couple of pratfalls yourself and are
afraid to build and test the circuit for fear that it'll vindicate my
approach and prove you wrong once again.

So, instead of taking the high road and practicing what you preach,
you revert to name-calling.

Typical Larkinese side-step.
---

I already have a much better, 3-part ZCD circuit that works without hazards.

---
Let's see a sim.

It's been posted, in a couple of variants, in s.e.d.

Since you will never believe me about async logic hazards, you might
google


logic race hazard

metastability

setup hold violation

asynchronous logic hazards


but you won't.

---
Go away, you tedious ass.

--
JF

On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:54:35 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:


Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious.

---
If it's so obvious you should have been able to prove me wrong by now
but, instead, you've taken a couple of pratfalls yourself and are
afraid to build and test the circuit for fear that it'll vindicate my
approach and prove you wrong once again.

So, instead of taking the high road and practicing what you preach,
you revert to name-calling.

Typical Larkinese side-step.
---

I already have a much better, 3-part ZCD circuit that works without hazards.

---
Let's see a sim.

It's been posted, in a couple of variants, in s.e.d.

---
Maybe I missed something, but I didn't see part numbers or even an
attempt at a finished design, from you, which would satisfy the OP's
requirements for a zero-crossing signal varying less than about +/- 2%
from the actual zero crossing, with mains frequencies of 50 and 60Hz
and voltages of either 120 or 240 VRMS.

--
JF

On Mon, 12 Mar 2012 18:18:29 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:54:35 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:


Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious.

---
If it's so obvious you should have been able to prove me wrong by now
but, instead, you've taken a couple of pratfalls yourself and are
afraid to build and test the circuit for fear that it'll vindicate my
approach and prove you wrong once again.

So, instead of taking the high road and practicing what you preach,
you revert to name-calling.

Typical Larkinese side-step.
---

I already have a much better, 3-part ZCD circuit that works without hazards.

---
Let's see a sim.

It's been posted, in a couple of variants, in s.e.d.

---
Maybe I missed something, but I didn't see part numbers or even an
attempt at a finished design, from you, which would satisfy the OP's
requirements for a zero-crossing signal varying less than about +/- 2%
from the actual zero crossing, with mains frequencies of 50 and 60Hz
and voltages of either 120 or 240 VRMS.

You missed something.


--

John Larkin, President
Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation

On Mon, 12 Mar 2012 18:34:04 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 18:18:29 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:54:35 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
m wrote:


Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious.

---
If it's so obvious you should have been able to prove me wrong by now
but, instead, you've taken a couple of pratfalls yourself and are
afraid to build and test the circuit for fear that it'll vindicate my
approach and prove you wrong once again.

So, instead of taking the high road and practicing what you preach,
you revert to name-calling.

Typical Larkinese side-step.
---

I already have a much better, 3-part ZCD circuit that works without hazards.

---
Let's see a sim.

It's been posted, in a couple of variants, in s.e.d.

---
Maybe I missed something, but I didn't see part numbers or even an
attempt at a finished design, from you, which would satisfy the OP's
requirements for a zero-crossing signal varying less than about +/- 2%
from the actual zero crossing, with mains frequencies of 50 and 60Hz
and voltages of either 120 or 240 VRMS.

You missed something.

---
I guess so, but it's a long thread to search and a simple enough
circuit that it wouldn't take much effort for you to post the final
schematic again, please?

--
JF

On Tue, 13 Mar 2012 06:03:50 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 18:34:04 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 18:18:29 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:54:35 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote:

On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote:

On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote:


Build your circuit and hook it up to an infinite-persistance digital
scope. It will screw up on the order of once an hour.

---
That task doesn't fall on me, it falls on you since you're the one who
wants to prove me wrong.

It's a simple circuit and, if you don't make too many wiring mistakes,
should be up and running quickly.

You'll let us know how it goes, yes?



It's an ugly hairball, full of hazards, and you're an amateur. There's
no point in demonstrating the obvious.

---
If it's so obvious you should have been able to prove me wrong by now
but, instead, you've taken a couple of pratfalls yourself and are
afraid to build and test the circuit for fear that it'll vindicate my
approach and prove you wrong once again.

So, instead of taking the high road and practicing what you preach,
you revert to name-calling.

Typical Larkinese side-step.
---

I already have a much better, 3-part ZCD circuit that works without hazards.

---
Let's see a sim.

It's been posted, in a couple of variants, in s.e.d.

---
Maybe I missed something, but I didn't see part numbers or even an
attempt at a finished design, from you, which would satisfy the OP's
requirements for a zero-crossing signal varying less than about +/- 2%
from the actual zero crossing, with mains frequencies of 50 and 60Hz
and voltages of either 120 or 240 VRMS.

You missed something.

---
I guess so, but it's a long thread to search and a simple enough
circuit that it wouldn't take much effort for you to post the final
schematic again, please?

Don't play your tedious games again. You know where the thread is.


--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators