-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add native Yosys/Nextpnr support #14
Conversation
I managed to resolve the Yosys WebAssembly runner issue; the hard nodefs dependency appears to be emitted directly by their icestorm project (here and here) and only gets executed when being compiled by emscripten and running in a nodejs environment. I wrote a small WebPack plugin to patch those nodefs mount calls out of the final bundle and removed the directories it tries to create before starting up yosys, which appears to resolve the issue. I think a long-term solution for this would be to submit a patch to their repository and add some kind of compilation flag so we can build Yosys without that dependency, as the current fix is definitely not great (it's a simple regex find-and-replace). I'm going to un-draft this PR as I don't think it will change much anymore, if at all, although it does still need more testing for all the different environments the extension will run in. I'll try to test it a bit more in the coming days. |
The import promise only rejects once, so any successive attempts would throw a different error
resolves #6
In the "old" implementation, Yosys/Nextpnr tasks were subclasses of
WorkerTaskTerminal
. Since this class was rather biased towards the webassembly implementation, I've refactored most of this code to decouple the tasks and webasm code from each other.Changes to existing code
WorkerTaskTerminal
is now calledTaskTerminal
, as it only handles terminal-related tasks and does not necessarily spawn workers anymore. Instead, it accepts aTerminalTask
in the constructor which it will set up, run and monitor.NextpnrTaskTerminal
and friends now subclass a new class:TerminalTask
. The implementations are largely the same, but this allows us to pull task-related code such as finding the command/args and i/o files into the task itself, decoupling it from theTaskTerminal
. They store these arguments in aRunnerContext
data structure, which can be passed on to aRunner
for actual execution.TaskTerminal
and into aWebAssemblyRunner
. It will set up, start and monitor the worker using the existing callbacks.Runner
s andTerminalTask
s allow setting a callback forTerminalMessage
s (println, error, done).TerminalTasks
proxy messages from theirRunner
straight to theTaskTerminal
by re-emitting the message, but they can send messages themselves as well.TODO
Currently broken since we need to use theworker_threads
API which is incompatible with the web workers one