New Contributor
Contributor
@Scarlet wrote:Here, the Tick_FPGA signal suddenly goes low.
According to the FSM's LEDs I set for each state, it has jump to an illegal state.
It's always good to add a default state to prevent (and more importantly recover from) these as much as possible. In your case statement, just try adding a state such as:
default: state <= IDLE; // and maybe re-set the LEDs
And with different clock domains considered, it might help to widen the data_valid pulse, I can see that it is one clock period wide in the current implementation. Not sure if that's sth you can adjust tho
New Contributor
@anonimcs wrote:It's always good to add a default state to prevent (and more importantly recover from) these as much as possible. In your case statement, just try adding a state such as:
default: state <= IDLE; // and maybe re-set the LEDs
I tried adding a default state, but it didn't seem to make much difference, so I decided not to include it later.
@anonimcs wrote:And with different clock domains considered, it might help to widen the data_valid pulse, I can see that it is one clock period wide in the current implementation. Not sure if that's sth you can adjust tho
It can be adjusted. Initially, the data_valid pulse was only sent after the data was confirmed.
To avoid having a data_valid pulse that was too narrow, some changes were made.
Currently, the local FPGA sets data_valid to 0 upon receiving the Tick_FPGA signal, and it returns to 1 only after the data transmission is complete, like this:
