Simple 4bit CPU: spike in PC CLK Pin

Good morning.
Speaking about mysterious .. I got a spike on the INC PC wire, totally invisible with a probe but it was enough to increment the Program Counter via its Clock Pin. I think it must be something in the Rom, I am quite sure it is not programmed this way to make a spike on Inc PC so I really don't know where this spike comes from. I tried a lot of things, even putting a different program counter there. Finally I tried a capacitor, it is left under in the picture and it is running nice now, the spikes are gone   
This is a very nice project, gives good insight in the working of micro-code. 
http://www.galacticelectronics.com/Simple4BitCPU.HTML
The outcome is not completely as intended yet but one thing at a time. I rearranged it to get a bigger picture. The program section is down under out of view. Don't need that now.




The simu fie is on Github, same title as in the picture. If somebody wants to try this.
https://github.com/Alectus/Gep-Cpu

Ps, INC PC is pin D6 top Rom 0.

It is dificult to say...

But the way that ROM is working could lead toproblems like that.

The output of that ROM is always connected, so any transient value will propagate to the circuit.
The address is set from different sources, not exactly at the same time, so until the address lines don't settle the value should not be outputed.

For other lines this probably does not matter but it does for PC CLK.
You probably want to "and" the PC CLK out of the ROM with the clock driving that 74LS93-Counter.
Or something like that...

A high-capacity capacitor is a bad idea. In the simulator, it may work, but in the real scheme it will lead to failures in operation at high frequencies. At a frequency of 7000 Hz, the signal on the INC PC line completely disappeared. A more sensible solution is to snap the information after the ROM. The modified scheme is in the archive. If you change the microcode, you can remove three triggers (circled in red).

Thank you both again, I'll take a better look tomorrow. I can say already that sometimes I also wonder if some wiring would work in real life. On the other hand, the author mentioned he had glitches with the Roms so in that matter it is a very good simulation.   
The code provided by the author didn't work for me, I was using sample one.
http://www.galacticelectronics.com/Simple4BitCPU.HTML
But it showed me the way and I got the leds counting over and over without restart. Unfortunately the stop/start issue did not go away. And had to put diodes in the Alu section, somehow the lines were pulled low (datasheet says High Impedance with /RE High. Tested it as stand-alone and saw no flaws). 
https://www.ti.com/lit/ds/symlink/cd74hc670.pdf?ts=1617825658372&ref_url=https%253A%252F%252Fwww.google.com%252F

Anyway, I am beginning to understand what the author is doing and a few more days playing with this Cpu and I can add it to the projects forum. Although, sample 2 is a bit more complicated.

https://github.com/Alectus/Gep-Cpu/blob/main/Gep%20Cpu%20Sample1.simu

I am not sure when somebody else uploads this that the rom and ram data are included with it. I guess so because when I downloaded some of your projects it always worked.



Sometimes the animation stays stuck, you have to tap it now and then to get a response. It doesn't affect the 7-segs luckily or the working of the simulation, as far as I have seen. But this is great fun, very glad to have this software.

As ROM 0 is working right now you will always get glitches.

One source of those glitches is the 74LS93-Counter:
Beacuse the Outputs of 74LS93 don't change at the same time.
For example let's say the output of 74LS93 is 3:
Q0 = 1
Q1 = 1
Q2 = 0
Q3 = 0

Now a pulse comes to CP0.. this triggers the first flipflop so Q1 goes LOW,
Now the output of of 74LS93 is 2:
Q0 = 0
Q1 = 1
Q2 = 0
Q3 = 0
As ROM 0 has no output control it will output contents of adress 2.

Now Q0 triggers CP1 and Q1 goes LOW
Q0 = 0
Q1 = 0
Q2 = 0
Q3 = 0
ROM 0 will output contents of adress 0.

Now Q1 triggers third flipflop and Q2 goes HIGH
Q0 = 0
Q1 = 0
Q2 = 1
Q3 = 0

Q2 will activate INS0 to INS3
Lets say INS0 = 1, and the rest = 0;
ROM 0 will output contents of adress 6.

If that ROM is controlling the clock of PC those glitches will cause problems.
Using capacitors is a hack more than a solution.

