Packed array syntax

[quic-nvettuva]

This is about the syntax type<size> used to denote packed arrays.

Given that most programmers are familiar with [] for arrays, I was wondering if we could move to a similar syntax to denote packed arrays? Perhaps we could use [size] for packed arrays and [%size%] (or something similar) for unpacked arrays?

I'm a bit worried that <size> may be a deterrent on adoption.

[dalance]

We previously explored various syntax options for packed/unpacked arrays.
(Apologies for the Japanese, but the following issue may be helpful: #94)

Here is a summary of my thoughts at the time of consideration, along with my current perspective.

First, the distinction between packed and unpacked arrays is necessary.
Initially, I considered unifying them into a single array syntax, but after considering interoperability with SystemVerilog, we concluded that the distinction is required.

Therefore, we must either distinguish them by the position of [] as in Verilog/SystemVerilog, or use different symbols.
Distinguishing by [] position is confusing and doesn't pair well with our current post-positioned type syntax, so we explored changing the symbols.

From the perspective of which symbol to assign to packed versus unpacked, we chose to assign [] to unpacked.
Although packed arrays are called "array", I believe they are essentially a way to declare types of arbitrary bit width, not arrays of bits.
In other words, logic<2> declares a "2-bit 4-value type," not an array of 2 elements.
On the other hand, unpacked arrays, as seen in interface arrays, align more closely with the concept of arrays in general-purpose programming languages.

If [] is assigned to unpacked, a different symbol is needed for packed, so we considered various notations such as <>, () and so on.
Each had pros and cons, but ultimately we chose <> to align with the notation for generic types in general-purpose programming languages.
I believe that users familiar with C++ templates or Rust generics can understand logic<2> as instantiating a generic type logic<N> with a concrete argument.

I understand that users of general-purpose programming languages are accustomed to array definitions using [], but since we are introducing the non-standard concept of packed/unpacked distinction, some friction is unavoidable.
Of course, we are open to considering better syntax proposals, and I deeply appreciate you raising this issue.

[quic-nvettuva]

Thank you for the response. I understand the need to keep packed and unpacked arrays separate for interoperability and I believe the overall direction you've chosen is the right one.

However, the main issues I see with assigning [] for unpacked arrays is that packed arrays are way more commonly used in the industry than unpacked arrays (I'd say 95% or more). This, IMHO, might have tuned most RTL designers to relate to packed arrays as just "arrays" and associate them with []. Hence my suggestion for using a less common operator for unpacked, to aid a more seamless transition from SV.

While I agree with the fact that packed arrays are synonymous to a type of arbitrary width, I'm not really sure if this definition can scale well for multi-dimensional packed arrays. A logic<2, 2> still needs to be interpreted as an array of something. Another question I would like to raise in this context is whether arithmetic is meant to be performed on a logic<8>. If yes, would it be cleaner to distinguish such a type as int<8> and a simple, non-arithmetic packed logic array as logic<8>? I think Chisel follows this approach.

If we strictly go by the semantics of C++ templates, then we'll have to interpret 2 as a property that manipulates/alters the underlying type logic, instead of extending its scope. I think something like logic_array<2> or array<logic, 2> may be semantically closer to a template-like packed array than logic<2>.

[dalance]

I'm skeptical about the fact that unpacked arrays are rarely used.
In designs using SystemVerilog, much of logic declared using packed arrays is hidden as members of structs or interfaces, while interfaces and modports require the use of unpacked arrays, so the proportion of unpacked arrays increases.
In the code base of my company's commercial products, the proportion of unpacked arrays may exceed 50%.

I agree that there are many people in this industry who stick to the traditional Verilog writing style, and they almost exclusively use packed arrays.
However, I don't think those people would switch to Veryl even if Veryl adopted [] as a packed array.

For these reasons, I am opposed to the idea of ​​assigning uncommon symbols simply because unpacked arrays are used less frequently.

On the other hand, it's probably true that logic with unpacked arrays are rarely used.
The few use cases I know of are where an unpacked array is needed to allow Vivado to infer Block-RAM.
Therefore, rather than simply assigning symbols to packed and unpacked arrays, the following hybrid strategy might be considered:

• In var/let declarations and port declarations other than modport, [] indicates a packed array.
• In var/let declarations and port declarations other than modport, #[] indicates an unpacked array.
• In inst declarations and port declarations of modport, [] indicates an unpacked array.

Using this method, most arrays that appear in source code will be standardized to [].
(The above rule is a simplified one; in reality, we may need to consider more corner cases.)

The problem with this method is that it complicates the correspondence with SystemVerilog semantics.
However, from the perspective of Veryl semantics, the fact that it simply "uses [] by default" may be an advantage.

[quic-nvettuva]

Perhaps the usage of unpacked arrays varies heavily across organizations? But, I think I agree with your point.

If the idea is to treat unpacked arrays under the general category of arrays, I think we could move ahead with that. Personally, I'd always pick a static operator assignment against an operator that varies its meaning with context.

A few thougths on the <> for packed arrays:

• I think we currently limit < and > from being used as relational operators? How about we swap <> with <: :>? That way, the comparison operators shall look similar and we get something unique logic<:2:> for packed arrays (which is a new operator anyway)
• I'm also wondering if it's possible to keep using < and > for comparison while continuing to use <> for packed arrays, like C++? Does this require the lexer and/or parser to be more context aware?
• Any thoughts on logic<2> vs logic_array<2>?

[dalance]

I agree that context-independent operator assignment is preferable.

A few thougths on the <> for packed arrays:

As you pointed out, packed arrays are a very commonly used syntax, so <::> feels too long.
I also agree that using <: for comparison operators is odd, but it has advantages in matching the character count of <= and making parsing of the generic <> easier.
As you noted, to use < for comparison operators, not only packed arrays but the entire generic syntax would need to be reconstructed, changing parsing behavior depending on context.
I believe that accepting the slightly odd <: for comparison operators allows <> to be naturally treated as brackets throughout the syntax, which is a significant advantage.

Regarding logic<2> versus logic_array<2>, I agree that the latter is closer to C++ template semantics, but I don’t think it’s necessary to fully mimic C++ templates.
I don’t see enough benefit to justify making a very commonly used syntax more verbose.