2 Replies Latest reply on Apr 14, 2016 7:28 AM by user_431614858

    How to specify false paths

    user_431614858

      Is there any way of specifying false paths or other timing exceptions for Warp synthesis in a custom component PSoC design?

         

      I seem to have run into a bit of trouble meeting the timing requirements for a PSoC 5LP design. Specifically the path from the output on a bidirectional GPIO pin back to the input pushes the synthesis over the edge. The input and the output logic are only used in separate modes of the system however so I am hoping to declare this as a false path without the synthesis failing or expending resources optimizing for it.

         

      I do know how to work around the issue with additional buffering however the margins of the design are getting alarmingly tight so any cycles shaved off would be a boon.

         

      Admittedly I am a programmer still very much struggling to get to grips with this HDL business and may well be going about designing and optimizing it all wrong. Incidentally any tips for suitable reading matter on this subject would be much appreciated, ranging from specific PSoC tricks to general hardware design principles.

        • 1. Re: How to specify false paths
          user_342122993
                  > Is there any way of specifying false paths or other timing exceptions for Warp synthesis in a custom component PSoC design? - None as I know. As you mentioned resolving the issue by "buffering" signals, the timing violation comes from asynchronous HDL design, so registering the outputs helps. The external pins can be synchronised or transparent, check how pin setting affects the design. There is always a last resort solution of changing system operating temperature range to 0-80 C (Design resources -> System), which would typically double Verilog code frequency limit.   
          • 2. Re: How to specify false paths
            user_431614858

            Thank you.

               

            Synchronizing the pins does indeed avoid the issue. Unfortunately it adds latency to the critical path which I was rather hoping to avoid. The design is configured for the narrow temperature range already I'm afraid.

               

            Oh well, I suppose I'll have to find some other cycles to shave off somewhere else.

               

            Honestly the main culprit is the indexed DMA which carries an unfortunate amount of latency at the moment. For one thing the safety margin for contention is set rather high since I wasn't too sure of my analysis. I should probably also try opportunistically triggering the DMA a few cycles early, then cancelling the action if it turns out not to be necessary.