Runtime model documentation

[Blebowski]

Hi @nickg,

I was trying to have a look at the PSL dumping into the waves, but I am quite stucked on how to proceed there.

My idea was to extend rt_prop_t with an optional callback element that would be called
from update_property. Such callback would then dump the waveform data based on
iterating the current property bit mask. In the rt_prop_t there is no way how to distinguish
the "initial" and "final" state to get more fine-grained information about the assertion state.
In the first run, I would distinguish just "idle" / "running" state based on non-zero state mask.

Still, I am having hard time digesting the run-time model principles (the nexuses, watches, wakeables, etc...).
It would be much easier had there been some architectural documentation on the run-time
model (or NVCs architecture in general). It would allow studying the fundamental concepts
more quickly (and avoid stupid questions). Of course all that can be figured out of the code,
but it takes lot of time and effort to do that.

I understand you have the project as hobby and writing architecture doc is not what you
want to spend your time on. Still, If you were willing to do so (at least partially), it would
simplify contributing.

[nickg]

It would be much easier had there been some architectural documentation on the run-time model (or NVCs architecture in general).

It may be easier if there was documentation but it's not something I'm likely to write. Documentation requires effort to write in the first place and then continuously update. I'm not even think the current design is particularly good and having documentation in place is just another barrier if/when I come to rewrite it.

I understand you have the project as hobby and writing architecture doc is not what you want to spend your time on. Still, If you were willing to do so (at least partially), it would simplify contributing.

I appreciate your enthusiasm but you're assuming I actually want more people contributing. If people send simple PRs that are mostly OK then I'll merge them. Fine. But I've explained before that I work on this in my spare time because the coding part is fun and a VHDL simulator has a lot interesting problems to solve. Reviewing code and having back-and-forth discussions about design is a chore and sounds exactly like my day job, why would I do that in the evening too? It's great that people find this program useful but I'm not interested in building a larger open source project or community around it precisely because the time spent managing that takes away limited time I have to do the stuff I actually enjoy.

[Blebowski]

I appreciate your enthusiasm but you're assuming I actually want more people contributing. 

Thanks, you are right, it is wrong assumption (as you explained before). Just let me know when
I get too annoying :)

Reviewing code and having back-and-forth discussions about design is a chore and sounds exactly like my day job, why would I do that in the evening too?

Yeah, it becomes a drag. I am at similar point in a daily job (with HW code though).

It's great that people find this program useful but I'm not interested in building a larger open source project or community around it precisely because the time spent managing that takes away limited time I have to do the stuff I actually enjoy.

Understood. Still, it is a pity because the project has big potential.