Support a second parser (other than Surelog) #319
Labels
enhancement
New feature or request
Comments
|
I have a strong preference for that second parser to be Verible but I don't believe we have the development resources to do that work at the moment? |
|
FYI - @hzeller |
This was referenced Jul 24, 2020
|
I started looking at this and had some questions about the model. Normally when using VPI the model is entirely the instantiated design, so each "module" is actually an instantiated instance with all parameter values set. When looking at, say, the genscope_cells example from the uhdm-integration repo, what I see is a bit confusing: there is an allModules array which has only one copy of the ibex_counter module even though there are two instances in the elaborated design. Is Surelog just picking one of the instances at random (probably the first occurrence) and throwing it into the "allModules" array? How does the tool decide which parts of an instance go in the "allModules" module and which go in the "vpiModule" entry within the genscope array? Are consumers expected to go back and re-elaborate the code in the allModules definition for each instance based on the actual param values? Unrelated, but also wondering why all of the variables seem to be serialized as nets, with a vpiNetType of 36 which isn't one of the listed nettypes in the spec... |
|
@alaindargelas ^ some questions for you |
|
UHDM has a flat list of modules, interfaces, packages classes (Named allModules....) and the Elaborated list of topmodules called topModules with all their respective hierarchy elaborated. The topModules does contain all the elaboration users need and they do not need to perform extra elaboration task. "Unrelated, but also wondering why all of the variables seem to be serialized as nets, with a vpiNetType of 36 which isn't one of the listed nettypes in the spec..." |
|
The instances in topModules does not seem to contain all of the information in the module though. For example, I don't seen any vpiProcesses and associated statements in there, or actually anything from the inside the module itself except for nested generate scopes. I'm using uhdm-dump on the output of the genscope_cells test by the way to inspect the database. Also as far as I can tell the variables are serialized as nets in the topModules tree as well, it doesn't look any different to me. |
|
I forgot, yes all the processes are not elaborated, so they reside in non-elaborated form in the allModules. Yosys and Verilator (The main targets for UHDM for now) do perform the final uniquification of the processes. The respective UHDM-Yosys UHDM-Verilator plugins do pass the elaborated tree from UHDM and the non-elaborated parts from the flat modules. If you check examples like: |
|
Ah, ok. Is there documentation of what gets elaborated and what does not? It's pretty confusing as-is. I see that continuous assigns don't show up in topModules, unless they're in a generate scope and then they do? Or is the model still a work in progress and not ready for another implementation? |
|
I'll write up a complete description of the elaboration in the README
shortly.
Essentially, we are trying to keep the model as folded as possible, until
it really needs to be uniquified. The examples you give are an illustration
of that.
The allModules will contain the processes and assigns at the top module and
placeholder ports and nets.
The topModules will contain the hierarchy, the elaborated nets with the
correct type. the generate statements, the logic generated in the generate
statements...
The plugins for Verilator and Yosys do a bit of assembly. Making the model
fully elaborated, is actually quite trivial (clone everything all the
time), but the memory required is quite large and make the downstream
plugins have to explicitly translate every object to the native data
structures of Yosys and Verilator which in turn do some elaboration (memory
bloat).
Keeping the model folded saves on the plugin memory footprint, also des not
replicate what the client applications are doing in their internal
elaboration anyway.
But we could easily create an optional fully elaborated model (with all the
objects cloned from allModules to the topModules for regression purposes,
say to compare the UHDM generated model in between our 2 implementations.
…On Tue, Aug 17, 2021 at 9:23 AM Michael Popoloski ***@***.***> wrote:
Ah, ok. Is there documentation of what gets elaborated and what does not?
It's pretty confusing as-is. I see that continuous assigns don't show up in
topModules, unless they're in a generate scope and then they do? Or is the
model still a work in progress and not ready for another implementation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>,
or unsubscribe
<https:/notifications/unsubscribe-auth/APFYJ5H4OGITAORN7Z4ZHB3T5KEIBANCNFSM4PHESB4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
Thanks, that makes sense. Have you thought about alternative models that would more compactly represent the elaborated design? It seems like if you require all downstream consumers to reimplement all of the type checking and propagation logic it somewhat defeats the purpose of UHDM being the full frontend, as that logic is quite complicated. You say that it's simple but I don't see how it could be; changing the parameter values for a module can result in wildly different types involved in each expression of a process / continuous assign. |
|
UHDM is a R/W model, so all the uniquification/type checking can be done
and annotated/substituted in the model itself by subsequent passes.
For Instance the -elabhm option of Surelog simply calls the UHDM Elaborator
class that clone UHDM objects (Say an assign stmt in a generate block and
bind the variables to the variables in the scope of the generate). That is
done by reading UHDM and writing back into UHDM. All the constant
propagation required to perform elaboration is done by Surelog, but
expressions that are "runtime" expressions are left unevaluated. One can
write an Evaluator on top of UHDM and decide to perform more evaluation
based on the UHDM model.
Similarly with the load/driver data, that can be computed from UHDM and
annotated back into UHDM.
All of these middle layer applications are in the TODO list.
To date I see 2 types of customer for UHDM,
- the Yosys/Verilator applications that already perform the additional
tasks above (So not an emergency for them),
- The lighter weight applications like State machine analyzer, netlist
viewer, linters that would benefit from these extra services but who
already make good use of the folded model.
…On Tue, Aug 17, 2021 at 1:39 PM Michael Popoloski ***@***.***> wrote:
Thanks, that makes sense. Have you thought about alternative models that
would more compactly represent the elaborated design? It seems like if you
require all downstream consumers to reimplement all of the type checking
and propagation logic it somewhat defeats the purpose of UHDM being the
full frontend, as that logic is quite complicated. You say that it's simple
but I don't see how it could be; changing the parameter values for a module
can result in wildly different types involved in each expression of a
process / continuous assign.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>,
or unsubscribe
<https:/notifications/unsubscribe-auth/APFYJ5HSIH6TNAZ5VE3MAYDT5LCHPANCNFSM4PHESB4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
@MikePopoloski, coming back to this after a while, sorry... surelog -parse -elabuhdm -d uhdm -d vpi_ids Produces the following fully elaborated tree (including processes and assigns): |
|
No problem, thanks for following up. I think I understand the two different modes now, and the additions to the README are helpful. I'll ask more questions as I run into them. Also as a side note, my original point about the nets instead of variables still stands. The original code declares a variable (just picking one as an example): but the UHDM dump has it as a net instead: |
|
Got it now. Since Surelog does not do driver/load analysis as of now, it can't know if he usage of a variable and assumes everything that is declared as a logic is a net. |
|
Oh, it's much simpler than that. A net declaration has a net type specified, and otherwise it's a variable. logic is a data type, not a net type, so the declaration is a variable. Net types are things like "wire", "tri", etc. You do need to handle user-defined nettypes but they are very rare in practice. |
|
OK, let's spec it out: module top (input logic in); // wire ? Page 704 of the 2017 standard has a lot of examples where ports of type wire are equivalent to "wire logic". |
|
Yes, that's right. The rules for ports are more complicated as you mention but still fully determined by the declaration itself and not how they are used. 23.2.2.3 has the algorithm for determining net vs variable for ports when not explicitly specified. |
|
The following put request: "fix net var to match standard chipsalliance/Surelog#1809" should fix this issue. |
I'm trying to replicate the kind of output you got here -- with the scope hierarchy. Using |
|
You are navigating the vpiAllModules instead of the vpiTopModules top level iterator. |
|
If you send snippet of code, it would be easier to point to the issues. |
|
Yeah, works with uhdmtopModules. So, just to conclude: If so, is there any {helper code/advice} you could {point to/give us}? Thank you so much! |
|
You got it.
That way you can navigate the uhdmTopModules and don't need to go to the uhdmAllModules. Memory is larger or course, but all types and sizes are uniquified. |
|
Wow, neat! Thank you |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The goal of UHDM is to allow "users" (like Yosys, Verilator and Icarus) of a SystemVerilog parsers not to care about the exact parser implementation. However, currently the only parser which exposes the UHDM interface is Surelog.
Adding a second parser which also exposed the UHDM API would help verify that the API isn't over fitted to Surelog in any way.
The text was updated successfully, but these errors were encountered: