Comments (5)
I'm not sure this can be accommodated without some significant changes + overhead re:tracking/indirection and if cannot be done in a single pass (+pre-pass for top-level declarations) should be considered carefully.
Yeah, this would need to be thought through carefully if we want to support this. Unlike modules, which can't have other modules in their signature, type aliases and object references can show up in signatures of modules and classes.
do we really parse class names in lexicographic order and not the order they appear in the file?
Sorry, I think I meant lexical order. What I mean is top to bottom in the order they appear in the file.
from circt.
Yeah I think we shouldn't reject this (actually the same error would happen for type aliases as well). This might be tricky because currently class types on ports are computed form classOp itself so it's hard to fix when there are classes that reference each other on ports.
e.g.
FIRRTL version 4.0.0
circuit Bar :
module Bar :
input foo :Inst<Foo>
module Foo :
input foo :Inst<Bar>
from circt.
Is possible to delay the classOp construction?
from circt.
This is a shortcoming of the current FIRRTL parser for classes, which is taking a single pass in lexicographic order.
So for the short term, if you know you're making Foo, and you're making a Bar with a reference to Foo, you can try to re-arrange your generator to produce Foo before Bar.
Another option is to type erase the instance type in Bar. Rather than a Class.unsafeGetClassTypeByName("Foo")
, you can construct a Property[AnyClassType]
. You are allowed to connect a reference to Foo to a Property[AnyClassType]
, and this will be handled transparently in FIRRTL and the OM dialect evaluator. This doesn't allow you to access fields of the foo
, because if the type is "any", we don't know what fields are legal. But if that is not required, that's another short term option.
The longer term option to handle this in the parser would probably require taking multiple passes through the textual FIRRTL to collect all the class names before parsing the class bodies. This is what we do for modules, so things like this are legal:
circuit Bar :
module Bar :
inst foo of Foo
module Foo :
skip
from circt.
Yes, cannot use type aliases or classes defined later in the file.
Modules we parse their signatures in one pass and then the bodies after -- this approach doesn't work for type aliases or classes which each may contain in their signature references to other types (aliased or classes). For this reason, module signatures also must only use types (aliased, classes, so on) defined before that point in the file.
We parse directly into typed IR and rely on this for diagnostics (e.g., accessing a field of a type that isn't a bundle or is but doesn't have one of that name).
Def-before-use policy also avoids various sorts of cycles -- mutually recursive type alias, so on -- that would need to be checked for otherwise.
I'm not sure this can be accommodated without some significant changes + overhead re:tracking/indirection and if cannot be done in a single pass (+pre-pass for top-level declarations) should be considered carefully. Mostly thinking about type aliases -- but probably class ref types too?
(BTW - do we really parse class names in lexicographic order and not the order they appear in the file? (!))
from circt.
Related Issues (20)
- [Docs] Installing Python bindings with pip HOT 1
- [FIRRTL] LowerClasses doesn't actually copy the leading part of the path from the owning module to the start of the NLA HOT 1
- [FIRRTL][DropConst] Preserve alias?
- [FIRRTL] LowerClasses should enforce single instantiation
- [HW] Incorrect SSA names for instance op. HOT 4
- [FIRRTL][LowerLayers] Lower layers does not update HPs of non-local annotations
- [HW] InstanceOp verifier failure HOT 3
- Windows compile error HOT 8
- [FIRRTL] Instance cycle - diagnose, don't crash
- [FIRRTL] Dialect/FIRRTL/lower-dpi-error.mlir failed in nightly integration tests HOT 1
- [CI] ccache doens't work on nightly integration tests HOT 6
- [CMake] Installation fails if SLANG_ENABLE_FRONTEND is enabled HOT 13
- [SimToSV] Lowering fails if a DPI call result is consumed by another
- [SV][HW] Introduce hw::HWFunctionType and use it for Sim/SV function ops
- [FIRRTL] Unsafe parallel mutation of IR in SpecializeLayers HOT 5
- [CMake] Both local install and compiled release usages failing HOT 2
- [Seq] Unify HLMem and FIRMem HOT 2
- [ImportVerilog] Upgrade slang to slang 5
- [Seq] FirReg is not appropriate for the seq dialect
- [Seq] Add reset type
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from circt.