Electronic Schematics (alt.binaries.schematics.electronic) A place to show and share your electronics schematic drawings.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops











  #2   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock. There's all
sorts of available pathologies.





--

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
  #3   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.


---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.


---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

--
JF
  #4   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2
Default ZCD with no Dflops

John Fields wrote:
On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.


---
Yup, that's how they're designed to be.


sorta...

---

There's all sorts of available pathologies.


---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

--
JF


It might not matter, but when you have PE async to the clock
you will at times violate one of the specs on the first page
preset removal time

-Lasse

  #5   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Sun, 04 Mar 2012 07:27:18 -0600, Lasse Langwadt Christensen
wrote:

John Fields wrote:
On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.


---
Yup, that's how they're designed to be.


sorta...

---

There's all sorts of available pathologies.


---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

--
JF


It might not matter, but when you have PE async to the clock
you will at times violate one of the specs on the first page
preset removal time

-Lasse


---
From figure 3, since the external clock is gated with PE and the
internal clocks forced high while PE is asserted, the state of the
external clock during load time doesn't matter.

You're right in that if PE is de-asserted and the external clock goes
high too soon after PE goes low, the Preset Enable Removal Time spec
will have been violated, but I think (since all the presets have
already been loaded and are stable) all that'll happen is that
there'll be a delay until the next clock high comes along before the
counter starts counting.

Assuming the clock frequency was set to cause 255 clocks to be counted
between the 150° and 210° points on a 60Hz input signal, that delay
would be ignored because of the right shift (MSB leftmost) between the
up and down counters.

--
JF


  #6   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.


---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.


---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.


Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.


--

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
  #7   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Sun, 04 Mar 2012 11:01:04 -0600, John Fields
wrote:

On Sun, 04 Mar 2012 07:27:18 -0600, Lasse Langwadt Christensen
wrote:

John Fields wrote:
On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.


sorta...

---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

--
JF


It might not matter, but when you have PE async to the clock
you will at times violate one of the specs on the first page
preset removal time

-Lasse


---
From figure 3, since the external clock is gated with PE and the
internal clocks forced high while PE is asserted, the state of the
external clock during load time doesn't matter.

You're right in that if PE is de-asserted and the external clock goes
high too soon after PE goes low, the Preset Enable Removal Time spec
will have been violated, but I think (since all the presets have
already been loaded and are stable) all that'll happen is that
there'll be a delay until the next clock high comes along before the
counter starts counting.


It does violate the requirements on the first page of the data sheet,
but maybe you know more about the internals of these parts than the
designers did.

The asynchronous CE hazard is much worse.


--

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
  #8   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,181
Default ZCD with no Dflops

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.


---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.


---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.


Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.


Well? You certainly seem annoyed. And look at all the time Fields
has caused you to waste ;-)

...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.
  #9   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Sun, 04 Mar 2012 11:23:24 -0700, Jim Thompson
wrote:

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.


Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.


Well? You certainly seem annoyed. And look at all the time Fields
has caused you to waste ;-)

...Jim Thompson


Not more than a couple of minutes; the data sheet is pretty simple.

So, you approve of JF's design here?

Seems like you've spent an awful amount of time on the bicycle
alternator and ZCD circuits... multiple iterations of both.


--

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
  #10   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,181
Default ZCD with no Dflops

On Sun, 04 Mar 2012 12:44:53 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 11:23:24 -0700, Jim Thompson
wrote:

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.


Well? You certainly seem annoyed. And look at all the time Fields
has caused you to waste ;-)

...Jim Thompson


Not more than a couple of minutes; the data sheet is pretty simple.

So, you approve of JF's design here?


Nowhere have I said that, have I?


Seems like you've spent an awful amount of time on the bicycle
alternator


Yes, I blew a lot of time there. I was amused that it had
possibilities, but the purposeful saturation effectively neutered
"getting something for nothing".

and ZCD circuits... multiple iterations of both.


Those took minutes, PSpice is fast; plus I've done similar stuff for
appliance controllers before... custom, no off-the-shelf limitations.

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


  #11   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

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

On Sun, 04 Mar 2012 12:44:53 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 11:23:24 -0700, Jim Thompson
wrote:

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.

Well? You certainly seem annoyed. And look at all the time Fields
has caused you to waste ;-)

...Jim Thompson


Not more than a couple of minutes; the data sheet is pretty simple.

So, you approve of JF's design here?


Nowhere have I said that, have I?


No, you are careful to not commit one way or the other. If you say
they're good, you'll be lying *and* look like a fool. If you say
they're bad, you'll be betraying a fellow hen\\\ ally.

