Although I am familiar with both Verilog and VHDL, VHDL is the language of choice in all of EyeLytics development projects. Both languages have their pros and cons but it is the reason of design reusability which makes me pick VHDL.

As project is getting bigger and bigger, design reusability is getting more and more important. It is even more important when multiple projects exist within a company. Able to reuse existing IP saves time and resources. It happens often that a similar circuit is needed by different projects or different parts of a project. Unfortunately, similarity does not mean identical. Do not let the slight differences between modules stopping designers from reusing existing IP. Modifying existing IP to match the new use is the preferred way to satisfy the new requirement. The modification needs to be done in such a way that the operations of existing applications using the IP are not disturbed.

As an example, an existing gray code counter IP supports counting up. A new project requiring a counter that can count both up and down is now in development. Instead of designing a new counter, one can modify the existing IP. In the Verilog world, designers will most likely save the two counters as two different files. This means two different IPs will be maintained from this point on. Another method is to throw away the old counter but this requires doing a search in the design database to see which designs use the existing IP and modify all the designs to use the new one instead. This is sometimes impractical when the design database is big or when part of the design is already 'released.' And of course, modifications increase chances of introducing bugs. In the VHDL world, an up_down signal is simply added and defaulted to one (or up). Since the up_down signal has a default value, all old applications still work even the signal is not connected. Yes, this means there is only one single IP to maintain.

There is actually a way to use a single Verilog module to support multiple designs. It is to use define and undef. Unfortunately, too much defines and undefines makes the code very unreadable. A lot of Verilog experts recommend limited use of defines and undefines.

As an IP provider, EyeLytics has to exhaust all the tools to make designs very reusable. This allows EyeLytics to maintain high quality IP for our customers. When a bug is found, all customers will be benefited. As a result, VHDL is used. EyeLytics H264 Encoder IP core is one good example. The core supports different options including I Frame Only option and QPEL disable option. It also allows optional connection of Quantization Table. All these features are supported using a single code base. None of these is possible if Verilog were the design language used.

I will conclude this article with the VHDL code of the GrayCodeCounter and to show how design reusability is made possible.

-- Original Application
-- Works with both old IP code and new IP code
U1: entity work.GrayCodeCounter
generic map(
WIDTH => 8
)
port map(
Clk => Clk,
Count => Count
);

-- original gray code counter IP
entity GrayCodeCounter is
generic(
WIDTH : natural := 8
);
port(
Clk : std_logic;
Count : std_logic_vector(WIDTH-1 downto 0)
);

-- new gray code counter IP
-- notice that the old application still works without any modification
entity GrayCodeCounter is
generic(
WIDTH : natural := 8
);
port(
Clk : std_logic;
Up_Down: std_logic := '1'; -- this signal is added but old app still works
Count : std_logic_vector(WIDTH-1 downto 0)
);