Processor stuck on the first instruction (logisim)

Discussion in 'Digital Circuit Design' started by JoLi, Apr 26, 2017.

  1. JoLi

    Thread Starter New Member

    Dec 5, 2016
    1
    0
    I have created a very simple processor in logisim that should be able to handle bitwise and, bitwise or, addition, subtraction, and also beq (branch if equals) instructions.

    It's basically finished, however, the main problem seems to be that PC doesn't change with the clock cycles, keeping the processor stuck on the first instruction.

    I've actually been ripping my hair for weeks about this, because even though I've found some very helpful guides on how to put together the data path, I have been unable to find the source of the problem. To me it looks like I'm doing it the same way.

    For example:

    https://www.youtube.com/watch?v=Ngu1UbRAeqQ

    and

    https://www.cise.ufl.edu/~mssz/CompOrg/CDA-proc.html




    Here is an image of the data path:
    (I wasn't able to open this, so in case it doesnt work for you either I have also incuded it in the folder below)

    datapath.png



    _________________________________________________________________________________________________________________


    Here is a jumpshare folder with the full file including all components in case you would like to open it (also contains the image of the datapath and test.asm):

    http://jmp.sh/9yAiccw


    __________________________________________________________________________________________________________________

    Just in case here is the little mips code I'm using to test the processor:

    .text
    addi $a0,$0,4 # set $a0 to 4
    addi $v0,$a0,2 # test addi, set $v0
    add $v0,$v0,$a0 # start of counter. Should be 10
    loop:
    beq $v0,$a0,done # test, jump to done.
    addi $v0,$v0,-3 # decrement. Loops twice.
    beq $0,$0,loop # emulating an unconditional jump
    done:
    add $0,$0,$0 # NOP
     
  2. WBahn

    Moderator

    Mar 31, 2012
    24,454
    7,653
    Your biggest problem is probably that you threw everything together without testing any of the pieces parts first. As a result, if it doesn't work you are left trying to track down a needle in a haystack.

    In your screen capture, is a green trace mean that it is a logic HI? If so, which input to the MUX is being used to calculate the next value of the program counter?

    What are these Sel blocks? I realize that Sel is probably the name of the side input, but there's no indicate what these blocks perform -- are they selectively inverting all of the bits?

    You might take a big step back and verify that your program counter actually counts. Strip out everything except those components needed to advance the program counter one instruction on each clock cycle. Then, and ONLY then, see if you can branch to a fixed program address using the left-most MUX. Hard code the BRANCH control signal in your simulation. Then test your Branch To Address block to see if it performs the offset calculation that it should. Then integrate it into the branch logic.
     
Loading...