So the idea is simple, I need an intermediate file format to define the logic gates of a library.

Doing a direct translation from Liberty or other formats to VHDL would be too complex so I do in two steps, the first being the refactoring of the existing tool.

The constraint is to KISS : keep it simple and even stupid, and a lot of complexity comes from parsers. The XML parser in bash is an example of overly crazy code that breaks and must be maintained in synch with the tool that generates the XML. But GHDL doesn't evolve fast and there is only one tool to read from. For Liberty, it's a totally different beast... Too many origins, too many tools, too many options and variations... I have collected a few .lib files from different origins and I welcome new ones to test my system.

But first I must define what the .lib parser must output, which should be as easy as possible to process on my side. The format is a text using a widely used function syntax, instead of a JSON or XML format, because I can directly process it in VHDL, C, JS, you name it. It gets parsed by the interpreter or the compiler, so that's as much I don't have to do.

First, define the library name:

define_library_name("somenamewithoutspace");

It must be called first and only once.

Then more calls are needed to define each cell/gate, which is either a combinatorial gate (could be a buffer too), a synchronous FlipFlop or an asynchronous Set/Reset latch.

define_combinatorial_cell("AND", "A and B", "Y", "A", "B");
define_sequential_cell("DFF", "Q", "D", "CLK", "CLR");
define_asynchronous_cell("RSLATCH", "Q", "S", "R");

The calling convention is still preliminary and will evolve. But the syntax follows the classic conventions and the calls end with a ";" (strip it if you want to use Python)

So far the limits are the multi-output cells (such as HAX1 and FAX1 of OSU) and the translation of AND, XOR and OR from the weird conventions of the Liberty format, as defined p96, section 4-36:

function : "Boolean expression" ;

The precedence of the operators is left to right,
with inversion performed first, then XOR, then AND, then OR.

Table 4-6 : Valid Boolean Operators in the function Attribute Statement

Operator Description
  ’      Invert previous expression
  !      Invert following expression
  ^      Logical XOR
  *      Logical AND
  &      Logical AND
space    Logical AND
  +      Logical OR
  |      Logical OR
  1      Signal tied to logic 1
  0      Signal tied to logic 0

So the Liberty parser's role is to deal with this mish-mash and output VHDL-correct boolean expressions. We'll see that later.

For now the idea for the flow is

1. get the .ali file with all the calls
2. script to add "decoration" to the list and create a function out of the file, following the language's conventions.
3. The target language will also have definitions of the functions.
4. The target language then call the custon function, that calls the subfunctions with the user's data/parameters.

For the VHDL version, the gate functions will be called twice : for the declaration then the definition. The gate functions must know which phase they are called from so they output the right text. And since they could be called in any order (you never know, bugs happen) they must also check it too.

The first thing to do now is to convert the A3P (and maybe OSU and others) libs to the ALI format, by hand, and see how to refarctor the tools to accept these.