Clock build log #5 - calendar module

One thing I've come to realise throughout this project is that describing the build is reasonably uneventful - it's really just a repetition of place components and do a load of soldering. It makes for much less of an interesting read.

Certainly on a personal level I have found the troubleshooting process to be much more interesting - discovering an issue and trying to figure out how to fix it in as few changes or additional components as possible. Some of my boards are quite dense with little room for more logic, especially if a fix needed a large block of logic to implement. And as you've seen the "rats nest" of wiring on the rear of the boards actually poses quite an accessibility problem getting to solder joints, even with the reasonably fine 1.5mm soldering iron tip that I have used.

Luckily, however, problems requiring fixes have been reasonably uncommon, with maybe a transistor or two added here and there. And I've been quite thankful for that.

So having said all of that, I'll skip most of the details of the build of this board, and fast forward to the troubleshooting stages.

Like in previous builds involving ripple counters, I built each stage one by one so that I could test that they all worked before burying them under a lot of wires. And like all of the counter stages that came before, I didn't encounter any significant issues. In fact, if I encountered anything that could be considered significant, it was generally that a floating reset input would generally cause that stage to not function until I pulled it low (otherwise it was in constant reset). One of the disadvantages of using MOSFETs over other types of transistors is that their gates are capacitive, which means that when they are floating their state is somewhat non-deterministic - that is to say they could be high, low, or somewhere "kind of in between" - so pulling up or down is essential.

This is often very easy to fix. Using a pair of tweezers I can create a short between the gate pin and the negative power supply rail, and that was usually enough to sort out that gate long enough that I was able to test the functionality of the n-bit counter that had been built up. Some gates were a little more stubborn than others and needed a tiny piece of wire soldered in to hold the pin low. The primary reason that was an issue at all was due to the way I built up the counter logic. I would typically start with the counter stages and then move to the surrounding reset logic, so to begin with the reset inputs of each counter stage were not connected.

By far the most significant issue that I came across with this build was to do with the preset input which was supposed to ensure that when the month counter resets (i.e. when the calendar moves between months) the day of month counter would reset to 1 instead of 0 (since there is no day 0 in any calendar I know of). As you'd see from the design log for the calendar module, I did breadboard the circuitry to determine whether or not using a small capacitor at the appropriate point in the circuit would hold the preset input low for a short period of time which would enable a corresponding reset input to assert itself high prior to the preset input going high. This sequence is required in order for the preset to work, and certainly it worked on my breadboard. Hence I designed in what was to be the original design of the circuit. But it turned out that this still didn't work quite right once the circuit had been fully built up, and it only became apparent when I showed off my clock to some friends and this little gremlin surfaced. So it was back to the drawing board to find a solution.

I started by scoping out the various reset signals to find out what was happening, and unfortunately I forgot to capture an image of the signals on my scope, but the basic problem that I discovered was that the reset signal that is generated by the large block of reset circuitry below the units counter would be so brief that combined with the capacitor loading the preset input I think it just never actually had a chance to go high. I believe I did notice the tiniest of bumps in the trace for the preset input where that signal had started to rise, but by that stage the counters had reset, and the resulting reset signal was no longer asserted, so the preset signal was dragged back down to ground.

My solution involved adding in some more gates to form another SR latch, one input would come from the original inverter that was connected to the preset input, with the capacitor removed. The other input would come from the AC_CLK/ signal to reset the SR latch once the preset input was no longer going to be needed. The capacitor was then moved down to the appropriate output of the SR latch and then fed in to the preset input. I did also breadboard this solution to ensure I wasn't going to be wasting more time, and that also proved to work, only this time in-circuit.

I really do wish I captured a screenshot from my scope so I could visualise all of what I just said above, but you'll just have to believe me (and I hope it all made sense). And yes, you're seeing the finished clock there, before I've gotten around to writing any blog material for the calendar decoder module. Oops? :-)

So while the day of month counter was now resetting correctly upon the month rolling over, the next problem I found was when pressing the reset button at the back of the clock, the day of month would reset to 0 instead of 1. I had a solution to this pretty much already worked out, and it used a typical combination of logic that I have used elsewhere to "suppress" a certain signal when another signal is asserted. This involves inverting the AC_CLK/ signal and feeding it in to a dual input NOR gate, with the other input of that NOR gate connected to MCLR. When ever MCLR happens to be asserted, the AC_CLK/ signal will not propagate to the SR latch to reset it, and thus the preset signal will be able to have some effect.

