17:00 <Forty-Bot> does anyone have suggestions on how to parametrize the number of states in a state machine?

17:01 <Forty-Bot> I am writing a module where some data is read in byte-by-byte, and I'd like to make the number of bytes parametric https://paste.debian.net/1274608/

17:01 <tpb> Title: debian Pastezone (at paste.debian.net)

17:01 <Forty-Bot> this is a stripped-down version for experimentation, in the real module there are a lot more states

17:02 <Forty-Bot> however, there is a difference in module size between the parametrized and non-parametrized versions

17:02 <Forty-Bot> I also tried using a counter, however this ended up taking even more resources https://paste.debian.net/1274609/

17:02 <tpb> Title: debian Pastezone (at paste.debian.net)

17:03 <Forty-Bot> I am using synth_ice40 for testing

17:19 <bl0x_> Forty-Bot: best to use a counter for the current byte and have the destination range depend on the value of the counter. The counter start value would be the parameters you pass in to the module.

17:19 <Forty-Bot> I tried that in the second link

17:20 <bl0x_> Ah, oops didn't read that far .. haha

17:20 <Forty-Bot> I would love to use that approach, but it takes more resources...

17:20 <bl0x_> Hm, what about a one hot counter?

17:21 <Forty-Bot> I think it's because yosys doesn't allow arithmetic to be part of state machines

17:21 <Forty-Bot> so any time you have something like `state_next = state - 1` or whatever, it disables the FSM optimization

17:21 <Forty-Bot> I'll try a 1-hot...

17:23 <bl0x_> What about generating code? Or does it need to be dynamic at run time?

17:24 <Forty-Bot> the rest of the project doesn't use code generation, so ideally I'd like to use parameters

17:25 <bl0x_> I meant to use a generate block. Not some external code generator

17:26 <Forty-Bot> 1-hot is better, but still not as good

17:27 <Forty-Bot> a generate block would be pretty awful because there are ~7-8 other (unparametrized) states

17:32 <bl0x_> Could you put in all states and then skip the unnecessary ones based on the parameter?

17:33 <Forty-Bot> yes, that's what happens in the first example when PARAM is set

17:35 <bl0x_> Ok.

17:36 <bl0x_> About the generate blocks: can't you generate only the additional states inside the fsm surrounded with 'generate if ... ' ?

17:36 <Forty-Bot> no

17:36 <Forty-Bot> generates are not allowed in always blocks

17:37 <Forty-Bot> definitely what I would have done given the choice

17:37 <bl0x_> Pretty sure that works in vhdl, no?

17:37 <Forty-Bot> no clue; I've only really used verilog

17:48 <tnt> I mean, this looks like this should be a shift register really ...

17:50 <Forty-Bot> tnt: for size 16 shift registers are larger

17:50 <Forty-Bot> but not by too much

17:50 <Forty-Bot> however, the parametrized version is still larger

17:52 <tnt> Forty-Bot: https://pastebin.com/1pW1ktQQ

17:52 <tpb> Title: module test #( parameter integer WIDTH = 32)( input clk, rst, - Pastebin.com (at pastebin.com)

17:53 <Forty-Bot> it's part of a larger state machine

17:53 <tnt> Well, we can't optimize something you doesn't give us ...

17:54 <Forty-Bot> so something like that isn't really what I had in mind... although that's a different way of approaching things

17:54 <tnt> but this should be implementable as a single state in it, just waiting for the last 'ena' to get out of that state.

17:54 <Forty-Bot> tnt: well, I wanted to start with something small which didn't have a lot of extra stuff in it

17:56 <Forty-Bot> tnt: https://github.com/Forty-Bot/ethernet/blob/WIP_axis/rtl/axis_wb_bridge.v

17:57 <Forty-Bot> right now the counter is constant 1, but I would like to also support different values based on DATA _WIDTH

20:13 <notafile[m]> nya!

20:13 <gatecat> mrow?