Add 'wait for' clause to output-only VHDL models

[iwbnwif]

This avoids creating an infinite loop as these models do not have any sensitivity lists (i.e., 'inputs') to create the necessary timing.

I am not sure if it is right to hard-code the 'wait for', but I can't see that abstracting it to higher up is that helpful either.

[iwbnwif]

See #395

[ra3xdh]

Thanks for the fix! Merged.

[zergud]

@iwbnwif @ra3xdh

I haven't touched digital simulations for a long time, but maybe we should use "wait for 0 ns" there?
so as not to introduce additional delays
"The wait 0ns forces the simulator to wait one delta cycle before processing the next instruction "
I don't have ghdl configured and can't test it

[iwbnwif]

Unfortunately, wait for 0 ns fails to simulate using my test setup. I tried wait for 1 fs, but that makes the simulation extremely slow.

I will look into if there is another way to minimize the delay without disrupting the simulation.

"The wait 0ns forces the simulator to wait one delta cycle before processing the next instruction "

Is this statement from the GHDL manual as I couldn't find it?

It is worth noting that this delay only affects the logic x and nBit Pattern devices which are initialized at the start of the simulation so it is only the first cycle (1 ns) that will be affected. From then on, everything will work normally. I am not sure why the simulator doesn't optimize away the successive cycles, but maybe it performs the whole simulation at the smallest granularity of the design? of course, it may be a problem with my test bench!!

[zergud]

Unfortunately, wait for 0 ns fails to simulate using my test setu
understand

It’s interesting to understand the question: why did it work in FreeHDL?
also Qucs/qucs#830 (comment)
there is no mentions about add "wait for"

p.s. maybe this PR is the only and correct solution.. sorry ;)

[iwbnwif]

Not at all, it's an interesting point!

The "wait for" was added in response the problem identified here: #395 (comment)

I had a quick look at the GHDL github and all the tests and examples use 1 ns or more. So this may be a problem with GHDL.

I'm guessing that 1 ns is thought suitable because it represents a shorter time than most FPGA hardware can transition and therefore is negligible in terms of effect on the overall simulation.

[zergud]

as mentioned here https://stackoverflow.com/a/70672467
we can try fill sensitivity list for process

[iwbnwif]

Okay, but as I said in my first comment to this PR, there are no inputs to the blocks so I am not sure what would be in the sensitivity list.

My understanding is that these Qucs-S blocks are a convenient way to provide a static input (single bit, or bit pattern) - sort of hardwired logic.

I suppose we could synthesize a 'start' pulse that is automatically generated at time zero, but this might add complexity and not achieve much! As I mentioned above, the only place that you will see this delay is in the first 1 ns of simulation and that is quicker than the actual hardware anyway ;)