• S/PDIF for Audio transmission
• LIN communications which is commonly used in Automotive applications
• Support for the CAN library from Vector
• External memory Interface (EMIF) support for PSoC 3
• Annotation Library which allows components from you board to be depicted in your Creator schematic

While you're working with these new components, we are busy working on the next set of new components.  Rather than make you wait until PSoC Creator 2.1 before you see more new components, we have another new feature in Creator 2.0 that allows us to provide you new components much more quickly.  The new feature is the capability to provide a Component Pack.  With a Component Pack we can deliver brand new components and deliver new versions of existing components.  We'll do this without changing PSoC Creator and without requiring a full new installation.  You can install a new component pack quickly and then you can choose when to start using these new components and new component versions all without impacting what version of Creator is building your current designs.

We have several new components that are finishing up now that will go into the first Component Pack which will ship early next year.

For those of you that like to dig a little deeper into how things work you may notice that with PSoC Creator 2.0 there is an additional library dependency called CyComponentLibraryUpdates that is included by default.  This is the library that will contain the new and updated components that ship in a Component Pack.  This library is currently empty.  With each component pack this library will add content and then when PSoC Creator 2.1 ships they will all migrate into the base CyComponentLibrary and we'll start building this update library again.  The PSoC Creator component catalog merges all the content from these libraries together into a single combined view, so you don't need to think about what library your content is coming from.  This is just the mechanism that we've added with PSoC Creator to make these rapid releases of content possible.

PSoC Creator has versioning built into the tool.  This allows me to release the fix for those customers that are in a place in their product development that they are able to integrate fixes.  It also allows customers that are currently using the existing version to continue to use that version, just in case my fix breaks something else.  The original version was version 1.0.  That is designated by naming the component with “_v1_0” at the end.  The new version is version 1.10.  The 1 is referred to as the major version and the 10 is referred to as the minor version.  Cypress has the policy that only the minor version number is updated for fixes and the major version is updated for breaking changes such as changing existing API signatures, adding pins, and the like.  This change was just a bug fix and won’t the break the operation for any current users of the component, so I just updated the minor version.  Also note that I changed from a minor version of 0 to 10.  Creator doesn’t handle single digit minor versions well, so versions 1 to 9 should be skipped.  Also be incrementing by 10 I’ve left space for future patches that could be made between versions.

The creation of the new version is handled mostly by Creator.  Here are the steps:

• Select the existing component in the Component tab
• Copy the component
• Select the project
• Paste the component
• This creates a new copy of the component
• Rename the component as desired

Creator automatically updates the names within the component files automatically.  For example the Verilog module name is updated for you without requiring any manual changes.  Now the functional changes can be made on this new version.

From the user perspective the availability of the new component will not change the existing usage of the component.  The library has both versions available for use.   Any new instance placed from the catalog will be the latest, but existing instances are left as they are.  Since there are now two versions the catalog shows the version number of the latest version.

To update the existing instances the Component Update Tool should be launched from the menu Project->Update Components.  This will provide the opportunity to select the version for each component instance that has multiple versions available.  UARTTx_1 is the instance of interest in this example.  Note that the Component Update Tool allows both upgrading and reverting to an older version if issues are found.

It also includes a link to the datasheet for the selected “Available Version”.  The datasheet has a section that describes the changes made.

I’ve updated the library and made it available here: PSoC Sensei Library 01/27/2011.

We’ve added a new capability to our Cypress blogs.  You can now comment on any blog post.  You’ll need to select the individual post (not the Full list of posts) and you’ll see all comments along with a dialog to allow you to add your own comments.  Now we can have a wider conversation about PSoC and component development.

• Schematic Component
• Verilog Component
• Datapath Component

At that point I had a set of 4 On-Demand Training classes (PSoC Creator 110 to 113) that explained the development of the first two component types.  Now I'd like to point you to the latest On-Demand classes that are focused on datapath component development.  Most of the digital components that Cypress provides in the standard library have been developed using datapaths and now the training is available to allow you to use the datapaths as well.

