Routing fails with less than 50% of MCs and PTs used. Why?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
ChRe_4711096
Level 4
Level 4
50 replies posted 25 replies posted 25 sign-ins

I've put a lot of effort into reducing the attached design's appetite for MCs and PTs from >80% to below 50%. However, as soon as I add the 17th timer to the top-level design, routing fails. Why? And how can I proceed?

0 Likes
17 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

ChRe,

I've tried to build your project.  In my case, I don't go as far as you do.

Apparently I don't have the following components:

  • ADCModule
  • ESCCore_sw_blanking

Also your VDAC component PDL revision is a bit old (v2.0)

I can't proceed any further without the missing components.

Note:  Without knowing what internal timer resources are being used by the missing components, the PSoC6 you've chosen has 32 Timers.  However, not all of them are the same resolution.  There are 8 32-bit timers and 24 16-bit timers.

I noticed your ESCCore_sw_blanking component has what appears to be 3 PWM outputs per component (PWM_A_x, PWM_B_x and PWM_C_x).   This requires at least 4*3 = 12 timers at a minimum for the ESCCore_sw_blanking circuit.   Is the component using 32- or 16-bit timers?

Are your outputs Comm_A_x, Comm_B_x and Comm_C_x using separate timers for the outputs?  If so, your timer count (not including Counter_1) has risen to 24 timers.  This is the max 16-bit counters supported by the fixed TCPWM resources on the PSoC6.

Good news though ...  using PSoC Creator and the UDB resources on the PSoC6, you can create your own user timers/counters.

Here's a Down_count7 component that can count down using 7 bits.

If that's not enough, the UDB blocks allow you to create your own timer/counter using logic gates such as D-flip-flops and combinatorial logic such as AND, OR, XOR and NOT gates.  Just to name a few.

If you want you can use the WARP tool in Creator to create a Verilog HW definition of the Timer/Count you want.   It will try to create it out of the UDB blocks available.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.

Hi Len, thanks for looking into it. First of all I have attached a workspace archive, not just the project that pulls it all together. That should give you a chance to see what's happening. With all components on the table, let's look at the internals, especially the usage of timers:

