10-24-2017 12:57 AM - edited 10-24-2017 12:58 AM
Hello
I'm trying to learn vhdl simulation and trying to solve a problem regarding to my design but after working almost two days cannot see the point I'm missing. Could anyone have a look at and point me to the mistake ?
This is a Finite State Machine simulation to transmit some data after reading 17 byte ram (1 byte for sync + 16 byte data).
There are two controller "flag" to start the process and repeat itself until all data transmitted.
First thing: repeating process look behaving independently than "Link_Info" if clause,
Second: There is a 0 after each data and the first data 127 is sent two times?? How is this possible and where al these o are coming from??
Period_Over_Flag: Start the process (time to transmit data flag)
Link_Info: controlls the line busy/idle if idle send the next byte!
Best regards and thanks in advance :)
10-25-2017 09:01 AM - edited 10-25-2017 09:46 AM
Dear @hgleamon1
Thank you for your answer. Line 66 doesn't hurt anything but useless. It only updates "s_Link_Status_Flag" and gives the correct value. So I have the correct info when I need it below. But anyway line 46 was removed.
Solution came from line 100, s_Data_Part <= X"00";
What a pity I didn't clearly understand the effect but when I remove this line I got the correct bytes after each "Link Idle" info (attached).
The only issue left I couldn't transmit the last byte.
Best wishes.
Edit: When I add one more byte to the end of RAM block this is solved as well.
10-24-2017 01:39 AM - edited 10-24-2017 04:49 AM
The Data_Part = 0 comes from the fact that you have a rising edge detector in your code for Link_Info. In your state machine, in the TRANSMISSION state, you look for the effective rising edge (s_Link_Status_Flag = '1') but, as this is a rising edge detector, it is only true for a single clock edge. If s_Link_Status_Flag = '0' then s_Data_Part <= X"00", as per your own code.
I haven't looked deeper yet but perhaps the 127 data repeating is a function of the clock delay for outputs from BRAMs. I'm still checking.
EDIT: It would be a lot easier to visually debug if the signal s_Link_Status_Flag was shown in the simulation. I think you need to look at what clock edges signals are becoming active in the way you want them. i.e. I think you are seeing a delay in the addr assignment due to the pipelining of the Link_Info signal. I can't be sure because I can't see the signal in your simulation (and I haven't simulated your design myself).
10-24-2017 04:58 AM
OK, I'm warming up to this now. I simulated it anyway.
You should definitely look at lines 46 and 66 in your DO_fsm.vhd file. Do you notice anything?
10-25-2017 09:01 AM - edited 10-25-2017 09:46 AM
Dear @hgleamon1
Thank you for your answer. Line 66 doesn't hurt anything but useless. It only updates "s_Link_Status_Flag" and gives the correct value. So I have the correct info when I need it below. But anyway line 46 was removed.
Solution came from line 100, s_Data_Part <= X"00";
What a pity I didn't clearly understand the effect but when I remove this line I got the correct bytes after each "Link Idle" info (attached).
The only issue left I couldn't transmit the last byte.
Best wishes.
Edit: When I add one more byte to the end of RAM block this is solved as well.