Code reuse is a practice that is followed in order to reduce time, effort, and cost by eliminating redundant effort. In the case of an electronic development project, time-to-market will have large impact on the success of the ensuing product.
There are a number of important factors that must be considered while implementing reusable code, including readability, simplicity, portability, and re-configurability. When creating RTL (register transfer level) representations with reuse in mind, it is necessary to consider the complexity, re-configurability, and synthesizability of the code so as to achieve latch-free design. This blog contains some simple examples that will help to make reusable RTL code by utilizing standard Verilog features.
The objective of this exercise is to provide basic knowledge about writing re-usable RTL code using a multiplexer (MUX) design as a reference. Also, to explore the concept of a "Configurable MUX" and to analyze how this can provide an efficient alternate to a conventional MUX in real-time configurable designs/environments. It is assumed that the reader has a working knowledge of the Verilog hardware description language (HDL).
Conventional MUX
A multiplexer -- commonly known as MUX -- is a digital block that allows the value of the selected data input to pass through and be presented on the output. A pictorial representation of a 4:1 MUX is shown below:
In this case, the "select" input would actually be a 2-bit binary value, with possible values of 00, 01, 10, and 11, as shown below:
The two conventional methods for coding the MUX are to use a "CASE" statement or an "IF-ELSE" statement as shown below (note that I have skipped the associated port declaration so as to keep things simple):
The problem with conventional implementations is that everything is fixed. In order to make our multiplexer easily reusable in other designs, every aspect of it should be parameterized. The simplest things to parameterize are the widths of the data inputs and outputs.
Also, we would like to parameterize the number of data inputs, but this is where things start to become a little tricky, because if we double the number of data inputs from 4 (in our example) to 8, then we will have to increase the number of select bits from 2 to 3. But look at the "CASE" and "IF-ELSE" statements above -- if we modify the number of select bits, then we are going to be forced to edit the number of selections within these statements.
In my next column, I will show an example of how to address this problem, but it would be great if you were to start pondering some possible solutions for yourself. (If you already know the answer, please don't give the game away just yet.) In the meantime, can you tell me if you typically re-code everything from scratch for each new project, or do you try to create reusable code wherever possible?
Tweet This
