- Hide module parameterization function arguments beginning with '_' from operation parameters.
- Module `.output_values()` returns a dict of output ports to Values.
- `System.print` passes through args.
- Use a bitcast in StructCreateOp.create() if the result_type is specified.
- Take advantage of type aliases in naming.
- In creating OutputOps, automatically convert to an alias if the port is just a type aliased version of the value being returned.
- (Unrelated) add class name in _create_output_op messages.
- Adds type checking to PyCDE module instantiations.
- Corrects generate to use types defined in class rather than the example op.
- Adds type checking to Python bindings ModuleLike.create()
- Adds a safety check to ModuleLike.__getattr_() to avoid infinite recursion.
First, some code that attempted to store into an instance variable
that no longer exists. This should have been included in the last PR.
Second, flush the stderr stream in the new struct fields test. This
may not have been necessary on its own before, but in my testing with
both PRs integrated, I was observing the struct fields showing up
after the other output, and FileCheck failing.
After these two minor fixes, the tests pass.
This builds on the previous support to allow naming types through
PyCDE's types module. A new method will declare the registered type
aliases in a given mlir::ModuleOp. Multiple invocations will only emit
each alias once per module. This method is not intended to be exposed
to an end user, rather it is invoked automatically within a PyCDE
System during the user-facing method run_passes.
The _Types is now just a regular instance with instance methods. These
methods now take a possible alias to apply to the requested type. The
aliases are stored and checked to ensure the same alias isn't handed
out to different types.
For new module instances, set to the callsite. For misc creation a generator,
use the location of the generator. I think this is the best we can reasonably
do without upstream support.
An exception during generation typically results from or in invalid IR, so
calling 'print' re-prints the IR validation error message followed by a lot of
generic IR. In short, this hasn't been terribly helpful and is annoying.
Since we want/need to support classes (for sanity's sake in large configuration
spaces), we need to include their data in the MLIR parameters attribute to
avoid duplication.
- Fixes a duplicate definition bug: in the case of parameterized modules, multiple generators (per parameterization call) are created so we cannot store the generated_modules map in the instance. Instead, we look it up in the IR.
- If the module has parameters, append them regardless of potential conflicts. This makes for less confusing code in the common case of multiple parameterizations since the first parameterization doesn't get a special name.
- Add the "pycde." prefix so we don't create modules which have name conflicts with existing RTL modules.
- Extern modules' instances types don't always match the declared types. Allow instance creation to specify the result types.
- (Unrelated) check the return types when creating output ops.
- (Unrelated) ditch the PyCDE version of connect.
If the user doesn't specify a get_module_name or otherwise set the
module_name parameter, use the improved module key as the name.
This will skip renaming for: 1) the first time a module with
parameters is instantiated, and 2) modules that are unparameterized.
To be able to fully skip renaming when all instantiations of a
parameterized module are the same, we'll either need some global data
on the side, or to start putting the parameters into the HWModuleOp.
Previously, different parameterizations of the same module would end
up using the most-recently registered generator and the
parameterization used when it was registered.
This includes the parameterization in the registered mapping, and
looks for that same parameterization when looking up generators. This
is trivially supported since we already store the parameterization as
an attribute on the Operation.
Added a few lines to the polynomial integration test to ensure the
behavior.
This supports lowering the `seq.CompRegOp` to SV operations before
exporting PyCDE Systems as SystemVerilog. The pass is already
registered, and just needs to be plugged in.
After significant restructuring in d52ef85d, a helper was added to
simply retrieve the module's inputs. This is the same for outputs. It
will be generally useful to some upcoming changes.
Require parameters, inputs, and outputs to be declared before operation construction. The supported way is to declare the class in a function then return it. This ensures that all the parameters are in scope for the generators, so they no longer need to be passed into it. This is a rather large refactor but this new way of parameterizing modules makes more sense.
The `generate` call accepts a list of candidate generators to run,
which defaults to empty.
When looking up a generator, the list is consulted. If it is empty,
and there is one generator, that is used by default. If it is present,
and it names one of the candidate generators, that is selected. If it
names multiple candidate generators, an error is raised.
We need the ability to convert Attributes back to python values for PyCDE. The MLIR conversation about this feature, however, isn't going anywhere fast. This includes a hack to get us unblocked until that conversation resolves.
This de-duplicates modules by the following properties:
* The Operation name being generated
* The Operation's Input names and types
* The Operation's Output names and types
* The Operation's Parameter names and values
This allows the same PyCDE operation to be instantiated multiple
times, without trying to define the module multiple times.
- Creating new frontends top level directory which contains frontends which are optionally included.
- Moving @module and @Generator into PyCDE frontend.
- Keeping connect in the bindings since it's used in the bindings tests.
- Fixing the integration tests.
Closes#1179.
John Demme