I'm working on a Async Bi-Directional Counter
The one-bit version works perfectly as expected, without fail. I've tested it thoroughly.
something about linking multiple of them up and cascading their inputs causes the simulation to go wafty and generate high outputs that can't be explained.
project can be found here: https://github.com/RobMayer/trh-dls-chips/tree/simbug
the only alterations I've done to the JSON directly were to change chip colors based on category (the script I wrote to do that is in the project, it makes no other alterations)
you''ll find two relevant chips both of which are starred: wip3 and wip3-2
one version uses a toggle-latch, the other uses a more simplified two-stage D-latch.
despite it's erratic nature, I was able to capture a few screenshots of an instance of it going wafty. it does not manifest like this exactly every time, but in a similar way:
Red is Output, Green is Borrow, Blue is Carry
initial state is thus
the Intent is that when I hit the "INC" input, it'll count upwards one step, and yet:
you'll see that after clicking INC once, the Blue Carry wire is on, as expected, but Q3 and Q4 activated despite their respective inputs never being triggered.
In another variant (wip3-2), where I'm using an 2-stage toggle flip-flop instead of a pair of D-Latches, I get the similar issues.
I've also tried a variation where I explicitly clear all the 1b counters before I start clicking INC and DEC - it still occurs.
I have also tested this where I bind the INC to a key, and view-in on a counter chip that shouldn't be changing state yet is, the relevant INC for that chip never gets activated, but the internal state of the chip changes anyways.
I've also tried both increasing and decreasing both my steps per tick and steps per second by an order of magnitude each.
I don't know how the innards work, and this is just going by gut , but it feels like some kind of stale state in packaged chips?
I'm working on a Async Bi-Directional Counter
The one-bit version works perfectly as expected, without fail. I've tested it thoroughly.
something about linking multiple of them up and cascading their inputs causes the simulation to go wafty and generate high outputs that can't be explained.
project can be found here: https://github.com/RobMayer/trh-dls-chips/tree/simbug
the only alterations I've done to the JSON directly were to change chip colors based on category (the script I wrote to do that is in the project, it makes no other alterations)
you''ll find two relevant chips both of which are starred: wip3 and wip3-2
one version uses a toggle-latch, the other uses a more simplified two-stage D-latch.
despite it's erratic nature, I was able to capture a few screenshots of an instance of it going wafty. it does not manifest like this exactly every time, but in a similar way:
Red is Output, Green is Borrow, Blue is Carry
initial state is thus
the Intent is that when I hit the "INC" input, it'll count upwards one step, and yet:
you'll see that after clicking INC once, the Blue Carry wire is on, as expected, but Q3 and Q4 activated despite their respective inputs never being triggered.
In another variant (wip3-2), where I'm using an 2-stage toggle flip-flop instead of a pair of D-Latches, I get the similar issues.
I've also tried a variation where I explicitly clear all the 1b counters before I start clicking INC and DEC - it still occurs.
I have also tested this where I bind the INC to a key, and view-in on a counter chip that shouldn't be changing state yet is, the relevant INC for that chip never gets activated, but the internal state of the chip changes anyways.
I've also tried both increasing and decreasing both my steps per tick and steps per second by an order of magnitude each.
I don't know how the innards work, and this is just going by gut , but it feels like some kind of stale state in packaged chips?