Cypress Perform

You can now add comments to blog entries.  Let me know your thoughts.

OK, so I just went through intensive Sensei training. I'm thinking of "growing my own" SPI component. So far it looks  complicated, but feasible because of your good training videos.

Here's the issue-I need a 12-bit DAC that can operate at 1M sample/sec. I found a TI DAC that I like (DAC8560), and it takes a 24-bit SPI data input (problem #1). Also, I found that the SPI data sheet is limited to 8 M bit/sec data rates, which is much too slow for 24bits * 1Ms/s + overhead. Overhead will be around 20% as a guesstimate. So we would need to bit-clock the USB/datapaths  at around a 28 Ms/s bit rate. Is this feasible? Can I gain clock rate by growing my own SPI interface?

Kelly C.

From the description of your application I expect that your question is for the SPI Master.

The limitation in the speed of the SPI Master is not the ability to clock the datapath fast enough.  The limitation is in the path for data coming back from the SPI Slave.

The critical timing path is the propagation of the SCLK from the Master, response on MISO from the slave, and propagation back into the PSoC.  With the current PSoC SPI Master this must meet the timing of 1/2 of an SCLK cycle.

Most SPI Slaves will keep the data available for an entire clock cycle, so the speed could double if the component was designed to sample after a full clock instead of 1/2 clock.

The other question would be what data you need back from the DAC.  If you can ignore the data from the DAC, you might be close to your target with the current component.

If you have any feedback on how we are handling the MISO signal sampling let me know.

Hi Brad,
Fortunately, there is no data coming back from the DAC. There are some relevant timing issues with respect to the select signal (called ~SYNC on the DAC). It's setup time before the first bit is 0, but it must hold after the last (24th bit) for at least 100 microsec's. I did not find a way to turn off the MISO, however. 
Thanks, Kelly 

Hi Brad,
Fortunately, there is no data coming back from the DAC. There are some relevant timing issues with respect to the select signal (called ~SYNC on the DAC). It's setup time before the first bit is 0, but it must hold after the last (24th bit) for at least 100 microsec's. I did not find a way to turn off the MISO, however. 
Thanks, Kelly 

No need to turn off the MISO.  You can just hook it to a constant 0 and ignore the data which would then always be zero.

Ok, sounds good - so I will just ignore the error status. Now how about the 24-bit question. Right now, if I run the SPI slower, then it holds the select low for all three bytes (as shown in the SPI data sheet). If I run the SPI clock faster - the equivalent of around 400Ks/s, then the sync goes high after each of the bytes, and the DAC "chokes". I figured out a scheme for managing the select manually, but that's just a work-around. Ultimately I need to get to 1Ms/s (or 770K for ES1), and I will chew up the processor, if I need to manage it manually. Is there a way to accomplish this by modifying or  extending the SPI device, somehow in Verilog (rather than starting from scratch). What would you use as a starting point?

The generation of the Slave Select in SPI automatically is problematic because different devices want to see different things.  The automatic generation in our component isn't going to work for you and the use of the CPU isn't going to come close to the performance you need.
I would not recommend trying to start from the SPI Master.  The requirements of this DAC are similar, but the specifics are different and the full SPI Master component is quite a bit more complicated.  In order to hit the performance you are interested in, you will have to create a custom component in order to meet the precise timing requirements of SYNC line.  Basically you want it high for exactly 3 clock cycles if possible to reduce the overhead and keep the clock rate in the possible range.  As a reference I would suggest that you look at the TX only UART.

