adder_with_flow_control design contains an adder with a separate flow control for each argument and the result.
The design is an answer to an RTL job interview question described by Yuri Panchul in an article (in Russian) on Habr website. The design is used as a part of systemverilog-homework and basics-graphics-music GitHub repositories. These repos are maintained by engineers and educators associated with the Verilog Meetup community.
In this solution to the interview question, the flow control is implemented using one of the following pipeline register/buffer modules. The choice is specified inside the adder_with_flow_control.sv module using the define macro FLOW_CONTROL_BUFFER.
More details about the modules:
This module is a general-purpose flow-controlled register which allows full back-to-back performance but has a combinational path between down_rdy and up_rdy which can introduce timing problems in deep pipelines.
This flow-controlled register has no combinational path at all, but cannot sustain a back-to-back stream of data. However, it requires fewer gates than fcb_4_wrapped_2_deep_fifo or fcb_5_double_buffer_from_dally_harting.
This flow-controlled register is suitable if the designer wants to always stall the whole pipeline at once, without parts of it making progress.
The most high-bandwidth flow-controlled buffer among those that have no combinational path between down_rdy and up_rdy. However this solution occupies the largest area.
This pipeline buffer is Yuri Panchul's edition of the code derived from Digital Design: A Systems Approach by William James Dally and R. Curtis Harting. 2012. It has high bandwidth and no combinational path between down_rdy and up_rdy, but not the highest possible bandwidth for this adder_with_flow_control design.
A self-checking testbench for the design is located in a directory test_extra that contains:
clean.bash - a script to delete temporary files produced by simulate.bash.
simulate.bash - a script that simulates the design together with a testbench using Icarus Verilog and produces a log log.txt.
tb.sv - a self-checking testbench that generates a log, a status PASS or FAIL, and performance data.
After the manufacturing, the design can be manually tested in the same way it is tested in the testbench. It is important to cover the following scenarios:
Buttons and LEDs
# | Input | Output | Bidirectional |
---|---|---|---|
0 | a_vld | a_rdy | a_data[0] |
1 | b_vld | b_rdy | a_data[1] |
2 | sum_rdy | sum_vld | a_data[2] |
3 | sum_data[0] | a_data[3] | |
4 | sum_data[1] | b_data[0] | |
5 | sum_data[2] | b_data[1] | |
6 | sum_data[3] | b_data[2] | |
7 | sum_data[4] | b_data[3] |