Feedback loop fix?

[shibin2018]

how I process the feedback?
for example, there are two modules A and B, A has outport bind to B, and A needs the feedback signal of B, when I make a outport from B to A, it will generate DAG CYCLE .

[klingaard]

Hi @shibin2018, without seeing your code, I will assume that the DAG cycle is due to the framework believing data propagation from A -> B is 0 cycles and that the feedback signal from B -> A is also 0 cycles. The framework makes the assumption that the feedback signal from B to A will cause A to send data to B in the same cycle, and that B will then resend the feedback signal to A again causing a potential infinite loop:

  B.feedback(A) -> A.send(B) -> B.feeedback(A) -> A.send(B) -> ...

Ways to fix this:

• Add a cycle to the feedback InPort in A
• Add a cycle to the InPort in B for the data
• Disable auto-precedence in A using this function from sparta::Unit

If you disable auto-precedence the framework will not make the assumption I mentioned above. Instead, the framework will now rely on the modeler to list the precedence rules between ports and events within the unit as well as between units. However, you now have the risk of introducing a DAG during simulation instead, so be mindful.

BTW, I have a small presentation on how this works here.

[shibin2018]

ok, I will try it, Thank you very much!

[shibin2018]

Hi, @klingaard May I ask another question?
what is the differenece between uniqueEvent and SingleCycleUniqueEvent. I can not find the distinction from the definition

[klingaard]

Both SingleCycleUniqueEvent and UniqueEvent share one main behavior: the modeler can schedule either of them multiple times for the same cycle, but the event will only be fired once for that cycle.

    my_unique_event_.schedule();  // This schedules for now
    my_unique_event_.schedule();  // ignored
    my_unique_event_.schedule();  // ignored
    my_unique_event_.schedule();  // ignored
    my_unique_event_.schedule(1); // This schedules for NOW + 1
    my_unique_event_.schedule(1); // ignored

The difference between the two is simply performance and one constraint. SingleCycleUniqueEvent can only be scheduled for either time now or for 1 cycle into the future. This allows SingleCycleUniqueEvent's design to be more efficient than UniqueEvent. By contrast UniqueEvent can be scheduled for any time -- now, 1 cycle from now, or N cycles from now, but the design requires a slight performance penalty in doing so.

I re-read the documentation for these types of events and indeed it's not clear on the differentiation. I'll fix that. Thanks!

[shibin2018]

ok, I see, Thanks!

[shibin2018]

Hi, @klingaard, I come again!
here is another question, how can I realize the function of valid-ready like digital circuit using the dataInport and dataoutport?
I find that when dataoutport send message by dataoutport.send(), the dataInport can receive it unconditionally, can we receive the mesage depend on some conditions?
Thank you!

[furuame]

I find that when dataoutport send message by dataoutport.send(), the dataInport can receive it unconditionally, can we receive the mesage depend on some conditions?

Either adding constraints on Sender's side, or adding filtering if-else on receiver's side. Or you can use cancelIf method when you find you have to cancel the transfer on the certain port.

[shibin2018]

but the link function with the dataInport will be called automaically when message send to the receiver. if I want to use the message under some condition, i need first store the meaasge and then use it?

[furuame]

Yes I meant you can do the following things:

• Check the condition on the sender's side to determine whether to "send";
• Check the condition on the receiver's side (i.e. adding if-else clauses in your handler) to determine whether to return early
• Use DataOutPort's public method cancelIf, then the DataInPort will not be called if the receiving data match your conditions.

[klingaard]

Zen is correct on his methodologies if you do not have a credit system established between the two communicating blocks.

Other methods of doing what you intend:

• Set up a signal ready port between the two units to indicate "can accept." See the Skeleton Pipeline example
• Set up another set of Data[In,Out]Ports between your units that communicate the number of allowable transfers:

  UnitA:
      DataOutPort<Data> data_out;
      DataInPort<int>   credits_in;
      int num_credits_from_unit_B = 0;

  UnitB:
      DataInPort<Data>  data_in;
      DataOutPort<Data> credits_out;
      sparta::Buffer    data_received;

[shibin2018]

ok, I will try it, Thank you very much!

[shibin2018]

Hi, @klingaard , How can I set the precedence beteween event and DataInPort if they are both in Tick phase?, I find that the callback function of dataInport will be called before the event automatically when data in, I need the opposite calling order. I try use >> opertator but it will generate compile error. And you mention that there is auto-precedence in sparta::Unit, what is the auto-precedence? Thank you for answering!

[shibin2018]

Hi, @klingaard , How can I set the precedence beteween event and DataInPort if they are both in Tick phase?, I find that the callback function of dataInport will be called before the event automatically when data in, I need the opposite calling order. I try use >> opertator but it will generate compile error. And you mention that there is auto-precedence in sparta::Unit, what is the auto-precedence? Thank you for answering!

[furuame]

So, is it your desired behavior: You'd like the Event happens before the data being sent to the Port?

[shibin2018]

yes, same cycle I'd like event happens before dataInport callback function

[furuame]

I think there is no direct way to do that. I'm not sure your scenario, but you can consider:

• Move the event to earlier phases, like Update or PortUpdate
• Assign 1-cycle delay to the Input Port, that would make Port handler be triggered in PortUpdate phase of Cycle T+1

[klingaard]

Zhen is correct that sparta does not support a precedence rule that ensures a given event occurs before data arrives on a given InPort. Not sure of the use case here -- why would you need an event to be fired before data arrives on an InPort? How are they related?

Zhen's solutions (putting the Event on an earlier phase) should work.

I don't see any issue allowing this functionality -- just need to establish a precedence between an Event and any InPort that are within the same phase.

Please open a GH issue for this support.

[shibin2018]

Zhen is correct that sparta does not support a precedence rule that ensures a given event occurs before data arrives on a given InPort. Not sure of the use case here -- why would you need an event to be fired before data arrives on an InPort? How are they related?

Zhen's solutions (putting the Event on an earlier phase) should work.

I don't see any issue allowing this functionality -- just need to establish a precedence between an Event and any InPort that are within the same phase.

Please open a GH issue for this support.

ok