There are a couple of reasons that you might want to consider using a datapath in your own components:

• Logic Density: The datapath portion of the UDB has significant capabilities.  It has 4 byte wide registers, 2 4-entry FIFOs, an ALU and up to 6 comparison outputs.
• CPU / DMA Communication: The datapath has two FIFOs that are perfect for communicating with the CPU or with DMA.
• Runtime Configuration: Datapath based components will typically have a portion of their configuration done by having the CPU write registers.  This gives the capability to change some of the configuration at runtime.  For example changing the Period of a PWM.

Developing datapath based components will require learning the way that a datapath is configured and that's why I've put together these training classes at www.cypress.com/go/training:

• PSoC Creator 210: Intro to Datapath Components
• PSoC Creator 211: Datapath Computation
• PSoC Creator 212: Datapath FIFOs
• PSoC Creator 213: Multi-Byte Datapath Components
• PSoC Creator 214: Datapath API Generation

Now I'll get working on some new components.

This component uses some optional pins, so I'll use this component as an example to explain how that is implemented.  There are several modes of operation for the Count7 and depending on the mode the enable (en) and load (load) signals may or may not be present.

This is implemented on the component by two parameters on the symbol.  These parameters are passed to the hardware where they provide the parameters to the count7 primitive instance.  The “Hardware” attribute of the parameter controls whether the parameter is passed to the Verilog implementation.

These parameters are also used to control the presence of the pins on the symbol.  To control the presence of a pin select the pin in the symbol editor.  Then right select and choose “Format Shape”.  In this dialog the Visibility of the pin can be controlled using an expression that uses parameter values.  A default value needs to also be provided.  The pin is always present for the Verilog instance, so this becomes the value used when the pin is not present.

Next time you need a 7-bit or smaller down counter you have another implementation option with the Count7.

The SimpleCount7Test project demonstrates the simple usage of the count7.  This design instantiates a count7 in Verilog as follows:

• cy_period: This is the 7-bit value that gets loaded when the counter reaches 0.  The overall period of the counter is (cy_period+1).  In this example the counter counts: 3, 2, 1, 0 for a period of 4.
• load: The routed load is disabled in this case so a constant 0 (don’t load) is used.
• enable: The routed enable is disabled so a constant 1 (enabled) is used.

The waveform shows the count sequence that is generated starting from power up.

CNT_START refers to the software enable bit for the count7.  The most common mistake I see with new users of the count7 is forgetting to set the software enable.  The count7 comes up disabled.  Software must write the CNT_START to 1 in the Aux Control register in order to enable the counter.  Refer to the main.c in the example projects.  The first cycle after being enabled the Period register is loaded into the counter and it then begins to count down.  Once it hits 0 the period is reloaded.  The Terminal Count (TC) goes active one cycle after reaching 0.  The TC signal is registered which is the reason for the one cycle delay from the 0 count.

The FullCount7Test project demonstrates more of the features of the count7.  It is instantiates the instance in Verilog as follows:

• cy_init_value: An initial value other than 0 can be provided.  It will be loaded by software at configuration time.
• cy_route_ld: Enables the routing of the load signal
• cy_route_en: Enables the routing of the enable signal

In this design the load and enable signals are connected to the two mechanical buttons on the DVK.  Those buttons are low when pressed, so the inverters on the schematic change the polarity so that pushing the buttons causes enable or load to occur.

The routed hardware enable is in addition to the CNT_START software enable.  Both must be active in order for the counter to count.  The counter counts down on each clock when the enable is high.

The routed hardware load will cause the counter to be reloaded with the period count value on any clock where load is high and enable is also high.  Note that enable must be high in order for the load to occur.

Another note on the load signal is that the load signal when count is 0 will prevent the TC from going active in the next cycle.

