The PSoC Sensei Component Library now has the 7-bit down counter hardware called Count7 encapsulated into a component.  The latest library is available here: PSoCSenseiLibrary122710.zip

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.

Each UDB has a datapath, control register, status register and 2 PLDs.  An additional resource that is available is a count7.  A count7 is 7-bit down counter that borrows some of the resources from the other parts of the UDB.  Specifically the count7 uses the control register, it uses the mask register of the status register and if a routed load or routed enable is used, then the inputs that would be used by the status register are consumed.  If neither the routed load nor enable are used, then a status register can still be used in the UDB, but the interrupt capability (statusi) is not available.  That means that for the cost of a control register and sometimes a status register you can get the functionality of a 7-bit down counter.

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.

Now that the datapath has been created, there is just a little more work required to complete the Verilog implementation of the high speed transmit only UART.

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.
 

Now that it's been determined that the there are two datapath operations that need to be performed, the Datapath Configuration Tool can be used to configure a datapath that performs those functions.

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.

In the next few posts I'll go through the implementation of the Transmit UART.

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.