TMS320F280025C: CLB HLC module read counter value, MOV C0,R3 are incorrect

Hi Cherry,

Can the customer provide some sample C0 values that they are getting? At first glance, I suspect it may be due to some latency between the HLC event trigger and the MOV command, but some concrete values would be helpful to see.

Regards,

Peter

Hi Peter,

Thanks for your help! Here's the values:

Counter0   MATCH1 =  100   MATCH2 =  200

R1_init = 10

HLC Event 0 (e0) = COUNTER_0.count_match1

Program0 :

 MOV C0,R3

SUB R1,R3

MOV_T1 R3,C1

They would like to implement the following feature: Read the value of C0 at COUNTER_0.count_match1 and subtract 10, then write to match1 at C1. The match1 of C1 should be around 90.

Measured waveforms: in most cases, it's normal. Occasionally, exceptions occur.

Figure 1-2 is the normal waveform, and figure 3 is the exception:

Could you help confirm these times:

1. How long does it take to execute from HLC Event 0 (e0) = COUNTER_0.count_match1 to Program0 : MOV C0,R3?

2. what is the instruction period of the HLC? Is it as 10 ns as CLB CLK?

Thanks and regards,

Cherry

Hi Cherry,

Thank you for the additional information. So if I am understanding correctly, the HLC program involving counter 0 works as desired most of the time, but there are instances where it malfunctions (as in the circled part of the waveform in figure 0). Is that correct?

If so, I have some additional questions for the customer:

• Is this issue happening after a consistent number of cycles after running the program, or is the issue happening at random?
• Is the waveform affected for cycles after the "glitch"? From the first set of images, it looks like the counter runs consistently and the counter1 match values do not go high for one cycle. However, in figure0 from your recent post, it looks like the subsequent cycles are elongated after the first "glitch".
• Is pipeline mode enabled?

To answer the questions:

Originally I had thought that the issue was that all C0 value readings were incorrect, as opposed to now in which the issue is that the C0 value is long sporadically. This timing is not documented so I will have to do some research. Ideally, the instruction after the HLC trigger condition should occur in the subsequent CLB clock cycle, and the HLC instructions should take a single CLB clock cycle each to execute.

Regards,

Peter

Hi Peter,

Thanks for your help!

Peter Luong said:

Is this issue happening after a consistent number of cycles after running the program, or is the issue happening at random?

It's happened randomly.

Peter Luong said:

Is the waveform affected for cycles after the "glitch"? From the first set of images, it looks like the counter runs consistently and the counter1 match values do not go high for one cycle. However, in figure0 from your recent post, it looks like the subsequent cycles are elongated after the first "glitch".

They've done some tests, and it should not be caused by glitches. The glitch in the above figures was caused by a C0 reading exception.

Peter Luong said:

Is pipeline mode enabled?

No. But after enabled the pipeline mode, the issue still remains.

Thanks and regards,

Cherry

Hey Cherry, 

Thanks for the additional information. One thing I am wondering is what is the purpose of Counter 0 Match2 = 200? Is the Match2 value being used for anything specifically?

If not, another addition that the customer might want to try is to stop the Counter0 counting whenever counter0.match1 is reached. The customer is saying that they are expecting the match1 value of Counter1 to be 90. By stopping the Counter0 value when counter0.match1 is triggered, it can be assured that the counter0 value will be 100 when it is MOV to R3 and that the counter0 will not go past the match1 value.

This can be accomplished by using the counter0.match1 signal into some LUT and FSM submodules and connecting that to MODEx of the counter0 to disable the counting and reset/resume when necessary.

Please let me know if this can be added.

Regards,

Peter

Hi Peter,

Thanks for your help. New lab data is as follows:

Set COUNTER_0 and COUNTER_1 to start at the same time.

COUNTER_1 is configured as follows:

event =  COUNTER_0.count_zero  

event_load_val = 0

mode1 = 1

What action should be taken on an event trigger = load

They want to implement:

When the COUNTER_0.count_zero event occurs, the COUNTER_1 is loaded = 0 and the COUNTER_1.mode0 = 1 bit is set, allowing COUNTER_1 to count up (This feature is implemented by LUT FSM)

When the COUNTER_0.count_match1 event occurs, clear COUNTER_1.mode0 = 0. Stops the COUNTER_1 count.

COUNTER_0.count_match1 triggers HLC MOV C1, R3 to read the value of C1. The COUNTER_1 is now stopped.

Reading the value of COUNTER_1 should be close to the value of COUNTER_0.count_match1. While the actual test results, most of the time were read correctly, but there still are random exception.

*** HLC MOV C1, R3 reads the value of C1 and allows enough time for COUNTER_1 to be counted up until the next COUNTER_0.count_zero.

Thanks and regards,

Cherry

Hi Cherry, 

Thank you for the additional information. The fact that it is working majority of the time but will miss some match cycles is very strange to me. What does the development environment look like? Are they using a LaunchPad/ControlCARD or a custom board? If there is a custom board, perhaps something may be affecting the device's clock.

Another experiment I think would be helpful to test (before implementing the logic I described in my last comment) is to change the match values to a higher number (for example, let counter0_match1 be 1000 or 2000 instead of 100). And then change the other match values by the same factor. This will increase the period of time between the match conditions. After doing this, does the customer see that the match exception happens less frequently, or even better, not at all? I think this would help us see if maybe the match condition in the original implementation happens too frequently for the HLC to perform the program. Please reach out with the results of this experiment.

Regards,

Peter