The result looks a bit more complicated than the original, and I guess it is, but hopefully is easy enough to follow:

Before

After

I was fairly confident this would now work properly, so I went straight ahead and built it up - a total of 7 transistors making 4 new gates (146-149). And afterwards when testing it out, it all worked perfectly. Day of month was now resetting correctly upon month rollover and when the reset button was pressed.

Calendar module done! Here are the results:

Since there were some modifications to the circuitry which occurred after the design log was published, I've uploaded revised schematics along with this blog. They are in the same location as before.

• GitHub repo
• calendar-module.sch EAGLE schematic file
• calendar-module.pdf

Clock design notes #5 - theory of operation

With all of the basics now covered, I thought it might be interesting to talk about the operation of the clock, and hopefully leave you with a good insight in to how it will function internally in order to produce the ever familiar output.

Here's a block diagram of all of the major parts to get started with:

And throughout the rest of this post I will (try to) explain the relationship of all of the items so that you understand what makes the clock tick (pun intended). There's a lot of repetition, so once you understand one little bit of it, you'll probably understand almost all of it.

But first, some terminology needs covering.

Things enclosed in parentheses indicate output signal names, for example, (AC_CLK/) indicates that AC_CLK/ is the signal output from that piece of the circuit.

Blue lines indicate clock signals, and there are numerous clock signals generated within the various modules of my clock which are used to advance successive counters, from seconds to minutes to hours to days and so on.

Green lines indicate counter outputs, and are usually multi-bit binary values. These outputs feed in to decoders that drive displays, and also in to reset circuitry that resets the counters and generates the various clock signals.

Red lines indicate reset signals which are used to either reset the entire clock (as in the case of MCLR), or only small portions of it, such as a single counter.

Black lines are generic signals.

Otherwise all of the boxes are labelled to indicate their purpose, and the lines are all capped off with an arrow head at one end indicating the direction that the signal is used.

Mains frequency prescaler

A simple circuit is used to produce a clock pulse of sorts from one half of the AC sinewave. This clock pulse is referred to as the AC_CLK/ signal because it pulses at the same frequency as the AC supply. It feeds the mains frequency prescaler, which increments on each falling edge of the AC_CLK/ signal. The forward slash indicates that it is an inverted signal, because AC_CLK/ is high when the AC waveform is low and vice versa.

This prescaler is tied to a reset circuit. The reset circuit can be configured to reset the prescaler at any value up to 63 because it's a 6 bit counter, so the clock can be used anywhere around the world, but in my case it will be configured to reset at 50 count because of where I'm located.

Upon the prescaler reaching 50 count, the reset circuit sets an SR latch sending its Q output high and complementary output (Q/ or "not Q") low. Q feeds in to the reset input of all of the D type flip flops that are part of the prescaler counter resetting them to 0, and Q/ creates a clock pulse to the seconds counter which is referred to as 1PPS_CLK/ (1 pulse per second).

On the rising edge of the next AC_CLK/ pulse, the SR latch will be reset causing its Q output to go low and releasing the reset on the counter, and Q/ output goes high. In this state the counter is at 0 count, and the next falling edge of AC_CLK/ will cause the counter to increment by 1.

Since I lack the requisite skills to make a fancy video, or maybe even an animation describing this, I'll try to illustrate it by way of another timing diagram. So here goes:

The very top signal of the timing diagram is AC_CLK/, oscillating back and forth between high and low states. The two signals below indicate the state of the SR latch outputs that form part of the reset circuit for the prescaler. Q feeds the reset of the counter, and Q/ forms the 1PPS_CLK/ signal to the seconds counter. PS 1 through PS 32 indicate the state of the Q outputs of the individual stages that make up the counter. A NOR gate connected to the complementary (i.e. Q/) outputs of PS 2, 16 and 32 acts as an AND gate to create a brief pulse in to the SR latch which triggers the reset when the count reaches 50.

