[Oberon] What is the status of Lola-2 and its use in the FPGAversion of Project Oberon?

Skulski, Wojciech skulski at pas.rochester.edu
Fri Mar 15 15:19:24 CET 2019


> I prefer to use Lola wherever possible, it's clearer than either (System)Verilog or VHDL. 

Clearer is in the eyes of the beholder. I never liked Lola (sorry), because it only supports one particular coding style. Just looking at the VID.Lola I can see the RTL-style coding. I am seeing this style since the very first Lola book. In modern FPGA programming the code is more often expressed behaviorally. RTL style is used in low level modules, and not even always there. The high level constructs are coded as behavioral. VHDL is better (in my opinion) for behavioral coding than Verilog. However, both languages are exactly equivalent. They only feel different way, which is important for a programmer (myself), but fundamentally there are no restrictions to write the same code either in Verilog or in VHDL.

For the laymen: Register Transfer Logic (RTL) is the style where you assign bits or vectors of bits directly by hand. Presumably this is how the flip flops and wires are connected in the FPGA. It is a low level style. Programming analogy: imagine you are coding a high level algorithm without using function calls, but rather assign many dozens of variables in one chunk of code. It gets very confusing very quickly. This is how RTL looks. (Look at VID.Lola or any other Lola module by Wirth.)

An even larger reservation against RTL coding is that modern FPGAs simply are not collections of flip flops and wires. They contain many configurable blocks ("hardened logic") which can hardly be described by RTL assign statements. The "behavioral" style of coding leaves the compiler freedom to map functions "as intended" to these hardened logic blocks, using the internal compiler heuristic. You basically tell the compiler "here is what I intend, go and figure it out". Most FPGA coding is done this way these days. The RTL-style is neither capable nor intended for doing that.

> If a feature requires special features not
> supported by Lola, I wrap it in Verilog.  The main cause of this
> currently is library identifiers (e.g. "_" characters), but in fact it's
> really wrapping the nonportable pieces.

Is there any special reason to not change Lola such that the main cause is just eliminated?

Thank you,

More information about the Oberon mailing list