Adds a backend for Cap'nProtoRPC-based cosimulation to the generated ESI runtime API. Makes said API actually useful for interacting with a simulation. In the (near) future, backends will be implemented for real hardware. Also adds a test.
Added the `ServiceDeclOpInterface` which is intended to be implemented by any op which'll be a service declaration. Has methods to get the list of service ports and validate a connection request. The introduction of a struct which describes a service port allowed me to clean up a bunch of code. This changed the error messages, requiring an update to the errors test.
Also took this opportunity to standardize terminology on `toClient` and `toServer` to provide better clarity. Was helpful in debugging this change.
Endpoint IDs differ by simulator by prefix, wherein the prefix is based
on the top module. Instead of specializing tests to the simulator,
automatically prepend the endpoint ID prefix to endpoint IDs on open
requests.
Build a model of the ESI system described in a `services.json` file. No 'backend' connectivity providers in this cut. Only integer types are supported for now.
Start of support for building specialized software APIs!
- Create an op to hold metadata about services being implemented.
- Create them when we create the implementation request.
- Copy them up the instance hierarchy modifying the 'path' as they get moved up.
- Rename the capnp schema pass to the more generic "emit collateral" pass.
- Emit the service hierarchy information for the top levels in said pass.
No more custom makefile generation and 'make' commands - this is handled by cocotb-test.
Eventually, we expect support for driving cocotb from within python to be included in a future cocotb release. The support in `cocotb-test` is currently identical to the (unreleased) support in upstream `cocotb`. Hence, we use `cocotb-test` since they publish a pypi package that can be easily downloaded.
Fixes an issue in PyCDE gen_fsm helper that causes all transitions to use the last guard. Fix captures the intended guard_port name at lamba creation time.
Co-authored-by: Aaron Landy <aalan@microsoft.com>
Allow users to request bidirectional channels (InOut). Decomposes into
one `to_server` and one `to_client` request. Cosim will detect that and
wire them up to the same endpoint.
- Add PyCDE service generator 'dispatcher' which gets called upon request from the wiring pass, then forwards the call to a generator which it has in its registry.
- Add a `ServiceImplementation` decorator to tag and mutate a class appropriately.
- Calls the `ServiceImplementation` generator passing both the usual module ports and the requested ESI connections.
- A few relevant fixes/additions to supporting code.
Using `__new__` to redirect construction to a specialized class had too
many side-effects. Trying to get around them led to convoluted code.
Move back to a function-based dispatch method.
* Bump LLVM
Bump LLVM to the current top-of-tree.
This requires changing a few `Attribute`s to the new `TypedAttr`
interface, since attributes no longer carry a type by default. We rely
on this type in quite a few places in the CIRCT codebase, which required
a switch over to `TypedAttr`.
See: https://reviews.llvm.org/D130092
Co-authored-by: John Demme <john.demme@microsoft.com>
Allows specifying muxes with `if`-like syntax. This is the closest we can
get without having to do AST inspection (I think).
```
@module
class IfDemo:
cond = Input(types.i1)
out = Output(types.i8)
@generator
def build(ports):
with If(ports.cond):
v = types.i8(1)
with Else:
v = types.i8(0)
EndIf()
ports.out = v
```
This commit represents a starting point for PyCDE+cocotb integration.
Currently, only iverilog is supported, seeing as verilator has questionable cocotb support (https://github.com/cocotb/cocotb/issues/2300), with questa posting another set of challenges locally.
Given the limited capabilities, the support is at this point mostly intended for PyCDE integration testing.
The "support" is mainly syntactic sugar in terms of moving things around to make PyCDE-like code fit into a cocotb flow.
The @testbench decorator defines a testbench on a PyCDE module. In here, @pycdetest functions are expected to take a single argument representing the top-level ports of the PyCDE module under test.
This function may then contain any cocotb-style code.
Under the hood, @testbench will:
1. Run the PyCDE flow, generating an SV file
2. Verbatum copy the @pycdetest functions to a separate file, rewriting these to conform to cocotb.
3. Create a makefile for driving the cocotb flow
4. Run `make` and let cocotb do its thing.
This commit adds support for infix operations on PyCDE bit vector values. Arithmetic operators are implemented through `hwarith` operation, logic operators through `comb`.
cleanup
review comments
Adds PyCDE constructs to model ESI service declarations and request connections to/from them. Also contains a "standard" `HostComms` interface and rudimentary way to get a cosim implementation.
This commit adds support for infix operations on PyCDE bit vector values. Arithmetic operators are implemented through `hwarith` operation, logic operators through `comb`.
Generate a FSM from a dictionary of states and their transitions.
E.g.:
```
{
"a": [
("c", "go"),
"b",
],
"b": [],
"c": []
}
```
creates an FSM with 3 states (a, b, c). 'b' and 'c' have no outgoing transitions, and 'a' has two outgoing transitions. The first transition ("c", "go") transitions to 'c' whenever an input port 'go' is asserted. The second transition is a default transition to 'b'.
Any state and guard referenced within the dictionary will automatically be created as a state operation and top-level input, respectively.
John Demme