Verilog and break statements is there a possible alternative?
Verilog is a HDL, not a procedural language. It is not in any way a derivation of C, it just has a vaguely similar syntax, but then so does Java.

Hardware description languages are just that, they are used to describe hardware - what logic circuit, registers, RAMs, etc - if-else statements for example represent multiplexers in digital logic. This is completely different from a procedural language where lines of code are executed on a CPU in turn where you can jump from one bit of code to another (break, goto, if-else).

"Break" statements don't make sense in HDL, because there is nothing to break out from - how would you jump out of a flip-flop? Unless you are meaning 'break' as in asking the FPGA to catch fire or something (which would definitely break it!).

I get the impression you are used to programming in a procedural language and are new to HDL. I would suggest that you go and research/learn the implications of a HDL - there are many tutorials out there e.g. Google "Verilog in one day". You need to understand that the code is not executed, but rather infers logic gates and flip flops (amongst other things). Understanding how HDL is synthesized to an RTL circuit is very important to being able to program with HDL languages.



For a case statement, you don't need a break statement, you would simply do:

case (something)
    value: begin
        //do something while "something==value"
    end
    othervalue: begin
        //do something while "something==othervalue"
    end
    default: begin
        //do something while "something" is none of the above
    end
endcase




Furthermore, your code doesn't make any sense - nor do some of your comments.

always @ (button) //start of the action section


That basically says implement the following block as combinational logic where the only input is a signal named "button". Yet you have lots of other inputs, so it makes no sense.

Now if you had:

always @ (posedge button)


it would infer a flip-flop whose clock is the "button" signal. The hardware inferred by the case statement would be triggered on the rising edge of the button signal. In reality this would be some combinational logic (which would always be being calculated as its a set of lookup tables), the output of which is latched on to one or more flip flops at the rising edge of the button signal



This is yet another example of an X-Y problem - you are telling us what you think the solution is (Y) rather than telling us what you are actually trying to do (X).