Hardware description languages (HDLs) are a category of programming languages that target digital hardware design. These languages provides special features to design sequential logic( the system evolve over time represented by a clock) or combinational logic (the system output is a direct function of its input). While these language have proved to be efficient to design hardware, they often lack the tool support (editors are far behind what you can get to edit C/java/etc) and the syntax can be hard to master. More-over, these language can generate sub-optimal, faulty hardware which can be very difficult to debug.
Over the past-year some alternative languages have arisen to address the main issues of the more popular HDLs (VHDL/Verilog). These new languages can be classified into two categories as follows.
Categories of Hardware description Languages (HDLs)
- HLS (High Level Synthesis) : HLS tools, try to take an existing programming language as an input and generate the corresponding HDL (hardware description language).. Some of these tools are quite popular in the EDA industry such as CatapultC from Mentor Graphics, Matlab HDL coder, but are very expensive. Xilinx recently integrated the support of SystemC and C in their Vivado toolchain but it only supports high-end FPGA.
- Alternative syntax : Some tools propose an alternative syntax to VHDL or Verilog. The alternative syntax approach keeps the control of the generated hardware, but gives the advantage of an easier to master syntax and sometimes of ease of debugging.
While the HLS seems attractive. there is a good chance it will generate sub-optimal hardware if the designer does not write the “software” with hardware in mind. The approach is a bit magical as you can take existing C/Matlab software and generate hardware in a few clicks.
HLS is very practical to reduce time to first prototype (especially with Matlab) and for people with little (or no) HDL knowledge to produce a functional hardware design. However, HLS tools are not good for the users who want to learn digital design and the good HLS tools are usually very expensive (a CatapultC license can cost more than 100k$ [link], and Matlab HDL coder starts at 10k$ [link]).
Over the past year some open-source, free to use alternatives to HDL have emerged. These tools do not pretend to create hardware from behavioral description, but propose to smoothen the learning curve for digital logic design by relying on easier to master syntax and feature rich tools.
In the following we will review two of these alternatives languages (myHDL, PSHDL). To test the languages, we will use them to design and debug a simple PWM module. We chose these two languages based on their distinct properties and community adoption but other tools such as MiGen (python based syntax) which will not be covered here, but use the same kind of design flow.
Category 1 - myHDL [http://www.myhdl.org/]
myHDL uses python to design and test hardware components. A hardware component is designed as a python function whose arguments are the inputs and outputs of the component. The component can then describe sub-functions and designate them as combinational or sequential logic using a decorator (some text prefixed by the @ symbol that defines properties for a function/method). Once the design is complete, it can be exported to HDL (VHDL or Verilog) using a small python snippet. The design can also be tested/simulated in the python environment and generate waveform traces.
Installation of myHDL
Installing myHDL is straightforward and can be done with a single line on a Linux system(not tested with windows).
sudo pip install myhdl
Design of the PWM module in myHDL
The pwm component is pretty straightforward. It has two inputs period and t_on that designate respectively the period of the pwm signal and the number of cycles that the pwm edges are triggered on. The module has two outputs: pwm_out that is the pwm signal and period_end that is asserted at the end of a period and de-asserted otherwise. Here is the corresponding myHDL code.
from myhdl import *
def pwm_module(period, t_on, pwm, period_end, clk):
count = Signal(intbv(0)[16:])
@always(clk.posedge)
def logic():
if count == period:
count.next = 0
period_end.next = 1
else:
count.next = count + 1
period_end.next = 0
if count > t_on:
pwm.next = 0
else:
pwm.next = 1
return logic
The module is evaluated/simulated using the following test-bench.
def TestBench():
clk = Signal(bool(0))
period = Signal(intbv(200)[16:])
t_on = Signal(intbv(100)[16:])
pwm_out = Signal(bool(0))
period_end = Signal(bool(0))
pwm_inst = pwm_module(period, t_on, pwm_out, period_end, clk)
@always(delay(1))
def tb_clkgen():
clk.next = not clk
@instance
def tb_stim():
period = 200
t_on = 100
yield delay(2)
for ii in xrange(400):
yield clk.negedge
print("%3d %s" % (now(), bin(pwm_out, 1)))
raise StopSimulation
return tb_clkgen, tb_stim, pwm_inst
if __name__ == '__main__':
Simulation(TestBench()).run()
The Corresponding HDL code is generated by changing this line of code:
pwm_inst = pwm_module(period, t_on, pwm_out, period_end, clk)
into this line of code:
pwm_inst = toVHDL(pwm_module, period, t_on, pwm_out, period_end, clk)
and here is the resulting VHDL:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use std.textio.all;
use work.pck_myhdl_081.all;
entity pwm_module is
port (
period: in unsigned(15 downto 0);
t_on: in unsigned(15 downto 0);
pwm: out std_logic;
period_end: out std_logic;
clk: in std_logic
);
end entity pwm_module;
architecture MyHDL of pwm_module is
signal count: unsigned(15 downto 0);
begin
PWM_MODULE_LOGIC: process (clk) is
begin
if rising_edge(clk) then
if (count = period) then
count <= to_unsigned(0, 16);
period_end <= '1';
else
count <= (count + 1);
period_end <= '0';
end if;
if (count > t_on) then
pwm <= '0';
else
pwm <= '1';
end if;
end if;
end process PWM_MODULE_LOGIC;
end architecture MyHDL;
myHDL lines to VHDL lines : 20 -> 42 = 0.47
Pro and Cons of using myHDL or similar languages
Pro:
- Python syntax is clean and forces the user to structure the code appropriately
- The syntax elements introduced for hardware design are relevant and does not add much syntax (the next attribute is a great idea and reflects the hardware behavior)
- The quality of the generated code is great !
- The simulation has a great potential, you can even generate a waveform
- One can take advantage of the extensive collection of Python packages to create powerful simulations
- Small designs can fit in one file.
Cons:
- The use of decorators is not great for readability (and i’am not a decorator fan …)
- One really needs to understand digital logic and hardware design before starting a myHDL module
- One really needs to master the basics of Python before getting started
- Python will raise errors for syntax errors but simulation does raise warning or errors if there is a design error (incomplete if/case clause or other things that a synthesizer would detect)
- There is no (that i know of) myHDL specific editor or environment that would ease the beginner experience.
Category 2 - The Custom Syntax Approach - PSDHL [http://pshdl.org/]
PSHDL (plain and simple hardware description language) is an HDL language with custom syntax that takes elements inherited from C/SystemC and adds a custom set of keywords and coding elements to represent a hardware module. A module has no arguments but declares some internal variables as “in” or “out”. The nice and clever thing about PSHDL is that only one keyword is used to represent a sequential part of the module. Instead of declaring a computational unit of sequential or combinational logic, a keyword “register” is used to identify the variables/signals that are to be updated in a synchronous process. This is particularly relevant because every HDL design will be translated into LUTs, MUXs, D-latches or registers.
The PSHDL syntax is fairly easy to understand and there is not much syntactical noise. The best thing about PSHDL is that it runs in the web browser! Just like the mBED initiative (for ARM micro-controllers), the pshdl.org website, proposes to create a workspace in which you can edit, compile (to VHDL) and debug your design all on-line. This means, no tools to install (still need to install the ISE/quartus tools to synthesize), OS independent (no problem with running it under Linux/Windows. The community is rather small up until now, but the tool deserves a try!
Creating the PWM module using PSHDL
Below is the PSHDL code for the pwm module:
module de.tuhh.ict.pwmModule {
@clock in bit clk;
in uint<16> period, t_on;
out bit pwm_out, period_end;
register(clock=clk) uint<16> counter;
if(counter > period){
counter = 0;
period_end = 1 ;
}
else{
counter = counter + 1;
period_end = 0;
}
if(counter > t_on){
pwm_out = 0;
}
else{
pwm_out = 1;
}
}
Below is the VHDL code generated by PSHDL
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.Casts.ALL;
use work.ShiftOps.ALL;
use work.Types.ALL;
entity de_tuhh_ict_pwmModule is
port (
rst : in std_logic;
clk : in std_logic;
period : in unsigned(15 downto 0);
t_on : in unsigned(15 downto 0);
pwm_out : out std_logic;
period_end : out std_logic
);
end;
architecture pshdlGenerated of de_tuhh_ict_pwmModule is
signal counter : unsigned(15 downto 0);
begin
process(counter, period, t_on)
begin
pwm_out <= '0';
period_end <= '0';
if (counter > period) then
period_end <= '1';
else
period_end <= '0';
end if;
if (counter > t_on) then
pwm_out <= '0';
else
pwm_out <= '1';
end if;
end process;
process(clk)
begin
if RISING_EDGE(clk) then
if rst = '1' then
counter <= (others => '0');
else
if (counter > period) then
counter <= (others => '0');
else
counter <= (counter + TO_UNSIGNED(1, 16));
end if;
end if;
end if;
end process;
end;
PSHDL lines to VHDL lines : 21 -> 51 = 0.41
Pro and cons
Pros :
- Online tool ! No installation and is OS agnostic
- Easy to use syntax for people who know C/C++
- Clever use of the “register” keyword to denote sequential assignments
- Outputs nicely formatted VHDL
- Generated VHDL interfaces easily with existing VHDL code
Cons:
- Online tool - some people may complain that its not great for privacy and intellectual property
- Some syntax elements like the package prefix for a module create lengthy text
- A “register” can be associated to a clock and reset by passing arguments to it. This is misleading for C/C++ programmers as it creates a type with an argument (and not a template like the other types) which is not valid C/C++ code.
- Simulation does not seem to be fully functional in the online tool
- The community is small (but can grow if you give it a try)
Conclusion
These two alternative HDL languages/tools do a great job to ease the process of writing and debugging HDL. They both rely on different principles. myHDL defines combinational/sequential functions while PSHDL defines sequential signals for the sequential behavior. This allows you to pick what works best for you! The main drawback with both of these (tools and other alternatives languages) is that they are not directly supported in the vendor tools (Quartus/ISE) and that they are not recognized as standard hardware design languages in the professional world. This means that you will still have to learn VHDL/Verilog at some point if this is part of your career plan.
There is no indication that FPGA vendors are willing to open the access to their synthesis tools for third parties, so for any VHDL/Verilog alternatives you will still have to install and use their tools to synthesize and create the binary files to configure the FPGA.
One other language that tends to emerge as a standard for hardware (and system) design is SystemC (at least with Xilinx). While myHDL does not rely on any of the SystemC concepts, PSHDL has the advantage of being (to some extend) C/C++ based.
To get more people to use FPGAs there is a need to propose a large diversity of languages/tools. See the diversity of languages available to program microcontrollers. Some years ago you had to use C or assembler to design embedded software, but now you can use C/C++, Arduino (C++ based), javascript, Python and more. We need the same kind of languages competition for HDL as each new language may attract more users and create new uses for FPGAs.
What features do you foresee being needed for a killer hardware description language?
This work is licensed under a Creative Commons Attribution 4.0 International License.
Top Comments