Worrying is good
Indeed!
This is why I prefer to latch these kinds of derived signals from a clock signal so that anything responding to them does so after the interim logic has settled down, and any feedback effects (like resetting counters) don't happen until the following clock cycle.
It makes sense of course, but (like you stated below) will you then be seeking 799? Or 800? That's just the point here. The async resets can be handled at that exact value, and I *know* it will be at that exact value. I used 799 on my breadboard with sync resets, but does that mean I should on my printed board? Can I trust my data on the breadboard? That's why I'm going with Ben's style of async resets, because it's Ben, and he makes money on this very thing we are discussing
You might be able to do that in Ben's design for the reset signal at least, using a D flipflop (I'd recommend getting some 74HC74s anyway, they are useful for all sorts of things) and that should ensure it stays asserted for at least one clock cycle. You'd wire the main clock (which causes the counters to tick up) into the DFF's clock input (possibly inverted if you need to change its phase) and the DFF's data input comes from /H800. The catch is, you might find you actually want /H799 instead for this... I haven't thought that through in depth.
Right, that's the hard part here. I definitely get the use of the '74, and I'm all for it, but then I'm back to sync/async issues again. Should I go with the 799? Or the 800? My breadboard test says 799, but Ben says 800 (or his equivalent).
I'm all for 'safe and assured', but I'm even more for 'working'. George, I am listening to what you and Bill are saying, very much so! I'm also showing what Ben does and Ben's design works.
I am very welcoming of the comments, both of you, and thank you for them. I am listening, and will be applying this to the design. And I'll be thinking over the other stuff as well.
Thank you both very very much!
Chad
EDIT:
I want to see if my logic in using the async over the sync makes sense. I know the sync logic, wait until the next clock pulse so that everything is "in sync" literally. So here is my async logic:
I'm using /H800 here. When the counter ticks to the 800 mark (synchronously) it's sending that signal to it's respective 74HC688's P lines. That chip is receiving all of the counters at once (sync counters, no ripple. Ben actually uses a slight ripple in his counters not using the "Figure 2" we had previously discussed, but whatever). The '688 then does it's logic stuff with the already high and low signals on the Q lines, so the result should likewise be synced, but delayed by 15ns or whatever.
At that moment, the /H800 that was high is now low, and at the exact same time, it's sending that signal to the /MR horizontal counters, and the PC vertical counters. As soon as the low pulse hits the /MR line (async here), it resets it's counters to zero. It takes 20ns for this to happen (as per the datasheet). That's 35ns now, which is getting close to my 40ns max for the 25.175 MHz clock pulse.
At the same time, /H800 is also going to the CP line on the vertical counters. Funny thing is that it counts on the up tick, so at this point, it's doing nothing. It just waits for the reset line to go back to normal.
At the 35ns mark the horizontal counters are zero, and 15ns later the /H800 signal is gone. Now we are at 50ns. But by then, about the 40ns mark the clock has pulsed and we have the horizontal counters ticking after 7ns or something small. This would then be around the 47ns mark, which is just about when the 50ns /H800 goes back high and now the vertical counters start ticking, their signal is delayed by again 7ns or so. Thus we have horizontal at 47ns now showing a "1", and 57ns when the vertical also now shows a "1". Their timing is off.
So how does Ben do it? A 74HC04 has a delay of 9ns, and a 74HC30 has a delay of 12ns, adds up to 21ns, which is slower than my 74HC688. Ok, so same math:
H-counters uptick and send it's signal to the NOT-NAND logic, 21ns. /H800 is now low, goes to /MR which transitions using 20ns, now we are at 41ns, which is past my 40ns limit on my clock (but not on his 10 MHz clock, hm). So would that tick now not be counted? Or would it still count to "1" at this point? At the same time, 41ns plus the 21ns back through the NOT-NAND logic make 62ns, and now the vertical counters tick, and then more 7ns, leaving us at: Horizontal counter possibly ticked up to "1" at 47ns, maybe, and the vertical counters ticked up to "1" at 69ns, which is even more of a delay.
I think what's going on here is that the 25.175 MHz clock is too fast for async resets. So I'm forced into sync resets. The only other option is to have a separate divider counter that is not tied in with the other horizontal counters in the "Figure 2" method, but is stand-alone, and simply gives me a 12.5875 MHz frequency, which is good enough for me because I was going to to use 2x2 pixel 'blocks' anyways.
Thoughts? I'm seeing that you guys are right. Ben is also right, but at a lower frequency it basically is a null argument. Keeping with the 25.175 MHz clock would require me to use sync resets. That's my conclusion.
Thanks for sticking with me on this. I'm learning math (and I teach it!).
EDIT EDIT:
Attached is an altered schematic. I added a 74HC74. One half is a clock divider, the other half is for the horizontal sync signal. This freed up 2 NAND gates for my enable logic to make more sense.
Just an update, thank you all.
