Regular Expressions

Proposal Details

  • Who Updates: DanielKho, <Add YourName>
  • Date Proposed: 2015-01-03
  • Date Last Updated:
  • Priority:
  • Complexity:
  • Focus:

Current Situation

Many VHDL features support a high level of abstraction, which allows a great many deal of things to be implemented directly in hardware rather than software, which usually translates to better performance, lower power, and lower system cost.

However, the lack of tools and standards in some areas, such as text processing and graphics, are leaving people with no choice but to implement these things in software.

Currently there is no built-in regular expression (regex) engine in VHDL. Many applications involving text processing are dealing with a much higher level of abstraction than what is easily available with existing VHDL. To compete with other software languages, VHDL needs to support these abstractions, including having a regular expressions parser built into the language, possibly in the form of a standard package.

Requirement

Standardize a library (package) allowing users to easily specify VHDL regular expressions. We may borrow regex syntax from established software languages such as Perl or C.

Implementation details

[In progress...]

Code Examples

Use Cases

Arguments FOR

-- DanielKho - 2015-01-03

  1. No other HDL I believe supports regex (perhaps myHDL?), so let's be the first.
  2. We are trending towards more functionality and less power consumption. Implementing things in software, while adding to the feature set, does in fact also gobble up much more power. To implement more features while not increasing the power consumption too significantly, a hardware solution is needed. To make it easier for hardware designers to do things traditionally done in software, we need easy-to-use libraries.

Arguments AGAINST

General Comments

-- DavidKoontz - 2015-01-03

The equivalent of a regular expression in hardware is a state machine also implying sequential logic, and implies full coverage for specific types to avoid inference of latches. The unrolling of a loop potentially involves element recognizers (classifiers) and rules comprised of potentially large AND-OR arrays expressing cases for each combination of elements across a potentially large array type constituted from individual elements being 'tested'.

There's this general issue of being able to relate synthesized hardware to a short hand for a regular expression, there is no specification extant today for synthesis mapping leaving implementation as a function or attribute (a function) with an argument representing the regular expression.

There'd be a need to express type specific element classifiers supporting regular expressions. It doesn't seem likely a non type specific solution exists, it seems unlikely you can generate implicit element classifiers for arbitrary types (the equivalent of values or ranges of values, an arbitrary table of values specifying inclusion or exclusion from a particular element classifer class membership).

It might be more useful to have a solution to demonstrate before proposing standardization, avoiding the appearance of generating a (potentially good) idea and simply throwing it over the fence for someone else to deal with.

There are also potential non language definition solutions such as a state machine generator that could swallow regular expressions.

-- DanielKho - 2015-01-04

I'm working on a package that hopefully, once I feel ready enough, I can submit to the group to review. I hope to be able to have an implementation of at least some simple regular expressions using mostly subprograms - and not have to revert to processes and statemachines. The idea is that users can use these subprograms in their statemachines or processes. For a start, at least some parts will be non-synthesisable, and I will think of how to make it synthesisable at a later time.

Supporters

Add your signature here to indicate your support for the proposal

-- DanielKho - 2015-01-03

Topic revision: r4 - 2020-02-17 - 15:34:37 - JimLewis
 
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback