Any PSoC4 experts? Clock domain question...

[AndyC_772]

Hi all

Today I've been taking my first steps with a Cypress PSoC4 dev kit.

I have a specific end project in mind, and one of the things it needs to be able to do is generate a pulse which has programmable start and end times with respect to a nominal reference point. So, for example, if I reset a counter to t=0, I want my pulse to go high at t=20 and low again at t=25.

To achieve this, I've instantiated two TCPWM blocks in Timer Counter mode. They have common Start and Clock signals, and their 'cc' outputs are connected to the S and R inputs of an S-R bistable. The idea is that when one timer matches its set value the output of the bistable goes high, and when the other matches, it goes low again.

This may not, of course, be the simplest possible way to achieve what I want, but at this point I'm more interested in understanding how the chip works than in making the most efficient use possible of its resources.

The data sheet for the TCPWM block says that "The overflow (ov), underflow (un), and compare/capture (cc) output signals have two HFCLK cycle pulse width for PSoC 4100/PSoC 4200 devices". I'm using a PSoC4200M, which I presume is included in that description.

Fair enough, I thought; the output pulses should, therefore, be in the HFCLK domain (48 MHz), even though the counters themselves are driven from a derived 12 MHz clock. A 'trap for young players', for sure.

But: when I build the project, I get a warning that there's an asynchronous path between "CLK_12M(FFB)" and "CyHFCLK".

This seems really odd to me, because:

- the TCPWM block is clocked from CLK_12M, which is itself derived from HFCLK
- the data sheet says the outputs are two HFCLK pulses wide, which sort of implies they should be in the HFCLK domain
- nowhere can I find what the (FFB) suffix is supposed to mean. (I know it's Fixed Function Block, but what that has to do with clocks I've no idea).

It's almost as though PSoC Creator doesn't know what the propagation delays are through the TCPWM block, and simply treats the outputs as though they are genuinely not synchronous to HFCLK.

I can't just feed them through a Sync circuit, because I really need their timing relationship to be consistent and predictable. A whole clock pulse's worth of jitter on the output of the S-R bistable would break my application.

Any suggestions please? Have I found a genuine limitation already?

[AndyC_772]

Interesting that the inputs to the TCPWM are double sampled as well, rather than being explicitly treated and analysed as synchronous signals. Thanks.

Maybe the real issue here is just that the device is so limited in terms of available resources, that if a design were to fail timing analysis, there are few if any ways to change the fit. Routinely treating signals as asynchronous to each other ends up with a system that logically 'works', but unfortunately in this case I need to generate a sequence of events which are absolutely predictable and repeatable, not subject to additional cycles' worth of delay and jitter just because the part has got warmer.

Maybe I need to delve deeper, and create my entire system as a custom part in Verilog? The complete system will need to trigger multiple events in sequence based on a common timer, and I can't believe that using multiple timers all synchronised together will end up being efficient or maintainable in the long run.

[AndyC_772]

Yeah it was the Cyboot component doc I was thinking of that also has a useful clocking section
http://www.cypress.com/file/274631/download

Indeed, it says:
"No timing assumptions should be made about signals coming from fixed-function peripherals."

...! 

Right, it's beer time. I think tomorrow I'll start over with an STM32, a CPLD and a few op-amps. Most of my hair is already grey, but I don't have to encourage the last few to turn as well. 

[AndyC_772]

I think on this occasion the right approach is for me to implement the system I have in mind using more familiar parts. Once I know the system works, perhaps I can port it to a PSoC 5LP if there's a commercial case for doing so.

In the meantime, any suggestions for what to do with a brand new, unused CY8CKIT-044? I'm thinking of sending it in to Lauri who runs Hydraulic Press Channel on YouTube.

[jnz]

So I know this isn't the right spot to ask, but I've been following this thread a little. When they say UDB and 8 Macrocells, what are the constraints on this? Is it really equivilent to full on CPLD/FPGA?

I see some of this products have CAN Bus peripherals, but could you use their programmable blocks to create a new CAN implementation for example?

I'm just not framiliar with this line at all.

[richardman]

So I know this isn't the right spot to ask, but I've been following this thread a little. When they say UDB and 8 Macrocells, what are the constraints on this? Is it really equivilent to full on CPLD/FPGA?

Don't think so.

[Yansi]

8 macrocells is good anough to make one or few simple address decoders. 

So no, it is not even comparable to any small CPLD, as those small PLDs usualy have at least order of magnitude more macrocells. Like 64 the smallest CPLDs on the market now.

Reasonable CPLDs start at hundreds of macrocells.

[hendorog]

Appendix A (page 21) of this doc shows a comparision between PSoc4, 5LP and other products.
It seems comparable at first glance - I'm not saying I understand this stuff.

http://www.cypress.com/file/45856/download

[Bruce Abbott]

PSOC4200 has 4 UDBs, each with 8 macrocells. That makes a total of 32 macrocells, the same as low-end CPLDs such as ispMACH 4032ZE and EPM3032.

[jnz]

PSOC4200 has 4 UDBs, each with 8 macrocells. That makes a total of 32 macrocells, the same as low-end CPLDs such as ispMACH 4032ZE and EPM3032.

Hmmm, that's a very cool chip. I'll have to look into it if I ever need and can afford PLD.

[AndyC_772]

I'm not sure the comparison is quite that simple, though. The PSoC doesn't just have the look-up tables and D-types that you get in a CPLD; it also has a 'datapath' in each block, which (I believe!) is effectively a simple ALU which can be called upon to perform operations like adding, subtracting or comparisons.

This means that the general purpose logic doesn't have to be used, which means it's free to do other things. The device should therefore be more capable than a CPLD with an equivalent number of macrocells - and it needs to be, because a MAX3032 really is a very small device indeed.