The best you've done is suggest that he's posting crap on purpose.
Pretty bad compromise.


--

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
  #12   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.


---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.


---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.


Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?


---
Yeah, you got it!

That, plus learning to read the 4516 timing diagram on page 3-253
would be a good start.
---

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.


---
Well, let's see...

Since they're asynchronous, there are no setup and hold times for the
PE inputs, only a minimum pulse width which, with a Vcc of 5V, is 220
ns, according to the table on page 3-249.

My PE input pulses for both the up and down counters are about 1µs
wide, which is well within spec.

There is a Release Time spec, though, (150ns) which defines how much
time must elapse between PE going low and the clock's next high-going
edge starting the count.

That spec will be violated if that time is less than 150ns - which
will happen in my circuit - but the only penalty that'll be paid is
that the counter won't 1ncrement/decrement until the next rising edge
of the clock; no big deal as far as my circuit is concerned.

As for the Carries, there's a maximum delay of 480ns from clock to
Carry Out of the first stage, a transition time of 200ns for the Carry
Out, and a setup time of 130ns for the Carry In of the second stage,

That means that from the time the high-going clock edge which drives
Carry Out low occurs, the next high-going clock edge must occur after
480 + 200 + 130 = 810ns elapses.

Since my clock is 50µs wide, I don't see much of a problem meeting
that criterion, do you?
---

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.


---
Only a "horrible asynchronous mess" to asynchyrophobes who can't
appreciate elegant timing and who use clock edges as crutches.

--
JF
  #13   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Mon, 05 Mar 2012 03:27:42 -0600, John Fields
wrote:


That means that from the time the high-going clock edge which drives
Carry Out low occurs, the next high-going clock edge must occur after
480 + 200 + 130 = 810ns elapses.

Since my clock is 50µs wide, I don't see much of a problem meeting
that criterion, do you?
---

Oops... 20µs.

Still no biggie.

--
JF
  #14   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Sun, 04 Mar 2012 13:48:00 -0800, John Larkin
wrote:

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

On Sun, 04 Mar 2012 12:44:53 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 11:23:24 -0700, Jim Thompson
wrote:

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
m wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.

Well? You certainly seem annoyed. And look at all the time Fields
has caused you to waste ;-)

...Jim Thompson

Not more than a couple of minutes; the data sheet is pretty simple.

So, you approve of JF's design here?


Nowhere have I said that, have I?


No, you are careful to not commit one way or the other. If you say
they're good, you'll be lying *and* look like a fool. If you say
they're bad, you'll be betraying a fellow hen\\\ ally.

The best you've done is suggest that he's posting crap on purpose.
Pretty bad compromise.


---
Ha ha!

Jim didn't take your bait so you got your knickers all in a bunch? :-)

Better take it easy or you'll be going apoplectic soon.

--
JF
  #15   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Sun, 04 Mar 2012 09:20:48 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 11:01:04 -0600, John Fields
wrote:

On Sun, 04 Mar 2012 07:27:18 -0600, Lasse Langwadt Christensen
wrote:

John Fields wrote:
On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.

sorta...

---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

--
JF

It might not matter, but when you have PE async to the clock
you will at times violate one of the specs on the first page
preset removal time

-Lasse


---
From figure 3, since the external clock is gated with PE and the
internal clocks forced high while PE is asserted, the state of the
external clock during load time doesn't matter.

You're right in that if PE is de-asserted and the external clock goes
high too soon after PE goes low, the Preset Enable Removal Time spec
will have been violated, but I think (since all the presets have
already been loaded and are stable) all that'll happen is that
there'll be a delay until the next clock high comes along before the
counter starts counting.


It does violate the requirements on the first page of the data sheet,


---
The point, which you missed, is that it doesn't matter.
---

but maybe you know more about the internals of these parts than the
designers did.


---
Straw man.
---

The asynchronous CE hazard is much worse.


---
You don't know what you're talking about.

--
JF


  #16   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops - ZCD7.pdf

On Sun, 04 Mar 2012 13:48:00 -0800, John Larkin
wrote:

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

On Sun, 04 Mar 2012 12:44:53 -0800, John Larkin
wrote:



So, you approve of JF's design here?


Nowhere have I said that, have I?


No, you are careful to not commit one way or the other. If you say
they're good, you'll be lying *and* look like a fool. If you say
they're bad, you'll be betraying a fellow hen\\\ ally.


---
Matter of fact, Jim _did_ take issue with my circuit, but apprised me
of a potential problem via private email.

