Hi, and thanks for keeping this project alive.
Accellera released a new Verilog-AMS LRM on Feb 14, 2024 (VAMS-2023), superseding version 2.4.0 from May 30, 2014. I went through Annex G, Table G.7 ("Changes from v2.4 to VAMS-2023") item by item and checked each one against the current tree at b4517ad. I'd like to propose bringing OpenVAF in line with it, and I'm offering to do the implementation work myself.
The good news is that the scope is small: VAMS-2023 is a maintenance release. Of the 31 Mantis items in Table G.7, 11 need compiler code, and only three of those add syntax that has to be parsed. The rest are corrections to the BNF prose in Annex A, fixed examples, or clarifications to operators OpenVAF already implements.
Gaps that need code
| Mantis |
Feature |
LRM clause |
Current state |
| 7780 |
expm1() / ln1p() |
4.3.1, A.8.2, B.1 |
Absent from BUILTINS (sourcegen/src/hir_builtins.rs:84) |
| 7795 |
Verilog-style $min() / $max() / $abs() |
4.3.1 |
$ln, $exp, $pow, $floor exist in SYSFUNS:115; these three do not |
| 7920 |
$rtoi() / $itor() in the analog context |
9.11 |
Absent from SYSFUNS |
| 7912 |
`__FILE__ and `__LINE__ |
10.7 |
Not handled in openvaf/preprocessor |
| 830 |
Jump statements return, break, continue |
5.11, A.6.5 |
None are keywords (sourcegen/src/ast/src.rs:61) |
| 7808 |
string return type and return in analog functions |
4.7.1, 4.7.2.2 |
Functions return only by assigning to their own name |
| 7810 |
Dynamic (non-constant) tolerance arguments to transition, timer, cross, above, absdelta |
5.10.3.1–5.10.3.4 |
Tolerance args are parsed then discarded (hir_lower/src/expr.rs, "we currently do not support tolerance") |
| 7921 |
VAMS-2023 as a keywords specifier |
10.6 |
`begin_keywords / `end_keywords not implemented |
| 7809 |
Analog named events, triggering and detection |
5.10.4 |
No named events; only @(initial_step), @(final_step), @(cross(...)) |
| 4848 |
Vector parameters for Laplace and Zi filters |
4.5.11, 4.5.12 |
laplace_nd works; zi_* and laplace_np/zd/zp are in UNSUPPORTED:28 |
| 7792 |
last_crossing() clarified semantics |
4.5.10 |
Operator itself is in UNSUPPORTED |
Items that need nothing
- 5027 removes the unused keyword
net_resolution, which OpenVAF never had.
- 7922 downgrades contributing to an input-direction port from an error to a warning. OpenVAF imposes no direction check at contributions today, so it already conforms.
- 7754, 7791, 7794, 7811, 7812 are clarifications to
$limit, limexp, analog initial variable domains, transition when interrupted, and absdelay interpolation. All are implemented, so these are conformance reviews rather than features — I'm happy to read the new wording against the implementations and file separate issues if anything diverges.
- 2594, 4926, 4935, 7891, 7901, 7909 plus the example and typography fixes are Annex A grammar-prose corrections with no effect on a hand-written parser.
- 7793 adds
$receiver_count(), which belongs to mixed-signal connect modules and is outside a Verilog-A compiler's remit.
Proposed sequencing
I'd rather send several small reviewable PRs than one large one:
expm1() / ln1p() — pure scalar math with exact C equivalents, trivial derivatives.
$min / $max / $abs / $rtoi / $itor — aliases and conversions that reuse existing signatures.
`__FILE__ / `__LINE__ — genuinely useful for $error messages in model code.
return / break / continue, then the string function return type.
- The larger operator work (
last_crossing, vector-parameter Laplace/Zi), only if you think it's worth it.
Questions before I start
- Is VAMS-2023 alignment something you want at all, or would you rather keep tracking 2.4.0 as the reference?
- Should PRs target
mob?
- One PR per feature as above, or would you prefer the three small ones batched together?
- For
expm1, note that integration_tests/HiSIMSOTB/hisimsotb.va defines its own analog function real expm1. I'd preserve user-defined functions shadowing builtins so that model keeps compiling — please confirm that's the behaviour you want, since the alternative is a deliberate breaking change.
- Is there a documented policy on when a new builtin needs OSDI-visible support versus frontend only?
Happy to split this into per-feature issues if a single tracking issue is unwieldy.
Hi, and thanks for keeping this project alive.
Accellera released a new Verilog-AMS LRM on Feb 14, 2024 (
VAMS-2023), superseding version 2.4.0 from May 30, 2014. I went through Annex G, Table G.7 ("Changes from v2.4 to VAMS-2023") item by item and checked each one against the current tree atb4517ad. I'd like to propose bringing OpenVAF in line with it, and I'm offering to do the implementation work myself.The good news is that the scope is small: VAMS-2023 is a maintenance release. Of the 31 Mantis items in Table G.7, 11 need compiler code, and only three of those add syntax that has to be parsed. The rest are corrections to the BNF prose in Annex A, fixed examples, or clarifications to operators OpenVAF already implements.
Gaps that need code
expm1()/ln1p()BUILTINS(sourcegen/src/hir_builtins.rs:84)$min()/$max()/$abs()$ln,$exp,$pow,$floorexist inSYSFUNS:115; these three do not$rtoi()/$itor()in the analog contextSYSFUNS`__FILE__and`__LINE__openvaf/preprocessorreturn,break,continuesourcegen/src/ast/src.rs:61)stringreturn type andreturnin analog functionstransition,timer,cross,above,absdeltahir_lower/src/expr.rs, "we currently do not support tolerance")VAMS-2023as a keywords specifier`begin_keywords/`end_keywordsnot implemented@(initial_step),@(final_step),@(cross(...))laplace_ndworks;zi_*andlaplace_np/zd/zpare inUNSUPPORTED:28last_crossing()clarified semanticsUNSUPPORTEDItems that need nothing
net_resolution, which OpenVAF never had.$limit,limexp,analog initialvariable domains,transitionwhen interrupted, andabsdelayinterpolation. All are implemented, so these are conformance reviews rather than features — I'm happy to read the new wording against the implementations and file separate issues if anything diverges.$receiver_count(), which belongs to mixed-signal connect modules and is outside a Verilog-A compiler's remit.Proposed sequencing
I'd rather send several small reviewable PRs than one large one:
expm1()/ln1p()— pure scalar math with exact C equivalents, trivial derivatives.$min/$max/$abs/$rtoi/$itor— aliases and conversions that reuse existing signatures.`__FILE__/`__LINE__— genuinely useful for$errormessages in model code.return/break/continue, then thestringfunction return type.last_crossing, vector-parameter Laplace/Zi), only if you think it's worth it.Questions before I start
mob?expm1, note thatintegration_tests/HiSIMSOTB/hisimsotb.vadefines its ownanalog function real expm1. I'd preserve user-defined functions shadowing builtins so that model keeps compiling — please confirm that's the behaviour you want, since the alternative is a deliberate breaking change.Happy to split this into per-feature issues if a single tracking issue is unwieldy.