Skip navigation
Home > All Places > PSoC 6 MCU Community > Blog > 2017 > June
2017

Hello!

 

Here is part 2 of the Serial Memory Interface (SMIF) feature in PSoC 6.

 

As described in a earlier post, the Serial Memory Interface (SMIF) in PSoC 6 operates in two modes of operation, the Command mode (MMIO) and Memory Mapped mode (XIP).  The memory mapped mode configures the external memory to be mapped into the PSoC 6 address space. This lets the user execute code from external memory or even use the external RAM memories as System RAM. The SMIF hardware implements two cache memory blocks of 4KB each. These cache are for improving performance of the memory mapped mode. These two blocks are available to serve CM0+ and CM4 masters independently.

 

One of the main focuses of the PSoC 6 family of devices is its emphasis on security. One important feature in this aspect for SMIF is encryption. The SMIF block has an inbuilt 128-bit AES encryption engine. This encryption hardware is dedicated for the SMIF block. This encryption is available for usage in both the Memory mapped (XIP) and command (MMIO) mode of operation. In the XIP mode the cryptography hardware supports on the fly encryption in write operations and on the fly decryption for read operations. Encryption support can be enabled/disabled, for individual external memory device slaves. Thus once configured initially the encryption feature is automatic and almost invisible.

 

The SMIF interface will be supported by a feature-rich SMIF driver and an associated GUI based configuration tool. The driver will provide easy to use functions for the users to set up the SMIF block for XIP mode. The driver will also have functions to create command formats in command (MMIO) mode of operation. This will be used to implement special commands supported by different memory vendors.

 

A GUI based tool is also distributed with the driver. The GUI based configuration tool can be used to configure different preset memory devices to different slave slots in the SMIF. New memory devices can also be added to the data base using a simple interface. The GUI also provides an easy way of defining the addresses to map the memories and also their attributes like encryption. The tool is then used to generate the code that can be used along with the SMIF driver.

 

Feel free to leave comments and ask questions!

Hello!

 

There are a lot of peripherals present in the PSoC 6 device. Quite often, in a system we will need to trigger an action in a peripheral based on an event in another peripheral. An example would be something like the ADC’s End of Conversion (EoC) triggering a DMA channel to transfer data from the ADC result register to a memory buffer. In this case you would route the ADC’s EoC line to the DMA’s trigger input (tr_in) line. What is the resource used to accomplish this routing?

PSoC 6 has a dedicated hardware block called the trigger multiplexer block. The trigger multiplexer block is simply a large group of multiplexers that lets you route trigger signals from any source peripheral to a destination peripheral. The trigger multiplexer block covers all potential trigger sources on its input side and lets user route them to destination peripherals. The trigger multiplexer block is a dedicated hardware and does not consume any of the programmable digital resources like the Universal Digital Block (UDB). The trigger multiplexer block also has a way for the user to generate a software trigger on a trigger route.

 

Feel free to leave comments and ask questions, we appreciate the feedback!

MichiyukiY_91

PSoC 6 I2S Feature

Posted by MichiyukiY_91 Jun 6, 2017

Hello,

 

Here is an update on the PSoC 6 I2S feature we have.

PSoC 6 has one I2S hardware block able to produce/receive digital audio streaming data to/from external I2S devices, such as audio codecs, microphones or simple DACs. The frames generated by the IP can be configured to generate data word length of 8-bit/16-bit/18-bit/20-bit/24-bit/32-bit per channel. The channel length is also configurable. The hardware IP provides two hardware FIFO buffers, one each for the Tx block and Rx block. Any writes and reads to/from the FIFOs can be handled by DMAs or CPU.

 

The overall I2S block diagram it shows below.

P6 I2S.jpg

 

Feel free to leave comments and ask questions, we appreciate the feedback!