So at the very left hand side of the timing diagram you see that PS 1, 2, 4 and 8 are low (0), and PS 16 and 32 are high (1), equalling a value of 48. At the falling edge of the first clock pulse you see that PS 1 transitions to a high state, so now the counter is representing a value of 49 (1+16+32). Then at the falling edge of the second clock pulse, PS 1 transitions to a low state, and that causes PS 2 to transition to a high state such that the counter now represents a value of 50.

As I have tried to represent in the diagram, it doesn't stay in this state for very long (on the order of nanoseconds really). At the point that PS 2, 16 and 32 are high, the NOR gate connected to the complement of those outputs goes high at its output (all low inputs = high output), and this causes the SR latch to invert its state. The Q output of the SR latch causes the counter to reset to 0, so you see after a short blip of PS 2 being high, it along with PS 16 and 32 all transition to a low state, and the counter now has a value of 0 with PS 1-32 all being low. And when Q/ of the SR latch transitioned to a low state, the falling edge of that signal would have caused the seconds counter to increment.

At the rising edge of the third pulse of AC_CLK/ you see that the SR latch inverts state again as it gets reset, and then at the falling edge of the third pulse you see that PS 1 goes high and we are back to a value of 1 again. It will continue incrementing until it reaches 50 count again, at which point it resets, generates another 1PPS_CLK/ pulse, and the seconds counter increments again. Lather, rinse, repeat until the end of time (or the power goes out).

Hopefully that gives you an idea of how the different clock pulses will be generated - they all operate in pretty much exactly the same way. Now I'll try and explain in a little more detail how everything ties together.

Seconds, minutes and hours

The seconds counter takes its input from the output of the prescaler, that is, the 1PPS_CLK/ signal. The seconds counter increments on the falling edge of the 1PPS_CLK/ signal which occurs when the prescaler reaches 50 count and resets. The seconds counter will count from 0 to 60, and upon reaching 60 count will reset itself to 0, so the effective count is 0-59.

Like the prescaler, the reset that occurs at 60 count sets an SR latch. The Q output of that SR latch goes high in order to reset the seconds counter to 0, and the Q/ output goes low generating the 1PPM_CLK/ (1 pulse per minute) clock signal which feeds the minutes counter.

At the next rising edge of AC_CLK/, the SR latch is reset and thus releases the reset on the seconds counter allowing it to start counting again at the next falling edge of 1PPS_CLK/.

Actually it's even a little more complicated than that, if you remember back to an earlier post I explained that each "counter" is really made up of two counters, each of which drives a display decoder. A "units counter" counts 0-9 and resets at 10, and that reset clocks the "tens counter" which counts 0-5 and resets at 6. That final reset at 6, which represents a total effective count of 0-59 is what generates the clock pulse to the next "counter".

The minutes counter will count 0-60 too, triggered by the falling edge of the 1PPM_CLK/ signal, and upon reaching 60, an SR latch is set, with the Q output resetting the counter to 0 and the Q/ output producing the 1PPH_CLK/ (1 pulse per hour) signal which feeds the hours counter.

I'm sure you can see where this is going ...

The hours counter counts 0-24 before resetting giving an effective count of 0-23, incrementing on the falling edge of the 1PPH_CLK/ signal, and resetting in the same maner as above with an SR latch generating a 1PPD_CLK/ (1 pulse per day) signal.

Pretty simple right?

Days and months

Days and months are a little more complicated. So lets start with a low hanging piece of fruit: day of the week.

Day of the week is a simple counter which is used to track the day of the week from Monday to Sunday, incrementing every falling edge of the 1PPD_CLK/ signal. It uses the same reset mechanism as all of the counters above, and upon reaching 7 it resets to 0 (with Monday being day 0 and Sunday being day 6). No clock signals are generated from its SR latch though, so I'll pretty much leave it there.

Day of the month is also incremented every falling edge of the 1PPD_CLK/ signal. But it includes a preset input to ensure that it always starts at a value of 1 since there is no day 0 in a month.

The reset circuit for day of month is also more complicated as it needs to handle a variety of situations, like resetting after the 30th or 31st day of certain months, or after day 28 or 29 in the month of February depending on whether it is a leap year or not. So it takes input from not only the day of month counter, but also the month counter, and the leap year toggle. The reset condition is generated based on the combinations of inputs from all of those sources according to this truth table:

