This looks like someone working on some homework.
Anyway....that's a Moore output. Why? It's only dependent on the fsm being in a particular state. In this case, sure it can be in one of two states, but still it's based only on the state of the fsm. The inputs don't come into the equation.
Now, a couple bits of constructive criticism:
assign y <= blah; // bad. Using non-blocking assignment with an assign statement. Don't do this. "IF" it simulates correctly, it may still give you issues at synthesis time.
Also, this is not the cleanest of ways to provide the output either. It will certainly work a lot of the time, but it is subject to generating a glitchy output during state transitions. So if the timing path starts hedging towards the critical edge of things, this could give you some headache. The better way to do it would be to generate the outputs directly from the fsm and as a registered output. An example of how I personally would code something like this:
(yes, I'm going to leave some stuff out and call this a code "snip-it", not the complete thing. Not to mention I've been coding in System Verilog for the past year which allows some terseness compared to Verilog)
reg y, next_y;
always @ (blah)
begin
next_y = y;
case (state)
A:begin
if (r)
begin
next_y = 1'b0;
next = D;
end
else
begin
next_y = 1'b1;
next = B;
end
end
<B looks pretty similar>
C: begin
if (r)
begin
next_y = 1'b1;
next = B;
end
else
begin
next_y = 1'b0;
next = D;
end
end
<rest of states, including default>
endcase
end
always @ (posedge clk or negedge reset)
begin
if (reset)
begin
state <= A;
y <= 1'b1;
end
else
begin
state <= next;
y <= next_y;
end
end
Notice that the big difference is y is its own flop. If you get in this habit of creating all registered outputs, your own life will be just that much easier in the long run, not to mention anyone designing a block that might be using your output will thank you.