-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[enhancement] [DSLX] Require opt-in "unsafe" keyword to use timing-sensitive operations #1468
Comments
related #1467 |
I don't actually think #1467 is related. This issue talks about making it opt-in to let procs use a few "non-KPN" (e.g., timing-sensitive) operations, but they still use channels & are scheduled; that issue talks about letting users write XLS blocks, which are (essentially) "always blocks on steroids", with direct port access & no scheduling. |
@ericastor understood, while I agree It would be also interesting to discuss if the set of I/O operations between in each safety domain are strictly disjoint or if they can overlap (are |
For the record, I wasn't suggesting an In my proposal, at least, safe operations are absolutely allowed in unsafe contexts. However, (Also, AFAIK, |
What's hard to do? (limit 100 words)
If we're writing code in DSLX, it's difficult to tell at a glance which code may contain timing-sensitive operations - and thus where we can't guarantee that the functional simulations (DSLX or IR interpreters at the function or proc level) will match the cycle-accurate simulations (block-level interpreters) or HW results.
Current best alternative workaround (limit 100 words)
Users can continue to learn directly that they should be cautious when writing code that uses
recv_non_blocking
, as well as any future non-KPN operations we may introduce (e.g.,peek
,try_send
, etc.).Your view of the "best case XLS enhancement" (limit 100 words)
Following Rust, make users opt into a lack of safety when writing procs that rely on non-KPN I/O operations, with something like an
unsafe
keyword that they can tag their proc - and fail to compile if they use an unsafe operation directly inside a safe proc.If we go this route, then just as safe code can call unsafe code in Rust, safe procs should be able to spawn & otherwise interact with unsafe procs.
The text was updated successfully, but these errors were encountered: