Allocating 16-bit status/control registers

[Anonymous]

What is the typical way of instantiating pairs of 8-bit status or control registers in order to create 16-bit accessible registers?

   

The hardware provides 16-bit registers pairs for the purpose (e.g. CYREG_B0_UDB00_01_CTL) however I haven't been able to figure out how to inform the fitter of the constraint that the two registers should be placed into consecutive UDBs.

   

For datapaths you would do so by tying the chaining signals between them however in this case there is nothing to be chained. Nor do the standard components seem to support allocation of wider registers. Is there perhaps something akin to a "cy_psoc3_control16" component or a special UDB pairing constraint directive?

   

This is part of the critical innerloop where every cycle counts (hence why it was was off-loaded to hardware in the first place) and so manually combining 8-bit accesses is rather expensive. The workaround would be to force the UDB allocation outright with placement_force directives but naturally I'd prefer letting the optimizer have as free of a reign as possible.

[Anonymous]

A bit more digging reveals that the status/control registers are inherently tied to the 16-bit concatenation setting of the UDB which they are allocated into. Therefore a placement_force workaround must also force the datapath allocation so as to avoid the unwanted working register mode.

   

Furthermore a common register wait-state setting (CYREG_BCTL[0-1]_WAIT_CFG) is apparently employed for either of the two UDB banks, both of which add two read cycles in my present configuration.

   

How are these wait-state settings determined and how do I optimize them? Dropping the system down to a single 1 MHz clock shaves off one wait-state without reaching zero. Presumably logic requiring fast bus access should be carefully allocated into one of the UDB banks, and care be taken so as not to inadvertently introduce wait-states by accident.

[odissey1]

The subject is rather deep, rising cypress support case would be appropriate.

   

One way to have "wider" register is to exploit a FIFO. See the updated component in this thread

   

http://www.cypress.com/forum/psoc-5-architecture/fifo-sample-8-or-16-bitparallel-inputs

       

And this may be relevant as well

   

http://www.cypress.com/forum/psoc-5-architecture/datapath-fifo-single-buffer-mode-and-aux-control-re...

Sorry, I can't help beyond that...   

[Anonymous]

Thank you, I think I'll give the support a shot if I can't figure things out by myself.

   

A parallel datapath "wrapper" might work here. Forwarding data to/from the FIFO would introduce an extra cycle of delay in either direction. However the status register is already implicitly used for parallel input mode of the datapath and so could probably be read directly in software.

   

To be honest I get the feeling that the documentation and tools to optimize a PSoC design seem fairly spotty, with a general focus more on ease-of-use.