The solution is only taking the address lines once they are settled o only taking the output from the ROM  once it's settled.

Something like this could probably work, but this is just a rought idea, I don't know the circuit.
Here the address is increased in the falling edge of the clock.
And address lines are fed to the ROM in the rising edge of the clock, when everithing is settled.
No glitches, just a clean output:

I will certainly try that, thanks a lot! 
Want to clean up the scheme anyway, remove the 4-poles switches for example. Did you consider adding a rotary switch in SimulIDE? DT and a TT   
To get to know the circuit takes time, I don't like to use my printer too much, also it is not very good in printing schematics, in stead I have a second laptop next to me. Old fashioned I sat down and used pen and paper to get sense of what the author Jon Qualey was doing back in 2006.
I made a table and it fits on one A-4



a is the address shown in the 7-segments left of the Roms.
b is the instruction name
c is the operation it does
d is the decimal to put into Ram1

So for example, to make the leds count you put into Ram 1: 
4,   3,   14,  4,   3,   14,   4,   3,   14,   4,   3,   14,   4,   3,   14,   0
That means INC followed by STORE and followed by OUT repeatively.
Maybe the last zero I should make it a 15, a NOP.
This table needs some more checking if no mistakes are made, by me.

http://www.galacticelectronics.com/4BitCPU_ROMDetail.HTML

The Rom 0 and 1 files don't need to be changed anymore, they are here: 
https://github.com/Alectus/Gep-Cpu

Ps, do you have an idea why I have to use the diodes at the 670 outputs to prevent the data-lines pulling down? I noticed something going wrong from the beginning, that's why I put the 4-poles switches on the data-bus so I could program by hand the Rams. 
And another thing is looming, it is the OE line of the 2114's , more about that later. This came up because the real 2114 does not have OE pins. 
http://hardware.speccy.org/datasheet/2114.pdf
In short, I tried inverting OE at the same time as Write pulse goes Low, shown in picture below, also as stand-alone, but could not write into Rams by hand with this inverter configuration. That's why OE has a separate line now.
Now if the programs want to write into Ram I need to figure out something else. Fact is, I don't know yet if the program is intended to write into Ram, I dont see a instruction for it. This one is used for putting Data out of Ram0 onto the databus:
/E INS DATA - Active low signal to enable program data on the data bus.
http://www.galacticelectronics.com/4BitCPU_ClockMicro.HTML

Anyway, don't bother yet, I moved this down the line for later to test more.

@Fizik_S,
I tried your modification with the above mentioned Led Counting set-up and that goes very well. So it is proof that the addition of the four 175's did not change the working of the scheme. More importantly, my hack with the capacitor can be removed. Arcachofo's suggestion I still have to try. 
About the three FlipFlopD's, I think I will leave them there because I find it also nice when the scheme of a simulation can be recognized as being close to the original. About 7000 Hertzs .. of course it is very helpfull for other readers and me that you explain why it will not work with a capacitor and I thank you for that but with only this output of 4 leds available high clockspeeds are not so needed.

arcachofo suggested a similar solution. I suggested the 74HC175 because it has forward and reverse outputs. This allowed us to get rid of the inverters after the ROM. You can use 2 latches 74HC574, but in this case you need to leave the inverters.
You can try to put a synchronous counter 74HC163 or 74HC193 instead of the counter 74XX93 (this is an asynchronous counter). Perhaps it will not require latches after the ROM. If you have a desire - try it. If the result is positive, you will have 4 options for solving the problem.

I didn't realize Fizik_S already provided a solution.

He implements the solution in the outputs of the ROM. I suggested a solution in the inputs.
Anyway my suggestion is just a rought idea, not a proper solution.

It was not a very big problem such as last time when I had no IC for the Ben Eater bread board and Fizik had to make one custom made. This simulation is running very nice, I had it running at 50 Hz and is going like a clock. One year ago this was not possible so I am very thankfull that a lot of components are added to the supply. I got an idea for the 2114, make an extra delay for the write pin. This appears to be working:



But I don't think I will need it anyway. The 2114 write pin tunnel in the schematic is only hand controlled, unless I overlooked something.