Lumorphix

A highly customizable processor IP, that supports the Lua scripting language.

Overview

The Lumorphix IP core features the following:

• Native execution of the Lua scripting language, including
  • REPL
  • Non-volatile program storage
  • Rich, full featured API
    • Constants
    • Functions
    • Interrupts
• Build-time configurable, including:
  • Number of supported processor cores (maximum of eight)
  • Stack / Heap size, per core
  • Support for a configurable number and type of digital I/O protocols (GPIO, PWM, SPI etc)
  • Support for an FPGA fabric bus
  • Support for inter-core communication
  • Support for inter-core synchronization
  • Support for timers, hardware watchdogs and interrupts
• Run-time configurable, including:
  • Digital I/O Pin type (i.e. GPIO, UART, SPI etc)
  • API
  • Interrupts
  • Timers
• Each processor core is heterogeneous
• Ultra-small footprint (minimal configuration) of only 1750 LUTs (AMD / Xilinx 28nm fabric) and 5 BRAM (20 kB)
• Clock frequency up to 500 MHz (AMD / Xilinx 16nm fabric)
• Simple UART-based user interface

See the product summary document for additional information.

---

Documentation

Product documentation is available online or as a downloadable document.

_{NOTE: As Lumorphix is still in Beta, the instructions related to evaluating a Beta Release are particularly relevant.}

---

Beta Release

Beta Release information and binaries are available here.

See here to subscribe to email notifications regarding Beta Releases.

---

Basic Usage

The following demonstrates performing ‘Hello World’ (of embedded systems – i.e. toggling a GPIO) via the Lumorphix REPL.

As can be observed, three lines is all it takes! Note that the Lumorphix boot messages have been included for reference (all text prior to horizontal line).

---

Use Cases

1. Supervisory Role

A common use case with which all FPGA designers will be familiar involves supporting ‘Supervisory’ functionality within an FPGA based product. This functionality is often ill-suited for implementation in RTL, and is much better suited to a Softcore or MCU. It could include, for example:

• Performing ‘Business Logic’, i.e. fundamental product functionality which has minimal performance requirements, but is potentially logically complicated and/or deep (i.e. such that it is much better suited to be implemented in code, as opposed to hardware).
• Providing an interface that allows a user (possibly either the customer or an engineer) to interrogate or modify the product state.
• Monitoring the state of FPGA modules and responding to events. For example, responding to the assertion of Hot-Plug of the MIPI interface in the diagram below.
• Modifying the state of internal FPGA modules. For example, performing a set of register reads and writes that must occur as part of a hardware component initialization after power-on.
• Providing a stream of information (i.e. via UART) which a user or engineer can use as a debugging tool.
• Communicate with external IC’s, i.e. supporting components of the product.

The tasks involved in this typically involve:

1. Selection of a Softcore or MCU.
   • If an external MCU is used, then there are additional requirements related to hardware / PCB design.
2. Selection and collation of the required driver components. For example, the Softcore may require SPI input, several GPIO outputs and Timer Interrupts etc.
3. Setup an IDE (and debugger) with an initial project, including the required drivers.
4. Write code to initialize the drivers, test until proven functional. Typically this is in a low-level language such as ‘C’.
5. Write product-specific code to perform the required supervisory tasks. This likely involves a continual cycle of:
   • Write a subsection of code.
   • Load onto the Softcore / MCU.
   • Test, repeat if non-functional.

Using Lumorphix in a Supervisory role negates a lot of this overhead. Each of the above tasks simplify as such:

1. No Softcore or MCU selection required and compatibility with an internal signalling is guaranteed, as Lumorphix is simply another internal FPGA component.
2. Simply select the required driver components as part of the Lumorphix IP configuration stage, and the API to configure and utilize them will be present.
3. No IDE required.
4. Minimal driver initialization required (possibly just a few lines of Lua to enable and set baud / frequency / number of data bits etc). This is done in a high-level scripting language, Lua.
5. Again, as a high-level scripting language is used, possibly as little as 10% of the overall lines of code are required (in comparison with ‘C’) and the complexity is greatly reduced. Also relevant:
   • Garbage collection.
   • Various libraries, i.e. math, string etc.
   • REPL, to prototype / tinker.
   • In-built performance profiling.
   • Multiple, heterogeneous sub-processors.

---

2. Third-Party IP Core bring-up

Another common use case with which all FPGA designers will be familiar involves the bring-up activities involved in integrating a Third-Party IP core into an FPGA based product. This typically involves:

1. Integrating the Third-Party IP core into the FPGA at the RTL level, which includes:
   • Providing appropriate signaling to the IP (i.e. clock, reset, enable, mode select etc).
   • Establishing a bus-level connection between the Third-Party IP and either an internal Softcore or external I/O bus (which is then driven by an Off-chip MCU).
2. Development of the Softcore / Off-chip MCU firmware that can perform the required register reads/writes and signal leveling (i.e. reset, enable, mode select etc) to initialize, monitor and handle any Third-Party IP Core bring-up firmware requirements.

It is primarily with regards to the second stage that the Lumorphix IP core adds value to the bring-up process. Instead of a Softcore / MCU based bring-up, which involves the following cycle:

1. Develop subsection of firmware (usually in a low-level language such as ‘C’)
2. Compile
3. Load onto FPGA
4. Test
5. Review results, if incorrect, return to stage ‘1’. Otherwise, continue with next subsection of firmware, and repeat the process.

Obviously, there is substantial overhead (time, engineering effort etc) in stages ‘2’ to ‘5’. With Lumorphix, the bring-up flow simplifies greatly:

1. Connect to REPL via UART
2. Dynamically develop first subsection of firmware, until functional. This development is in a high-level scripting language (Lua) as opposed to ‘C’.
3. Continue with the next subsection.

In addition to a simplified bring-up flow, the REPL has the added advantage of allowing the user to ‘tinker’ / ‘poke-prod’ the module under bring-up (as it is often somewhat of a ‘Black-Box’). Consider the following diagram.

A brief example of a possible bring-up phase is as follows (NOTE: the UART connection to Lumorphix has already been established – and the boot messages are not included in the snippet).

---

3. External IC interface

Similar to the ‘Supervisory Role’ use case, this use case involves communication between FPGA and external IC’s. Again, such functionality is common, and is unsuited to RTL implementation (e.g. would likely require lengthy state-machine based logic, wasting critical FPGA fabric resources). Since with many external IC’s, there is minimal performance requirements, this functionality can simply be implemented using a Softcore, as follows:

Again, many of the advantages listed in the ‘Supervisory Role’ use case apply – i.e. minimal driver configuration / setup, REPL for experimentation etc.

---

4. Standalone

The final use case that is advertised is to simply use Lumorphix as a standalone unit, for example:

In this use case, the FPGA becomes a scriptable MCU, similar to a RPi Pico or Bus-pirate type product.

---

Mailing List

See here to subscribe to email notifications regarding Lumorphix.

---

Other

An overview of all BrisbaneSilicon IP is available here.