From previous articles, it might be obvious that I’m a fan of code-generation over the language features in VHDL.  This is mainly because the vendors are always slow to adopt any existing parts of the VHDL standard.  Further, portability is destroyed when the common subset of supported features is considered.

Python is a fairly nice language.  Realistically, perl or ruby might also make good choices.  I chose python because I know python.

My previous code generators have been written as custom scripts.  Mainly because I wanted to have fine control over the exact code output.  I wanted to publish the output in a readable format, so more care was placed on beautification features.

My GF256 and Reed-Solomon examples produce output that is nicely formatted and easy to read.  In general, the only reason to make the generated code easy to read is to aid in debugging.  This is one issue with code generation — debugging the generated code can be difficult because of the long lines and poor formatting.

Why Code Generation

In this case, it’s for VHDL-2008 features.  With code generation I now have access to type/function generics.  I also have access to if-elsif-else generates.  Python, not having a case statement of its own, makes the case-generate a bit difficult, so I don’t have that.

I also have the ability to use python’s functions, and write python functions instead of VHDL functions in many places.  Thus, I no longer need to deal with VHDL’s math functions when I want to want to declare constants or signals.  I can also pull in parameters from any source I want — command line, file, ftp, ect…

How it Works

I decided to add three constructs.  The first of which is designed to execute python code:

-- this is the vhdl file
!{# python code
  x = range(10);
  y = 3
  }

This is my !{} operator.  This is mainly intended for things like “import re” or “import mylib”.  Stock editors won’t know how to do syntax highlighting for the embedded python, so any large body of code will just be better in its own file.

The next operator is a “insert string” operator.  It will call str(expr).  This allows ${obj} to call obj.__str__().  I decided to use ${}, as it is familiar from shell scripting.   The result looks like:

 x_${y} <= ${tgts[y]};

Which shows an example of y being used to index a list or dictionary on the RHS.  Unlike shell, I don’t have support for just $name.  I might add that at some point if I find that I mainly use expressions with no spaces.

Finally, I added a python-generate statement.  The intention here is to add a python control structure (for-each/while/if-elsif/else) to allow VHDL code generation.  I decided to make this look like a VHDL construct:

py_label : python for ii in x generate
  x(${ii}) <= Din(${permute(ii)});
end python;

The code will then generate VHDL statements assigning bits of Din to other bits of x, based on whatever “permute” does.

Limits

There are still some features missing.  The biggest is features to aid in a bottom-up pass at elaboration.  Basically, I dislike the top-down elaboration in VHDL.

An example of why would be a register interface.  With a hierarchy, register addresses would be allocated and assigned from the top.  This means that the top level of the design now needs to know implementation details about every level of hierarchy.  This isn’t what I want.

This would be something like “output generics”.  The number of registers could be passed up and accumulated moving up the hierarchy.  Once the allocation of registers is known, the top level could assign addresses to its immediate components, which then would assign registers down the hierarchy.

Similar “read first then do” type actions would also benefit the VHDL code generator for similar reasons.  This can make the design complicated though.  It places more requirements on the allowed VHDL code.  The elaboration might result in a change to a parameter used previously, and would need a re-elaboration.

A bigger issue would be mixing VHDL’s generates/generics with the new python generates/code.  Really, just interacting with the VHDL objects at all would be difficult.  Right now, the python code is completely unaware of the VHDL constructs.

Conclusions

This is just the first pass at my VHDL code generator.  It currently is in an alpha stage, with some desirable features missing.  There are some bugs as well.  The intention behind this is to allow VHDL code generator to be written easily.

As mentioned, there are still some issues.  For writing code, the main issue is that text editors don’t like the mixed languages.  For implementing code, the main issue is that syntax errors can occur in the code generator as well as the output VHDL.  This makes it hard to trace an error at line 100 to the correct line of the code generator.

Here is the alpha version of the code generator.  It really was more of an OOP test, and will probably be heavily modified in the future.