gmcpu8 issueshttps://cvs.sonologic.net/gmc/gmcpu8/-/issues2019-07-05T13:37:09Zhttps://cvs.sonologic.net/gmc/gmcpu8/-/issues/3Refactor cpu_tb.v2019-07-05T13:37:09ZKoen MartensRefactor cpu_tb.vIt is becoming unwieldy, very long and re-organizing is painful because of the asserts on the opcode addresses.
Split in multiple tb's? Dynamically track addresses instead of hardcoding them?It is becoming unwieldy, very long and re-organizing is painful because of the asserts on the opcode addresses.
Split in multiple tb's? Dynamically track addresses instead of hardcoding them?https://cvs.sonologic.net/gmc/gmcpu8/-/issues/2Optimize ip and sp arithmetic2019-06-26T12:03:43ZKoen MartensOptimize ip and sp arithmeticUse ALU? Or dedicated adder/subtractor? Experiment wrt synthesis resource usage. Currently it's a lot of add/subtract logic I suspect.Use ALU? Or dedicated adder/subtractor? Experiment wrt synthesis resource usage. Currently it's a lot of add/subtract logic I suspect.https://cvs.sonologic.net/gmc/gmcpu8/-/issues/1optimize memory cycles for push ip and multi-byte opcodes2019-06-26T12:01:47ZKoen Martensoptimize memory cycles for push ip and multi-byte opcodesCurrently there's an empty cycle in between writes (state `PUSH_IP_MSB_WAIT`) and reads (state `STATE_FETCH_OPCODE1_LATCH`) when ack_i is asserted. Should be possible to pipeline the reads and lose that wasted cycle.Currently there's an empty cycle in between writes (state `PUSH_IP_MSB_WAIT`) and reads (state `STATE_FETCH_OPCODE1_LATCH`) when ack_i is asserted. Should be possible to pipeline the reads and lose that wasted cycle.