Lenny Truong

@pmaupin Interesting point of view! Makes sense to me and does seem like a better approach.

Yes, if you'd like to pursue using this on windows native, we'll need to start with buildling coreir succesfully on that platform, so I would suggest opening an issue in...

Could we do it similar to how we handle loops/if? E.g. `task1 = tester.create_task()` and task1 provides the tester interface for doing the actions? Seems like we could track a...

That all sounds reasonable. Do the timing controls usually use the SV wait statement?

For 2. are you using the syntax `tester.circuit.O.expect(value)`? If so, you can try `tester.expect(DUT.O, value)` instead. The `tester.circuit` syntax has some intrinsic performance issues (it uses the inspect library). Using...

Looking at https://github.com/Kuree/kratos-dpi/blob/master/tests/test_function.py#L18-L28, it does seem quite nifty, I think we could simply integrate this into fault by having `fault` be aware of these DPI functions and generate the code...

e.g. `tester.expect(test.call(, ...args))`, so we could add a `call` action that accepts a DPI function and generates the code to invoke it

Actually for 2. I noticed now that you're using the `lassen` PE to compute the expected result, so that doesn't make it easy to do the file based pattern unless...

Also, are input values being generated ahead of time? (I'm guessing so since expect values are generated ahead of time). That might be a related problem, having to store all...

Thinking about this pattern at a higher level though, it seems like ideally the functional model should not change (maybe every so often when obscure bugs are found). So, pre-computing...