UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer maxdz8
Observer
794 Views
Registered: ‎01-08-2018

Flexibility in next state FSM transition

Jump to solution

I'm having plenty of trouble fitting FPGA learning in 1h/day so I guess instead of trashing another week I can ask for a suggestion.

 

I have an algorithm mangling a 16x16 matrix. I need to build a palette of those which I need to keep around for quite a while. This palette however gets produced in various ways so I need a common 'copy from/to palette storage' function. How would you suggest to implement that? I want to make Vivado inference happy!

 

I would like to just have a next_fsm_state register. Then, copying to palette would just be a matter of setting it to the right next-state and then setting fsm state to next_fsm_state. I see a problem with this however, all examples I've seen happen to encode fsm next-state transitions to constants. Unless the synthesis is smart in understanding value assignments of next_fsm_state it would have no way to understand what the next state will be out of a 'copy to palette' state. Is that even a problem?

 

Option number 2.

 

Have two FSMs (in the same module!), let them be algorithm_fsm and copy_to_palette_fsm. This would allow me to separate/reuse the states. The copy to palette operation would then go in its own function (containing the fsm case) and it could be more easily reused. Is this a better idea?

 

Bonus question.

 

I am already reusing a state transition. The way I generate my matrices is like M = g(f(x)). It happens g and f are almost the same thing so to understand if I'm doing g or f I keep a bit and the next state is like:

// example of f~g, yes, they are really this similar
m[0] += 5;
m[1] += 2;
....
m[14] += fg_bit? (a + b) : (a - b);
m[15] += a << (fg_bit? 1 : 2);
fg_bit = ~fg_bit;
next_state = fg_bit? truly_go_next : do_another_fg;

Is that sensible?

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
1,012 Views
Registered: ‎07-21-2014

Re: Flexibility in next state FSM transition

Jump to solution

@maxdz8

 

If the FSM consist of a state register, next state function and an outputs function by keeping coding guidelines in mind, I believe Vivado Synthesis will be able to infer the FSM for you. It would be better if you can paste the RTL code with the results for us to understand the requirement in more details.

 

To me, the second option of having two separate FSM looks better approach but you can still try the first approach as Vivado should be able to infer the FSM.

 

Thanks

Anusheel

2 Replies
Moderator
Moderator
1,013 Views
Registered: ‎07-21-2014

Re: Flexibility in next state FSM transition

Jump to solution

@maxdz8

 

If the FSM consist of a state register, next state function and an outputs function by keeping coding guidelines in mind, I believe Vivado Synthesis will be able to infer the FSM for you. It would be better if you can paste the RTL code with the results for us to understand the requirement in more details.

 

To me, the second option of having two separate FSM looks better approach but you can still try the first approach as Vivado should be able to infer the FSM.

 

Thanks

Anusheel

Observer maxdz8
Observer
700 Views
Registered: ‎01-08-2018

Re: Flexibility in next state FSM transition

Jump to solution

Thank you this is still in very early prototyping stages. By better studying the algorithm I've decided to go with two hierarchical FSMs and replicate the copy operation manually for the time being.

0 Kudos