On 6/1/23 11:01 AM, dwp@md1tech.co.uk wrote:

Hello,

I have a component with the following spec:

<ComponentSpec>
<Property name='scalingStyle' type='string' stringlength='10' writable='true' default='log'/>
<Property name='maxValueAfterScale' type='ULong' writable='true' default='255'/>
<Property name='verbose' type='bool' writable='true' default='false'/>
<Port name='in' producer='false' protocol='largeIqStream-prot.xml'/>
<Port name='outULong' producer='true' protocol='largeULongStream-prot.xml' optional='true'/>
<Port name='outUShort' producer='true' protocol='largeUShortStream-prot.xml' optional='true'/>
<Port name='outUChar' producer='true' protocol='largeUCharStream-prot.xml' optional='true'/>
</ComponentSpec>

In order to avoid sending unnecessarily large streams of data, the output port that should be used will depend on the value of maxValueAfterScale (0-255 uCharStream, 255-65,535 uShortStream, 65,535+ uLongStream).

Within the RCC Worker for this component, a check is performed that only the correct output port is connected and RCC_FATAL is returned if this is not the case.

  1. Is there a way I can specify within a unit test that I only want certain output ports to be connected? The application file that gets generated has all 3 ports connected with the following test XML:
    <Tests UseHDLFileIo='true'>
    <Input port='in' script='generate.py'/>
    <Output port='outUChar' script='verify.py'/>
    <Property name='scalingStyle' values='log, linear, none'/>
    <Property name='maxValueAfterScale' values='100, 10000, 100000'/>
    </Tests>

I believe the "testoptional" attribute (for input or output) specifies that an optional port is disconnected in the test case.
Not a great name I suppose.  This is in the documentation.

  1. Thinking more generally, how can I test within a unit test that a component fails when it is supposed to, and test the console output it gives in these fail situations.

Since failure can happen for many reasons, there is no such option (to specify that ocpirun returns an exit status of non-zero).

Perhaps some more narrowly specified error condition (i.e. the worker failed explicitly) could be a good option to propose.

The best you could do now is to designate a property that indicated something like that (and perhaps also issue an EOF to end execution early), but that sounds clumsy.



_______________________________________________
discuss mailing list -- discuss@lists.opencpi.org
To unsubscribe send an email to discuss-leave@lists.opencpi.org