`CLK_ENA` should only go high after `OSC_STABLE`

[Rodrigodd]

Noticed that when integrating this CPU into the complete Game Boy system made by msinger. That work is displayed at msinger/dmg-sim#1.

From msinger research, CLK_ENA should only go high after OSC_STABLE, otherwise the OSC_STABLE never goes up (this is better explained in the link above).

Extracting the logic of CLK_ENA from Seq.v, we can see it never interacts with OSC_STABLE, and goes up immediately after RESET:

RESET	SYNC_RESET	CLK_ENA
0	0	~(d[100] | IR[4] & d[101]) | SeqControl_1
0	1	~(d[100] | IR[4] & d[101])
1	x	0

• d[100]: s1_op_halt_s0xx
• d[101]: s1_op_nop_stop_s0xx

[ogamespec]

Hi, and I was just checking a couple days ago to see if anyone was interested in this repository in 2024. And then a day later, you write. Coincidence? I don't think so, hehe.

I've realized the problem, I'll see how the wires go and report back what I find. I had to spend some time just to remember the context (wires, signal assignments, etc.) 😅

[ogamespec]

There is a "big picture" derived from PlanAhead by digesting the Seq.v:
https://raw.githubusercontent.com/emu-russia/dmgcpu/main/HDL/Design/Seq.png

I have traced how OSC_STABLE connects through all the gates to CLK_ENA. Here is the path: OSC_STABLE -> g59 -> g58 -> g57 -> g44 -> g45 -> g43 -> g49 -> g31 -> CLK_ENA.

It's about the "never interacts" thesis 😃

[msinger]

@ogamespec, did you automatically generate the HDL from this circuit diagram or vice versa? Or is it possible that there was a mistake made by hand? I mean, does it make sense to double check that the logic in the diagram matches the logic implemented in HDL?

[Rodrigodd]

"never interact"

I think I exagerated here. There is a path between OSC_STABLE and CLK_ENA, but when you trace the signals through all gates, it nevers changes the final result.

I confirm this a couple of times by tracing by hand, and I also convert the logic to SymPy (see logic.py in my PR), from which I derived the truth table I showed above.

[ogamespec]

@ogamespec, did you automatically generate the HDL from this circuit diagram or vice versa? Or is it possible that there was a mistake made by hand? I mean, does it make sense to double check that the logic in the diagram matches the logic implemented in HDL?

If to speak about Seq.v, there the most part is made automatically, a little bit corrected by hands (renaming of signals) (See https://github.com/emu-russia/dmgcpu/tree/main/netlist);
The rest part is also partly automatic, partly manual, I don't remember exactly, but I think decoders are made automatically and corrected by hands.

There is a path between OSC_ENA and CLK_ENA

I'm confused. The description of the Issue includes OSC_STABLE.

There can certainly be errors in HDL (any chip study is prone to this), my main concern was to reconstruct the topology and transistor circuits. HDL is just a "bonus". 😄

[Rodrigodd]

I'm confused. The description of the Issue includes OSC_STABLE.

Sorry, was a typo. I edit it to fix it.

[ogamespec]

Looks like I should make a sequencer in Logisim so you can poke around :) I'll be back later, see what I can do.

[ogamespec]

Started analyzing the sequencer in Logisim, so far it's going well:

The whole left part is occupied by 2 circuits: the beginning and the end of the interrupt sequence.

On the right side is a more confusing instruction clocking sequencer schematic, continued...

[Rodrigodd]

When I was investigating I generated the following schematic using yosys and https://github.com/nturley/netlistsvg. Here, in case it is useful:

I used yosys's connect -unset and optimization passes to only show the gates connected to CLK_ENA:

Details

yosys -p "\
read_verilog _GekkioNames.v SeqCells.v Seq.v; \
prep -top Sequencer; \
select Sequencer; \
connect -unset a; \
connect -unset OSC_ENA; \
connect -unset RD; \
connect -unset MREQ; \
connect -unset SeqOut_1; \
connect -unset SeqOut_2; \
connect -unset SeqOut_3; \
select -clear; \
prep -top Sequencer; \
write_json sequencer.json"

# prep -top Sequencer -flatten; \


netlistsvg sequencer.json -o sequencer.svg

[ogamespec]

Big picture from Logisim:

We have the same subcircuit for CLK_ENA, but I haven't figured out if that's good or bad yet.

I'll do some more tinkering and check the topology photos and the restored netlist for the SYNC_RESET and RESET signals. I take it you expect the circuit to behave differently?

EDIT: Oh lol read the title of the issue again 😄

[ogamespec]

hmmm... g49 is seq_rs_latch2. I may have incorrectly reconstructed the circuit logic of this gate.

[ogamespec]

I traced the RESET and SYNC_RESET signals again, there is no problem with them. They go where they need to go.
Most likely the nr and s inputs for cell g49 (module4_2) are just mixed up. I will check it now.

[msinger]

Here is the circuit outside of the CPU, which requires CLK_ENA to go high after OSC_STABLE:

The magenta circle encloses the relevant circuit and the smaller red circle marks the important part which is the reason for this "CLK_ENA after OSC_STABLE" constraint.
We have a latch TUBO to the left of the red circle. This latch gets reset to 0 at system reset (RESET) or when the crystal oscillator gets disabled (OSC_ENA=0), so it starts out at 0. It's ~Q output is 1 then. It goes into the AND-gate UNUT (the part that I have encircled red). The other input of this AND-gate comes from the DIV-register. The wire marked "16Hz" will get high after around 32 milliseconds after reset. So only when TUBO is reset and after these 32 milliseconds, UNUT's output can be high. UNUT outputting high will raise OSC_STABLE and it will deassert reset signals to most peripherals including the SYNC_RESET of the CPU.
If the CPU raises CLK_ENA before the 32 milliseconds have passed (which is signaled by a raising OSC_STABLE), then the ~Q output of TUBO will be low and UNUT is blocked from ever outputting high, therefore AFER will never release the SYNC_RESET.

Just wanted to put this out there so that the statement of "CLK_ENA has to go high after OSC_STABLE" is not just floating there in the air.