vunit
vunit copied to clipboard
VUnit
Simple signal_driver
This is a simple counter-part of the signal_checker / std_logic_checker.
I like this concept, using the message queue as a way to encode a sequence of value changes to a signal without the need to wait for clock edges inside the calling process. To make it more useful with sequences that don't change on every clock, is it possible to extend the drive() function with a parameter 'delay_clocks' (or a better name) with default of 0, that waits for the specified amount of clock cycles?
@smenzel That is certainly possible, probably not even difficult - but I'm very time-limited right now. The PR won't be merged until #520 is done, and then I have to modify this PR anyway. So for the "final" version, I'll include this.
@smenzel The waiting for some time is now included as by VC requirements. Instead of clock cycles, you have to specify a time. I've added two short testcases to check if it does not fall off by one cycle this way. It seems to work. However, the tests rarely cover all applications, so please expect some off-by-one-cycle effects...
@LarsAsplund Added your inputs with a separate commit. Do you prefer that squeezed?
@LarsAsplund Actually, your comment about the stream master interface made me think about the use of this block. I guess one point where it differs from a stream master is that there is no valid signal and the output is always driven. But maybe I should add a generic option to not have the output clocked? That would mirror the signal checker behaviour directly and could have some use.
@eschmidscs I rather have that squeezed. Makes the history cleaner.
The stream master interface doesn't dictate that you need a valid signal. The push procedure has an optional last parameter and it defaults to false. As long as we're pushing data it's a valid interface to reuse. The details about how things are pushed is for the VC to decide so that may differ between different components.
@LarsAsplund Ok, I just squeezed all three commits.
Sorry, I was somewhat unclear: It is not the stream master interface that requires the valid, but the stream master VC (at least the axis one). I was trying to find a reason to have the signal_driver at all. If the axi_stream_master would keep the output stable after valid, it would be some kind of signal_driver, right? Thus the signal_driver could distinguish a bit more by allowing signals to be driven unclocked (i.e. in the moment the push is issued).
@eschmidscs Both axi_stream_master and avalon_source could be reduced to just outputting data if you do not connect the other signals and keep some inputs static. I think the signal driver has a place though. It is more intuitive to use that rather than a bus standard which many would feel is unrelated to what they are trying to achieve.
I think you're right about the clock. Default should be as simple as possible and that means no wait for the clock. The port we're driving might be asynchronous.