Monday, April 28, 2008

synthesizable Verilog from behavioral constructs - 3

To modify a behavioural Verilog fork and join statement to make it synthesizable.


Behavioural:

command1;
fork
// start of fork block 1
begin
wait (y != 0);
a = y;
end

// start of fork block 2
begin
wait (z != 0);
b = z;
end
join
command2;

command2 will execute only after fork blocks 1 and 2 have finished.

Synthesizable:

case (state)
0 : begin
command1;
done_fork_block_1 = 0;
done_fork_block_2 = 0;

if (y != 0)
begin
a = y;
done_fork_block_1 = 1;
end

if (z != 0)
begin
b = z;
done_fork_block_2 = 1;
end

if (done_fork_block_1 & done_fork_block_2) command2;
else state <= 1; end 1 : begin if ((y != 0) && !done_fork_block_1) begin a = y; done_fork_block_1 = 1; end if ((z != 0) && !done_fork_block_2) begin b = z; done_fork_block_2 = 1; end if (done_fork_block_1 & done_fork_block_2) command2; // else state <= 1; end endcase In some special cases, it may not be necessary to have done signals, but in general the blocks of commands being executed in parallel by fork may finish at different times. Again, if a cycle delay between command1 and the other commands executing is acceptable, then this code is simpler: case (state) 0 : begin command1; done_fork_block_1 = 0; done_fork_block_2 = 0; state <= 1; end 1 : begin if ((y != 0) && !done_fork_block_1) begin a = y; done_fork_block_1 = 1; end if ((z != 0) && !done_fork_block_2) begin b = z; done_fork_block_2 = 1; end if (done_fork_block_1 & done_fork_block_2) command2; // else state <= 1; end endcase As y or z may have different values after a clock cycle passes, care needs to be taken in choosing the simpler alternative, that doesn't exactly implement the behavioural code. Note: in general commandi refers to a block of commands. It is assumed there is an appropriate clock for the case statement state machines. Care is required in setting appropriate reset states, initialization, and completion of use of a state machine: * Is there a signal to tell the state machine to begin? * Does a done signal go high, signalling the state machine has finished? * When it is not in operation, does the state machine idle correctly? Does it change signal values shared with other code? Does it set outputs from it to appropriate idling values? * Is the state machine reset to the idle state by a reset signal? * Ensure that you initialize all registers. * Ensure that your state register has the correct bit width - if it is too small, assigning a larger state value will just return it to an earlier state.

No comments:

Archive