Sure, if you couldn't build up a hierarchy, HDLs would be rather limited.
For example, you could have:
module ic2323(
input p0,
input n0,
input p1,
input n1,
input clk,
output q0,
output q1,
output x
);
// Instantiate a pn for p0, n0 and q0.
pn pn_a(
.p (p0),
.n (n0),
.clk (clk),
.q (q0)
);
// Instantiate another pn for p1, n1 and q1
pn pn_b (
.p (p1),
.n (n1),
.clk (clk),
.q (q1)
);
// XNOR the two outputs together
assign x = ~(q0 ^ q1);
endmodule
As with any undertaking, you want to break the project into systems, then subsytems, finally down to each detail. You’ve left so much to consider.
“To invent something, all you need is imagination and a big pile of junk.” ― Albert Einstein
What do you have in your junk box or what is readily available (and affordable) from vendors?
Let’s nit-pik the details:
(You say you wish to move the hands of the clock via the adjustment knob but I suspect that’ll not last long, failure of the adjustment mechanism will occur sooner than later.)
Are the hands of the clock independently controlled? Will the hands move in one direction or both directions? Do you wish to control the speed of the hand(s) movement? (Determines if you need a simple on/off or a simple PWM speed controller for single direction or a PWM controlled H-Bridge for direction and speed.)
What physical size clock will you use and what sized motors will fit inside the clock?
How will you mechanically interface the motor(s) with the hand(s)?
Will the clock ever return to “normal,” current time?
"My mind is a raging torrent, flooded with rivulets of thought cascading into a waterfall of creative alternatives." - Hedley Lamarr
Once you have the number of motors and controllers, then you may decide on the number of wires your remote control will require followed by determining the power supply requirements. You might consider looking at the cheapie 433MHz wireless modules. Finally, you may consider the power supplies requirement and the available options.
As part of our Halloween stuff, I built a “Twilight Zone” clock using a large, old, school clock. Three tiny motors driven by H-Bridges (for both speed and direction control) allowed for the hands to spin in all sorts of directions, sometimes the hands moving quickly enough to almost be a blur and other times moving slow enough to almost make the viewer rip off the glass and move the hands manually. Very little original clock movement was used, instead it took a lot of soldering of tiny brass tubes and rods to brass gears from slot cars. (If I were to build another, I’d use plastic and carbon fiber.) It has a microcontroller running it though.
I’d be interested in hearing how this project of yours proceeds. :)
Best Answer
Since both your clocks are generated by the same PLL, they are synchronous with well known phase relationship. Hence, there is no asynchronous clock domain crossing between the signals driven by
base-clk
andfast-clk
.When sending data from slow clock to fast clock, as long as the fast clock has sufficiently smaller time period, there should be no risk of data loss. However, these inter-clock paths have to be properly multi-path constrained and ensure that timing is met.
Sending data from fast clock to slow clock is different story. You will get some good insight here