Speaking of invalid states... I haven't thought this through properly but it, at a quick glance, looks like there are not synchronisation between the inClk and the inRun signals. This means that you can get a very short clock pulse out of the AND gate if the inRun is toggled at the wrong time, and that might make (some of ) the 74'74s not to clock properly and they might and up in a undefined/non-approved state. But maybe you will have those signals synchronised outside of this module already. A tip for Digital is to use the "Triggered Data Graph" instead of the older plain "Data Graph". The output from the triggered one is much more similar to what we're used to from oscilloscopes and logic analysers. The plain one advances a grid as soon as any of the monitored signals changes state and not on a regular timing basis (from the CLK for instance). This makes it really hard to get a proper view of the timing of the signals. For instance if you have a signal that has 50% duty cycle and you also monitor another signal that sometimes changes in the middle of the 50% duty pulse. Then the curve for the 50% duty will get another grid there and be longer and not look like a 50% duty on the screen. I got bit by that many times and caused a lot of confusion and headache before he implemented the Triggered Graph.
Appreciate the comments. Yes, I see your point about the inClk/inRun synchronization. This is not the final design on the clock, so will consider that when I revisit the final clock design. Anywhere in the design using individual gates and not 7400 IC's is temporary logic. Yeah, I noticed the issues with the Data Graph. Will look at the Triggered Graph if needed in the future. Hey, I saw your Digital simulator work with the PDP-8. That looks really cool. Well beyond what I'm doing here. I will have to download that when I have some (more) free time. Thx.
Hey Mat, I went ahead and added a D latch on inRun so it will only clock if inClk is low to add some synchronization as you suggested. It's not rock solid, but better. In practice the Run/Pgm will only be used during system development. Thanks.
Cool stuff
Thx
Speaking of invalid states... I haven't thought this through properly but it, at a quick glance, looks like there are not synchronisation between the inClk and the inRun signals. This means that you can get a very short clock pulse out of the AND gate if the inRun is toggled at the wrong time, and that might make (some of ) the 74'74s not to clock properly and they might and up in a undefined/non-approved state. But maybe you will have those signals synchronised outside of this module already.
A tip for Digital is to use the "Triggered Data Graph" instead of the older plain "Data Graph". The output from the triggered one is much more similar to what we're used to from oscilloscopes and logic analysers. The plain one advances a grid as soon as any of the monitored signals changes state and not on a regular timing basis (from the CLK for instance). This makes it really hard to get a proper view of the timing of the signals. For instance if you have a signal that has 50% duty cycle and you also monitor another signal that sometimes changes in the middle of the 50% duty pulse. Then the curve for the 50% duty will get another grid there and be longer and not look like a 50% duty on the screen. I got bit by that many times and caused a lot of confusion and headache before he implemented the Triggered Graph.
Appreciate the comments. Yes, I see your point about the inClk/inRun synchronization. This is not the final design on the clock, so will consider that when I revisit the final clock design. Anywhere in the design using individual gates and not 7400 IC's is temporary logic.
Yeah, I noticed the issues with the Data Graph. Will look at the Triggered Graph if needed in the future.
Hey, I saw your Digital simulator work with the PDP-8. That looks really cool. Well beyond what I'm doing here. I will have to download that when I have some (more) free time.
Thx.
Hey Mat, I went ahead and added a D latch on inRun so it will only clock if inClk is low to add some synchronization as you suggested. It's not rock solid, but better. In practice the Run/Pgm will only be used during system development. Thanks.