Home |
Search |
Today's Posts |
|
Electronic Schematics (alt.binaries.schematics.electronic) A place to show and share your electronics schematic drawings. |
Reply |
|
|
LinkBack | Thread Tools | Display Modes |
#1
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
ZCD with no Dflops
|
#2
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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 |
#17
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic,sci.electronics.design
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic,sci.electronics.design
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic,sci.electronics.design
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic,sci.electronics.design
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic,sci.electronics.design
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic,sci.electronics.design
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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
Posted to alt.binaries.schematics.electronic
|
|||
|
|||
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 |