Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Digital Logic Sim

​A minimalistic digital logic simulator · By Sebastian Lague

Did anyone tried to make a counter in this version?

A topic by chandlerkc created 9 days ago Views: 399 Replies: 14
Viewing posts 1 to 14

I was struggling to make a simple 2-bit counter, I found a very useful implementation using JKFFs but here it didn't work, same thing with DFFs.
An edge detector is sufficient for me to implement that, thanks in advance!

(1 edit)

I came across this when I was trying to make a double-NOR-style JK Flip Flops and couldn't get it to work. I pivoted to a OR-NOT-AND-style JK Flip Flop do, but it didn't work until I used a Master-Slave JK Flip Flop instead of a bare JK Flip-Flop because of the race condition.



Here's my MSJK flip-flop if you want to try that.

Thanks I will try that!
I did mine this way: but it does not flip when J and K are 1

thank you very much, that worked!

for further elucidation: that style chip has a race condition (which I think is made "worse" by the simulation)  - see here: 

the solution in meatspace is in the next video, too.

(+1)

I was struggling to make wider counters that way so I made it with double buffer implementation:

(+1)

(1 edit)

yep! i made a counter for 1 byte, but its kind of fast...

so i improved it!


its the same thing in itself through some registers, and its controlled by a clock (top adder, output "8"). much faster than the one we were given.

edit1: the clock we were given*

So, mattzoglman, Rob Mayer and myself have noticed that there is an issue with chaining counters in this version.


We've tracked it down to a single-tick discrepancy in the time it takes for any NOR based, NAND based, or AND/NOT/OR based SR-latches to set and reset.


It's taking those latches one tick longer to set than it's taking them to reset, and in my case this caused issues where the zero-check I perform in my counter to trigger the carry signal would give false positives every time the next-most significant bit was turned on, as all the less significant bits would turn off a single tick earlier, causing the wires to read a zero for a split-second.

Thankfully, with some help from KatIsBackKathTorio on discord, Rob identified a workaround; Use RS latches instead of SR latches for your registers.


Hopefully this helps!

(RobMayer here) I spoke too soon in that github issue - I was wrong about the RS vs SR latches, sort of.

there's some nuance to it regarding both latch set/reset time asymmetry as well as race conditions brought on by simulation propagation. Some level of intersection of those two things is the source of counter-releated heartburn.

my full analysis is in this github issue (https://github.com/SebLague/Digital-Logic-Sim/issues/326) but the test results of latch set/reset asymmetry are detailed here specifically (https://github.com/SebLague/Digital-Logic-Sim/issues/326#issuecomment-2814708390)  and some details about pre-latch and post-latch state race conditions here (https://github.com/SebLague/Digital-Logic-Sim/issues/326#issuecomment-2813148144)

Here is a design using Flip-Flops:Flip-Flop (FF):

To add to the growing pile of people's suggestions, I have also made a full 8-bit counter

Here is the JKFFs

64-Bit counter: (please excuse my very sloppy wiring)