I tried to implement a 32x32 bit register file using Logisim, however once I have finished drawing and proceeded to test it by initializing the content of individuals registers to zero using the reset input, only some of them have reset, others have generated an error.

To clarify I have implemented all the sub-circuits used myself and have tested them individually and they work as required.

So, this is the register file and as you can see some outputs are red:

Register file design

Each register is implemented in a sub-circuit composed of 32 flip flops D (as in the image shown here). The supercircuit error is actually caused by errors in one (or more) of the flip flops that make up the register

Register design

Going even deeper, analyzing the flip flops that give errors and the relative latches that compose them, the result is the following: (Note that the clock is enabled although not visible in the screenshots as I am debugging)

Flip Flop D

Latch D

Bistable SR sync

Bistable SR async

I can't explain why some registers and their sub-circuits work correctly while others give this kind of error. I don't think the error is related to my implementation but I'm not sure if the error depends on Logisim itself (I know it has several bugs and issues).

Any additional information or help is welcome as I personally have not found anything about it by searching the web.

  • \$\begingroup\$ Don't know what all these colors denote, but why is the last NOR gate's ~Q output 0 when both inputs are 0? Are blue and green separated in time? \$\endgroup\$
    – td127
    Dec 5, 2020 at 20:29
  • \$\begingroup\$ @td127 about colors: green (light/dark) denote 1 or 0 on the wire, blue means idle state as if the simulation is not enabled and red denote that the state cannot be defined. The fact that ~Q is equal to 0 is exactly the problem and blue and green are supposed to be in the same time \$\endgroup\$ Dec 6, 2020 at 10:29

1 Answer 1


Allora, the one suspicious element I see are the two D flops in series that implement your FF compoent. As you stated, these are actually latches. (The “>” symbol on the inputs is misleading – that denotes an edge-sensitive clock. Should probably use “G” to denote a gated latch.) So with the two D latches there is a race condition: rising CLK causes 1st Q to change, but also causes falling clk (gate) to 2nd latch, which latches output. So 2nd latch’s D and G are changing at essentially the same time. Non si fa cosi.

If the simulation is using post-layout timing, then it could be that only some paths fail because their internal routing delays resulted in setup/hold violations at the second latch.

enter image description here

  • \$\begingroup\$ Ok grazie, for the answer. I understand what you are saying but I'd like to ask you a little more... Why has it this behavior only with some of them? And I also tried to implement the registers using the D latch and it still gives error on some of the bits \$\endgroup\$ Dec 6, 2020 at 21:33
  • \$\begingroup\$ If this simulation is not mapped to hardware then I can’t explain why only certain bits would fail (simulator bug?) But if the simulation is for the post placed-and-routed design, then every path will be slightly different, and the only bits that will fail are the ones where by (bad) luck the delays on the paths are such that the 2nd latch’s D is changing at the same time as its G falls. And I don’t understand “tried to implement using a D latch”.. You already have a D latch. Can you try using two edge-sensitive flops instead? There should be no race condition then. \$\endgroup\$
    – td127
    Dec 6, 2020 at 22:03
  • \$\begingroup\$ with D latch I mean implement the register using D latches. And about two edge-sensitive FF I'll try them. Thank you again for your answer \$\endgroup\$ Dec 7, 2020 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.