Wisely, I think, in order to keep your nasty, self-serving vitriol out
of the loop.

In any case, the fix was duck soup and the potential problem is now
solved.

Care to _guess_ what it was?

Attached, for your viewing pleasure, is the schematic.

Enjoy! :-)

--
JF


Attached Files
File Type: pdf ZCD7.pdf (68.3 KB, 27 views)
  #17   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops - ZCD7.pdf

On Mon, 05 Mar 2012 06:09:59 -0600, John Fields
wrote:

On Sun, 04 Mar 2012 13:48:00 -0800, John Larkin
wrote:

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

On Sun, 04 Mar 2012 12:44:53 -0800, John Larkin
wrote:



So, you approve of JF's design here?

Nowhere have I said that, have I?


No, you are careful to not commit one way or the other. If you say
they're good, you'll be lying *and* look like a fool. If you say
they're bad, you'll be betraying a fellow hen\\\ ally.


---
Matter of fact, Jim _did_ take issue with my circuit, but apprised me
of a potential problem via private email.


Makes my point. He won't comment on a bad circuit in the group because
his loyalties are more to geezerdom than to electronics. How the
mighty have fallen.


Wisely, I think, in order to keep your nasty, self-serving vitriol out
of the loop.


He's gone private to worm out of being honest in public. He does that
a lot. When you are willing to hide from the truth, you design bad
electronics.


In any case, the fix was duck soup and the potential problem is now
solved.

Care to _guess_ what it was?


No, there are far too many candidates.


--

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
  #18   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops - ZCD7.pdf

On Mon, 05 Mar 2012 06:58:58 -0800, John Larkin
wrote:

On Mon, 05 Mar 2012 06:09:59 -0600, John Fields
wrote:

On Sun, 04 Mar 2012 13:48:00 -0800, John Larkin
wrote:

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

On Sun, 04 Mar 2012 12:44:53 -0800, John Larkin
wrote:



So, you approve of JF's design here?

Nowhere have I said that, have I?

No, you are careful to not commit one way or the other. If you say
they're good, you'll be lying *and* look like a fool. If you say
they're bad, you'll be betraying a fellow hen\\\ ally.


---
Matter of fact, Jim _did_ take issue with my circuit, but apprised me
of a potential problem via private email.


Makes my point. He won't comment on a bad circuit in the group because
his loyalties are more to geezerdom than to electronics. How the
mighty have fallen.


---
Total nonsense, since it's not a bad circuit. He was just giving me a
heads-up in an area where there might be a little trouble.

Had he posted it here, you would - of course - have blown everything
way out of proportion, just like you're doing now, in an effort to
exalt yourself at the expense of others.

It's also nonsense because he has no qualms about commenting on your
atrocious garbage all the time.
---

Wisely, I think, in order to keep your nasty, self-serving vitriol out
of the loop.


He's gone private to worm out of being honest in public. He does that
a lot. When you are willing to hide from the truth, you design bad
electronics.


---
Then your stuff must be really rotten to the core, just like you are.
---

In any case, the fix was duck soup and the potential problem is now
solved.

Care to _guess_ what it was?


No, there are far too many candidates.


---
Translation: "I can't, but I'm a loudmouthed, sneaky sonofabitch, so
I'll make some noise and sidestep the issue."


--
JF
  #19   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Mon, 05 Mar 2012 03:27:42 -0600, John Fields
wrote:

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.


Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?


---
Yeah, you got it!

That, plus learning to read the 4516 timing diagram on page 3-253
would be a good start.
---

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.


---
Well, let's see...

Since they're asynchronous, there are no setup and hold times for the
PE inputs, only a minimum pulse width which, with a Vcc of 5V, is 220
ns, according to the table on page 3-249.

My PE input pulses for both the up and down counters are about 1µs
wide, which is well within spec.

There is a Release Time spec, though, (150ns) which defines how much
time must elapse between PE going low and the clock's next high-going
edge starting the count.

That spec will be violated if that time is less than 150ns - which
will happen in my circuit - but the only penalty that'll be paid is
that the counter won't 1ncrement/decrement until the next rising edge
of the clock; no big deal as far as my circuit is concerned.

As for the Carries, there's a maximum delay of 480ns from clock to
Carry Out of the first stage, a transition time of 200ns for the Carry
Out, and a setup time of 130ns for the Carry In of the second stage,

That means that from the time the high-going clock edge which drives
Carry Out low occurs, the next high-going clock edge must occur after
480 + 200 + 130 = 810ns elapses.

Since my clock is 50µs wide, I don't see much of a problem meeting
that criterion, do you?
---

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.