That's all there is to using the count7 in your own Verilog component.  When you just need a count7 in a schematic design and to provide examples of how to create APIs around the count7, my next post will be a count7 for the PSoC Sensei library that you can just drop into a schematic.

The datapath configuration tool created the instance of the datapath and it was used to fill out all the parameters that were needed to configure it.  The tool didn’t however connect the datapath up to the rest of the Verilog implementation.  That part is done from the PSoC Creator editor. With the datapath fully configured and saved, it can be loaded back up in the editor in Creator.  The top part of the instance is all the parameters that were populated by the Datapath Configuration Tool and they should be left untouched.  The bottom part of the instance is where all the ports of the instance are connected.  Typically only a small portion of these will be connected.  In this case the following need to be connected:

• clk:  A clock must always be provided.  This is the clock that everything in the datapath is clocked by.  Because the registers of the datapath also are read and written by the CPU or DMA which is operating using BUS_CLK, the clock provided as the clock should also be synchronous to BUS_CLK.
• cs_addr[2:0]:  This is the control store address bus.  It selects which of the 8 possible dynamic configurations are executed for each clock period.  This will need to be connected to something other than the default 3’b0 unless only one operation is needed.  For this component it is connected to the cfg signal that has been decoded from the State register.
• so:  Shift Out is the signal that provides the shifted out value that is transmitted as the data for the UART.
• f0_bus_stat:  This is one of the status signals for the F0 FIFO.  The F0 FIFO is the FIFO that is providing the data to be sent by the UART.  When a FIFO is configured for input (input into the datapath) this signal indicates that the FIFO is not full.  That information is needed by the CPU or DMA to prevent them from overflowing the FIFO.  For the CPU this is passed via a Status register.  For the DMA this signal is passed to the DMA controller directly as the drq signal on the component.
• f0_blk_stat:  This is the other status signal for the F0 FIFO.  This signal indicates that the FIFO is empty.  It is used by the state machine to know when to move on and transfer the next byte of data.

Here is the Verilog connectivity for the datapath.

There are two remaining pieces to this component: Clocking and the Status Register.  Many datapath components will also have a Configuration Register.  This component only implements the transmit side of the UART, so it doesn’t need an enable bit which would require a Control Register.  As long as nothing is sent from the CPU/DMA, then it just waits for data.

As mentioned earlier, datapath components need to be driven by a clock that is synchronous to BUS_CLK.  There are some rare exceptions to this rule, and it is much more difficult to create a component that isn’t synchronous to BUS_CLK.  This component is designed with the expectation that the clock is synchronous to BUS_CLK.  There is a special component that has multiple clocking uses called UDB Clock Enable.  I’m not going to discuss all the uses for this component here, but I will show this specific use.  If a clock signal is passed as an input to this component and it is configured to have it’s sync_mode set to TRUE, then the clock signal that comes out of this component will always be synchronous.  PSoC Creator will analyze the input clock.  If it is already synchronous, then this component will just pass the input clock to the output clock.  If the input clock were not synchronous, then PSoC Creator would create a double flip-flop synchronizer circuit.  This would cause the output clock to be synchronous to BUS_CLK.  The input clock used is the clock provided to this component.  The output clock is then used throughout the implementation of this component.

For the overall implementation of this component including the APIs, the CPU will need some information about the current status of the component.  In this case a status register is used to provide this information from the hardware.  In addition to just providing the status it may also be desired to generate an interrupt to the CPU, so a specific type of Status register that can generate an interrupt called a statusi is used.  This type of status register can have up to 7 bits.  Each of those bits can be masked.  If any of the bits are high and the mask for that bit is high, then an interrupt is generated.  Each of the bits can be transparent or sticky.  The transparent bits provide the direct value of the signal to the CPU.  In sticky mode the signal is captured at every rising edge of the clock.  If it is high at that time, that high is retained (sticky) until it is cleared by the CPU reading the status register.

