- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
What is the maximum input frequency of a PSoC5 digital clock divider block?
I'm working on a design that modifies the PLL at runtime and the PLL sources one of the digital clock divider blocks. When I set the PLL out to be 60MHz or above, the output of the digital clock divider block goes effectively to DC.
I've looked in all the PSoC5 info I could access with no luck. I could find other maximum input clock frequencies for other blocks but this one is not mentioned.
Len
"Engineering is an Art. The Art of Compromise."
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/odissey1,
I'm generally familiar with your DDS24. In my case, I'm trying to develop a "near-zero" added component frequency accuracy improvement. It uses the PSoC's PLL and a digital clock divider block (the only added component which are normally needed in serial down-rate conversions) to achieve a 'more' accurate target frequency.
FYI: LIN master spec requires +/-0.5% accuracy. LIN slave is +/-1.5%.
For example:
Let's say you want to support the USB UART of the CY8CKIT-059 board @ 115.2Kbps. Using the standard 8x oversampling you need 921.6KHz as an input clock.
If you use "external clock" mode for the input clock, it will try to find the 'closest' clock which in most cases will be the internal IMO(@3MHz)->PLL_OUT(@24MHz)->DCDB(@26 divider). This provides a UART input clock @ 923.08KHz (921.6KHz+0.16%). Note: This assumes an accurate IMO frequency. With an internal IMO of +/-1% you're getting an end result of +1.16%/-0.84% Not bad.
If you use the "external clock" option it is basically the same.
Using the standard DWR "Configure system clock" I can manually configure the PLL_OUT to 54.375MHz. This gives me a P/Q factor of 145/8. The new DCDB divider value is 59. The UART input clock is now 921.61KHz which is now only +0.0011% from target and with a IMO accuracy of +/- 1% we get +1.0011%/-0.9989%. The new PLL adjustment is more 'optimal' to target.
This can be done manually or with code. I've got a code function that will compute the 'optimal' PLL and DCDB settings need to be based on PLL input frequency and target DCDB frequency. This code function can be used in a future Creator update if they'd like.
,
You are correct. I need a XTAL with small ppm accuracy (<100ppm or <0.01%) to effectively remove the 1% (or more) tolerance with the PSoC internal IMO oscillator. You can do that with an external XTAL. My proposal is to use an external XTAL_32K. It is usually cheaper, and smaller for an added BOM component. More on that when I finalize my project and submit it to the PSoC community for use and/or comment.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Len,
I am not sure if this will help, from TRM
"The PLL's charge pump current (Icp) can be configured using bits 6:4 of register FASTCLK_PLL_CFG1. This bit-field must be set to 0x01 (2 µA) when the output frequency <67 MHz. It must be set to 0x02 (3 µA) when the output frequency is > 67 MHz."
What output frequency range/resolution you need?
/odissey1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/odissey1,
Thank you as always. I referred to the "PSoC 5LP Registers TRM, Document No. 001-82120 Rev. *F" which says:
Bits Name Description
6:4 icpsel[2:0] Charge Pump current select. This bit-field should be set to 0x01 for all configurations.
However "PSoC 5LP Architecture TRM, Document No. 001-78426 Rev. *F" does refer to the snippet you cite.
In general, I'm hoping to use the full PLL output range allowed (24M-80M) to supply as an input to a digital clock divider block. However if there is a Fmax limitation of the input to this block, I may need to perform some other SW adjustments.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Can you please specify the exact device that you are using and how the clock signal was measured?
To which digital peripheral is the output of clock divider connected?
Also, if the PLL is dynamically changed, the register has to be manually modified as the reply above suggests.
Thanks and regards
Harigovind
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HarigovindH_31,
In short, I'm planning on sourcing the PLL_OUT clock to a DCDB (digital clock divider block) and the output sources the clock to a UART. (As shown below)
I have SW I'm willing to share with the PSoC community shortly that will significantly improve the target accuracy of the baud rate (bit-rate) to any PSoC serial block. My preliminary show better than 0.5% accuracy. This could be very useful if you're using the PSoC as a LIN master which requires 0.5% or better to meet spec.
I'll definitely take /odissey1's recommendation (which is in conflict with the register TRM). The issue I'm having appears to be linked to potentially the Fmax of the DCDB input. I cannot find the Fmax of this block in either TRM doc. This closest possible 'analog' is the DSI Fmax of 33MHz. But I'm not sure this applies.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Len,
For finely--tuned frequency for UART, also another (DDS) approach can be used. For example DDS24 or DDS32 components can provide clocks in several MHz range with 1-0.01 Hz.
DDS24: 24-bit DDS arbitrary frequency generator component
PLL can be dynamically tuned with approx. 50Hz precision. Both approaches require XTAL as reference clock source to reach that precision. I don't know what precision needed for LIN.
/odissey1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/odissey1,
I'm generally familiar with your DDS24. In my case, I'm trying to develop a "near-zero" added component frequency accuracy improvement. It uses the PSoC's PLL and a digital clock divider block (the only added component which are normally needed in serial down-rate conversions) to achieve a 'more' accurate target frequency.
FYI: LIN master spec requires +/-0.5% accuracy. LIN slave is +/-1.5%.
For example:
Let's say you want to support the USB UART of the CY8CKIT-059 board @ 115.2Kbps. Using the standard 8x oversampling you need 921.6KHz as an input clock.
If you use "external clock" mode for the input clock, it will try to find the 'closest' clock which in most cases will be the internal IMO(@3MHz)->PLL_OUT(@24MHz)->DCDB(@26 divider). This provides a UART input clock @ 923.08KHz (921.6KHz+0.16%). Note: This assumes an accurate IMO frequency. With an internal IMO of +/-1% you're getting an end result of +1.16%/-0.84% Not bad.
If you use the "external clock" option it is basically the same.
Using the standard DWR "Configure system clock" I can manually configure the PLL_OUT to 54.375MHz. This gives me a P/Q factor of 145/8. The new DCDB divider value is 59. The UART input clock is now 921.61KHz which is now only +0.0011% from target and with a IMO accuracy of +/- 1% we get +1.0011%/-0.9989%. The new PLL adjustment is more 'optimal' to target.
This can be done manually or with code. I've got a code function that will compute the 'optimal' PLL and DCDB settings need to be based on PLL input frequency and target DCDB frequency. This code function can be used in a future Creator update if they'd like.
,
You are correct. I need a XTAL with small ppm accuracy (<100ppm or <0.01%) to effectively remove the 1% (or more) tolerance with the PSoC internal IMO oscillator. You can do that with an external XTAL. My proposal is to use an external XTAL_32K. It is usually cheaper, and smaller for an added BOM component. More on that when I finalize my project and submit it to the PSoC community for use and/or comment.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Len,
Thank you for detailed explanation. Looking forward to see a new community component.
/odissey1