---
Only a "horrible asynchronous mess" to asynchyrophobes who can't
appreciate elegant timing and who use clock edges as crutches.


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.

It's much worse if you consider what happens *inside* the chips.

Once you do async stuff, and violate the data sheet requirements, all
sorts of hazards become possible, and you have to identify them all
and prove that none of them will break the logic. That's hard.



--

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
  #20   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2
Default ZCD with no Dflops

John Fields wrote:
On Sun, 04 Mar 2012 07:27:18 -0600, Lasse Langwadt Christensen
wrote:

John Fields wrote:
On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.


sorta...

---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

--
JF


It might not matter, but when you have PE async to the clock
you will at times violate one of the specs on the first page
preset removal time

-Lasse


---
From figure 3, since the external clock is gated with PE and the
internal clocks forced high while PE is asserted, the state of the
external clock during load time doesn't matter.

You're right in that if PE is de-asserted and the external clock goes
high too soon after PE goes low, the Preset Enable Removal Time spec
will have been violated, but I think (since all the presets have
already been loaded and are stable) all that'll happen is that
there'll be a delay until the next clock high comes along before the
counter starts counting.


I wouldn't count on it, it is the exact same reason some stay away from async
resets. If you happen to deassert it right before a clock edge some flops might
see the clock edge others might not

looking at the internals I think the sames goes for the carry in, hard to tell
what
would happen if the carry is asserted/deasserted and rippling through that next
state logic right when there's a clock edge

-Lasse



  #21   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

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.

Then, later on, when the comparator goes low again, the carry inputs
of both counters will be enabled, U2 and U6 will start accumulating
new clocks, and U9 and U7 will time out and provide the divide-by-two
pulse at the zero crossings.

--
JF
  #22   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 93
Default ZCD with no Dflops


"John Larkin" schreef in
bericht ...
On Mon, 05 Mar 2012 03:27:42 -0600, John Fields
wrote:

On Sun, 04 Mar 2012 09:14:57 -0800, John Larkin
wrote:

On Sun, 04 Mar 2012 04:13:51 -0600, John Fields
wrote:

On Sat, 03 Mar 2012 20:18:46 -0800, John Larkin
wrote:

On Sat, 03 Mar 2012 16:24:01 -0600, John Fields
wrote:

Yikes, the PEs are completely asynchronous to the clock.

---
Yup, that's how they're designed to be.
---

There's all sorts of available pathologies.

---
None that I can see; peruse:

http://www.ti.com/lit/ds/symlink/cd4516b.pdf

for a clue.

Clue, like reading the table on the first page of the datasheet? Clue,
like looking at the internal logic diagram?


---
Yeah, you got it!

That, plus learning to read the 4516 timing diagram on page 3-253
would be a good start.
---

You are violating the setup and hold times specs for both PE and CE
inputs, and doing that across cascaded chips to boot. This *will*
screw up, and won't take long to do it... just long enough to be a
maddening intermittent failure.


---
Well, let's see...

Since they're asynchronous, there are no setup and hold times for the
PE inputs, only a minimum pulse width which, with a Vcc of 5V, is 220
ns, according to the table on page 3-249.

My PE input pulses for both the up and down counters are about 1µs
wide, which is well within spec.

There is a Release Time spec, though, (150ns) which defines how much
time must elapse between PE going low and the clock's next high-going
edge starting the count.

That spec will be violated if that time is less than 150ns - which
will happen in my circuit - but the only penalty that'll be paid is
that the counter won't 1ncrement/decrement until the next rising edge
of the clock; no big deal as far as my circuit is concerned.

As for the Carries, there's a maximum delay of 480ns from clock to
Carry Out of the first stage, a transition time of 200ns for the Carry
Out, and a setup time of 130ns for the Carry In of the second stage,

That means that from the time the high-going clock edge which drives
Carry Out low occurs, the next high-going clock edge must occur after
480 + 200 + 130 = 810ns elapses.

Since my clock is 50µs wide, I don't see much of a problem meeting
that criterion, do you?
---

Next thing you'll be claiming is that you designed this horrible
asynchronous mess on purpose to annoy people.


---
Only a "horrible asynchronous mess" to asynchyrophobes who can't
appreciate elegant timing and who use clock edges as crutches.


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.

It's much worse if you consider what happens *inside* the chips.

Once you do async stuff, and violate the data sheet requirements, all
sorts of hazards become possible, and you have to identify them all
and prove that none of them will break the logic. That's hard.



--

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