There are two pieces of status information that are provided by this component.  The first is whether the FIFO is not full.  As long as this is active the CPU can continue to send data.  The second piece of information is whether the component is idle.  The idle indication can be used to determine when the transmission of a message has been fully sent by the hardware of the UART. 

The parameters passed to the Status register are:

• cy_force_order:  This must always be set to 1.  It forces PSoC Creator to maintain the ordering of the bits exactly as described.  This is the only mode currently supported.
• cy_md_select:  This selects on a bit by bit basis whether the bit is transparent (0) or sticky (1).  In this case the bits are all transparent.
• cy_int_mask:  This is the interrupt mask.  This is typically set by default to 0 which disables interrupts for all bits.  Later if desired an API can write the mask to another value.

Below is the instance of the status register used for this component.

That completes the hardware implementation of this component.

If you’d like to build your own component or you have an idea for an interesting design, take a look at the Cypress ARM Cortex-M3 PSoC 5 Design Challenge.
 

The Datapath Configuration Tool is only installed with PSoC Creator Beta 5 if you chose to do a Complete install.  If you chose to do a Typical install it was not installed.  You can go back and change your installation to Complete and it will add the Datapath Configuration Tool.  With the next PSoC Creator release the Datapath Configuration Tool will be made part of the typical installation.

To start using the Datapath Configuration Tool you need to have a Verilog file to work with.  I'll assume that you've gone through the training on creating a Verilog component.  Refer to my post on "Creating Your Own Components".

Launch the Datapath Configuration Tool from the Start menu at Cypress->PSoc Creator 1.0->Component Development Kit->Datapath Configuration Tool.  Make sure that the Verilog file that you've created in PSoC Creator is saved.  The Datapath Configuration Tool will read this file in and then later it will be saved back with changes, so you need to be careful to only edit in one place at a time and to save when switching between which editor is changing the file.  Use the File->Open menu item to open the Verilog file.

At this point you wouldn't have created any datapath instances in your Verilog, so there are no datapaths to configure yet.  Use Edit->New Datapath... to create a datapath.  Give it a name and select the 8-bit datapath cy_psoc3_dp8.  Your new datapath will show up in the Configuration selection with the instance name you chose followed by "_a(8)".  The "_a" is the extension given to the least significant byte of a datapath and the "(8)" indicates this is used as part of an 8-bit datapath.  If this had been a wider datapath then there would have also been an "_b" configuration and possibly an "_c" and "_d".  Each byte of the datapath has its own configuration.  Only an 8-bit datapath is needed to implement a UART.

There are two pieces to the configuration: Dynamic and Static.  The Dynamic configuration is the CFGRAM area at the top of the Datapath Configuration Tool.  The Static portion is the rest of the configuration.

In the Verilog code the two dynamic operations have been labeled LOAD and SHIFT and assigned addresses 0 and 1 respectively.  The usage of the dynamic configuration is controlled by the control store address (cs_addr port of the datapath instance) which has been assigned to the cfg signal.

Using the pictures from the previous post, the dynamic configuration can be filled out to match the operations:

Only the first two configurations are populated since the others are unused.  In the LOAD configuration the only operation to perform is to load A0 from the F0 FIFO.  This is done by setting the A0 write source (A0 WR SRC) to F0.  The ALU function being performed doesn't matter.  For the Shift operation the ALU operation is simply to PASS the value in A0 (SRCA is used for the PASS operation) and then shift it right (SR SHIFT operation).  Then that result is written back to A0 (ALU as the A0 WR SRC).

There are several columns that have not been used that I'll mention here.  CFB EN is only used for CRC type operations, so this is typically disabled.  The CI SEL, SI SEL, and CMP SEL select which static configuration to use for carry input, shift input and comparison.  Each of these has an A and a B choice and then in the static configuration there is a configuration for A and B.  For this component only a shift is used and only one configuration is needed, so A is chosen and then static configuration for A is configured.

The Static configuration is the same for all 8 of the dynamic operations with the exception that for several of the operations there is an A and a B configuration that can be selected dynamically.  I'll address more of the static fields with other component examples.  For this component the fields of importance have been highlighted:

