Comments (4)
I think adding explicit FIFO operations into the handshake dialect is a good first step. I think @hanchenye has done some of this but might not have it upstreamed yet. Making the implicit fifo size configurable in the handshake runner is also a good idea.
from circt.
Thank you for creating this issue!
There are several things that I'm not sure about and it would be great to have your input on them:
- Why is it necessary to make the handshake-runner a multi-threaded executable? My intuition is that because the FIFO will be dynamically resized, there should be a thread that manages such resizing tasks in the background to avoid overhead. I'm wondering maybe there are other reasons.
- How should we express the unbounded FIFO in the handshake dialect? FIFO seems to be implicitly constructed in designs represented by Handshake. So will the unbounded FIFO be something implicitly lowered from things equivalent to
while(true) {...}
in the standard dialect?
from circt.
- It's not really necessary, but at a certain point as we scale up to larger designs, faster simulation on multi-core machines would be nice.
- Well, there are maybe two different kinds of models. A 'higher-level' model where the connections between processes represent unbounded fifos, and a 'lower-level' model where fifos of bounded size are explicit in the model (essentially they are special kinds of processes) and the connections between processes have no implicit buffering. The simulator today actually implements something in between where an implicit fifo of size one exists on every connection. These differences are subtle, but at a certain point we want to make sure that we model hardware accurately in order to detect that deadlock conditions in the model aren't implemented in hardware.
from circt.
Thank you Steve for explaining these 👍
Well, there are maybe two different kinds of models. A 'higher-level' model where the connections between processes represent unbounded fifos, and a 'lower-level' model where fifos of bounded size are explicit in the model (essentially they are special kinds of processes) and the connections between processes have no implicit buffering.
I'm just wondering whether it is a better idea to enable Handshake to explicitly express FIFOs first before taking care of unbounded FIFOs? Then the differences between high- and low-level models will be the absence/existence of FIFO operations. This might make things a bit easier to understand, and may make future deadlock detection simpler to implement.
Otherwise, if we don't want to introduce explicit FIFO operations, what I'm intending to do for this issue will be changing all the implicit size-one FIFO constructions to some other dynamically-sized FIFO instantiation. Does this sound good to you? :)
from circt.
Related Issues (20)
- [FIRRTL] CheckCombLoops: does not find all comb loops
- [FIRRTL][LowerLayers] Analyze instances and conservatively don't sink them if not safe HOT 1
- [Docs][FIRRTL] Missing intrinsic ops docs
- [ESI] Add readable `__version__` attribute to esiaccel package
- [FIRRTL] extmodule's supporting enablelayer? HOT 1
- [FIRRTL] layer-enable attribute verifier allows module as layer symbol
- [FIRRTL] Layer Sink can sink subfield which is "non passive"
- [ESI][Runtime] Teardown: memory ownership
- [SimToSV] Add includes guard to SV import
- [ExportVerilog] [SV] Open array raw data is not accessible from verilator HOT 1
- [FIRRTL][Layers] ref.send is rejected but is always passive capture HOT 2
- [FIRRTL][LowerSignatures] Const is dropped, breaking IR HOT 1
- Crash in circt-verilog: Assertion `succeeded(result) && "expected ConstantLike op to be foldable"' failed. HOT 3
- circt-verilog: failed to legalize operation 'moore.variable' HOT 5
- [Verif][Sim][Feature] Inline Simulation Tests
- [Moore] Redesign `wait_event` operation
- [Moore] Mem2Reg Error
- [ExportVerilog] Pass should fail if any failure occurs while running HOT 3
- [FIRRTL] Tighten Layerblock Checking of Writes Outside the Layerblock
- [FIRRTL][LowerLayers] ref.send capture of non-passive doesn't work
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.