I should not rely on asynchronous signals controlling a synchronous
circuit - except may be for power on reset. Otherwise I used to take
D-fipflops to synchronise

When a long time ago I started to design digital circuits I ran into a
problem with a big, expensive chip with a designflaw inside. The workaround
of the manufacturer used asynchronous signals and I did not trust it. Maybe
more a feeling then a solid knowing but as it was too complicated (for me at
the time) to analyse I decided to build my own circuit. Some months later
the manufacturer asked us how come we had no problems with our customers
about the reliability as others reported random failing boards every now and
then. (Off course, they knew darned well about their clock circuit and had
wished me well when I told them I would design my own.) So they were saved
by the bell, my bell, but I never trusted asynchronous ever since unless I
had a full analysis. And even then ...

BTW. Although the circuit may do for the project at hand, I wonder why so
many people spend so much time on an obsolete circuit. I obviously missed a
great part of the dicussion. Guess a simple 8-pins micro will do the job at
least as well.

petrus bitbyter


  #23   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

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.


--

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
  #24   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Tue, 6 Mar 2012 01:22:33 +0100, "petrus bitbyter"
wrote:


BTW. Although the circuit may do for the project at hand, I wonder why so
many people spend so much time on an obsolete circuit.


---
It's just for "fun"; a response to a challenge from John Larkin to
start a discussion by posting an original circuit for a zero-crossing
detector.

Looks like it worked!

--
JF
  #25   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Tue, 06 Mar 2012 08:58:27 -0600, John Fields
wrote:

On Tue, 6 Mar 2012 01:22:33 +0100, "petrus bitbyter"
wrote:


BTW. Although the circuit may do for the project at hand, I wonder why so
many people spend so much time on an obsolete circuit.


---
It's just for "fun"; a response to a challenge from John Larkin to
start a discussion by posting an original circuit for a zero-crossing
detector.

Looks like it worked!


It did; at least you tried. And it is a nice illustration of the
many-layered hazards of haywire async 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


  #26   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

On Tue, 06 Mar 2012 08:50:12 -0800, John Larkin
wrote:

On Tue, 06 Mar 2012 08:58:27 -0600, John Fields
wrote:

On Tue, 6 Mar 2012 01:22:33 +0100, "petrus bitbyter"
wrote:


BTW. Although the circuit may do for the project at hand, I wonder why so
many people spend so much time on an obsolete circuit.


---
It's just for "fun"; a response to a challenge from John Larkin to
start a discussion by posting an original circuit for a zero-crossing
detector.

Looks like it worked!


It did; at least you tried. And it is a nice illustration of the
many-layered hazards of haywire async logic design.


---
Ah, but there's yet more to come, illustrating how the lot of you who
can't make decisions between clock transitions are crippled.

Stay tuned...
--
JF
  #27   Report Post  
Posted to alt.binaries.schematics.electronic,sci.electronics.design
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Tue, 06 Mar 2012 19:30:48 -0600, John Fields
wrote:

On Tue, 06 Mar 2012 08:50:12 -0800, John Larkin
wrote:

On Tue, 06 Mar 2012 08:58:27 -0600, John Fields
wrote:

On Tue, 6 Mar 2012 01:22:33 +0100, "petrus bitbyter"
wrote:


BTW. Although the circuit may do for the project at hand, I wonder why so
many people spend so much time on an obsolete circuit.

---
It's just for "fun"; a response to a challenge from John Larkin to
start a discussion by posting an original circuit for a zero-crossing
detector.

Looks like it worked!


It did; at least you tried. And it is a nice illustration of the
many-layered hazards of haywire async logic design.


---
Ah, but there's yet more to come, illustrating how the lot of you who
can't make decisions between clock transitions are crippled.



Synchronous logic makes decisions between clocks, namely executes the
combinational logic that maps the current system state into the next
one. But it doesn't *act* on those decisions until they are stable,
and then only at the next clock. It's not the only way to design
logic, but it's the only practical way to design reliable logic of any
complexity, as your circuit bugs demonstrate.

Wikipedia has an article on async logic, and includes a long list of
async computer designs that never made it to production. Intel among
others has dabbled in async design and there are rumors that some
sections of some of their CPUs are async logic. Also rumors that an
async x86 design was scrapped in 1997.


Stay tuned...


Can't wait.


--

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
  #28   Report Post  
Posted to alt.binaries.schematics.electronic,sci.electronics.design
external usenet poster
 
Posts: 2,181
Default ZCD with no Dflops

On Tue, 06 Mar 2012 21:54:41 -0800, John Larkin
wrote:

