7 Replies Latest reply on May 17, 2018 9:35 AM by rlos

    posedge vs negedge clocking in UDB component designs in verilog

    Burt_Harris_1507271

      Is it safe to use negedge clocking in PSOC Verilog.  I was concerned because AN82250 PSoC® 3 PSoC 4 and PSoC 5LP Implementing Programmable Logic Designs with Verilog, on page 13 says:

       

      Note To reduce the likelihood of timing and synchronization failures, it is preferable to use posedge clocking in PSoC designs.

       

      But no further detail on why the AppNote says this.   On the other The  Warp Verilog Reference Guide doesn't seem to mention anything against negedge, and uses it in several examples.

       

      When designing for DDR style clocking from an external source, using both posedge and negedge clocks seem needed (or to resort to a significant oversampling using an internal clock.)     Is it reasonable to ignore AN882250's advice in this case, doing something like:

       

      always @ (posedge clock) 
      begin 
      . . .  something
      end

       

      always @ (negedge clock) 
      begin 
      . . .  something else
      end

       

      ?

      PSoC® 3 PSoC 4 and PSoC 5LP Implementing Programmable Logic Designs with Verilog.pdf

        • 1. Re: posedge vs negedge clocking in UDB component designs in verilog
          Burt_Harris_1507271

          Also, in Just Enough Verilog for PSOC, at page 6 it says:

           

          There also exists a negedge keyword. However, because of the architecture of the PSoC, only posedge should be used. Timing and synchronization failures are likely if negedge is used. If it is essential that something occur on the positive and negative edge of a clock, use the rising edge of a clock twice the frequency to trigger the circuitry.

           

          This seems in direct conflict with the examples in The Warp Verilog Reference that use negedge.  What about the PSOC architecture leads to this guidance?

          • 2. Re: posedge vs negedge clocking in UDB component designs in verilog
            rlos

            If you need to work on both edges, it is recommended to run the clock to the UDB logic much higher than the external clock to the PSoC.

             

            For instance, if the external clock is 4 MHz, you can drive the UDB logic at 32 MHz, then implement something like this:

             

            wire external_clock;

            reg  external_clock_reg;

            wire falling_edge;

            wire rising_edge;

             

            always @ (posedge clock)

            begin

              external_clock_reg <= external_clock;

            end

             

            assign falling_edge = !external_clock & external_clock_reg;

            assign rising_edge = external_clock & !external_clock_reg;

             

            What the App Note states it is not recommended to clock the UDB logic with an external clock. All the logic should be synchronized to the internal clock that drives the UDB logic.

            • 3. Re: posedge vs negedge clocking in UDB component designs in verilog
              Burt_Harris_1507271

              Thanks @rlos, but that's not the answer I'm looking for.   That would force me into running a clock PSOC clock at a much higher rate than I want to just to deal with a relatively rare case.   

               

              In my case, I've got multiple clock domains, interfacing to asynchronous systems.  I'm expecting the external clock to be in the range of 12-13 MHz.   Scaling that to run 8x oversampling of your example on a PSOC 5 exceeds the maximum available clock frequency.  

               

              I understand the challenges of multiple clock domains, and want to use the UDB FIFOs to synchronize them, rather than resorting to oversampling on an internal clock.  It seems like the FIFOs have been designed with that in mind,  e.g. they gray code addresses which are safer across clock boundaries than normal binary.

              • 4. Re: posedge vs negedge clocking in UDB component designs in verilog
                rlos

                You might be able to make it work with a 4x the external clock. It depends how much delay you can add in your logic.

                • 5. Re: posedge vs negedge clocking in UDB component designs in verilog
                  Burt_Harris_1507271

                  Yes @rlos, I understand that.  But the appnote's guidance still seems in conflict with the examples in The Warp Verilog Reference that use negedge.  What about the PSOC architecture leads to this guidance?

                   

                  I've got two use-cases where negedge seems helpful:

                   

                  One is like I2C's START symbol:  while the bus is idle both SDA and SDC will be pulled high externally and I'm looking to conserve energy in potentially lengthy idle periods before START.  When the master is ready to START, he pulls SDA low (while SDC remains high, which makes it a START). 

                  start_cond.jpg

                  For power conservation, I really don't want to depend on any high-speed PSOC bus clock while waiting for START (which started me on the negedge topic) because it might be a long time in coming.   If this were I2C FM+, I'd have something like 260 ns of hold time after START till SCL changes, but assuming the faster data rates expected, that hold time drops 38.4 ns .   That might be a problem if I don't have SCL sampled synchronously with the external START event, but I haven't done a detailed analysis of it.  

                   

                  The other use case I where timing might get challenging is writing to the bus in DDR, I've only got a few 10s of nanoseconds after the clock changes to update the output (at max bus loading).   I think that's the tightest external timing requirement, and conservatively I may not be able to hit it, even using the external clock directly:   The PSOC 5LP: CY8C58LP Family datasheet has relevant content in section 11.6.8 saying that 20-25 ns propagation delay from clock to data is possible with optimal placement, routing and pin selection, but frankly DDR support isn't a must-have, I'm more concerned with the power used waiting for START.  

                  • 6. Re: posedge vs negedge clocking in UDB component designs in verilog
                    Burt_Harris_1507271

                    I've found more detailed explanation in PSoC® Creator™ PSoC 3/PSoC 5LP System Reference Guide section on Clocking; this seems authoritative and answers some of my questions..   Based on that, it seems I may be able to, with "special care" use the Sync component of a UDB to permit me to run some of the logic from the external clock signal, then to the FIFO.

                     

                    It sounds like the SPI slave component may be what I need to pattern my solution on, which makes a fair amount of sense to me.   My clock rates are similar to those typically quoted for SPI, but faster than the 5 MHz quoted in the SPI Slave features list!?   Is the Verilog source for the SPI slave available somewhere, or some other example that uses Sync components?

                    • 7. Re: posedge vs negedge clocking in UDB component designs in verilog
                      rlos

                      Burt,

                       

                      If you are worry about power consumption with I2C, you are better off using the I2C fixed function implementation. PSoC supports waking up from deep-sleep when there is activity on the I2C bus. But that only works if you use the I2C fixed function.

                       

                      For the Verilog Source, you have access to the implementation of all components available in the Cypress catalog. You can either import the component, refer to PSoC Creator Tutorial - Importing and Copying Components - YouTube  , or accessing the code in the PSoC Creator installation folder at C:\Program Files (x86)\Cypress\PSoC Creator\4.2\PSoC Creator\psoc\content\CyComponentLibrary\CyComponentLibrary.cylib