Many of these settings are the default values, but the values of each of these settings applies to this application:

• DEF SI: The default shift in value can be either 0 or 1.  Here it is configured as 0.
• SI SELA: The A shift In selection is being used in the dynamic configuration.  It is configured to use the default shift in value which is 0.  This isn't actually important for this application since 8 bits are shifted out and then the value that remains is not used.  This setting however will result in A0 having 0 in it once it has shifted out the 8 bits.
• SHIFT SEL:  Selects whether the shift out signal is taken from the left or from the right.  This can be confusing since the dynamic configuration has already selected that a shift right will be implemented.  The dynamic configuration does determine the final ALU result which is written back.  This static confguration determines whether the LSB or MSB is sent out on the shift out (so) port.  This application is using the shift out bit as the bit to transmit, so it must be configured to take the LSB (shift right).  Note that the shift out is still the LSB or MSB even when no shift operation is being performed.  That can be useful for some applications where the LSB or MSB is needed, but a shift is not desired.
• F0 INSEL: This selects the direction of the FIFO.  In this case the FIFO value should come from the CPU or DMA (BUS).
• FIFO ASYNC: This controls whether the FIFO block fill level signal needs to be synchronized.  Setting this to ASYNC means that this datapath is not running on BUS_CLK and needs the synchronizer to be added.  This will add a single flip-flop clocked on the datapath clock.  This makes the block status synchronous to the datapath clock and means that timing will be easier to meet in the logic that uses this signal.  This selection should normally be set to ASYNC as shown here.

With the configuration complete the Verilog file is written back with this configuration added to the instance for the datapath by using File->Save.  If you reload the Verilog in PSoC Creator you can see that the datapath instance has a set of parameters as part of the instance.  These are a direct reflection of the configuration information selected in the Datapath Configuration Tool.  These could have been entered by hand, but the Datapath Configuration Tool allows this large amount of configuration data to be entered and read in a graphical manner.

With the next post I'll take a look at connecting up the datapath to the rest of the Verilog.

The first step is to create a state machine that controls the operation of the UART.  Most all components will include a state machine and a datapath.  The state machine will be written in synthesizable Verilog and gets placed into the PLD logic of the UDBs.  The datapath portion will get instantiated into the Verilog description and is implemented with a datapath instance in the UDBs.  Below is the state diagram for the UART:

The state machine waits for the CPU or DMA to place an entry in the transmit FIFO.  Once there is data present it transmits one Start bit, 8 data bits and finishes with one Stop bit.  The bits are sent starting with bit 0.  A design requirement is that two bytes can be sent back to back, so the STOP state must go directly to the START state if more data is available.  The implementation in Verilog is a direct mapping of this diagram to a Verilog case statement:

Now that the state diagram is in place, what happens in each of those states needs to be defined.  For a UART implementation the Start bit is a 0, the Stop bit is a 1, and the data bits are shifted out from bit 0 to bit 7.  In addition when nothing is being transmitted (Idle state) the output is held high (same as the Stop state).  To avoid any glitches on the output the tx signal is implemented with a register.  If it was implementated directly as combinatorial logic the value output can quickly oscillate between low and high as all the state bits are decoded to determine the next output value.  The code below implements this functionality.  The signal "so" is the Shift Out value from the datapath.

The state machine is used to control the datapath.  Based on these 11 states there are just 2 operations that need to be performed.  Either a new value needs to be LOADed from FIFO or a bit of the data needs to be SHIFTed out.  There are some other states such as STOP and IDLE where what operation happens doesn't matter as long as there aren't any negative side effects.  In these cases SHIFTing can be done and the shift out bit is just ignored.  The code to map the states to the datapath operations is as follows:

So there are two operations that need to be implemented in the datapath: LOAD and SHIFT.  The datapath allows up to 8 operations to be configured.  Each operation will do an ALU operation and update some registers.  Only a limited number of combinations are possible, so based on capabilities of the datapath, the registers and ALU operations need to be carefully laidout.  Below are the two operations that this component needs:

