[enhancement] [DSLX] Require opt-in "unsafe" keyword to use timing-sensitive operations

[ericastor]

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.

[proppy]

related #1467

[ericastor]

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.

[proppy]

@ericastor understood, while I agree unsafe annotation and block construct look like orthogonal features: I thought it would still be interesting to cross-reference them as, if both implemented, developers will need to adopt a gradual model to reason about "safety-ness" when reading code: a) proc → 100% KPN, guarantee match between simulation and hardware b) proc w/ unsafe block →local pocket of non-KPN ops, recommendation to vet block sim / generated hardware behavior. c) block construct → un-scheduled code, recommendation to vet behavior and timing thru waveform inspection.

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 safe operation permitted in unsafe block? are unsafe operation permitted in block construct? etc)

[ericastor]

For the record, I wasn't suggesting an unsafe block construct; I was suggesting an unsafe proc, the same way Rust has unsafe fn. But I see your point if we were to go that route.

In my proposal, at least, safe operations are absolutely allowed in unsafe contexts. However, proc operations are not permitted in block contexts; as blocks have wires/ports rather than channels, it wouldn't really be meaningful to allow either safe or unsafe proc operations in blocks.

(Also, AFAIK, block constructs would still be vettable using block simulations? But I think we're getting way off topic for this issue.)