On Tue, 06 Mar 2012 19:30:48 -0600, John Fields
wrote:

[snip]
---
Ah, but there's yet more to come, illustrating how the lot of you who
can't make decisions between clock transitions are crippled.



Synchronous logic makes decisions between clocks, namely executes the
combinational logic that maps the current system state into the next
one. But it doesn't *act* on those decisions until they are stable,
and then only at the next clock. It's not the only way to design
logic, but it's the only practical way to design reliable logic of any
complexity, as your circuit bugs demonstrate.

Wikipedia has an article on async logic, and includes a long list of
async computer designs that never made it to production. Intel among
others has dabbled in async design and there are rumors that some
sections of some of their CPUs are async logic. Also rumors that an
async x86 design was scrapped in 1997.


Stay tuned...


Can't wait.


I'm certainly no logician, but surfing on "async logic" brings up some
interesting discussion that async can result in 40% power savings, but
takes more gates to do so. Considering the continual reduction in
ASIC feature size, considerable effort is in play for using async in
portable devices and in medical implants. The biggest impediment
right now to that development is the lack of async synthesis tools.

...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.
  #29   Report Post  
Posted to alt.binaries.schematics.electronic,sci.electronics.design
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Thu, 08 Mar 2012 08:53:14 -0700, Jim Thompson
wrote:

On Tue, 06 Mar 2012 21:54:41 -0800, John Larkin
wrote:

On Tue, 06 Mar 2012 19:30:48 -0600, John Fields
wrote:

[snip]
---
Ah, but there's yet more to come, illustrating how the lot of you who
can't make decisions between clock transitions are crippled.



Synchronous logic makes decisions between clocks, namely executes the
combinational logic that maps the current system state into the next
one. But it doesn't *act* on those decisions until they are stable,
and then only at the next clock. It's not the only way to design
logic, but it's the only practical way to design reliable logic of any
complexity, as your circuit bugs demonstrate.

Wikipedia has an article on async logic, and includes a long list of
async computer designs that never made it to production. Intel among
others has dabbled in async design and there are rumors that some
sections of some of their CPUs are async logic. Also rumors that an
async x86 design was scrapped in 1997.


Stay tuned...


Can't wait.


I'm certainly no logician, but surfing on "async logic" brings up some
interesting discussion that async can result in 40% power savings, but
takes more gates to do so. Considering the continual reduction in
ASIC feature size, considerable effort is in play for using async in
portable devices and in medical implants. The biggest impediment
right now to that development is the lack of async synthesis tools.

...Jim Thompson



That's been the problem for decades. Synchronous logic synthesis and
analysis separates the issue of logic correctness (pure state machine
stuff) from the issue of timing analysis, namely how fast can you
clock it reliably. Pipelining is a major tool to fix the problem of
the combinational logic limiting clock rates, but pipelined logic is
still just logic.

Async logic tangles the logic functionality with the speed issues. I'd
imagine that the simulation burden explodes when you do async logic:
what had been logical simulation becomes essentially analog
simulation. Imagine simulating an analog circuit that has a billion
transistors and thousands of inputs and outputs. Now do that over Vcc
and process variations and temperature.


--

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
  #30   Report Post  
Posted to alt.binaries.schematics.electronic,sci.electronics.design
external usenet poster
 
Posts: 2,181
Default ZCD with no Dflops

On Thu, 08 Mar 2012 08:38:49 -0800, John Larkin
wrote:

On Thu, 08 Mar 2012 08:53:14 -0700, Jim Thompson
wrote:

On Tue, 06 Mar 2012 21:54:41 -0800, John Larkin
wrote:

On Tue, 06 Mar 2012 19:30:48 -0600, John Fields
wrote:

[snip]
---
Ah, but there's yet more to come, illustrating how the lot of you who
can't make decisions between clock transitions are crippled.


Synchronous logic makes decisions between clocks, namely executes the
combinational logic that maps the current system state into the next
one. But it doesn't *act* on those decisions until they are stable,
and then only at the next clock. It's not the only way to design
logic, but it's the only practical way to design reliable logic of any
complexity, as your circuit bugs demonstrate.

Wikipedia has an article on async logic, and includes a long list of
async computer designs that never made it to production. Intel among
others has dabbled in async design and there are rumors that some
sections of some of their CPUs are async logic. Also rumors that an
async x86 design was scrapped in 1997.


Stay tuned...

Can't wait.


I'm certainly no logician, but surfing on "async logic" brings up some
interesting discussion that async can result in 40% power savings, but
takes more gates to do so. Considering the continual reduction in
ASIC feature size, considerable effort is in play for using async in
portable devices and in medical implants. The biggest impediment
right now to that development is the lack of async synthesis tools.