During the LOAD operation the FIFO (F0) is read from and the value is stored in the accumulator (A0).  During the SHIFT operation A0 is read, passed through the ALU (no operation), shifted right and then written back to A0.  The bit that is shifted out is sent out of the datapath on the "so" signal which was shown in the Verilog code earlier.

With the next post I'll show how these operations are mapped onto the datapath with the Datapath Configuration Tool.

No problem.  A custom component to do just what I need will be small and fast.  I only need to support the typical UART configuration of 8 bits, no parity and 1 stop bit (8-N-1).

I've added this Tx only UART to the PSoC Sensei Library.  This component uses the datapath and the PLD portions of the PSoC Universal Digital Blocks (UDB), so in future posts I'll describe the design process that was used to build this component.

I've attached two simple test projects to show the UART being written by the CPU and to show the UART being written using DMA.  Both these projects are in the same Workspace.  Just select the project that you want to use and build and download it to the DVK to experiment.  The transmit pin in these examples is connected to pin 0[0], so wire that up in the breadboard area to the Tx connector just to the left of the breadboard area.  Also make sure that you have jumper J10 connected to provide power to the RS232 drivers.  Then hook the design up to a terminal emulator running at 57.6K baud.  The CPU based design will print out "Hello, world!" each time the device is reset.  The DMA based design will print all the capital letters continually as fast as the baud rate will allow.
 

You'll need the updated PSoC Sensei Library and the Test projects.  Unzip both of these in the same parent directory.

PSoCSenseiLibrary103110.zip

UARTTxTest.zip

All the components in the library will be versioned.  For example the first component in the library is FIFOIn v1.0.  If I make functional changes to that component I'll create a new version.  Both the new version and all older versions will continue to be in the library.  You can make the decision on when you want to upgrade to a newer version of a component.  This is the same methodology used with the core library.  The Component Update Tool can be used to choose the version of a component you want to use.

