PSOC 5 32-Bit UDB Timer Running at 80 MHz

[ErNo_1148106]

Hi All,

 I am aware that if I try to run the 32-bit UDB timer component at 80 MHz it gives me a setup time violation warning. Is there any way around this? I need a 32-bit timer or some way to be able to generate an interrupt when a 32 bit value reaches a specific value. I thought about using the PLD logic but unsure if I go to all the trouble writing a verilog component that too will create a timing violation. Any Ideas? 

Thanks,

Eric 

[odissey1]

ErNo

Please check this thread

Phase offset and Quadrature signal generator for lock-in 

It contains custom 32-bit Counter_ex component, which can operate up to 80 MHz. Internally it is a standard Counter component, which has been optimized to operate at higher frequency (so standard datasheet remains handy). Since Timer, Counter and PWM are practically same component, it should be possible to utilize this Counter_ex instead of the Timer.

     I believe that supplemental project is very close to your requirements.

/odissey1

[ErNo_1148106]

Thanks Odissey1 I'll check it out 😁

[ErNo_1148106]

Hi Odissey1,

 I added it to my design and I can select up to 24-bit and it not give me a timing violation but if I go up to 32-bit it gives a violation. I will try it in system tomorrow and if it doesn't work I might have to write a custom component. I created a custom laser controller and the step pulses have to be accurate otherwise it skews things a bit and that is not acceptable. 

If I were to create my own verilog 32 bit counter and compare unit can the PLD's in PSoC 5 go to the full 80 MHz? I want to make it purely hardware and have control registers write the 32-bit value and then when the counter counts up to the value loaded trigger an interrupt and restart the counter.  Let me know what components would be a speed bottleneck.

Thanks,

Eric 

[odissey1]

ErNo,

From my experience, the 32-bit counter realized in PLD, will be limited to 30-40MHz.

I believe the 32-bit Counter_ex itself can go over 80 MHz. I suspect that there are other parts of your schematic, which limit frequency. Can you post a screenshot or send it using private messaging?

     I suggest to set system operation range to 0-85C to see improvement and add Sync component on critical paths on the schematic. To make it easyer, you can utilize a custom Sync32 component, which doesn't take space

Sync32 custom component for PSoC5 and PSoC4 

/odissey1

[ErNo_1148106]

Hi Odissey1,

Here are the images of my design:

As you can see I don't have anything that would really violate the timing unless there is something I am not seeing. As you can see from the first page the STEP TIMER is 24-bit and the clock is set to 80 MHz. I have an external 12 MHz 10 ppm crystal connected to the PSOC 5:

Here is another picture of the clock list:

As you can see here the example uses a 16-bit UDB component and it works up to 80 MHz no problem:

Any suggestions I am open to them 😁!!

Thanks,

Eric

[odissey1]

ErNo,

Sorry for misleading, but the Counter_ex goes maximum to 68 MHz in 32-bit mode, and ~81MHz in 24-bit mode. 

If 32-bit mode is REALLY important for driver operation I see following options:

1. Ignore Setup Time violation Warning. It is likely that project shall work OK at ambient temperature, and only degrade at low end, T<0C. It is only low temperature limit which affects the signal propagation. From my experience with laser drivers, they mostly run at 40+C, so there should be no problem.

2. Lower the BUS_CLK to ~68MHz. Since project utilizes software control through the interrupt, actual precision is no longer 32-bit: the interrupt risetime (10-15 clocks) plus time to execute the interrupt code itself shall degrade 32-bit precision. You  will actually get better precision at 68MHz if "tc" and "comp" outputs directly control hardware logic.

[ErNo_1148106]

Hi Odissey1,

 I tried the first approach and although it compiled fine with the violation the counter didn't run. I might be missing something but looking over the functions I don't think I am. I went back to using a fixed function timer with 16-bit and it runs so I might just stick with this. The only thing I don't like about not having the 32-bit timer or counter is that I sacrifice some tracking and it is visible in the marking as it leaves a high spot in the material in the middle compared to the edges as the speed changes because the rpm calculation is also used for the laser pwm output as it scales it so that the output is consistent with speed and that is why I am critical of the whole thing being 32-bits. If you can think of any other ideas I am open to trying something.

Thanks,

Eric

[RodolfoGL]

One suggestion.

Create a project that only contains the 32-bit counter. Based on the discussion, it seems this will not have any warnings. 

Now capture the location in the UDBs of the datapaths used by this counter. You can get this information in the *.rpt file. 

Then, go back to your original project and force the UDBs to go to that location. You can use control files to force that.

https://community.cypress.com/t5/PSoC-5-3-1-MCU/Creating-a-Control-File-to-Replace-Directives-cydwr/...

See if this solve the problem or at least improves the results. You can start adding other elements in the design and forcing their placement till you get something without warnings.

[odissey1]

RodolfoGL,

Thank you for the tip. Unfortunately, even in empty project, the Counter_ex in 32-bit mode shows limit of 68.7 MHz (0-85C).

On the other hand, I am surprised that laser timing might really need a 32-bit precision. We live in (mostly) 8-bit world, so 24-bit should suffice. 

[ErNo_1148106]

Hi RodolfoGL,

 Ill look into this.

Thanks,

Eric

[RodolfoGL]

