• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 373 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

J722SXH01EVM: TIDSP bugs and improvements

Tyler Middleton
Prodigy 110 points
Part Number: J722SXH01EVM


Tool/software:

Hello,

The idea of this thread is not to fix a particular issue, but to note difficulties I have with TIDSP as I try to use it in our system. Hopefully you will find these suggestions helpful in designing the next revision.


1) superNode::exec should be virtual. Your existing superNode subclasses both run fine with the superclass implementation, but I needed a different implementation.

2) superNode constructor should not require an opVec reference (or it can require a const opVec reference). I have a custom superNode I don't want to use opVec for, but it is impossible for me to call the super constructor without creating an empty opVec on the top level

  • 0
    TI__Genius 10170 points

    Hi Tyler,

    Thanks for following up with feedback after the last thread. I had some discussion with the dev team regarding the points you brought up - 

    We understand that your suggestions originate from the requirement for a supernode not to have "opVec" as a parameter. The "opVec" parameter enables us to pass the compute involved in the superNode whilst the data transfer is accomplished in parallel via DMA within the superNode. Are you looking for a superNode that only performs DMA and does not perform any computation? If so, could you please help us understand this requirement?

    Best,

    Asha

  • 0 in reply to Asha Bhandarkar
    Prodigy 110 points

    Hi Asha,

    The supernode in question that I made was similar to the example 2d supernode, but after every n blocks a secondary operation needs to be performed.

    This doesn't fit the opvec model because the flow is transfer -> op1 -> transfer -> op1 -> ... -> transfer -> op1 -> transfer -> op2 -> transfer

    (several blocks being summed up)

    I suppose there may be a clever way to use opvec here, but it seems easier for me to just make a custom exec() loop.

  • +1 in reply to Tyler Middleton
    TI__Genius 10170 points

    Hi Tyler,

    Thanks for clarifying the feedback. I've passed on your use case to our development team to see if this can be addressed in a future release. 

    Closing this now, unless there are any other points you would want to bring up?

    Best,

    Asha