Verilog RTL II – Reuse
Parameterization, FSM, memories, FIFO, arbiter, interrupts
What you will learn and practise
Complete the stages in order and retain the requested evidence.
parameter/localparam
Functions and tasks
generate-for / generate-if
Hierarchical reusable RTL
Compile-time configuration
1. Parameterized adder/MUX/comparator
2. Parameterized register/counter
3. Arithmetic/parity functions
4. Stimulus task
5. Generate register bank
6. Generate adder array
7. Conditional generate
8. Multi-channel configurable design
9. WIDTH 8/16/32 reuse challenge
10. Parameter override at instantiation
Fix bad parameter widths and generate conditions
Create reusable RTL package folder
Reusable parameterized RTL set
Create reusable configurable RTL using parameters, localparams, functions, tasks and generate constructs.
- Create project_workspace/week3_verilog_rtl2/day11_reuse with rtl, tb, sim and logs directories.
- Use Icarus Verilog for compile/simulation and GTKWave when waveform evidence is useful.
- Keep WIDTH configurations 8, 16 and 32 available for reuse testing.
- Implement parameterized adder, MUX and comparator blocks.
- Implement parameterized register and counter blocks.
- Create arithmetic/parity functions and a reusable stimulus task.
- Build a generated register bank.
- Build a generated adder array and conditional-generate example.
- Create one configurable multi-channel design.
- Override parameters at instantiation and test WIDTH 8/16/32.
- Differentiate parameter and localparam.
- Explain elaboration-time generate-for and generate-if.
- State when a function is preferable to duplicated combinational expressions.
- Explain the role of tasks in reusable simulation stimulus.
- Describe two width-related defects that can break reusable RTL.
Repair bad parameter widths and incorrect generate conditions, then document why each failure occurred.
- Reusable RTL source
- testbench
- 8/16/32 simulation results
- debug notes
- written answers
- All configured widths compile
- Required configurations simulate correctly
- No hard-coded width dependency remains in the reusable blocks
Build, run and retain evidence
project_workspace/week3_verilog_rtl2/day11_reuse/
Review before completing Day 11
- Concept
What is the practical difference between parameter and localparam in reusable RTL?
Review answer
A parameter is intended to be overridden when a module is configured or instantiated; a localparam is an internal constant that cannot be overridden from outside the module.
- RTL reasoning
A module has parameter WIDTH=8 but an internal temporary is declared [7:0]. What can happen when WIDTH is overridden to 16?
Review answer
The fixed 8-bit temporary can truncate or corrupt 16-bit values. Internal widths that depend on configuration should normally be derived from WIDTH or another appropriate parameter/localparam.
- Debugging
Why is using a runtime input signal as the condition of generate-if incorrect?
Review answer
Generate constructs are elaboration-time structural choices and require constant expressions. Runtime behavior must be implemented with normal RTL logic rather than generate-if.
- Short answer
Why should a reusable block be tested at WIDTH 8, 16 and 32 rather than only at its default width?
Review answer
Multiple configurations expose hidden hard-coded slices, width mismatches, truncation and loop-bound assumptions that may not appear at the default width.
Assessment: