Implementation internally of 'sticky' status register

[RiAs_1660756]

Me again with the silly questions.  Perhaps someone with a bit of time on their hands could assist?

My design compiles if the latch is transparent but not if it is sticky.  The design is rather full.  My first question is: is the hardware implementation in Figure 1 of the datasheet (Document Number: 001-96683 Rev. *A, page 3) the actual hardware implementation inside the chip?  If so, surely it should make no difference if the mode signal is high or low?  Or does that create issues in creating the mode signal for selective inputs?

This leads me to a more general question: if the router fails, what strategies can I adopt to assist it in achieving a successful routing?

For example, if a port pin is bit 4, say, is it better to take it to the bit 4 input of a status register rather than, say, bit 0?

Is it better to route a pin to a status register and use that to issue an interrupt, or to put an interrupt component on the pin or just to use the pin's interrupt?  Or does the router resolve any of those to the same result?

Is it better to use fewer clocks and route them to the components that need them or to use individual clocks albeit at the same frequency?

Maybe there is a cool document that has a raft of neat tricks that can be used or has a list of space-reclaiming strategies for when designs refuse to route.  Does anyone know?

Profound thanks to anyone who takes an interest!

Richard.

[Bob_Marlowe]

In PSoC5 most of the components are made using UDBs and a hardware definition language named Warp Verilog. Usually there are no (or few) restrictions in routing components to pins, Can you please post your complete project so that we all can have a look at all of your settings. To do so, use

Creator->File->Create Workspace Bundle (minimal)

and attach the resulting file.

Bob

[RiAs_1660756]

Hi, Bob,

Thanks for replying to my posting.

Company policy prevents me from sharing design files.  However, my query was a general one, not related specifically to my current project.

My questions amount to this: when I get Error M0004, what, in general, should I try, other than trial-and-error, to improve the router's chances of success? 

- Richard.

[odissey1]

richard.aston,

In my view, the most scarce resource of PSoC is the routing, once it comes to ~80%, the project is at its limits. Try to unlock i/o pins and let Creator to assign pins by itself (Clean and Build option). As to the "sticky" option of the Ststus Register, try to attach the BUS_CLK to it instead of wiring-in some other clock.

/odissey1

[RiAs_1660756]

Hello, /odissey1,

Thank you for the suggestions.  The first one is unavailable as the hardware is complete - but it was more-or-less how the pins were allocated at the design stage anyway.  However, the second is worth a try.

At the moment, the circuit is fine.  It uses a lot of the 5888's capability and does everything I need it to.  However, I am in the position you describe where the project is nearing the limit of what can be accommodated.

I find that I can make a tiny change and it won't route.  Using the interrupt associated with a pin will cause it to fail.  If I put a signal to one input of a status register, it fails; the adjacent input and it routes.  If I change the PLL to 48MHz, it fails; 36MHz it routes.

This suggests to me that there may be strategies that can be used to get out of jail.  Your suggestion to use the bus clock is exactly what I am talking about. 

- Richard.

[Vasanth · Accepted solution]

Hi Richard,

As there is no project attached, you can follow the best design practices for PSoC5 devices in this document: https://www.cypress.com/documentation/application-notes/an81623-psocr-3-psoc-4-and-psoc-5lp-digital-... .

Extending response 4, we would add that it is preferable to use as few unique clocks as possible because different clocks can introduce placement constraints.

Best Regards,

Vasanth