cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
1,611 Views
Registered: ‎01-05-2017

FSM Simulation Problem

Jump to solution

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 :)

DO_FSM_Test.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Explorer
Explorer
2,181 Views
Registered: ‎01-05-2017

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. 

 

View solution in original post

Tags (2)
0 Kudos
3 Replies
Highlighted
Teacher
Teacher
1,593 Views
Registered: ‎11-14-2011

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).

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Highlighted
Teacher
Teacher
1,568 Views
Registered: ‎11-14-2011

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?

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Highlighted
Explorer
Explorer
2,182 Views
Registered: ‎01-05-2017

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. 

 

View solution in original post

Tags (2)
0 Kudos