Each ESC core drives one BLDC motor. The commutation timing is done by ESC_Comm_v2::Timer_Comm. Whenever this  timer overflows, the next commutation pattern is forwarded to the driver pins (Ap, Ac, ... Cc). Only one of those pins is actively driven by the ESC's PWM timer (ESC_Comm_v2::Timer_PWM), so I don't need 3 PWM timers per ESC. Which pin that is is decided by the software that writes the next pattern to ESC_Comm_v2::CommPattern_v (not fully implemented yet, but at the moment it's a parallel out 8-bit datapath acting like a memory-to-fabric latch enabled by the commutation timer).

The two other timers in ESC_Comm_v2 are used to suppress data from the ADC during periods where no useful samples can be taken.

So I have 4 ESCs with 4 timers each = 16 timers, and 8 of them are 32-bit timers. I might get away with using a 16-bit timer for Timer_Toff, but I haven't done the math for that. I'm not using too many timers, otherwise PSoC Creator would tell me. BUT I have searched for topics here that involve many timers, and I might be overusing the trigger mux block. When I remove Timer_PWM_ringing from ESC_Comm_v2, I can place a timer on the top level schematic and things are fine. I can also place other logic there and routing works just fine, as long as I'm not triggering too many timers.

ESC_Comm_v2::Timer_PWM_ringing could be replaced with a datapath, but I don't know if that's actually helpful because, from the report or the error messages that I get, I can't be sure if the bottleneck is actually in the trigger mux block. The changes to the ESCs must be chosen with care because each change has 4x the impact on the overall outcome. One extra control reg means four of them, same for datapaths, counters, status, and so on.

The ADC Module is not using any complex components other than the SAR ADC and a datapath to filter out samples within a noise band around zero. DMA is used to get data from the ADC to the datapath, and to update the current channel number in order to route reduced information to the correct ESC.

The "other" analog stuff: There's a buffered 1V2 output that is used to bias voltage dividers on the BLDC's phase feedback. Pretty much just an experiment.

The DAC+Comparator are used to detect line sync from an analog camera, in order to overlay an on-screen display. That part isn't implemented yet because (you might have guessed it) I had difficulties even placing just one single timer to detect the line sync pulse. Again, when Top level Counter_1 is removed, the design can be routed.

0 Likes

ChRe,

I've downloaded your last workspace.  It is VERY complex.  I see you are trying to tackle component design.   Bravo!   This is a significant challenge even for the seasoned PSoC user.

I couldn't get it to build.   The major stumbling block is the component "AnalogModule_Single" is not included in your workspace.

pastedImage_0.png

pastedImage_1.png

Additionally your project "fittingTest_4in1" is calling for ESC_Comm_v1_1.  Should I be upgrading to ESC_Comm_v2_0?

There are other errors I need to resolve first.  Here is a printout of the output of the Application Build phase.

pastedImage_2.png

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

ChRe,

Without being able to Application Build, I counted your TCPWM block count based on the ESC_Comm components and Counter_1.

You have allocated 8 32-bit and 9 16-bit TCPWM blocks.  This should theoretically fit.  You have 0 left-over 32-bit TCPWM blocks and 13 left-over 16-bit TCPWM blocks.  This applies to v1_1 and v2_0 component versions.

Since I don't have the "AnalogModule_Single" component, I don't know if any TCPWM blocks are being used.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.

That was a major oops I guess. I have loaded the project into the workspace again. However, if that still doesn't include everything you need, here's a screenshot of ADCModule's internals:

Anmerkung 2020-09-07 165253.png

As you can see, it doesn't include any timers. ADC_Filter_UDB also doesn't include any "hidden" timers, and I agree with your overall timer count.

The project doesn't build in the state I have attached now, but it does if you disable Counter_1's start input on the fittingTest_4in1 top level schematic. You can also see some other minor changes like the extra output_polarity component, but I'm pretty sure it doesn't cause any of the issues the router is running into.

Regarding the errors you posted, most of them come from the missing ADCModule which should now be included in the archive. The PDL errors are a bit surprising - is my PDL outdated?

0 Likes

ChRe,

Your new upload allowed me to Application Build.

EXPERIMENT 1

Here's my new output when I disable Counter_1:

--------------- Build Started: 09/07/2020 12:55:46 Project: fittingTest_4in1, Configuration: ARM GCC 5.4-2016-q2-update Debug ---------------

cydsfit.exe -.appdatapath "C:\Users\user\AppData\Local\Cypress Semiconductor\PSoC Creator\4.3" -.fdsnotice -.fdswarpdepfile=warp_dependencies.txt -.fdselabdepfile=elab_dependencies.txt -.fdsbldfile=generated_files.txt -.fdsreffile=referenced_files.txt -p "C:\Users\user\Documents\PSoC Creator\User_Projects\20200829_BLDC_splitAnalog\fittingTest_4in1.cydsn\fittingTest_4in1.cyprj" -d CY8C6347BZI-BLD34 -s "C:\Users\user\Documents\PSoC Creator\User_Projects\20200829_BLDC_splitAnalog\fittingTest_4in1.cydsn\Generated_Source\PSoC6" -- -yv2 -q10 -ygs -o2 -v3 -.fftcfgtype=LE

Elaborating Design...

HDL Generation...

Synthesis...

Tech Mapping...

ADD: pft.M0040: information: The following 46 pin(s) will be assigned a location by the fitter: Comm_A_1(0), Comm_A_2(0), Comm_A_3(0), Comm_A_4(0), Comm_B_1(0), Comm_B_2(0), Comm_B_3(0), Comm_B_4(0), Comm_C_1(0), Comm_C_2(0), Comm_C_3(0), Comm_C_4(0), M_A_1(0), M_A_2(0), M_A_3(0), M_A_4(0), M_B_1(0), M_B_2(0), M_B_3(0), M_B_4(0), M_C_1(0), M_C_2(0), M_C_3(0), M_C_4(0), M_P_in_1(0), M_P_in_2(0), M_P_in_3(0), M_P_in_4(0), M_Y_1(0), M_Y_2(0), M_Y_3(0), M_Y_4(0), Pin_1(0), Pin_2(0), PWM_A_1(0), PWM_A_2(0), PWM_A_3(0), PWM_A_4(0), PWM_B_1(0), PWM_B_2(0), PWM_B_3(0), PWM_B_4(0), PWM_C_1(0), PWM_C_2(0), PWM_C_3(0), PWM_C_4(0)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: TCPWM[3].line. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: TCPWM[19].line. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: CSD[0].csd_tx. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: CSD[0].csd_tx_n. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: TCPWM[3].line_compl. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: TCPWM[19].line_compl. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: CSD[0].csd_tx. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: CSD[0].csd_tx_n. (App=cydsfit)

Analog Placement...

Analog Routing...

Analog Code Generation...

Digital Placement...

Warning: placer did not place the following components:

   \ADCModule_1:ADC_1:SARMUX\:SARMUX

Digital Routing...

Bitstream Generation...

Bitstream Verification...

Static timing analysis...

Warning: sta.M0019: fittingTest_4in1_timing.html: Warning-1366: Setup time violation found in a path from clock ( CyClk_Peri ) to clock ( CyClk_Peri ). (File=C:\Users\user\Documents\PSoC Creator\User_Projects\20200829_BLDC_splitAnalog\fittingTest_4in1.cydsn\fittingTest_4in1_timing.html)

API Generation...

Dependency Generation...

Cleanup...

--------------- Build Skipped: 09/07/2020 12:56:41 ---------------

It builds but indicates to potentially major issues:

Warning: placer did not place the following components:

  •   \ADCModule_1:ADC_1:SARMUX\:SARMUX
  • Warning: sta.M0019: fittingTest_4in1_timing.html: Warning-1366: Setup time violation found in a path from clock ( CyClk_Peri ) to clock ( CyClk_Peri ). (File=C:\Users\user\Documents\PSoC Creator\User_Projects\20200829_BLDC_splitAnalog\fittingTest_4in1.cydsn\fittingTest_4in1_timing.html)

Here is  the resource meter for TCPWMs

EXPERIMENT 2

When I enable Counter_1, I get the following output.

--------------- Build Started: 09/07/2020 13:05:07 Project: fittingTest_4in1, Configuration: ARM GCC 5.4-2016-q2-update Debug ---------------

cydsfit.exe -.appdatapath "C:\Users\lpoma\AppData\Local\Cypress Semiconductor\PSoC Creator\4.3" -.fdsnotice -.fdswarpdepfile=warp_dependencies.txt -.fdselabdepfile=elab_dependencies.txt -.fdsbldfile=generated_files.txt -.fdsreffile=referenced_files.txt -p "C:\Users\lpoma\Documents\PSoC Creator\User_Projects\20200829_BLDC_splitAnalog\fittingTest_4in1.cydsn\fittingTest_4in1.cyprj" -d CY8C6347BZI-BLD34 -s "C:\Users\lpoma\Documents\PSoC Creator\User_Projects\20200829_BLDC_splitAnalog\fittingTest_4in1.cydsn\Generated_Source\PSoC6" -- -yv2 -q10 -ygs -o2 -v3 -.fftcfgtype=LE

Elaborating Design...

HDL Generation...

Synthesis...

Tech Mapping...

ADD: pft.M0040: information: The following 46 pin(s) will be assigned a location by the fitter: Comm_A_1(0), Comm_A_2(0), Comm_A_3(0), Comm_A_4(0), Comm_B_1(0), Comm_B_2(0), Comm_B_3(0), Comm_B_4(0), Comm_C_1(0), Comm_C_2(0), Comm_C_3(0), Comm_C_4(0), M_A_1(0), M_A_2(0), M_A_3(0), M_A_4(0), M_B_1(0), M_B_2(0), M_B_3(0), M_B_4(0), M_C_1(0), M_C_2(0), M_C_3(0), M_C_4(0), M_P_in_1(0), M_P_in_2(0), M_P_in_3(0), M_P_in_4(0), M_Y_1(0), M_Y_2(0), M_Y_3(0), M_Y_4(0), Pin_1(0), Pin_2(0), PWM_A_1(0), PWM_A_2(0), PWM_A_3(0), PWM_A_4(0), PWM_B_1(0), PWM_B_2(0), PWM_B_3(0), PWM_B_4(0), PWM_C_1(0), PWM_C_2(0), PWM_C_3(0), PWM_C_4(0)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: TCPWM[3].line. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: TCPWM[19].line. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: CSD[0].csd_tx. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWDIO_TMS(0) at location P6[6] prevents usage of special purposes: CSD[0].csd_tx_n. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: TCPWM[3].line_compl. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: TCPWM[19].line_compl. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: CSD[0].csd_tx. (App=cydsfit)

Info: plm.M0038: The pin named CY_CPUSS_SWJ_SWCLK_TCLK(0) at location P6[7] prevents usage of special purposes: CSD[0].csd_tx_n. (App=cydsfit)

Analog Placement...

Analog Routing...

Analog Code Generation...

Digital Placement...

Warning: placer did not place the following components:

   \ADCModule_1:ADC_1:SARMUX\:SARMUX

Digital Routing...

Error: rtr.M0004: E1217: Failed to route all nets; unable to resove overuse

Error: rtr.M0004: Error routing design: Routing Failed (11)

Dependency Generation...

Cleanup...

Error: fit.M0050: The fitter aborted due to errors, please address all errors and rebuild. (App=cydsfit)

--------------- Build Failed: 09/07/2020 13:05:54 ---------------

I still get the SARMUX not placed warning.

I get a new message that is a bit confusing:  Error: rtr.M0004: E1217: Failed to route all nets; unable to resove overuse

What is "resove"?  I'm assuming it's "resolve".

Here's the resource meter for TCPWMs:

This matches the 8 32-bit and 9 16-bit TCPWMs we've estimated.

I don't think the problem you are having is a TCPWM resource issue.  I think Creator is having trouble routing the timers for some reason.

EXPERIMENT 3

If I enable Counter_1 and change the schematic as indicated below

pastedImage_3.png

I get the Application to build with the same warnings as the experiment with Counter_1 disabled.  However, No errors.   This experiment proves it is not an TCPWM resource issue,  Only a digital routing issue to Counter_1 start input.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.

First of all, I'm glad that you now have everything you need to help me. Let's have a look at those warnings you mentioned in the beginning:

SARMUX is not placed, but to be honest I don't know what to conclude from that. SARSEQ is apparently cycling through channels, I can see that when I run the analog module on actual hardware (that cy8cproto 063 BLE thing).

Also I have no clue if the setup time violation is actually a problem, because I have no prior experience with PSoCs other than some tinkering to get this project to the state that it is in now. There's a lot of room for unforeseen delays between the ADC module and the ESCs, so I might get away with it. I can produce a scope screenshot if that helps, but that would go into a different discussion.

The PWM ringing timer in ESC_Comm_v2_0 has now been replaced by a datapath based timer, because I had to place an additional datapath anyway and there was free "functionality space" in there. I'm now down to 12 timers (2 32-bit, 1 16-bit per ESC), with 4 PLD blocks completely free. I could place a chain of 5 timers in the top level schematic, without errors (I stopped at 5 because I reached the bottom of the schematic, and 2 or 3 chained timers should be enough for the actual application).

One worrying detail about the current output is that no parallel out datapaths are reported. In previous attempts they showed up in the control cell subsection of the report file.

Current state is attached.

0 Likes

Regarding the missing output about parallel out datapaths: When I disable parallel in (on the same datapaths), parallel out is reported again, and the number of MCs and PTs is the same. Could this be a bug in PSoC Creator, or am I trying to use a combination of features that is (silently) not allowed? Anyway this observation belongs in a separate question.

0 Likes

ChRe,

I see you were able to get many more Timers added (by reducing the TCPWM count in ESC).  A very complicated design.   And you're using Verilog.  Bravo again!

I'll try to answer some of your latest questions:

SARMUX is not placed, but to be honest I don't know what to conclude from that. SARSEQ is apparently cycling through channels, I can see that when I run the analog module on actual hardware (that cy8cproto 063 BLE thing).

Yes this is very confusing.  Possibly a bug in the component code or less likely a Creator bug.   You may want to report it to Cypress since it appears to be working.

Also I have no clue if the setup time violation is actually a problem, because I have no prior experience with PSoCs other than some tinkering to get this project to the state that it is in now. There's a lot of room for unforeseen delays between the ADC module and the ESCs, so I might get away with it. I can produce a scope screenshot if that helps, but that would go into a different discussion.

The setup time violation is coming from the design rule checker phase of the Application build.  The design rule checker in this case is using a static transient analysis based on the "known" propagation delays and setup and hold time of the internal latches across all operational temps.

If you look at the file "fittingTest_4in1_timing.html" you will see the violation:

as well as

pastedImage_5.png

I'm going to look at whether this may be an issue.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.

ChRe,

I've performed some more experimentation that has yielded a bit more data,

Issue 1

First off, I ran into some 'weird' build issues.  However I blame it on PSoC Creator in a way.  In summary, your project with your very complex custom components is VERY COMPLEX.  Any changes I make in the TopDesign most likely causes Application Build issues.  When this happens, I save the project with the changes and exit Creator.  I reload Creator and Application build again.  The 'weird' errors I previously received have gone away.  I still receive many of the warnings and notes but the errors are gone.

I believe this is because Creator although a excellent and complex program on it's own has trouble caching info between consecutive modifications of the same Creator session.  Exiting and reentering Creator, flushes the cached info for a 'cleaner' build.

Issue 2

I believe I have the reason for the warning:

Warning: sta.M0019: fittingTest_4in1_timing.html: Warning-1366: Setup time violation found in a path from clock ( CyClk_Peri ) to clock ( CyClk_Peri ). (File=C:\Users\user\Documents\PSoC Creator\User_Projects\20200829_BLDC_splitAnalog\fittingTest_4in1.cydsn\fittingTest_4in1_timing.html)

You're trying to drive 5 clock inputs into ADCModule_1 and into all 4 ESCCore_sw_blanking instances with Clk_Peri (@ 72MHz) directly.  The UDB resources are naturally internally clocked by Clk_Peri already.  Because you were sourcing these clock inputs with the same clock as the internal clock, the static timing analysis was indicating a setup timing issue of about 4ns.

I changed these 5 clocks and all the ESCCore_sw_blanking instance clocks of PWM and COMM to Clk_Peri/2 = 36 MHz.  The setup timing violation went away.

Question:  Do you actually require the clocking of the PWM and COMM clocks at 72 MHz?

Opinion:

If you're driving BLDC motor windings, even PWM clocks above 100KHz is almost a waste.

This statement is two-fold.

  • Most drive FETs have a lot of trouble driving above 25KHz because of internal gate capacitances.  Driving fast causes the FET outputs to operate more time in the linear mode.  This is more of a problem if the FETs are being used in a push-pull configuration (H-bridge) where some deadband time is needed to minimize punch-through losses.  All these issues create a need for more thermal mitigation technique which may include a heatsink with possible active cooling (fan).  If you're driving high current, these factors are multiplied.
  • The natural inductance of the motor winding will limit the maximum in-rush current (di/dt) in time.  Going faster than this inductive factor will cause much larger voltages to be generated (due to the motor inductance) than may be desired causing avalanche poke-through events.  The higher of the anticipated drive current, the higher the inductance factor.

Since you've got a partially working system, I recommend tuning your BDLC drive frequencies to as low as can be tolerated.  This should result in better thermal reliability, better inductance effect mitigation as well as reducing potential CPU loading of interrupts for real-time processing.

Issue 3

There is a potential issue with your TopDesign with as many common clocks (@ 72MHz and @ 1MHz).

With as many clocks as you were using (count = 10), you didn't run into a clock resource issue which is great (and a bit surprising to me).

However, the Creator build might be assigning a new clock driver for each of the Clock components listed.  It might not try to optimize.

The issue might be more of a potential problem with the Sequential 5 Timer circuit using a common frequency of 1MHz.  Although the gate-to-gate skew between clock drivers might be very low, actually making the clocks common to one clock driver might help reduce a problem with setup and hold times of the downstream logic.

I've attached a changed version of your TopDesign.  If you replace your older TopDesign file with this one, you will notice:

  • All the udb_clk are driven off the same Clk_9 (@ 36MHz). 
  • All the pwm_clk and comm_clk  clock inputs are sourced from Clock_1 (@36MHz).
  • All the clock inputs of Counter_1 through Counter_5 are source off Clock_4 (@1MHz)

Hopefully this wordy post comes in handy.

Len 

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Don't worry, I don't mind a lengthy post if it comes with some substance.

The "weird" build issues appear all the time while modifying the top level schematic, and I have the impression that unloading projects that I'm not actively working on helps a bit. That's the reason why you initially didn't have all components - one project was unloaded and thus not archived. PSoC Creator seems to have a background elaborator process which tries to make sure your components are wired correctly as you edit them. With a complex design like mine, it apparently runs into memory leaks and such. PSoC Creator crashes very often on my computer with "out of memory" exceptions. Also errors that are long fixed are still reported, but the build output is fine.

Clocking. Let's start with PWM! The motors I intend to drive run at a commutation frequency of up to 40 kHz (some 60k rpm or so). PWM frequency should definitely be higher than 2xf_comm, so we end up at around 100 kHz. As f_comm approaches f_pwm/2, the motor begins to resonate with the PWM frequency which is usually a major problem for the rpm control system. I agree that PWM frequency should be as low as possible, and the (PSoC) hardware is designed to support variable PWM frequency. The code will start at roughly 24 kHz and go up to, say, 100 kHz. The minimum resolution we need for the duty cycle is about 500, so the PWM timer and the datapath it feeds into should run at 50 MHz or more (the datapath generates the 6 FET gate outputs).

The PWM timer triggers a datapath that now replaces a one-shot timer. This one-shot timer is used to suppress ADC samples that were taken shortly after any PWM switching event. The one-shot duration is somewhere between 300 ns and something like 2 us I'd say, and we don't need excess resolution here. This off-time may be sloppy, anything 10 MHz upwards is enough for this datapath.

The commutation timer doesn't need to run very fast. For 1% commutation time resolution at 40 kHz we could theoretically clock it with at least 4 MHz. Unfortunately, it must also allow for very low commutation frequencies so it has to be a 32 bit timer.

the commutation timer triggers another one-shot timer that suppresses ADC results during a phase current decay period after commutation. Again, 4 MHz should be plenty for that one, and it could even be 16 bit. Currently it's a 32-bit timer because that eases the computation of this timer's period.

We now have discussed the clocks used in the ESC cores, so let's head over to the ADC thing.

The ADC itself actually creates a performance bottleneck. For maximum sampling frequency it needs an 18 MHz clock, derived from clk_peri. Since we want the M4F at > 100 MHz (just because), the M0+ is limited to multiples of 18 MHz, and f_M4F/2. But I'm just ranting. The ADC_Filter_UDB receives an ADC sample (16 bit) via DMA into its FIFOs (2 x 8 bit). This sample is then compared against a noise level, and if it's outside of the noise band, it's forwarded to the selected ESC core. The evaluation takes just a few clock cycles, so I think it's safe to let this run at 36 MHz instead of 72. The ADC result - reduced to sign and a trigger - only passes through some glue logic into a status register. No other clocks other than the status register clock are encountered on the way. If the status register needs its own clock (independendent from the PWM and commutation stuff), I have to split it off that udb_clk input but that's a minor change.

A tiny amount of glue logic might be still get added to suppress ADC samples after a zero crossing was detected, but no complex blocks that require their own clock.

The large number of clocks in the top level schematic is an effect of laziness (and those crashes I described above: Copy a couple of components - paste - hope for the best - align - place - save - repeat). I didn't really think about the other clocks I described above either: I went for "maximum" due to lack of experience. You now forced me to put some thought into them, and it seems that only the PWM part needs a really fast clock.

0 Likes

ChRe,

Thanks for the details.

Given the complexity of your design, I'm still trying to digest all of it.

That's the beauty of being the creator.   To do your best job, you need to know your system requirements thoroughly.

Good luck.  If you still need to need to run the ESC PWMs at 72MHz, consider changing the Clk_Peri to 144MHz and use Clk_Peri/2 (=72MHz) to drive the ESC components.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

As far as I understand it, the limit for clk_peri is min(100 MHz, clk_fast/2) - is that not correct?

If you need some guidance through my design, please feel free to ask about anything! I can also talk you through it via teams or skype. To be honest it can't be fully understood by bystanders because I mainly focused on getting the right components wired up and routed. I know that understanding some else's design (no matter which field) is a larger challenge than creating it in the first place, so thanks again for at least trying. Unfortunately, problems usually only arise once a certain level of complexity is reached. And it will only get weirder.

Some softer aspects aren't fully defined yet, like some datapath instructions or anything that needs CPU intervention.

0 Likes

ChRe,

You are correct.  Clk_Peri maximum frequency is 100MHz.

Thank you for the offer for further insight into your design.   I may take you up on the offer.  Right now, I've got a high priority project to get to the next stage.  I've been trying to steal some time to try to answer some user's PSoC questions such as yours.

I have some familiarity with motor drive designs in both HW and SW.  My previous designs were with 50amp stall BDC motors.  BLDC is significantly more complicated (at least 3x more).  Kudos to you and my condolences at the same time.

With the large current BDC motor design, I had to keep the PWM output frequency above 20KHz to keep the PWM harmonics from being audiable.

I realize you're trying to do the same by keeping the PWM output frequency high enough (100KHz) to keep it inaudible.  I noticed you're driving the 16-bit PWM of ESC with 72MHz.  You have a period of 720 to provide the aggregate PWM output of 100KHz.

Suggestion:  Use the 36 MHz as the input clock and change the period to 360.  Will that give you enough PWM resolution?

Suggestion #2:  Drive the output of Clk_Peri = 50MHz.  You can use this frequency into the ADC and ESC modules.  Then you need to change the PWM period to 500.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

360 wouldn't be enough resolution. Around 500 seems to be the minimum for the real application, and I'd like to get there. It would be possible with a UDB clock of 48 MHz and f_PWM = 96 kHz, but in that case with

peri_clk = slow_clk = 72 MHz: f_UDB > peri_clk/2. PSoC Creator doesn't complain though!

I've brought this up earlier, but the response so far wasn't really helpful: Confused by missing (?) warning about max UDB clock speed

The problem is not so much about the max udb clock, but about the constraint udb_clk <= peri_clk/2.

0 Likes

I found a way to maintain pwm_clock at 72 MHz (one timer and the associated datapath), and slowed the rest down to 36 MHz. That should be plenty for all applications. It required two sync components in a very long combinatorial logic path:

The ADC Module contains a datapath that is driven by a state machine. One of the states is used to generate a 2 clock wide trigger pulse that has to go through the demultiplexer that routes the generated trigger to the correct ESC. There it goes through "ADC enable" logic, and is finally forwarded to a status register. The ADC result's sign takes a very similar path. I placed a sync register in both of these, and get no timing violations.

I'll upload the project again when I've done some cleanup.

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

ChRe,

Since Counter_1 is being used as a "debouncer/deglitcher"  here is an equivalent circuit as a one clock debouncer.

If you absolutely need a multi-clock deglitcher, let me know how many clock edges you want to filter through.  I can help you devise a circuit.

One additional Note:

If you've got a alot of CPU cycles to spare, you can do a debouncer/deglitcher ALL in SW.  To do this, create the circuit below:

and then assign the ISR to get every edge of the comparator along the CPU SysTick timer and some RAM variables to determine if the signal is deglitched.

Additionally setting the comparator to "Low Power" is a way to reduce the threshold crossing response time.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes