Comments (3)
Note that peek() is generally requested to implement arbiters without the need for additional state within the block (or when the outside world uses a pop() as a signal that the arbiter chose a particular candidate).
from xls.
For example:
(token, data, valid) = peek(token, ch0); (token, data0) = recv(token, ch0);
In hardware, the behavior depends on how peek and recv are scheduled. Let's say that they are scheduled in the same cycle. In this case, once the recv occurs, valid will be true and data will be equal to data0.
In an interpreter, one possible sequence of events is that the channel is empty, and peek executes --> data = 0 and valid = 0. The interpreter then blocks on recv. Once there is data on the channel, recv executes and returns data0.
I'm not quite sure this is fully accurate as written, and I don't believe it's necessarily a problem.
One way to think about this is that in both cases, it depends on scheduling. If the peek
is before or at the same time as the recv
, then we get one result (valid && (data == data0))
, but if it's after, we get (!valid && data = 0
).
Currently, the DSLX interpreter, proc IR interpreter, and proc IR JIT don't ever simulate operations as happening simultaneously, so given the token edge, we can only get the ordering peek
before recv
, whereas in HW we could get either peek
before recv
or peek
& recv
in the same stage... so the HW realization allows strictly more execution orders than the interpreter.
This is to be expected, since the interpreter serializes things, and is why logic that involves non-KPN operations can't be fully covered by simulations that don't take scheduling into account. FWIW, we also don't stress-test the results of changing execution order, so the interpreter doesn't even maximize the possible coverage for this scenario within these bounds.
So - I'm not sure we shouldn't just go ahead and implement peek()
? It won't add any new inaccuracies to the interpreter, as it would only continue the pattern we already have... and I'm pretty sure it's impossible to avoid at least some of those inaccuracies before scheduling.
On the other hand, the proposed peek_and_recv_conditional
block expression does have the advantage of being easier to use correctly, at the cost of being more complex to use at all (think poll(2)
vs. fgetc
+ fungetc
).
from xls.
I agree with @ericastor that matching interpreter and hardware behavior generally for latency sensitive operations is really hard to do if not impossible and shouldn't stop us from implementing a generally useful operation like peek
. I can see more complex operations being useful as well like the proposed peek_and_recv_condional
and maybe something like channel select (see https://gobyexample.com/select). However we should probably still support the basic underlying peek primitive.
from xls.
Related Issues (20)
- Logging of `trace_fmt!()` should include source location in *.x file
- Add source location directives in DSLX for trace/error logging
- [enhancement] Add latency-sensitive block construct to DSLX
- [enhancement] [DSLX] Require opt-in "unsafe" keyword to use timing-sensitive operations HOT 4
- Compiler segfaults while emitting verilog with cryptic error message HOT 5
- Compiler bug when generating SRAM blocks using a `for` statement HOT 3
- [Enhancement]: make `trace_fmt!()` emit full file and line/column information
- interpreter failure w/ const_expr bit slice HOT 2
- failing to provide a required parametric func slot should produce an actionable error message HOT 1
- add_with_carry function not found HOT 2
- Assignments with `if` statements are not optimized
- DSLX formatter removes comments around proc channel declarations HOT 1
- [crash] Can not use `map()` on a function that uses `assert!()` or `fail!()`
- Array index with compile-time constant is not optimized HOT 2
- Map return type inference not working HOT 3
- Better error messaging for extra semicolon on last expression in function
- PrioritySelect specialization can be improved
- [enhancement] missed optimization opportunity for duplicated logic in `sel` branches
- The same warning is reported multiple times in parametrized functions
- Type aliases cannot be used in parametric instantiations
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 xls.