...Jim Thompson



That's been the problem for decades. Synchronous logic synthesis and
analysis separates the issue of logic correctness (pure state machine
stuff) from the issue of timing analysis, namely how fast can you
clock it reliably. Pipelining is a major tool to fix the problem of
the combinational logic limiting clock rates, but pipelined logic is
still just logic.

Async logic tangles the logic functionality with the speed issues. I'd
imagine that the simulation burden explodes when you do async logic:
what had been logical simulation becomes essentially analog
simulation.


Not so. Logic simulation remains logic simulation. Take the student
version of PSpice for a test drive and see how the logic simulator
works... it'll spit out all the hazards in a nice list.

I would imagine, at least for analysis, that VHDL and Verilog will
continue to work. Synthesis is the difficulty.

Imagine simulating an analog circuit that has a billion
transistors and thousands of inputs and outputs. Now do that over Vcc
and process variations and temperature.


Billions, and billions, and billions... ;-)

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


  #31   Report Post  
Posted to alt.binaries.schematics.electronic,sci.electronics.design
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Thu, 08 Mar 2012 09:50:25 -0700, Jim Thompson
wrote:

On Thu, 08 Mar 2012 08:38:49 -0800, John Larkin
wrote:

On Thu, 08 Mar 2012 08:53:14 -0700, Jim Thompson
wrote:

On Tue, 06 Mar 2012 21:54:41 -0800, John Larkin
wrote:

On Tue, 06 Mar 2012 19:30:48 -0600, John Fields
wrote:

[snip]
---
Ah, but there's yet more to come, illustrating how the lot of you who
can't make decisions between clock transitions are crippled.


Synchronous logic makes decisions between clocks, namely executes the
combinational logic that maps the current system state into the next
one. But it doesn't *act* on those decisions until they are stable,
and then only at the next clock. It's not the only way to design
logic, but it's the only practical way to design reliable logic of any
complexity, as your circuit bugs demonstrate.

Wikipedia has an article on async logic, and includes a long list of
async computer designs that never made it to production. Intel among
others has dabbled in async design and there are rumors that some
sections of some of their CPUs are async logic. Also rumors that an
async x86 design was scrapped in 1997.


Stay tuned...

Can't wait.

I'm certainly no logician, but surfing on "async logic" brings up some
interesting discussion that async can result in 40% power savings, but
takes more gates to do so. Considering the continual reduction in
ASIC feature size, considerable effort is in play for using async in
portable devices and in medical implants. The biggest impediment
right now to that development is the lack of async synthesis tools.

...Jim Thompson



That's been the problem for decades. Synchronous logic synthesis and
analysis separates the issue of logic correctness (pure state machine
stuff) from the issue of timing analysis, namely how fast can you
clock it reliably. Pipelining is a major tool to fix the problem of
the combinational logic limiting clock rates, but pipelined logic is
still just logic.

Async logic tangles the logic functionality with the speed issues. I'd
imagine that the simulation burden explodes when you do async logic:
what had been logical simulation becomes essentially analog
simulation.


Not so. Logic simulation remains logic simulation. Take the student
version of PSpice for a test drive and see how the logic simulator
works... it'll spit out all the hazards in a nice list.

I would imagine, at least for analysis, that VHDL and Verilog will
continue to work. Synthesis is the difficulty.


VHDL is not an analysis language, it's a logic description language.
Actual gates and flops are synthesized downstream, with other tools,
and may look very different from the VHDL when it's actually mapped
into specific hardware.

There are VHDL simulation programs, but they usually work from the
VHDL itself, not the synthesized logic. What we usually do is sim at
VHDL level and do static timing analysis (which is ignorant of the
logic intent) after logic synthesis, and hope that the logic synthesis
stuff worked.

One could write an async logic design in VHDL - just don't clock
anything - but I don't know where you'd go from that, or how you'd
verify the final logic. Sounds like a nightmare, which is why nobody
has got it to work very well.


--

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
  #32   Report Post  
Posted to alt.binaries.schematics.electronic,sci.electronics.design
external usenet poster
 
Posts: 93
Default ZCD with no Dflops


"John Larkin" schreef in
bericht ...
On Thu, 08 Mar 2012 09:50:25 -0700, Jim Thompson
wrote:

On Thu, 08 Mar 2012 08:38:49 -0800, John Larkin
wrote:

On Thu, 08 Mar 2012 08:53:14 -0700, Jim Thompson
wrote:

