TMS570LS3137 N2HET and HTU requests

For example, the below code does not work:

S00
L00   ECMP { en_pin_action=ON,pin=2,action=PULSEHI,reg=A,data=0};
L01   BR { reqnum=0,request=GENREQ,cond_addr=S00,event=NOCOND};

and below code works fine:

S00
L00   ECMP { en_pin_action=ON,pin=2,action=PULSEHI,reg=A,data=0};
L01   CNT { reg=B,max=1};
L02   ECMP { next=S00,cond_addr=L03,pin=0,reg=B,data=1};
L03   BR { reqnum=0,request=GENREQ,cond_addr=S00,event=NOCOND};

The HTU request 0 is configured to transfer the value from the main memory to L00 data field in both the cases.

Hello Gobind,

I have forwarded your issue to one of our NHET/HTU experts. They should reply to your issue shortly.

Hello Gobind,

  Can you tell me the PFR register setting that you use to setup the loop resolution clock period? It is possible that the amount of time taken to transfer the data from the main RAM to the HET RAM is longer than one resolution clock if the loop resolution clock is short. It takes cycles for the HTU request generated by the NHET to be registered by the HTU and based on the request to advance its state machine and start the bus transaction involving reading from the main RAM and then write to the HET RAM.

The PFR register is set to 0x400. i.e., LRP = 16 cycles. The HET Clock is 80MHz. HR clock is same as HET Clock.

Hello,

  16 cycles may be tight but I think it is sufficient for the HTU to read data from the main RAM and write to the HET RAM. One thing to also check is about the HTU overload. Please go to the HTU chapter in the TRM and look for the section "HTU Overload and Request Lost Detection". It describes the scenarios under which a very frequency HTU request may be lost.

  Looking at your below code you didn't start with an CNT. Normally, a CNT-ECMP pair is used to generate PWM. Without the CNT you are comparing the ECMP data field with the register A and the register A is not known. Mostly likely register A contains just the reset value.

S00
L00   ECMP { en_pin_action=ON,pin=2,action=PULSEHI,reg=A,data=0};
L01   BR { reqnum=0,request=GENREQ,cond_addr=S00,event=NOCOND};

Thanks Charles. I added the CNT instruction before the ECMP. (I thought the register A if not initialized will be zero, but it was not true.)

Also I tried with LRP 32, 64 and 128. They all worked fine with no problem. But as soon as i change my LRP to 16, the HTU requests are lost. And if I set CORL bit in RLBECTRL register, it looks like every alternate request is lost and i get the same output as i got with LRP 32.

Does this mean that HTU takes more than 16 cycles to process the request?

Thank you.

Hi Gobind,

  As I said., 16 cycles will be tight but I thought it could be sufficient. I think you have proven that 16 is not sufficient. As I mentioned in the earlier reply, yhe request signal generated by the NHET will first be sampled by the HTU. Once sampled, it will advance the HTU's state machine to initiate bus transaction. Since this is a transfer from main RAM to HET RAM, the HTU will first need to read the data from the main RAM. The bus transaction can go through some infracstructure componenets in the device before the bus transaction is routed to the CPU's AXI-Slave interface. All accesses by non-CPU masters need to go through the CPU's AXI-Slave interface in order to access the ATCM/BTCM interface memories. Inside the CPU there will be arbitration between CPU's PFU and LSU and the AXI-S access. If there is conflict among the three then the AXI-S will be the lower priority. CPU's LSU has the highest priority. Once the data is returned to the HTU it will be first stored in a buffer before it is written out to the HET RAM. Again there will be some arbitration involved if the HTU and the NHET are both writing to the same NHET RAM bank. HTU will be of lower priority compared to the NHET. 16 cycles (in terms of VCLK2) could be a bit tight and I think this explains your observation.

Hi Charles,

Thank you.

Is this limitation (overloading of HTU) also applicable if i raise two DIFFERENT HTU requests? I mean, if i raise a request on channel 0 and another on channel 1 in a single LRP of 32, will the HTU be still overloaded?

Hi Gobind,

  This is possible. If there is a overload situation for one request in a LRP of 16 cycles then  it is certainly possible to have the same problem with two requests even if you increase the LRP to 32 cycles. It is still tight. In the first LRP two requests are generated. The HTU must complete the two different channel transfers before the next LRP starts in which two more requests will be generated again. Depending on the application, you might want to consider using one request to transfer two different data instead of using two different requests. Using a simple example, let's say you have just a CNT and two ECMP instructions. Instead of using each ECMP to generate a HTU request, you can consider using the second ECMP to generate the HTU request but in the HTU contol packet setup, you will transfer two elements to the data fields of the two ECMP instructions. In this case, you eliminate the overhead of launching a new channel transfer.