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)
- N-level nested symbol tables, the Inner* infra, and upstreaming
- MLIR lowering issue HOT 1
- [FIRRTL] Sometimes `cmem` unexpectedly generates no wmask port
- [FIRRTL] Bitcasts reverse bundle field order in LowerTypes HOT 3
- [ExportVerilog] Unpacked array assignment to wire HOT 1
- [LLHD] Typed pointers are deprecated (warning) HOT 1
- [Arc] Support hw.wires of aggregate types
- [CI] Python wheel action is failing on MacOS. HOT 1
- [CI] Separate Python wheel upload jobs for MacOS and Linux.
- [HW] Error compiling with `loc(unknown)` for ports HOT 3
- [circt-reduce] Use upstream MlirReduceLib instead of reimplementing HOT 1
- [Arc] Improve how memory writes are legalized
- [FIRRTL] Improve GroupSink
- [firtool] Directories Incorrect for Probes
- [FIRRTL] Windows builds failing randomly HOT 5
- [FIRRTL] Incorrect multbit mux canonicalization
- [FIRRTL] FModuleOp::getPort() is broken
- [FIRRTL] Property flow checking should ensure we can't assign an output to an output HOT 1
- [HW] Unkown location attributes on HWModule ports missing in serialized IR
- [CMake] Local install doesn't produce CIRCT targets in lib/cmake/mlir/MLIRTargets.cmake HOT 3
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.