|
ZCD with no Dflops
On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: [snip] So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. Nope. Jim has no opinion, since I am not a logic designer and never claimed to be. I do approve of Fields jerking you around, though it's getting tiresome. You are indeed suffering from brachycephalic rectumitis (otherwise known as "with big head up butt" :-), and seem hell-bent to dominate this group, preventing all real circuit discussion... claiming nothing can work but what you scribble (and fail to prove). So I'm contemplating pulling a Woodgate and giving only advice on the LTspice group where it'll be appreciated. ================================================== ============= || || || I'll also be available, when time allows, to help people || || who wish to contact me privately... use the "Envelope" || || symbol on my website. || || || ================================================== ============= You are treating the PE inputs of the counters as if they are edge triggered. They are not. If you assert PE for 1.4 microseconds, what gets jammed into U7/U9 is what's at their inputs at the *end* of the 1.4 usec. As I've shown, that can be wrong. You ended your timing diagram *before* the hazard. You are hiding from the hazards because you don't want to see them. Jim approves. See! You even go out of your way to prove that you are fully infected with brachycephalic rectumitis (otherwise known as "with big head up butt" :-) ...Jim Thompson -- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)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. |
ZCD with no Dflops
On Sun, 11 Mar 2012 12:59:31 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 12:47:30 +0100, "petrus bitbyter" wrote: "John Fields" schreef in bericht . .. On Mon, 05 Mar 2012 19:31:23 -0800, John Larkin wrote: On Mon, 05 Mar 2012 17:51:35 -0600, John Fields wrote: On Mon, 05 Mar 2012 09:33:16 -0800, John Larkin wrote: Consider this: the comparator output is low, so CE is true into U6. U6 and U2 are happily counting clocks. Suppose the U6 count is 0xF, and U2 is 0x4. U6 carry out is true (low) into U2. The correct next count would be Ox0 and 0x5, which is 80 counts decimal. Now let the comparator output go high, so U6 no longer sees a true carry input. But it takes a while before the "don't count" Cout/Cin signal propagates out of U6 into U2. Clock it then. U6 doesn't count, but U2 does. The next state is U6 = 0xF, U2 = 0x5, 95 decimal, which is bad wrong. Classic carry chain error. U9+U7 have the same issue. --- True enough, but what you've missed is that what happens with U2 and U6 when the comparator goes high doesn't matter, since the comparator's going high generates a high-going pulse out of U3 which loads the contents of U2 and U6, at that moment, into U9 and U7. "At that moment?" Wrong yet again. The PE from U3 to U7/U9 is 1.4 us wide, and it's an async DC jam load. When U6 and U2 count wrong, as noted above, the bad count is settled after a typ delay of 200 ns after the clock, and that's what gets loaded into U7/9. It's a hairball. You don't get hazards like this in a clocked synchronous system. --- Apparently, what you've missed is that carry out is synchronous. -- JF This counter is an example of a so called Mealy machine which means that at least one of the outputs depends on both the current state an one or more input signals. The carry_out is such an output. It depends on the current state, the carry_in and the up/down. So as long as these last two signals are synchronous, the carry_out signal will be synchronous as well, otherwise you have to make sure that the inputs are stable some setup time before the next active clock edge. If not, the counter may fail to count correctly. petrus bitbyter Cin to U6 and U9 are both asynchronous, which makes their carry outs async too, so there are hazards. There's no reason to create hazards like this. --- Clearly, you don't understand the 4516's carry circuitry, and are making a fool of yourself by pretending you do by tilting at windmills. -- JF |
ZCD with no Dflops
On Sun, 11 Mar 2012 15:37:45 -0500, John Fields
wrote: On Sun, 11 Mar 2012 12:59:31 -0700, John Larkin wrote: [snip] Cin to U6 and U9 are both asynchronous, which makes their carry outs async too, so there are hazards. There's no reason to create hazards like this. --- Clearly, you don't understand the 4516's carry circuitry, and are making a fool of yourself by pretending you do by tilting at windmills. Otherwise known as brachycephalic rectumitis :-) ...Jim Thompson -- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)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. |
ZCD with no Dflops
On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: On Sat, 10 Mar 2012 19:18:31 -0800, John Larkin wrote: On Sat, 10 Mar 2012 18:30:33 -0600, John Fields wrote: On Mon, 05 Mar 2012 19:31:23 -0800, John Larkin wrote: On Mon, 05 Mar 2012 17:51:35 -0600, John Fields wrote: On Mon, 05 Mar 2012 09:33:16 -0800, John Larkin m wrote: Consider this: the comparator output is low, so CE is true into U6. U6 and U2 are happily counting clocks. Suppose the U6 count is 0xF, and U2 is 0x4. U6 carry out is true (low) into U2. The correct next count would be Ox0 and 0x5, which is 80 counts decimal. Now let the comparator output go high, so U6 no longer sees a true carry input. But it takes a while before the "don't count" Cout/Cin signal propagates out of U6 into U2. Clock it then. U6 doesn't count, but U2 does. The next state is U6 = 0xF, U2 = 0x5, 95 decimal, which is bad wrong. Classic carry chain error. U9+U7 have the same issue. --- True enough, but what you've missed is that what happens with U2 and U6 when the comparator goes high doesn't matter, since the comparator's going high generates a high-going pulse out of U3 which loads the contents of U2 and U6, at that moment, into U9 and U7. "At that moment?" Wrong yet again. The PE from U3 to U7/U9 is 1.4 us wide, and it's an async DC jam load. When U6 and U2 count wrong, as noted above, the bad count is settled after a typ delay of 200 ns after the clock, and that's what gets loaded into U7/9. --- Just because the PE is 1.4µs wide doesn't mean it takes 1.4µs to snag the contents of the up counter before they change. According to the data sheet, the setup time for the data on the jam inputs is 12ns, and the hold time for PE is 35ns. When the comparator's output goes high there's a 125ns delay through U3, and that's when PE for U7 and U9 gets asserted. Since the Q outputs of U2 and U6 haven't changed yet, the 12ns setup time spec has been met, and after the 35ns hold time has passed, the contents of U2 and U6 will have been loaded into U7 and U9. Since you want the clock to go high when the comparator goes high, and the delay from clock to Q is 200ns, then that means that the data present on the outputs of U2 and U6 will be loaded into U7 and U9 160ns after the comparator goes high, which is 40ns before the data on the outputs of u2 changes. He ______________________ U6CI ____| . 250 |_________________ U6CO ____._____| . _________________ CP ____._____| . .200 .____________ U2Qn ____.__________| .125.___________________ U7PE ____.___| . .35.________________ U7LOAD __.______| --- It's a hairball. You don't get hazards like this in a clocked synchronous system. --- Apparently, what you've missed is that carry out is synchronous. No, it's combinational. Look at the chip schematic. --- It's only combinatorial when CARRY IN goes high and forces CARRY OUT high regardless of the state of the clock. When CARRY IN goes low, however, the counter counts synchronously and when CARRY OUT is asserted also follows the edge of the clock, synchronously. On the 4510/4516 data sheet, under "FEATURES", we find that one is: "Synchronous internal carry propagation." Then, looking at the chip schematic, it appears that the external clock, when not overridden by either RESET or PRESET ENABLE, is supplied as an internal clock to the Tflop counter chain. The chain's outputs are synchronous and are used to feed the Q outputs of the chip as well as the inputs of the carry out generator. Now, since the outputs of the Tflops are synchronous, the output of the carry generator is also synchronous and will settle down before the arrival of the next clock edge. So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. You are treating the PE inputs of the counters as if they are edge triggered. They are not. If you assert PE for 1.4 microseconds, what gets jammed into U7/U9 is what's at their inputs at the *end* of the 1.4 usec. As I've shown, that can be wrong. You ended your timing diagram *before* the hazard. You are hiding from the hazards because you don't want to see them. Jim approves. --- Jim this and Jim that? Sounds to me like you've met more than your match and are going through death throes trying to deny it. As far as the rest of it goes, a simple perusal of the schematic, the timing diagram, and the data sheet would convince an honest pilgrim of his errors. That lets you off the hook, of course. -- JF |
ZCD with no Dflops
On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson
wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: [snip] So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. Nope. Jim has no opinion, since I am not a logic designer and never claimed to be. I do approve of Fields jerking you around, though it's getting tiresome. You are indeed suffering from brachycephalic rectumitis (otherwise known as "with big head up butt" :-), You and JF constantly mention things anal and penile. Enjoy! -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
ZCD with no Dflops
On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: [snip] So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. Nope. Jim has no opinion, since I am not a logic designer and never claimed to be. I do approve of Fields jerking you around, though it's getting tiresome. You are indeed suffering from brachycephalic rectumitis (otherwise known as "with big head up butt" :-), You and JF constantly mention things anal and penile. Enjoy! I _do_ enjoy you being caught with your head up your own butt, but you no longer exist. Bye. ...Jim Thompson -- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)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. |
ZCD with no Dflops
On Sun, 11 Mar 2012 15:52:21 -0500, John Fields
wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: On Sat, 10 Mar 2012 19:18:31 -0800, John Larkin wrote: On Sat, 10 Mar 2012 18:30:33 -0600, John Fields wrote: On Mon, 05 Mar 2012 19:31:23 -0800, John Larkin wrote: On Mon, 05 Mar 2012 17:51:35 -0600, John Fields wrote: On Mon, 05 Mar 2012 09:33:16 -0800, John Larkin wrote: Consider this: the comparator output is low, so CE is true into U6. U6 and U2 are happily counting clocks. Suppose the U6 count is 0xF, and U2 is 0x4. U6 carry out is true (low) into U2. The correct next count would be Ox0 and 0x5, which is 80 counts decimal. Now let the comparator output go high, so U6 no longer sees a true carry input. But it takes a while before the "don't count" Cout/Cin signal propagates out of U6 into U2. Clock it then. U6 doesn't count, but U2 does. The next state is U6 = 0xF, U2 = 0x5, 95 decimal, which is bad wrong. Classic carry chain error. U9+U7 have the same issue. --- True enough, but what you've missed is that what happens with U2 and U6 when the comparator goes high doesn't matter, since the comparator's going high generates a high-going pulse out of U3 which loads the contents of U2 and U6, at that moment, into U9 and U7. "At that moment?" Wrong yet again. The PE from U3 to U7/U9 is 1.4 us wide, and it's an async DC jam load. When U6 and U2 count wrong, as noted above, the bad count is settled after a typ delay of 200 ns after the clock, and that's what gets loaded into U7/9. --- Just because the PE is 1.4µs wide doesn't mean it takes 1.4µs to snag the contents of the up counter before they change. According to the data sheet, the setup time for the data on the jam inputs is 12ns, and the hold time for PE is 35ns. When the comparator's output goes high there's a 125ns delay through U3, and that's when PE for U7 and U9 gets asserted. Since the Q outputs of U2 and U6 haven't changed yet, the 12ns setup time spec has been met, and after the 35ns hold time has passed, the contents of U2 and U6 will have been loaded into U7 and U9. Since you want the clock to go high when the comparator goes high, and the delay from clock to Q is 200ns, then that means that the data present on the outputs of U2 and U6 will be loaded into U7 and U9 160ns after the comparator goes high, which is 40ns before the data on the outputs of u2 changes. He ______________________ U6CI ____| . 250 |_________________ U6CO ____._____| . _________________ CP ____._____| . .200 .____________ U2Qn ____.__________| .125.___________________ U7PE ____.___| . .35.________________ U7LOAD __.______| --- It's a hairball. You don't get hazards like this in a clocked synchronous system. --- Apparently, what you've missed is that carry out is synchronous. No, it's combinational. Look at the chip schematic. --- It's only combinatorial when CARRY IN goes high and forces CARRY OUT high regardless of the state of the clock. When CARRY IN goes low, however, the counter counts synchronously and when CARRY OUT is asserted also follows the edge of the clock, synchronously. On the 4510/4516 data sheet, under "FEATURES", we find that one is: "Synchronous internal carry propagation." Then, looking at the chip schematic, it appears that the external clock, when not overridden by either RESET or PRESET ENABLE, is supplied as an internal clock to the Tflop counter chain. The chain's outputs are synchronous and are used to feed the Q outputs of the chip as well as the inputs of the carry out generator. Now, since the outputs of the Tflops are synchronous, the output of the carry generator is also synchronous and will settle down before the arrival of the next clock edge. So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. You are treating the PE inputs of the counters as if they are edge triggered. They are not. If you assert PE for 1.4 microseconds, what gets jammed into U7/U9 is what's at their inputs at the *end* of the 1.4 usec. As I've shown, that can be wrong. You ended your timing diagram *before* the hazard. You are hiding from the hazards because you don't want to see them. Jim approves. --- Jim this and Jim that? Sounds to me like you've met more than your match and are going through death throes trying to deny it. Match? He refuses to discuss digital logic, either because it's too hard for him to understand, or out of loyalty to you. What weird old hens you guys are. -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
ZCD with no Dflops
On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: [snip] So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. Nope. Jim has no opinion, since I am not a logic designer and never claimed to be. I do approve of Fields jerking you around, though it's getting tiresome. You are indeed suffering from brachycephalic rectumitis (otherwise known as "with big head up butt" :-), You and JF constantly mention things anal and penile. Enjoy! --- When we talk about little pricks like you who are such big assholes, how can it be avoided? -- JF |
ZCD with no Dflops
On Sun, 11 Mar 2012 15:37:45 -0500, John Fields
wrote: On Sun, 11 Mar 2012 12:59:31 -0700, John Larkin wrote: On Sun, 11 Mar 2012 12:47:30 +0100, "petrus bitbyter" wrote: "John Fields" schreef in bericht ... On Mon, 05 Mar 2012 19:31:23 -0800, John Larkin wrote: On Mon, 05 Mar 2012 17:51:35 -0600, John Fields wrote: On Mon, 05 Mar 2012 09:33:16 -0800, John Larkin m wrote: Consider this: the comparator output is low, so CE is true into U6. U6 and U2 are happily counting clocks. Suppose the U6 count is 0xF, and U2 is 0x4. U6 carry out is true (low) into U2. The correct next count would be Ox0 and 0x5, which is 80 counts decimal. Now let the comparator output go high, so U6 no longer sees a true carry input. But it takes a while before the "don't count" Cout/Cin signal propagates out of U6 into U2. Clock it then. U6 doesn't count, but U2 does. The next state is U6 = 0xF, U2 = 0x5, 95 decimal, which is bad wrong. Classic carry chain error. U9+U7 have the same issue. --- True enough, but what you've missed is that what happens with U2 and U6 when the comparator goes high doesn't matter, since the comparator's going high generates a high-going pulse out of U3 which loads the contents of U2 and U6, at that moment, into U9 and U7. "At that moment?" Wrong yet again. The PE from U3 to U7/U9 is 1.4 us wide, and it's an async DC jam load. When U6 and U2 count wrong, as noted above, the bad count is settled after a typ delay of 200 ns after the clock, and that's what gets loaded into U7/9. It's a hairball. You don't get hazards like this in a clocked synchronous system. --- Apparently, what you've missed is that carry out is synchronous. -- JF This counter is an example of a so called Mealy machine which means that at least one of the outputs depends on both the current state an one or more input signals. The carry_out is such an output. It depends on the current state, the carry_in and the up/down. So as long as these last two signals are synchronous, the carry_out signal will be synchronous as well, otherwise you have to make sure that the inputs are stable some setup time before the next active clock edge. If not, the counter may fail to count correctly. petrus bitbyter Cin to U6 and U9 are both asynchronous, which makes their carry outs async too, so there are hazards. There's no reason to create hazards like this. --- Clearly, you don't understand the 4516's carry circuitry, and are making a fool of yourself by pretending you do by tilting at windmills. Look at the 4516 internal logic diagram. Cin contributes, asynchronously, to Cout, and to the various logic that generates the next-state T inputs of the flops. It has one prop delay into the T input of the first flop, and *three* PDs into the rest of the flops. Change Cin at just the right time relative to the clock, tease all those internal gate delays, and you can totally befuddle the next counter state. The data sheet warns you to not do this. And, as I've shown, you can screw up the carry from one counter chip to the next. Why are you fighting against doing safe logic design? -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
ZCD with no Dflops
On Sun, 11 Mar 2012 16:24:34 -0500, John Fields
wrote: On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin wrote: On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: [snip] So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. Nope. Jim has no opinion, since I am not a logic designer and never claimed to be. I do approve of Fields jerking you around, though it's getting tiresome. You are indeed suffering from brachycephalic rectumitis (otherwise known as "with big head up butt" :-), You and JF constantly mention things anal and penile. Enjoy! --- When we talk about little pricks like you who are such big assholes, how can it be avoided? There you go again. -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
ZCD with no Dflops
On Sun, 11 Mar 2012 14:30:04 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 15:37:45 -0500, John Fields wrote: Clearly, you don't understand the 4516's carry circuitry, and are making a fool of yourself by pretending you do by tilting at windmills. Look at the 4516 internal logic diagram. Cin contributes, asynchronously, to Cout, and to the various logic that generates the next-state T inputs of the flops. It has one prop delay into the T input of the first flop, and *three* PDs into the rest of the flops. Change Cin at just the right time relative to the clock, tease all those internal gate delays, and you can totally befuddle the next counter state. The data sheet warns you to not do this. And, as I've shown, you can screw up the carry from one counter chip to the next. --- Blather. You've shown nothing but stupidity by adhering to statements you've made which have been proven to be untrue. You really don't know what you're talking about, as evidenced by your recent posts in this thread, and even though you'll soldier on, chanting your ever deceitful mantra, you've been found out. --- Why are you fighting against doing safe logic design? --- You presume to know, and therefore dictate what's safe and what isn't, but the fact remains that you're a coward who's afraid to venture outside of the comfort zone of his paint-by-number world, and willfully maligns criticism. -- JF |
ZCD with no Dflops
On Sun, 11 Mar 2012 14:31:05 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 16:24:34 -0500, John Fields wrote: On Sun, 11 Mar 2012 14:15:50 -0700, John Larkin wrote: On Sun, 11 Mar 2012 13:25:58 -0700, Jim Thompson wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: [snip] So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. Nope. Jim has no opinion, since I am not a logic designer and never claimed to be. I do approve of Fields jerking you around, though it's getting tiresome. You are indeed suffering from brachycephalic rectumitis (otherwise known as "with big head up butt" :-), You and JF constantly mention things anal and penile. Enjoy! --- When we talk about little pricks like you who are such big assholes, how can it be avoided? There you go again. --- And why shouldn't I? -- JF |
ZCD with no Dflops
On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: On Sat, 10 Mar 2012 19:18:31 -0800, John Larkin wrote: On Sat, 10 Mar 2012 18:30:33 -0600, John Fields wrote: On Mon, 05 Mar 2012 19:31:23 -0800, John Larkin wrote: On Mon, 05 Mar 2012 17:51:35 -0600, John Fields wrote: On Mon, 05 Mar 2012 09:33:16 -0800, John Larkin m wrote: Consider this: the comparator output is low, so CE is true into U6. U6 and U2 are happily counting clocks. Suppose the U6 count is 0xF, and U2 is 0x4. U6 carry out is true (low) into U2. The correct next count would be Ox0 and 0x5, which is 80 counts decimal. Now let the comparator output go high, so U6 no longer sees a true carry input. But it takes a while before the "don't count" Cout/Cin signal propagates out of U6 into U2. Clock it then. U6 doesn't count, but U2 does. The next state is U6 = 0xF, U2 = 0x5, 95 decimal, which is bad wrong. Classic carry chain error. U9+U7 have the same issue. --- True enough, but what you've missed is that what happens with U2 and U6 when the comparator goes high doesn't matter, since the comparator's going high generates a high-going pulse out of U3 which loads the contents of U2 and U6, at that moment, into U9 and U7. "At that moment?" Wrong yet again. The PE from U3 to U7/U9 is 1.4 us wide, and it's an async DC jam load. When U6 and U2 count wrong, as noted above, the bad count is settled after a typ delay of 200 ns after the clock, and that's what gets loaded into U7/9. --- Just because the PE is 1.4µs wide doesn't mean it takes 1.4µs to snag the contents of the up counter before they change. According to the data sheet, the setup time for the data on the jam inputs is 12ns, and the hold time for PE is 35ns. When the comparator's output goes high there's a 125ns delay through U3, and that's when PE for U7 and U9 gets asserted. Since the Q outputs of U2 and U6 haven't changed yet, the 12ns setup time spec has been met, and after the 35ns hold time has passed, the contents of U2 and U6 will have been loaded into U7 and U9. Since you want the clock to go high when the comparator goes high, and the delay from clock to Q is 200ns, then that means that the data present on the outputs of U2 and U6 will be loaded into U7 and U9 160ns after the comparator goes high, which is 40ns before the data on the outputs of u2 changes. He ______________________ U6CI ____| . 250 |_________________ U6CO ____._____| . _________________ CP ____._____| . .200 .____________ U2Qn ____.__________| .125.___________________ U7PE ____.___| . .35.________________ U7LOAD __.______| --- It's a hairball. You don't get hazards like this in a clocked synchronous system. --- Apparently, what you've missed is that carry out is synchronous. No, it's combinational. Look at the chip schematic. --- It's only combinatorial when CARRY IN goes high and forces CARRY OUT high regardless of the state of the clock. When CARRY IN goes low, however, the counter counts synchronously and when CARRY OUT is asserted also follows the edge of the clock, synchronously. On the 4510/4516 data sheet, under "FEATURES", we find that one is: "Synchronous internal carry propagation." Then, looking at the chip schematic, it appears that the external clock, when not overridden by either RESET or PRESET ENABLE, is supplied as an internal clock to the Tflop counter chain. The chain's outputs are synchronous and are used to feed the Q outputs of the chip as well as the inputs of the carry out generator. Now, since the outputs of the Tflops are synchronous, the output of the carry generator is also synchronous and will settle down before the arrival of the next clock edge. So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. You are treating the PE inputs of the counters as if they are edge triggered. They are not. --- Since all logic switches when a certain input _voltage_ level is exceeded, edge triggering is a myth. --- If you assert PE for 1.4 microseconds, what gets jammed into U7/U9 is what's at their inputs at the *end* of the 1.4 usec. --- 1. Disconnect U7P4 from 0V, connect it to Vcc and run the sim. 2. Probe U7PE 3. When PE goes high, zoom in on the pulse and probe U7Q4. 4. How soon after the _beginning_ of PE does Q4 go high? 5. What happens to Q4 when PE goes low? --- As I've shown, that can be wrong. --- How so? --- You ended your timing diagram *before* the hazard. --- As demonstrated, since it's the _leading_ edge of PE which does the broadside load, there _is_ no hazard. --- You are hiding from the hazards because you don't want to see them. --- You're either making up "hazards" because you don't want to admit that you were wrong, or because you're too stupid - or blinded by your colossal stubbornness - to see that they don't exist. Which is it? -- JF |
ZCD with no Dflops
On Mon, 12 Mar 2012 09:13:29 -0500, John Fields
wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: On Sun, 11 Mar 2012 14:01:09 -0500, John Fields wrote: On Sat, 10 Mar 2012 19:18:31 -0800, John Larkin wrote: On Sat, 10 Mar 2012 18:30:33 -0600, John Fields wrote: On Mon, 05 Mar 2012 19:31:23 -0800, John Larkin wrote: On Mon, 05 Mar 2012 17:51:35 -0600, John Fields wrote: On Mon, 05 Mar 2012 09:33:16 -0800, John Larkin wrote: Consider this: the comparator output is low, so CE is true into U6. U6 and U2 are happily counting clocks. Suppose the U6 count is 0xF, and U2 is 0x4. U6 carry out is true (low) into U2. The correct next count would be Ox0 and 0x5, which is 80 counts decimal. Now let the comparator output go high, so U6 no longer sees a true carry input. But it takes a while before the "don't count" Cout/Cin signal propagates out of U6 into U2. Clock it then. U6 doesn't count, but U2 does. The next state is U6 = 0xF, U2 = 0x5, 95 decimal, which is bad wrong. Classic carry chain error. U9+U7 have the same issue. --- True enough, but what you've missed is that what happens with U2 and U6 when the comparator goes high doesn't matter, since the comparator's going high generates a high-going pulse out of U3 which loads the contents of U2 and U6, at that moment, into U9 and U7. "At that moment?" Wrong yet again. The PE from U3 to U7/U9 is 1.4 us wide, and it's an async DC jam load. When U6 and U2 count wrong, as noted above, the bad count is settled after a typ delay of 200 ns after the clock, and that's what gets loaded into U7/9. --- Just because the PE is 1.4µs wide doesn't mean it takes 1.4µs to snag the contents of the up counter before they change. According to the data sheet, the setup time for the data on the jam inputs is 12ns, and the hold time for PE is 35ns. When the comparator's output goes high there's a 125ns delay through U3, and that's when PE for U7 and U9 gets asserted. Since the Q outputs of U2 and U6 haven't changed yet, the 12ns setup time spec has been met, and after the 35ns hold time has passed, the contents of U2 and U6 will have been loaded into U7 and U9. Since you want the clock to go high when the comparator goes high, and the delay from clock to Q is 200ns, then that means that the data present on the outputs of U2 and U6 will be loaded into U7 and U9 160ns after the comparator goes high, which is 40ns before the data on the outputs of u2 changes. He ______________________ U6CI ____| . 250 |_________________ U6CO ____._____| . _________________ CP ____._____| . .200 .____________ U2Qn ____.__________| .125.___________________ U7PE ____.___| . .35.________________ U7LOAD __.______| --- It's a hairball. You don't get hazards like this in a clocked synchronous system. --- Apparently, what you've missed is that carry out is synchronous. No, it's combinational. Look at the chip schematic. --- It's only combinatorial when CARRY IN goes high and forces CARRY OUT high regardless of the state of the clock. When CARRY IN goes low, however, the counter counts synchronously and when CARRY OUT is asserted also follows the edge of the clock, synchronously. On the 4510/4516 data sheet, under "FEATURES", we find that one is: "Synchronous internal carry propagation." Then, looking at the chip schematic, it appears that the external clock, when not overridden by either RESET or PRESET ENABLE, is supplied as an internal clock to the Tflop counter chain. The chain's outputs are synchronous and are used to feed the Q outputs of the chip as well as the inputs of the carry out generator. Now, since the outputs of the Tflops are synchronous, the output of the carry generator is also synchronous and will settle down before the arrival of the next clock edge. So, even though the logic between CARRY IN and CARRY OUT may be combinatorial, it's driven synchronously, so its negative output will always bear a fixed relationship, in time, to the positive going edge of the external clock. You have broken the synchronous nature of the carry chain - and of the counter's internal logic - by feeding U6 carry in from the asynchronous comparator output, splattering asynchronous levels all over the place. You are doing this just to be peverse, to prove somehow that hairball logic is a good thing. Jim approves. You are treating the PE inputs of the counters as if they are edge triggered. They are not. --- Since all logic switches when a certain input _voltage_ level is exceeded, edge triggering is a myth. --- If you assert PE for 1.4 microseconds, what gets jammed into U7/U9 is what's at their inputs at the *end* of the 1.4 usec. --- 1. Disconnect U7P4 from 0V, connect it to Vcc and run the sim. 2. Probe U7PE 3. When PE goes high, zoom in on the pulse and probe U7Q4. 4. How soon after the _beginning_ of PE does Q4 go high? 5. What happens to Q4 when PE goes low? --- As I've shown, that can be wrong. --- How so? --- You ended your timing diagram *before* the hazard. --- As demonstrated, since it's the _leading_ edge of PE which does the broadside load, there _is_ no hazard. --- You are hiding from the hazards because you don't want to see them. --- You're either making up "hazards" because you don't want to admit that you were wrong, or because you're too stupid - or blinded by your colossal stubbornness - to see that they don't exist. The people who wrote the CD4516 data sheet put the setup time requirements there because they matter. Which is it? Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
ZCD with no Dflops
On Sun, 11 Mar 2012 14:18:22 -0700, John Larkin
wrote: On Sun, 11 Mar 2012 15:52:21 -0500, John Fields wrote: Jim this and Jim that? Sounds to me like you've met more than your match and are going through death throes trying to deny it. Match? He refuses to discuss digital logic, either because it's too hard for him to understand, or out of loyalty to you. --- He's already stated that he's not a logic designer, so his decision to not discuss digital logic is hardly surprising. Of course, being as malignant as you are, you have to make up all sorts of negative attributes and ascribe them to people you can't control in order to try to discredit them and make it seem like they're beneath you. --- What weird old hens you guys are. --- Actually, I kind of like that, the eggs being my helpful posts on USENET and the pecks my critiques. -- JF |
ZCD with no Dflops
On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin
wrote: On Mon, 12 Mar 2012 09:13:29 -0500, John Fields wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: You are hiding from the hazards because you don't want to see them. --- You're either making up "hazards" because you don't want to admit that you were wrong, or because you're too stupid - or blinded by your colossal stubbornness - to see that they don't exist. Which is it? --- The people who wrote the CD4516 data sheet put the setup time requirements there because they matter. --- Really? Knowing that, you should have realized that the setup time requirement states how long data on the jam inputs has to be stable before the leading edge of PE enters the chip. The PE hold time requirement also matters, and is the amount of time PE must remain true to successfully load the data at the jam inputs into the Tflops. That's all been previously discussed, and the timing diagram I posted earlier clearly shows that there's no problem with loading the data from the up-counter into the down-counter before the data on the up-counter outputs changes. So, I wonder, why are you dancing about spouting irrelevancies when you could just ask for as much rope as you need? --- Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? -- JF |
ZCD with no Dflops
On Mon, 12 Mar 2012 10:03:56 -0500, John Fields
wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin wrote: On Mon, 12 Mar 2012 09:13:29 -0500, John Fields wrote: On Sun, 11 Mar 2012 12:57:04 -0700, John Larkin wrote: You are hiding from the hazards because you don't want to see them. --- You're either making up "hazards" because you don't want to admit that you were wrong, or because you're too stupid - or blinded by your colossal stubbornness - to see that they don't exist. Which is it? --- The people who wrote the CD4516 data sheet put the setup time requirements there because they matter. --- Really? Knowing that, you should have realized that the setup time requirement states how long data on the jam inputs has to be stable before the leading edge of PE enters the chip. The PE hold time requirement also matters, and is the amount of time PE must remain true to successfully load the data at the jam inputs into the Tflops. That's all been previously discussed, and the timing diagram I posted earlier clearly shows that there's no problem with loading the data from the up-counter into the down-counter before the data on the up-counter outputs changes. So, I wonder, why are you dancing about spouting irrelevancies when you could just ask for as much rope as you need? --- Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. I already have a much better, 3-part ZCD circuit that works without hazards. -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
ZCD with no Dflops
On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin
wrote: On Mon, 12 Mar 2012 10:03:56 -0500, John Fields wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin wrote: Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. --- If it's so obvious you should have been able to prove me wrong by now but, instead, you've taken a couple of pratfalls yourself and are afraid to build and test the circuit for fear that it'll vindicate my approach and prove you wrong once again. So, instead of taking the high road and practicing what you preach, you revert to name-calling. Typical Larkinese side-step. --- I already have a much better, 3-part ZCD circuit that works without hazards. --- Let's see a sim. -- JF |
ZCD with no Dflops
On Mon, 12 Mar 2012 10:54:35 -0500, John Fields
wrote: On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:03:56 -0500, John Fields wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin wrote: Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. --- If it's so obvious you should have been able to prove me wrong by now but, instead, you've taken a couple of pratfalls yourself and are afraid to build and test the circuit for fear that it'll vindicate my approach and prove you wrong once again. So, instead of taking the high road and practicing what you preach, you revert to name-calling. Typical Larkinese side-step. --- I already have a much better, 3-part ZCD circuit that works without hazards. --- Let's see a sim. It's been posted, in a couple of variants, in s.e.d. Since you will never believe me about async logic hazards, you might logic race hazard metastability setup hold violation asynchronous logic hazards but you won't. -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
ZCD with no Dflops
On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin
wrote: On Mon, 12 Mar 2012 10:54:35 -0500, John Fields wrote: On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:03:56 -0500, John Fields wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin wrote: Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. --- If it's so obvious you should have been able to prove me wrong by now but, instead, you've taken a couple of pratfalls yourself and are afraid to build and test the circuit for fear that it'll vindicate my approach and prove you wrong once again. So, instead of taking the high road and practicing what you preach, you revert to name-calling. Typical Larkinese side-step. --- I already have a much better, 3-part ZCD circuit that works without hazards. --- Let's see a sim. It's been posted, in a couple of variants, in s.e.d. Since you will never believe me about async logic hazards, you might logic race hazard metastability setup hold violation asynchronous logic hazards but you won't. --- Go away, you tedious ass. -- JF |
ZCD with no Dflops
On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin
wrote: On Mon, 12 Mar 2012 10:54:35 -0500, John Fields wrote: On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:03:56 -0500, John Fields wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin wrote: Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. --- If it's so obvious you should have been able to prove me wrong by now but, instead, you've taken a couple of pratfalls yourself and are afraid to build and test the circuit for fear that it'll vindicate my approach and prove you wrong once again. So, instead of taking the high road and practicing what you preach, you revert to name-calling. Typical Larkinese side-step. --- I already have a much better, 3-part ZCD circuit that works without hazards. --- Let's see a sim. It's been posted, in a couple of variants, in s.e.d. --- Maybe I missed something, but I didn't see part numbers or even an attempt at a finished design, from you, which would satisfy the OP's requirements for a zero-crossing signal varying less than about +/- 2% from the actual zero crossing, with mains frequencies of 50 and 60Hz and voltages of either 120 or 240 VRMS. -- JF |
ZCD with no Dflops
On Mon, 12 Mar 2012 18:18:29 -0500, John Fields
wrote: On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:54:35 -0500, John Fields wrote: On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:03:56 -0500, John Fields wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin wrote: Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. --- If it's so obvious you should have been able to prove me wrong by now but, instead, you've taken a couple of pratfalls yourself and are afraid to build and test the circuit for fear that it'll vindicate my approach and prove you wrong once again. So, instead of taking the high road and practicing what you preach, you revert to name-calling. Typical Larkinese side-step. --- I already have a much better, 3-part ZCD circuit that works without hazards. --- Let's see a sim. It's been posted, in a couple of variants, in s.e.d. --- Maybe I missed something, but I didn't see part numbers or even an attempt at a finished design, from you, which would satisfy the OP's requirements for a zero-crossing signal varying less than about +/- 2% from the actual zero crossing, with mains frequencies of 50 and 60Hz and voltages of either 120 or 240 VRMS. You missed something. -- John Larkin, President Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation |
ZCD with no Dflops
On Mon, 12 Mar 2012 18:34:04 -0700, John Larkin
wrote: On Mon, 12 Mar 2012 18:18:29 -0500, John Fields wrote: On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:54:35 -0500, John Fields wrote: On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:03:56 -0500, John Fields wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin m wrote: Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. --- If it's so obvious you should have been able to prove me wrong by now but, instead, you've taken a couple of pratfalls yourself and are afraid to build and test the circuit for fear that it'll vindicate my approach and prove you wrong once again. So, instead of taking the high road and practicing what you preach, you revert to name-calling. Typical Larkinese side-step. --- I already have a much better, 3-part ZCD circuit that works without hazards. --- Let's see a sim. It's been posted, in a couple of variants, in s.e.d. --- Maybe I missed something, but I didn't see part numbers or even an attempt at a finished design, from you, which would satisfy the OP's requirements for a zero-crossing signal varying less than about +/- 2% from the actual zero crossing, with mains frequencies of 50 and 60Hz and voltages of either 120 or 240 VRMS. You missed something. --- I guess so, but it's a long thread to search and a simple enough circuit that it wouldn't take much effort for you to post the final schematic again, please? -- JF |
ZCD with no Dflops
On Tue, 13 Mar 2012 06:03:50 -0500, John Fields
wrote: On Mon, 12 Mar 2012 18:34:04 -0700, John Larkin wrote: On Mon, 12 Mar 2012 18:18:29 -0500, John Fields wrote: On Mon, 12 Mar 2012 09:17:09 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:54:35 -0500, John Fields wrote: On Mon, 12 Mar 2012 08:26:44 -0700, John Larkin wrote: On Mon, 12 Mar 2012 10:03:56 -0500, John Fields wrote: On Mon, 12 Mar 2012 07:22:12 -0700, John Larkin wrote: Build your circuit and hook it up to an infinite-persistance digital scope. It will screw up on the order of once an hour. --- That task doesn't fall on me, it falls on you since you're the one who wants to prove me wrong. It's a simple circuit and, if you don't make too many wiring mistakes, should be up and running quickly. You'll let us know how it goes, yes? It's an ugly hairball, full of hazards, and you're an amateur. There's no point in demonstrating the obvious. --- If it's so obvious you should have been able to prove me wrong by now but, instead, you've taken a couple of pratfalls yourself and are afraid to build and test the circuit for fear that it'll vindicate my approach and prove you wrong once again. So, instead of taking the high road and practicing what you preach, you revert to name-calling. Typical Larkinese side-step. --- I already have a much better, 3-part ZCD circuit that works without hazards. --- Let's see a sim. It's been posted, in a couple of variants, in s.e.d. --- Maybe I missed something, but I didn't see part numbers or even an attempt at a finished design, from you, which would satisfy the OP's requirements for a zero-crossing signal varying less than about +/- 2% from the actual zero crossing, with mains frequencies of 50 and 60Hz and voltages of either 120 or 240 VRMS. You missed something. --- I guess so, but it's a long thread to search and a simple enough circuit that it wouldn't take much effort for you to post the final schematic again, please? Don't play your tedious games again. You know where the thread is. -- John Larkin, President Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators |
All times are GMT +1. The time now is 06:21 PM. |
|
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004 - 2014 DIYbanter