Here are some things to think about:
 (1) Don't send a clock signal directly to the output.  The delay on a clock line to an output is different than the delay from a normal signal to an output.  So run the component at 2x the clock rate (around 56 MHz) in your case, divide that by 2 and send that signal that is now a data signal out.
 (2) The first 8 bits aren't real data.  It may be easier to have your component generate this for you.  You could have a control register that has the 2 mode bits.  That would just leave you with 16-bits of data to provide which would give the CPU less to do.
 (3) You could use an 8-bit wide datapath or a 16-bit wide datapath (24-bit is you don't implement #2).  I would probably use the 16-bit approach, but either can be used.

Hi Brad,
Excellent ideas - thanks for your help. I'll give it a try and let you know. BTW, nice blog!
Kelly

Hi Brad,

I am working on WiFi interface application on PSoC3 and PSoC5.I am using a SPI Master component on PSoC module to communicate with the SPI slave on the WiFi interface card.The default Data Bits size is 8.The WLAN throughputs were measured to be around 1 Mbps or sometimes 3 Mbps(after making clock adjustments) which is suboptimal for my application.I would like to increase the Data Bits size to 32 bits and check is my throughput results improve.If i have to try that,do i need to custom build a SPI component? or Are there any options?

If i need to custom build a SPI component,please help me get started.

Thanks.

Regards,
Karthik

Karthik - You are not going to be able to implement a 32-bit SPI Master with the current component.  I'm skeptical that this would be the best approach for your problem.  I don't know about your specific WLAN device, but I'm surprised that it could accept 32-bit SPI transactions.  That would require all transfers be a multiple of 4 bytes in length.  That is not typical of byte oriented network traffic, so are you sure that your device is oriented that way.  That would also mean that on data received by PSoC that it would have to stuff any extra bytes to get to a 32-bit boundary and that your PSoC software would be able to determine what the real length was.  The focus should be on making the software on PSoC running faster and I don't expect that changing to 32-bit will make it faster.  Here are some suggestions for optimizing the performance of the SPI component: (1) Make sure that you have compiler optimization at its highest setting Project->Build Settings->Compiler->Optimization  5 is the highest free option for PSoC 3 (2) What size buffer are you using for the Rx and Tx buffers?  There is a 4 byte hardware buffer.  If you use a larger buffer there is maintenance of the software buffer that must be done.  I expect that you'll get higher performance from a buffer of 4 versus a larger software buffer  (3)  DMA could be used to transfer data, but that adds to complexity, so start by trying to optimize the software.
- Brad

Hi Brad,

Thanks for the prompt reply and suggestions.Currently,RX and Tx buffers sizes are set  to be at 4 bytes each.

The WiFi interface card that i am using does have a SPI device that supports a 32 bit transactions.Here is what i am trying to do.

1) I initialize the WiFi SPI device using 8 bit transactions with PSoC3/5 SPI as the master.
2) I send data to the WiFi SPI device from PSoC controller(SPI master data size is 8 bits) so that the WiFi device sends data on air to a remote machine.
3) Right now the remote machine is receiving data at the rate of 1-3 Mbps.However,i want to get that up to 9Mbps because the WiFi card is capable of transmitting data over the network at 9Mbps.

So,i am trying to figure out where the data is getting throttled that the remote machine is able to receive only at the rate of 1-3Mbps.I visualised the system as follows:

There are two communicating devices with a physical channel between them.The wider the physical channel,more the data between them.In this context the two communicating devices are SPI Master component on PSoC5 and SPI slave on WiFi card.

So,i thought by making the SPI master component capable of 32 bit transactions,the WiFi card will have enough data to send it over air instead of 8 bits at a time thereby the processor core and the SPI master would be closely in sync. 

CPU CLK = 24MHz and it is the same clock source for SPI Master component on PSoC5.

Thanks.

Regards,
Karthik

Hi Brad,
Thanks for your help
I learned a lot about programming and datapath UDB with your help and your videos and examples.
I want to understand how to program using UDB PLD + Datapath to develop a logic control "push" A1, "Push" A2 and retrieve the output result. For example: calculate the sum of: (A1 + A2 = B1) through datapath and C, with the details and logic inputs and output in ALU, Mask, etc.. to understand.

Thanks for the prompt reply and suggestions
Best Regards

Hi
Does anyone know how the arithmetic works in UDBs?, The goal is to create a small interpreter ? I still did not succeed .....
In addition, how to delete posts and commments with the error, in this forum ?

Parrain - Are you still having issues getting arithmetic to work in the datapaths?  For example to do the simple example that you describe I would recommend the following:
 - There are two FIFOs, so you will need one in each direction, so one will be used to send the data in (A1 and A2) and the other will be used to send the data out.
 - The processing will be very fast compared to the processor, so for now you don't need to worry about status signals to the CPU, just write two values and then read the result.
 - You will need to worry about the status signals of the FIFOs for getting the A1 and A2 data.  The state machine that you create to control the datapath will have to wait for the data to be present in the FIFOs before continuing forward.
 - You can't use the data from the FIFO directly, you need to first transfer it to a register.  You can either load the data into A0 and D0 from F0 or you can load into A0 and then transfer to A1 and then load the second into A0.
 - Once you do the addition you can directly load the result directly to the output FIFO.