If that looks slightly confusing (like, there aren't 32 days in any months you know of...), it's because that is the value that the day of month counter needs to be at in order to set the SR latch which causes the reset to occur, so the effective day count is one less than that since it will only stick around at 32 count for a few tens of nanaoseconds.

But the same basic principal applies in that it counts, and upon the above conditions being met it is reset, and an SR latch generates the 1PPMO_CLK/ (1 pulse per month) signal which causes the month counter to increment.

The month counter increments on the falling edge of the 1PPMO_CLK/ signal, and will reset at a count of 12 using the same SR latch mechanism. The same output of this latch which resets the month counter also feeds in to the leap year toggle to reset it at the end of the year such that the next year wont be counted as though it is a leap year - so you can set it at the start of the year, and not need to worry about turning it off. It's all about the little things in life...

I hope this has given you a good insight in to how the clock will function internally and how all of the various clock signals are generated and used.

Clock design notes #4 - ripple counters

Ripple counters are used extensively in my clock. I use them as a prescaler for the mains frequency, and also for the various counters in the time and calendar "modules".

A ripple counter is an asynchronous counter. An external clock signal is applied only to the input of the first stage. The output of the first stage feeds in to the clock input of the second stage, and the output of the second stage feeds the next stage, and so on and so forth for as many stages as required. So as the name suggests, any changes that happen to the output state of each stage within the counter are going to ripple from one stage to the next - something like a line of dominos falling over.

This is basically the opposite of a synchronous counter, whose outputs all change at the same time based on a clock signal which is applied to all stages simultaneously. This results in an instantaneous change to all outputs at the same time in line with the clock signal.

I chose to use ripple counters instead of some other kind of synchronous counter (like one built from master-slave JK flip flops) because they are easier to implement with fewer transistors, and my clock doesn't have such an operating frequency where a synchronous counter might actually be necessary. For example, a modern CPU in a computer has an operating frequency somewhere in the multiple gigahertz (GHz) range (1GHz is 1 billion hertz... or 1 billion cycles per second), whereas my clock is timed from the AC mains frequency, which will be 50 or 60 hertz (hz) depending on where it is operated. So a little bit of delay here and there is not really detrimental to its operation - theres a relative eternity for things to settle down and work itself out (20ms per cycle at 50hz vs 1ns at 1GHz, several orders of magnitude).

So what is a ripple counter? It can be (as in my case) a series of D type flip flops cascaded together, and a D type flip flop is basically a series of SR latches.

So .. what is an SR latch? It's a very simple latch with two inputs, S (set) and R (reset), and two outputs, Q and the complement of Q (often referred to as "not Q"). The two inputs can be used to switch between two states: Q high and not Q low, or Q low and not Q high. In order to bring Q high, you must place a high signal on the set input. To bring Q low, you place a high signal on the reset input (not Q is always the opposite). Importantly, and as a latch, it holds the last state you applied even after you remove your input signal. Setting both the set and reset inputs high at the same time is an invalid input state, and at that point both Q and not Q will be low. As you'll see below, the topology of the SR latch circuit is symmetrical, so you can arbitrarily assign set and reset to either of the two inputs, the only rule is that Q will be the diagonally opposite output to the set input, and not Q will be diagonally opposite to the reset input.

You'll see them represented like this in my schematics, made easily out of two 2-input NOR gates:

You wont always see the inputs and outputs labelled in my schematics, and you might not always see the two outputs of the latch being used, but you will see this kind of circuit topology very frequently. I use a forward slash to indicate an inverted signal (i.e. the complement).

The explanation above is a bit brief, so I present to you a video by Ben Eater who explains this in more detail, and provides some practical examples to show its behaviour. It's a good video, and he has plenty more covering a project to build a small computer of sorts on a series of breadboards. Well worth watching his videos if you are interested in digital electronics, I highly recommend you check his channel out - you will learn a lot.

Moving on, three SR latches make a D type flip flop. In my clock I use D type flip flops with up to three inputs: clock (always), reset (always), and preset. Flip flops tend to be "edge triggered", that is, they will change state on either the rising or falling edge of the input clock pulse - which one depends on its construction. You may also be able to configure a flip flop to invert its state each time the clock input is pulsed, but this is not always the default behaviour. In my case, since I am using NOR logic, my flip flops will trigger and invert on the falling edge (high to low) of the input clock signal.

Setting the reset pin high will cause it to reset to a default state, in my case, Q being low. It's worth noting that while the clock input triggers on the falling edge, the reset input triggers on the rising edge.

In between resetting a D type flip flop and the next clock pulse, you can also feed in a preset signal. If the preset signal is high, the flip flop will start with Q being high, and the next clock pulse will transition Q to low. If the preset is left low, or no preset input is provided, the flip flop starts with Q low and the next clock pulse will transition it to high. A "full featured" D type flip flop will look like this in my schematics:

But once again, the inputs and outputs wont always be labelled, I've included them here to show you where those inputs are located. And as you can see, it's nothing more than three SR latches crossconnected in a specific way.

I don't have a particularly good video in mind to provide a link to to give a better explanation of the D type flip flop other than Ben Eaters video above, but I do have a link to a web page with a simulator that you can play with. It's not an exact representation of what I have here, but its pretty darn close and the operation is exactly the same. The only thing you need to do is set the D input to what ever the "not Q" output is before clicking the clock button, and you will see that you get the required behaviour which is to invert state on every clock pulse (you can see in my schematic above, not Q is tied to one of the inputs of GATE4, and that in the web based simulator, the same input to GATE4 is just a toggle).

There's also a mountain of additional reading on flip flops on this Wikipedia page.

Getting to the point where this all relates to a ripple counter... With the above theory in mind, recall that I have configured my D type flip flops to invert state on each clock pulse, and that they do this on the falling edge of the clock pulse.

If we start with all ripple counters in a reset state, such that Q is low for all outputs, and then feed a clock pulse in to the first stage (referred to as the "least significant bit") of the ripple counter, its Q output inverts to high on the falling edge of the clock pulse. On the next clock pulse, Q inverts back to low at the falling edge of the clock pulse. That output is also connected to the clock input of the second stage, so on the first stage output transitioning from high to low, Q of the second stage then inverts from low to high. We have just counted from 0 to 1 to 2. Now, the next clock pulse to the first stage inverts its Q output to high, and with high Q outputs on our first two ripple counter stages we are at binary value of 3. A further clock pulse to the first stage inverts its output to low, and that high to low transition causes the second stage to invert its Q output to low, and with the second stage output tied to the third stage clock input, that high to low transition causes the third stage to invert from low to high. We've now counted  0, 1, 2, 3, 4 (in binary, with the least significant bit on the right: 000, 001, 010, 011, 100).

But words aren't always interesting, so here's what is known as a timing diagram to visualise all of what I wrote above, plus a few extra clock pulses so you can see how it continues on:

As you can see, after the 8th clock pulse transitions high to low, all 3 stages return to low Q output state. It's no coincidence, a 3 bit counter can count from 0-7 which is 8 different values.

Bear in mind that this is just for demonstration purposes. Recall that a ripple counter is an asynchronous counter, so the outputs do not all transition instantly at the falling edge of the clock, rather, the falling edge of the clock is only when the "chain reaction" will begin, starting with the first stage and "rippling" through the counter as each stages output transitions from high to low, but only as far as the first stage that transitions low to high (because further stages will only be clocked when the preceeding stage transitions from high to low). The above diagram would indeed be accurate for a synchronous counter. Just a limitation of trying to draw it up in a spreadsheet I guess. But we are talking on the order of nanoseconds here, so it might be reasonably fair to say they do change "pretty much all at the same time".

If that still isn't enough to satisfy your understanding, I also provide a logicly file where you can see it in action for yourself. Heres a screenshot if you want to reconstruct it in the online demo:

If you look through logicly's options and ensure that the "Limit Propagation to Frame Rate" option is checked, then you may actually be able to see the ripple effect in action.

As I mentioned at the start of the post, I'm using ripple counters throughout my clock. In fact there will be 7 in total. I also use a lone D type flip flop as a toggle for leap year handling.

The day of month counter is the only counter in the clock which accepts a pre-set value. This is so that each time it is reset it can be set to start counting from 1 instead of 0 like all of the other counters.

And finally, if you were wondering about transistor counts as per my recent posts, a D type flip flop with no preset input takes 14 transistors to implement or 15 with a preset input, but there is also some additional reset logic to go along with these counters, so more detailed counts will be provided in future posts when I discuss their specific design and construction.