Looking again at your TopDesign, I agree with odyssey1, it doesn't seem you really need a 32-bit timer. You basically implementing a SysTick timer. There is no external signal driving your counter. You just want to clock at 80 MHz, so why not use the SysTick timer?  You woudn't get 32-bit, but you get 24-bit at least.

If you need a 32-bit value, you can easily assembly that on your ISR. Just do something like this:

void systick_timer_callback(void) { systick_ov++;}

uint32_t get_tick(void)

{

    return (0xFFFFFF - CySysTickGetValue()) + (systick_ov * 0x1000000); 

}

[ErNo_1148106]

Hi RodolfoGL,

 Funny you mention the SysTick timer as I thought about this earlier but it is only 24-bit as you said. The STEP_isr interrupt drives the motion of the system and has to be accurate. How accurate and repeatable is the SysTick Timer from an interrupt and cpu intervention standpoint? Im looking for something that won't burden the cpu any more than it has to at higher speeds. I can't have any lag in the time it takes to fire the interrupt and then resume the job it was doing. The heart and what sets the Period of the timer is this:

dt += prep.dt_remainder; // Apply previous segment partial step execute time
float inv_rate = dt/(last_n_steps_remaining - step_dist_remaining); // Compute adjusted step rate inverse.

uint32_t cycles = (uint32_t) ceilf( (float)(F_CPU)*60*inv_rate ); // (cycles/step)

prep_segment->cycles_per_tick = cycles;

I then do this in the same STEP TIMER interrupt routine:

// Initialize step segment timing per step and load number of steps to execute.
STEP_TIMER_WritePeriod(st.exec_segment->cycles_per_tick);

Isn't there a 32-bit timer inside the Arm Cortex processor other than SysTick? Let me know what you think about the above code and in the meantime Ill continue looking for another option.

Thanks,

Eric

[RodolfoGL]

Oh, I see. You actually don't need to get the counter value. You just need to trigger an interrupt on a specific time.

A simple way to make this work with little overhead is to setup a 16-bit timer to set the period at cycles/2^16. On the 2^16th interrupt, you trigger your algorithm.

Answering your question, the precision of the SysTick is as good as the UDB counter or fixed-function counter. All of them are based on the BUS_CLOCK (80 MHz).

<CORRECTION: The number 2^16 can be substituted to any number multiple of the cycles but smaller than 2^16. The catch is to come up with the number that is multiple of cycles quickly, so you can keep the time precision>

[ErNo_1148106]

I think what I need to do is to look at the cycle value that is being put out via terminal program at the highest rpm and then make a decision on the precision of the the timer. I might not even need a 32 bit timer for this application... One thing I do need is the 80 MHz speed that I do know

-Eric

[odissey1]

ErNo,

I hope that you reset the Timer/Counter each time writing the new Period:

STEP_TIMER_WritePeriod(st.exec_segment->cycles_per_tick);

Without a full reset, a new period value shall execute only NEXT time the Counter reloads! (Simply put, one step later)

[ErNo_1148106]

Ah and how do I do this reliably and quickly? Do I call the stop function and then start again? Would that add a small delay? 

[RodolfoGL]

I find odd you need actually 80 MHz, since the time it takes to interrupt the STEP_Timer is way more than 1 cycle. And you are even running floating-point operations in the ISR, so it will take hundreds of cycles to complete that.

If you simply use a 40 MHz counter, the worst case scenario is that it might take 2 more cycles to trigger the interrupt, comparing to hundred of cycles to do the operation. 

The precision of the timer only makes a huge difference when you rely on an external signal and it is handled in hardware. If you rely on the CPU to do anything, you lose that, specially if you have other interrupts going on your system. For example, the time it takes to switch from another interrupt to the STEP interrupt (even if the STEP interrupt is the highest priority), it is different if switching from the main loop.

[ErNo_1148106]

I originally thought the same way but as it turns out the way this seems to correlate is the clock pulse of the timer needs to be the same as the cpu clock because other sections of the code use the CPU speed 80000000u in this case to factor in ticks per microsecond and that sets the speed etc of how fast the motors need to run and also the planner uses this too. The value that is computed from those lines of code in the previous message is this:

As you can see the lower number (2000) in this case is the fastest step pulse to step pulse time and as the number gets larger so does the time between step pulses resulting in slower speed and eventually stopping. In this case a 24-bit timer would be sufficient for my needs.

I agree that there is 100's of cpu clock cycles being used for the floating point operations but what I have observed lately by making the clock the same (80 MHz) the tracking of the step pulse timing to laser pwm tracking time has gotten much better and that is because I made the clock of the timer the same and it makes sense. Before when I had the clock to the STEP_TIMER at 12 MHz it would be too slow. I tried increasing the clock to the STEP_TIMER to 24 MHZ and more and the problem started to clear up so there is a correlation between the cpu clock to the timer clock to synchronize the operations if that makes sense. 

[RodolfoGL]

You can't reach precisely 12 MHz or 24 MHz out of 80 MHz. Maybe that explains the precision issue you are observing.

You can do a very simple experiment. Try to setup your STEP_TIMER to run at 40 MHz and divide your cycles by 2. You might not see any significant difference in behavior on your system.

[ErNo_1148106 · Accepted solution]

This sounds like an interesting idea. Ill give it a try and let you know