Extended String Literals

Proposal Details

• Who Updates: JimLewis
• Date Proposed:
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Requirement

VHDL's default string literals do not allow any mechanism for including non-printing characters into the string, such as LF.

Using the same style of extension that is used for bit string literals, create a new class of string literals that support C-style quoting within strings.

Related Issues

NewRulesBitLiterals poses some questions regarding how to make the implementation of bit string literals more robust. If this proposal addresses all the concerns regarding how graphic characters may be used in a (normal) string literal, we can use this same proposal and apply them to bit strings. The LRM allows anyone to insert graphic characters into bit string literals (rarely used, but possible), so we should have a robust implementation that takes care of all scenarios, e.g. usage of double-quote characters in a string, among others. See Code Examples for an example on this issue.

Proposal

Extend string_literal to be:

string_literal ::=
     " { graphic_character } " |
    C"{ escape_sequence | graphic_character_except_slash }"

Questions

Code Examples

write(OUTPUT, C"line \t1 \n line \t2 \n line \t3 \n") ; 

Note LF is also interpreted as newline in VHDL.

Example using the double-quote (") character for (normal) string literals. Currently, this is a problem with bit-string literals (but not a problem with string literals).

    -- (old) string literals vs. proposed.
    signal a: string(1 to 256) := (others => nul);
    constant str0: string := "Processing sequence ""0x01""";
    constant str1: string := c"Processing sequence \"0x01\"";    --proposed implementation is clearer.
    ...
    a(str'range) <= str1;  -- or str0

Example where one may like to declare his/her own custom logic, possibly with "weird" graphic characters other than the usual 'X', 'Z', '-'.

    signal b: custom_logic_vector(15 downto 0);
    ...
    b <= x"12ab"; ...    -- hex number similar to unsigned/signed.
    b <= x"abzz"; ...    -- with tristated values
    b <= x"ab""";        -- ?

Arguments FOR

-- JimLewis - 2014-11-20

I for one have been using the concatenation method for some time now and find it inconvenient to break a string just to get a line feed. Anyone try alert/bell or backspace in VHDL?

-- DanielKho - 2015-01-01

I find it inconvenient to have to concatenate many control characters into the same string:

report lf & "####################################" & lf &
    " PARAMETERS " & lf &
    "maxPositions: " & to_string(maxPositions) & lf &
    "resolution: " & to_string(resolution) & lf &
    "offset: " & to_string(pulseWidthRange(0)) & lf & lf &
    "refreshRate: " & to_string(refreshRate) & lf &
    "resolution/refreshRate: " & to_string(resolution/refreshRate) & lf &
    "####################################" & lf severity note;

I remember having another application (this time it's for synthesis), where I wanted to send out ASCII strings over a communications bus (perhaps SPI or I2C), and I tried synthesizing characters and strings. While they synthesized well, I ended up having to concatenate quite a few control characters, including CR and LF.

-- DanielKho - 2015-01-02

This proposal could also help answer some of my questions in NewRulesBitLiterals.

Arguments AGAINST

-- DavidKoontz - 2014-11-18

This doesn't appear necessary. Today you can concatenate string literals and character literals to create strings comprised of graphic characters and format effectors or other non-graphic character literal enumerations. Numeric literal to character conversion appears to be the domain of type conversion functions. The type STRING is an array of elements of type CHARACTER and CHARACTER is an enumeration literal. The proposed escape sequences embrace some graphic characters as well as format effectors and numeric literals. For the two escape sequences showing numeric literals use concatenation and either attributes (e.g. "A" & character'VAL(16#42#) & "C"), a type conversion function, an overloaded "&" concatenation operator ("A" & 16#42# & "C") or an alias to one of these. (There'd need to be four flavors of an overloaded concatentation operator - [string, natural return string], [character, natural return string], [natural, string return string] and [natural, character return string], the natural could be range constrained or an assertion error generated allowing a customized error message).

-- TristanGingold - 2014-11-19

I agree with David: this brings nothing as concatenation provides the same feature. I don't think C strings are particularly more readable than usual VHDL strings with concatenation.

-- MartinThompson - 2014-11-19

I also agree - concatenation has been fine in my experience.

<Brent Hayhoe> Also in agreement. The standard control CHARACTERs are defined (e.g. LF) for use in concatenation and the extended controls as Cnnn. One may need to qualify them with CHARACTER`LF depending on usage. Also, there is the CHARACTER`VAL(n) attribute for accessing non-keyboard characters (e.g. CHARACTER`VAL(160) - non-breaking space). I tend to use strings concatenated with CR to generate large summary tables into text files at the end of verification runs.

</Brent Hayhoe> - 2014-11-19

General Comments

Supporters

Add your signature here to indicate your support for the proposal

-- PatrickLehmann - 2016-02-19