You are here

Synchronizing Signals with the Production Creator 1.0 | Cypress Semiconductor

Synchronizing Signals with the Production Creator 1.0

PSoC Creator is no longer Beta.  It made the leap to a Production Release this week.  It’s available for download now.  If you already have a Beta version installed you can just upgrade with the installer from the Beta release.  If you haven’t installed PSoC Creator yet, then you can find it at www.cypress.com/go/psoccreator and then click the Download button.

 
With the Production release there are some new features and components.  This post will discuss how to synchronize signals including how to use the new Sync component.
 
 
PSoC 3 and 5 have considerable flexibility in the clocking mechanisms that are available.  Throughout the digital logic array (UDB array) there are 9 low skew clocks available.  One of these is always the bus clock (BUS_CLK).  This is the clock that the system bus that runs throughout the device runs at.  By default this is also the speed that the CPU is running at (PSoC 3 can support a divided CPU clock).  There is another clock called the master clock (MASTER_CLK).  This is the fastest clock in the system.  It is possible to have BUS_CLK be divided down from MASTER_CLK, but I strongly encourage that you always have this divider set to 1 (that is the default).  If you follow that recommendation BUS_CLK, MASTER_CLK and the CPU_CLK will all be the same frequency and the fastest clocks in the system.  The other 8 clocks will be divided down versions of any of the clocks in the system.  These clocks by default will be synchronized to MASTER_CLK.  This is controlled by a check box in the clock customizer.
 
 
You will generally want all your clocks synchronized to MASTER_CLK.  That will allow easy communication between these clock domains and communication with the CPU or DMA.  With all these clocks synchronous to MASTER_CLK a signal crossing between the domains will need to meet setup timing requirements within a MASTER_CLK period.  When going from one clock domain to a slower clock domain the signal will need to be held long enough that it will be sampled by the slower clock domain, but there aren’t any asynchronous clock crossing issues.
 
Some signals in your system will likely come from sources that are asynchronous to the clock domain where they are used.  The most common source for an asynchronous signal is an input pin.  By default digital input pins are synchronized.  This checkbox causes the input signal to be synchronized to BUS_CLK.
 
 
Synchronization is done by a double synchronizer.  Logically a double synchronizer is implemented as two back to back flip-flops.
 
 
The theory behind this structure is that the signal may fail to meet the setup or hold time of the first flip-flop causing it to go to a metastable state.  If that condition occurs it will settle to either 0 or 1 before the value gets clocked into the second flip-flop, so the value from the second flip-flop can be used with confidence that it will change only on the clock edge.  A double synchronizer will introduce from 1 to 2 clock cycles of delay on the incoming signal.
 
The synchronizer for the input pin will be implemented directly at the pin if BUS_CLK is less than or equal to 33 MHz, and it will be implemented within the UDB array for higher speed clocks.  When implemented within the array a special configuration of a Status register is used that can synchronize up to 4 signals to the same clock.  PSoC Creator will automatically pack signals synchronized to the same clock.  In either case the synchronization is done with BUS_CLK.
 
Synchronizing to BUS_CLK provides lower latency than synchronizing to a lower speed clock, but it places tighter timing constraints.  Ideally signals should be synchronized to the same clock domain where they will be used.  This can be accomplished by using the new Sync component which can be found in the component catalog in the System folder.  For a pin the Sync can be used in place of the BUS_CLK synchronizer by turning off synchronization on the pin component and using the Sync component.  The clock for the Sync component can be any clock in the system.  
 
 
The Sync component is always implemented with the special mode of the Status register.  When reviewing the report file for resources utilized you’ll find separate entries for Status and Sync Cells, but they are using the same resources.  To account for this the number listed as the Max Sync Cells is calculated as 4 times the Free Status registers.
 
 

Comments

Diode Dan's picture

Could you do a post on how to do a double buffer with the FIFO and DMA? I think users would like to see how a double buffer (ping pong buffer) scheme would work in PSoC 3/5 hardware.

bjbu's picture

I could certainly do that. Could you describe a little more about the kind of thing you'd like to see? For example if it is fixed length data blocks and you just want them to alternate back a forth between two buffers, then that is simple to implement. You would need to know which buffer to use in software (likely use an interrupt), but otherwise this is just two TDs.

Diode Dan's picture

There are three major areas of PSoC that could use some explanation (in my opinion):

1) Ping Pong Buffering. For example, a sensor collects data and the DMA forwards it into buffer A, the program then switches to buffer B to fill. Essentially this is a traditional ping pong buffer as you described.

2) External clocks and digital speeds. My understanding is that the PSoC can only handle up to 33 MHz external signals. however, what happens to the 67MHz & 80MHz limits of the PSoC 3&5? Can they not handle these signals in the UDB? For example, say I have an external 60 MHz clock that is a synchronous data transmission clock. Can I not use this with a sync component?

3) Where are we with EMIF?

Thanks. The blog is really helpful.

bjbu's picture

Thanks for your comments Dan. I'll try my best to respond to these 1) A ping pong buffer is straight forward to implement with PSoC 3/5. The chained structure of the TDs fits well with this construct. In its simplest form you would have two TDs with one for each of the two buffers. These would be chained together in a loop. The important part is coordinating with the CPU. You want to use the TERM_OUT capability that can optionally be generated at the end of a TD. As long as you are certain not a miss an interrupt, then the CPU will know which buffer has been filled and be able to toggle between the buffers. This concept can also be expanded to support any number of buffers. I've used this also with a continuous stream of data placed in a circular buffer. In that case the interrupts are used to keep track of the fill level. 2) The output frequency of the GPIOs is limited to 33MHz, but the input frequency is limited to 67MHz. That means that you could bring in a higher frequency clock signal, but there isn't tight control between an input signal that is brought in as a clock and an input signal that is brought in as data. That would make handling high speed source synchronous interfaces difficult with PSoC. Typically the data interfaces with PSoC will want to be sampling using the opposite edge of the clock from the clock edge that changes the data. The MASTER_CLK/BUS_CLK in PSoC when it is operating at higher speeds is generally created by the PLL. For example you can take a 3MHz IMO clock or 12MHz Crystal and have the PLL create a 67MHz clock from it. Then that is the clock that runs the system. The chip is able to handle signals across the full speced operating range, so you can use 67MHz clocks in the UDBs. You will however find that many functions that you would want to implement with a UDB will not be able to meet timing at that speed. That depends on the level of complexity of the function. Refer to the component datasheets for an expectation of performance and the STA report for the timing for your specific design. You can use the Sync component with any signal, but you will need a clock of at least 2x the rate of the incoming signal in order to sample the signal and not loose edges. 3) The EMIF is supported in the production PSoC3 silicon (along with ES3) that is now available. Support in PSoC Creator is available starting with the 1.1 release coming in Q3. The PSoC5 device will not have EMIF support. That feature is being removed from the datasheet.

jordanss123 jordanss123's picture

Thanks for you share great topic with us. fake yeezy boost 350

 

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.