On Tue, 06 Mar 2012 21:54:41 -0800, John Larkin
wrote:

On Tue, 06 Mar 2012 19:30:48 -0600, John Fields
wrote:

[snip]
---
Ah, but there's yet more to come, illustrating how the lot of you who
can't make decisions between clock transitions are crippled.


Synchronous logic makes decisions between clocks, namely executes the
combinational logic that maps the current system state into the next
one. But it doesn't *act* on those decisions until they are stable,
and then only at the next clock. It's not the only way to design
logic, but it's the only practical way to design reliable logic of any
complexity, as your circuit bugs demonstrate.

Wikipedia has an article on async logic, and includes a long list of
async computer designs that never made it to production. Intel among
others has dabbled in async design and there are rumors that some
sections of some of their CPUs are async logic. Also rumors that an
async x86 design was scrapped in 1997.


Stay tuned...

Can't wait.

I'm certainly no logician, but surfing on "async logic" brings up some
interesting discussion that async can result in 40% power savings, but
takes more gates to do so. Considering the continual reduction in
ASIC feature size, considerable effort is in play for using async in
portable devices and in medical implants. The biggest impediment
right now to that development is the lack of async synthesis tools.

...Jim Thompson


That's been the problem for decades. Synchronous logic synthesis and
analysis separates the issue of logic correctness (pure state machine
stuff) from the issue of timing analysis, namely how fast can you
clock it reliably. Pipelining is a major tool to fix the problem of
the combinational logic limiting clock rates, but pipelined logic is
still just logic.

Async logic tangles the logic functionality with the speed issues. I'd
imagine that the simulation burden explodes when you do async logic:
what had been logical simulation becomes essentially analog
simulation.


Not so. Logic simulation remains logic simulation. Take the student
version of PSpice for a test drive and see how the logic simulator
works... it'll spit out all the hazards in a nice list.

I would imagine, at least for analysis, that VHDL and Verilog will
continue to work. Synthesis is the difficulty.


VHDL is not an analysis language, it's a logic description language.
Actual gates and flops are synthesized downstream, with other tools,
and may look very different from the VHDL when it's actually mapped
into specific hardware.

There are VHDL simulation programs, but they usually work from the
VHDL itself, not the synthesized logic. What we usually do is sim at
VHDL level and do static timing analysis (which is ignorant of the
logic intent) after logic synthesis, and hope that the logic synthesis
stuff worked.

One could write an async logic design in VHDL - just don't clock
anything - but I don't know where you'd go from that, or how you'd
verify the final logic. Sounds like a nightmare, which is why nobody
has got it to work very well.


--

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


Down at the transistor level it's all analog. The combinatorials like the
gates can be considered analog and simulated that way but there's hardly a
thing to gain. Once you're using feedback building fliplops and other
sequential elements, analog simulation become more difficult though not
impossible. At this level the elements are still asynchronous but can be
used to build synchronous circuits. You can bet, the logic diagrams of the
internals of synchrounous counters and the like (hopefully) describe the
function, not the internal design. (Which is not uncommon in analog circuits
as well.) I'm not certain to what limit you can use analog simulation for
digital circuits these days, but it's clear that even a simple small micro
cannot be simulated this way. I heard rumours last year about design
software to build asynchronous sequential circuits, faster then the
synchronous counterparts, but I couldn't find it and the rumour died.

petrus bitbyter


  #33   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

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
  #34   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,181
Default ZCD with no Dflops

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.

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.


Larkin misses lots of things, gets threads out-of-sequence, and bases
his snotty remarks on his perceived sequence. My father would
designate Larkin as "trailer trash".

...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.
  #35   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

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.

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.


--

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


  #36   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

On Sat, 10 Mar 2012 17:44:59 -0700, Jim Thompson
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.

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.


Larkin misses lots of things, gets threads out-of-sequence, and bases
his snotty remarks on his perceived sequence. My father would
designate Larkin as "trailer trash".

...Jim Thompson


Care to say something on topic, once in a while, just for variety?

Do you think JF's circuit is hazard-free? Come on, man up, say yes or
no.


--

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
  #37   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 93
Default ZCD with no Dflops


"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


  #38   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 2,022
Default ZCD with no Dflops

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
  #39   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

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.



--

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
  #40   Report Post  
Posted to alt.binaries.schematics.electronic
external usenet poster
 
Posts: 1,420
Default ZCD with no Dflops

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.

--

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
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 01:00 PM.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 DIYbanter.
The comments are property of their posters.
 

About Us

"It's about DIY & home improvement"