How to build reasonable signal sequence

[kudo1017]

As a newbie in this industry, im now very eager to learn about proficient skills of signal sequence building.
As I was checking about those codes inherented in the database, I find those styles are so different from what I've learnt in the universities.
I wonder if there's any book or well-known paper writing regarding of this?
I just perceived of this concept (signal building)

How do u guys usually do after u've got a new module design task?

Normally we are expecting to receive a pinlist, a functional description, port sequence protocols, delay requirements, and maybe algorithm in C and so on.
How do we start our work to make it more efficient? like how to predefine the inner register list from signal sequence building consideration? how to trace the state shifting to make sure both required signals not to mismatch each other cause of wrong delay estimation? I was getting frustrating lately because of this. I thought I have perfectly planned everything, however it failed by last cause 1 clk period delay mismatch in the datapath and control path.

I've been very admired of a newly learnt coding style, that is to rip all combinational logics off FSM and finish it's building work with all logical descriptions. I really wanna master this style but I find out I always make mistakes. Here's an example:

//conbinational logic that ripped off from FSM
always@(*) begin
nxt_state=0;
case(state)
0: begin
if(a) nxt_state=1;
else if(b) nxt_state=2;
else nxt_state=0;
end
1: nxt_state=2;
2: nxt_state=0;
endcase
end

//FSM
always@(posedge clk or negedge rst_n) begin
if(rst_n) state<=0;
else state<=nxt_state;
end

Is anyone here in favour of this style? This one is simple, but while I was designing a core to bus bridge, I always have to patch my original idea again and again to really make it work. And this, for me, must be wrong with the way I work. I need some suggestions.

How did u guys improve urself at the beginning when u started ur career in digital IC design?

 

[FvM]

It's standard FSM style, replicated in various designs a million times. There are some possible variations, but they don't differ regarding basic synchronous logic behaviour.

If you have problems in this relation, e.g. said delay differences, it's a matter of managing the principles of synchronous design, not particularly FSM related.

According to my experience, a pencil-and-paper timing diagram can help to visualize the design behaviour and add pipeline stages to correct it if necessary. Then use simulation to validate it.

 

[kudo1017]

It's standard FSM style, replicated in various designs a million times. There are some possible variations, but they don't differ regarding basic synchronous logic behaviour.

If you have problems in this relation, e.g. said delay differences, it's a matter of managing the principles of synchronous design, not particularly FSM related.

According to my experience, a pencil-and-paper timing diagram can help to visualize the design behaviour and add pipeline stages to correct it if necessary. Then use simulation to validate it.

Thank you so much for your penning design suggestion, I will give a go and feedback about it here.
But still I don't think this style is alleged 'standard FSM style', cause what I learnt in school lectures is to include all state-shifting-conditions into the FSM, the most significant difference to this example is the extinction of the wire 'nxt_state', please notice that all combinational logics along with nxt_state has been ripped off the FSM, the whole FSM is just the second always block, that is the statement.

state <= nxt_state;

alas, im not saying that such difference will make change to the circuit schematic, otherwise it will be referred as a 'new structure' instead of 'new style' to me.

 

[FvM]

Writing the FSM in one or two always block doesn't necessarily change anything to the logic behaviour and respective synthesized gate level logic. It's just a matter of preference.

Most text books are showing separated combinational and registered always blocks (or VHDL processes). But personally I prefer combining both into a single block/process for better readability.

Both styles have possible trapdoors, e.g. separate combinational blocks can create unintended latches for regs that aren't driven in all case branches.

 

[kudo1017]

Writing the FSM in one or two always block doesn't necessarily change anything to the logic behaviour and respective synthesized gate level logic. It's just a matter of preference.

Most text books are showing separated combinational and registered always blocks (or VHDL processes). But personally I prefer combining both into a single block/process for better readability.

Both styles have possible trapdoors, e.g. separate combinational blocks can create unintended latches for regs that aren't driven in all case branches.

now I get your point, thank you.