Long ago when I last posted to the blog (I'll be posting more frequently) I provided an 8-bit wide FIFO component.  Even though PSoC 3 has an 8-bit processor, much of the infrastructure in the chip is either 16-bits or 32-bits wide.  In particular the DMA path from the UDBs to SRAM supports 16-bit transfers.  This means that you can get twice the performance by using a 16-bit wide version.  The component in the PSoC Sensei library supports both 8 and 16-bit operation.  The example that I've provided uses the component in 16-bit mode.

In this example there is a 16-bit free running counter providing the input data.  The Timer is used to indicate when to capture a word from the counter.  The Timer component will produce a single cycle pulse every time it counts down to 0.  This is used to control the rate that data is sampled.  As configured it causes a counter value to be captured every 9 cycles.  This is as fast as the DMA engine can capture a single one word burst of data from the UDBs.  This is true whether it is capturing an 8-bit word or a 16-bit word.  These 9 cycles are made up of 7 cycles of overhead and 2 cycles to transfer the word.

If you run the design in the debugger you can watch the buf[] array and see the values that are captured.  The starting value is dependent on when the components are enabled, but each entry after the first should be 9 more than the last.  Below is a capture from the debugger:

As described, the maximum rate is dependent on the overhead cycles and the transfer cycles.  If you need to transfer words faster than 9 cycles per word, then you can transfer more than one word at a time.  This can be accomplished by setting the FIFO up to cause a DMA to occur once the FIFO is at least half full.  This indicates that there are at least 2 words available.  That configuration is done by configuring the component as shown:

Now that you know that at least two words are available you can change the setup of the DMA to do 4 byte bursts (2 words) instead of 2 byte bursts.  That is done in the DMAInitialize() function call with the first parameter as shown here:

Now the system is able to transfer 2 words every 11 cycles.  These cycles are made up of the same 7 overhead cycles and then 4 cycles for the transfer of the two words.  That makes the average rate 5.5 cycles per word.  The last change to make is to change the period of the Timer component.  Update that from a period of 9 to a period of 6.  Now a word will be put in the FIFO every 6 cycles.  The result is shown from the debuggger:

Attached is the example project and the library.  The example is dependent on the library (Project->Dependencies...).  PSoC Creator puts dependencies in a project relative to the location of the project.  If you unzip both of these files in the same parent directory, then the example will be able to find the library.  If you place the library somewhere else, then you will need to update the dependency to point to the right place.  I've included a complete datasheet with the FIFOIn component, so take a look at the datasheet and at this example for more details on the use of this component.

Example FIFOIn 16-bit project:  FIFOIn16Example.zip

PSoC Sensei Component Library: PSoCSenseiLibrary.zip

I've provided a component that takes a parallel 8-bit input and sends it into the datapath FIFO.  In future posts I'll provide components that are both 8 and 16 bits wide along with providing components that operate with the FIFO in the opposite direction.  To prove out the operation of this first component I've included the following project:

This project has two components.  The FIFOIn8 component is the component that gives you access to the datapath FIFO.  On each clock (clk) if the enable signal (en) is high, then the data is sampled and placed into the FIFO.  The status provided is an indication of whether the FIFO is currently full and a DMA request that triggers the DMA if the FIFO is not empty.  The DMA must be operated in a level triggered manner (refer to the main.c example code for how to set the DMA into that mode).  The second component is the Count8 component.  This is simply an 8 bit counter that counts up whenever the enable signal is high.  By using the FIFO full flag to throttle the counter (enabled when the FIFO is NOT full) to the speed that the DMA can remove data from the FIFO, the result is a continuous stream of incrementing bytes into the FIFO.

To observe how this operates, bring the design up in the debugger within PSoC Creator.  Set a Watch on the buffer (buf[]).  Initially the buffer will be filled with all 0's.  Allow the code to run and then pause the code execution.  Now the debugger will update the display of the buffer and you will see that it contains the sequential values that have been DMAed in from the FIFOIn8 component.

This component can be used anywhere that you want to capture a stream of values.  For example if you want to capture a stream of values coming in on the pins of the device, those pins could be connected to the data lines of this component and the values could be captured to SRAM or the data transferred to a peripheral.  The datapath FIFO provides a 4 entry buffer to allow time for a DMA response and it also provides the appropriate signals to trigger the DMA.

The design InOut8 Project can be downloaded and run on any PSoC 3 based development kit.  This same code will also work with the upcoming PSoC 5 development kits.

There are 3 levels of components that a user might want to develop:

1. Schematic Component
2. Verilog Component
3. Datapath Component

Each level gets progressively more involved and more powerful.  A schematic based component provides a hierarchical schematic capability.  Here you can combine any of the components in the current library and also encapsulate the APIs that go with that combination.  With a Verilog based component you have the ability to pull in more complex unique digital content and take direct advantage of the PLDs built into PSoC 3 and 5.  The capability to do either Schematic or Verilog based components is in Creator today.  The third level, datapath based components, adds to a Verilog component the usage of the datapath resources in PSoC 3 and 5.  With datapaths you can create denser designs and more flexibily communicate between your hardware component and the CPU.  The ability for customers to take advantage of datapaths in their own components will be made available in Creator with the Beta 5 release due out later this year.

In order to get you started on the right track, I've developed several training classes that each include:

• Video
• Slides
• Example Projects

They are all posted on the Cypress website under the Design Support tab, then Technical Training, then On-Demand Training, or you can skip directly there with the following links:

• PSoC Creator 110: Schematic Components 
• PSoC Creator 111: Component Parameters 
• PSoC Creator 112: Introduction to Component API Generation 
• PSoC Creator 113: PLD Based Verilog Components 

 Then I'll build on this training with some more examples and insights here on the blog.

Specifically it can be interesting to look at how many PWM outputs can be generated by a single PSoC 3 device.  The digital array (UDB array) has 24 UDBs.  Each of those UDBs can be used to create an 8-bit PWM.  Each of those PWMs can generate 2 independent outputs.  They have the same period, but the duty cycle is independent.  So if the entire array is dedicated to generating PWM outputs, then 48 PWM outputs can be generated.  To make sure there aren't any gotchas, the video shows a design that includes 48 PWM outputs along with the utilization report showing the resources used.  If by chance, 48 PWM outputs is not enough you can squeeze 4 additional PWM outputs from the fixed function counter/timer/PWM blocks.  I've not used those in the designs shown here, but they are available and can be used to provide 4 extra single output PWMs.  So the correct answer to the question posed by this post is 52.

The next question is what to do with all of these PWM outputs.  There are many real world examples where a large number of signals that have individually controllable PWM signals would be useful.  For this example I'm going to use them to control the brightness of LEDs.  In particular I've built a design that uses RGB LEDs, so I'll need 3 PWM outputs for each LED in order to control the three color components.  This will allow the creation of 16 Million possible colors since each of the color components can take on 256 distinct levels of brightness.  I didn't want to breadboard up a system with 16 of these LEDs, so to prove the concept I've used just 2 of the RGB LEDs.  To make it a little more interesting I've used the CapSense capability of PSoC to control the LEDs.  I'm using the 2 CapSense buttons on the DVK to select the LED and the color component and then using the slider to control the brightness.  Have a look at the video:

If you'd like to experiment with this design, you can download it here: RGB_LED Design

Now that you have Beta 4 installed, the first thing that you'll notice when you use it with your Beta 3 designs is that a dialog will pop up asking about whether you would like to run the component update tool.  We realize that depending where you are in your design process, you may want to limit the changes to the components in your design or you may want to get all the latest updates and bug fixes for the components that are already in your design.  PSoC Creator includes a versioning system that allows full flexibility for the user to manage what version is used for each component instance.  Just because you've updated to the latest version of Creator, you are not forced to update to the latest version of each of the components.  From the component update tool you can see what version you have of each component, what the latest version is, and what has changed between versions.  Then you can select which instances to update.  You even have the flexibility to revert to an older version if you try a newer version and decide that you want to move back to an older version.

I've provided a video here that shows you the process along with some extra details:

The implementation of an indexed DMA uses one or more DMA Transaction Descriptors (TDs) to transfer an address from a component to another TD that performs the transaction of interest.  In this example 3 TDs are used as shown:

The first two TDs read the address from the Phase Accumulator component.  The third TD reads from that address and sends it to the DAC.

The Phase Accumulator is a custom hardware component that was built for this example and is included with the design.  It uses the programmable digital logic in the UDB array to generate the address needed by the DMA.  The implementation of this Phase Accumulator uses a 16 bit counter and a programmable increment value.  The upper ten bits are used as the index into a 1,024 entry sine wave SRAM lookup table.  The lower 6 bits allow for finer increments in the generated frequency.  The result is a Direct Digital Synthesis implementation.  The focus of this blog entry is the Indexed DMA functionality.  Details about building hardware components will be addressed in future blog entries.

This example brings together the unique combination of capabilities of PSoC 3 and PSoC 5 (programmable digital, programmable analog and flexible DMA engine) resulting in a design that is fully controllable by the processor, but also fully offloads the processor. 

You can see PSoC in action here and the design is attached for you to experiment further with the power of PSoC: IndexedDMA.zip
 

Since PSoC Creator is an integral part of doing any PSoC 3 or PSoC 5 design, I'll often use a video to show the application development process.  Here is a video showing the construction of the DMA and the results obtained using the PSoC 3 DVK.

I encourage you to download PSoC Creator if you haven't already and experiment with the design for this project which I've provided here: DMA_DAC.zip

In case you want to experiment with the waveform, I've also included the simple program that I used to create the waveform: main.zip