Nick Gasson

Yes I think the flow will be parse -> generate FSM -> lower to vcode, and then the rest of the code generation is as if it's a normal VHDL...

I've pushed what I have. It's mostly just the parsing part.

I added some basic runtime support in [9f3ad9e](https://github.com/nickg/nvc/commit/9f3ad9ee42a0ae3ccc38ef098388cbab6a6dd267). It can handle very simple assertions like `always x -> next y` but nothing more.

I don't have particularly strong feeling about this. AFAIK people normally only expect simulators to implement the simple subset but supporting more seems fine if it doesn't add extra implementation...

I'm going to close this now as the VHPI implementation is more-or-less at a point where it can run cocotb (@Forty-Bot did most of the work).

If you update to the latest master branch of nvc those VHPI errors should be gone (actually they are hidden unless you pass the `--vhp-debug` flag). By default all diagnostic...

I think this is not valid - the procedure cannot be instantiated until its body has been analysed - but it still shouldn't crash. It now produces an error: ```...

Hm, ok. But it's not clear to me how this could be implemented.

I need to do some refactoring of how subprogram instantiation works.

Should work now, sorry it took so long!