Philipp Wagner

I did think about cocotb and fusesoc/edalize a bit more, and I think edalize is the wrong place to add support for it. Cocotb is ultimately nothing more than a...

> Would you have a cocotb core file that solely builds the cocotb VPI module The cocotb VPI libraries (one for each simulator) are built during "pip install", i.e. at...

vopt is not called by edalize, as far as I see it -- therefore no options are needed. Or do you see calls to vopt that I missed (entirely possible!)?

Maybe the simplest option is to not have edalize call make with any `-j` argument and document that the user can use the `MAKEFLAGS` environment variable to get parallel builds,...

> I want to avoid adding Makefile-specific things because, as you noted, I want to eventually support other flow executioners (first ninja, but also simpler like just as list of...

I'm mainly wondering about the motivation to have an abstraction between edalize and ninja, or in other words, use cases that ninja wouldn't work for.

pip typically does not change system-wide dependencies, and Jinja is installed in that way on your machine. The error message isn't great and it's not how it normally looks. But...

> Tool in system path: get the ModelSim path from vsim binary. Can you elaborate on that a bit and describe your use case? What is the "ModelSim path"? >...

On MODEL_TECH: I agree getting rid of it would be a good thing, and detecting it from the vsim path sounds good. On providing tool-specific path overrides: I disagree that...

How about going even simpler: Make it one single prefix. If users want something clever, they can have an intermediate script that does exactly what they want (e.g. dispatch Vivado...