How to use External SPI Delay Module on ADAU1452 with SigmaStudio Dev.Tool?

Hello Mia,

Mia said:

1. Does the External SPI Delay Module work correctly in SigmaStudio Dev.Tool 4.6? If yes, can you provide application examples of this module?

There were some bugs with this module in SS4.6, so we recommend you use the latest version.

Please have a look at this thread here, it may give you an idea.

Mia said:

If we use this module to implement audio delay, is the hardware reference design as shown below?

Yes, you can refer this circuit for designing your SPI RAM circuit.

Mia said:

And which external Flash models are available?

Make sure that you are not exceeding the memory bandwidth which is mentioned in the above thread.

Regards,

Harish

Thank you,Harish.

Hello Mia,

I want to point out that you are mentioning EEPROM and FLASH when usually you use SPI RAM for this type of application because it is faster. You would need to verify the timing on FLASH to see if it can be written to and read from very quickly and often. Usually EEPROMs and FLASH are guaranteed for a few million write cycles. You will reach that in a day or so if you are writing and reading every sample period. 

Dave T

Hello Dave,

          We have successfully used external SPI Delay module in our projects. As shown above,we designed two external SPI Delay modules,but only one can work.Is this correct?

Hello Mia,

This is dependent on your sample rate and the clock speed setting of the SPI interface. Usually at 48kHz fs and up to 20MHz clock speed you will not quite get four channels. 

Do an experiment or two. 

1) Reduce one of these to only one channel of delay and see if you can write and read back three channels successfully. 

2) Grow one of these to three channels and only use one 3-channel block. 

See if either of these will work. If they work then let me know and also let me know if your application would be OK with only saving 24 bits of data to the delay instead of 32 bits? Most of the time 24 bits is fine. If 16 bits is fine let me know that as well. 

I have programs to pack four channels of 24 bit data into three channels of 32 bit data and to unpack them. I also have programs packing two 16 bit words into one 32 bit word. That is a lot easier. There is a library block to do that. 

Dave T

Hello Dave,

1) Reduce one of these to only one channel of delay and see if you can write and read back three channels successfully. 

--------For ExDelay1_2 module, reduce to one channel, and the ExDelay1_3 module keep two channel, we can write and read back three channels successfully. But the audio output is noisy.

2) Grow one of these to three channels and only use one 3-channel block. 

--------For this settup, we can also write and read back three channels successfully. But the audio output is noisy. Based on this settup, we reduced the SPI rate to 20M and the noise was reduced(There is noise only at high volume).

We found that delay with more than 2 channels did not work well with 16bit. How do we use 24bit of data to the delay insted of 16bit? We want to change 24bit to see if it is fine.

Hello Mia,

I had some time to do an analysis of this for you. This will be a long post so grab a cup of coffee and perhaps some popcorn! LOL

Here is the simple project I am starting with. 

You can see one stereo external SPI delay. 

The project is setup for 48kHz fs. 

Here is the test platform and this is important. 

This is our internal bench evaluation board we use for testing many parts and failure analysis etc. It has a socket to hold the DSP. Then the socket is mounted on a socket PCB because we also have small daughter cards that are solder-down instead of a socket. 

Then to the left of the daughter board you see two 8-pin sockets. One is for an I2C part and the other for  SPI part. These are connected to the master port and I have a SPI RAM installed in the socket. It is an 8-pin DIP package. The reason why I am saying this is important is because all of these sockets are terrible for signal integrity!!! Electrically it is a long run and what you do not see is that there are many stubs that go on to a 10-way header for a Beagle and I have the scope connected to test points. All of those stubs can cause reflections. I guess you can say I am testing for a worst case. It would be difficult for you to produce a layout that is worse than this! 

In this case we have no choice. We need to measure and analyze the parts. 

With two channels of 32 bit audio the fastest I can run the SPI clock is 12MHz. 13MHz I start getting noise when the levels get higher. The noise you hear are bit errors where a bit is not stored or read correctly. I suppose both can also be the case. 

We do have drive strength registers and in this case it did not really help. Which tells me it is not the edge speed that is the issue but reflections in the transmission lines. Also, I cannot change the drive strength of the RAM output to the DSP. That is out of our hands. 

Here is what one sample period looks like on a scope:

I will explain the setup of the scope.

The bottom trace is the LRCLK, the sample rate. I triggered the scope off of this signal so we can see the SPI transactions as it pertains to the sample period. You can see the small "T" showing the trigger point. 

The red trace is the MOSI which is the output of the DSP SPI port. One byte is the command byte, then three bytes for the address and then two 32 bit words (8 bytes) for the two channels of data to write to the RAM. 

I do not show the Slave Select but it would go high and then back low for the next command. That would be a Read command. Note the slightly wider bar because read is two LSBs high on the command byte. Then three bytes for the read address. Then the SPI RAM will output the 8 bytes and that is on the blue line. So that is the data coming from the RAM. 

The top trace is the SPI clock. You can see it is grouped in byte-sized chunks. (LOL, bite sized) You can see I drew with my mouse a red line showing the last four bytes. Note how long this is. How much time it takes. 

Then the clocks stop and it waits for the next sample period to start over. 

Note that there really is not enough time for another four bytes to be written and then read back. So there is no way to write and read three 32 bit words. It would take twice the length that I had sketched with my mouse. So the only way to do this is to increase the clock frequency. 

I will do that and show you.

It is hard to tell but at 12kHz clock it is bouncing around and is not in sync with the sample rate because it is taking too long each frame. 

At a 15kHz clock speed it finished just in time for the next frame. It looks good on a scope but I am getting bit errors so there is noise. 

To get this to work would be an exercise in PCB layout techniques and the actual RAM chosen might also be a factor. 

This should work with a good layout. We characterized the SPI port up to 24MHz. 

If you can get the three channels to work at 15MHz with your PCB then you can use the program I did to pack four channels of data into three 32 bit words and unpack it when it comes back from the delay. 

While I had everything setup I sent further. I grew the delay to the max of four channels. 

I had to increase the clock speed up to 18MHz to get it to complete the write and read in one sample period. So it should be very much possible to have four channels of 32 bit delay. The ability to do it comes down to PCB layout and the actual drive strength of the SPI RAM. I do not expect the drive strength of the RAM to be a problem but it is an unknown so I have to mention it. 

Then if you pack two channels of 16 bit audio into the 32 bit word then that is eight channels of delay! Cool!

Note that this is with the module grown. You cannot do this with separate blocks. If the delay time needs to be different with different channels then the read address would have to be different which means a new SPI command and lots more time to do that. 

What I would do is use regular RAM delay in the DSP to provide a variable delay to a fixed longer SPI delay. Usually you do not need to have hugely different delays channel to channel. So delay everything by X samples using the SPI delay and then use some DSP RAM delay for the small adjustment range.

If you do this in your program. Two blocks rather than grow one block.

Then you get this:

I got it to fit in one sample period by going up to 18MHz but the audio is garbage. Noisy with clicks and pops. 

Note that there are two write commands circled and two read commands circled. Compare this with my first screenshot. To make it efficient you have to grow the block. as soon as you drop in a new block it will have to do a read and write only for that block. 

Sorry for my rough mousing job drawing the circles. I had shoulder surgery two weeks ago so I am still mousing with my left hand! LOL

I hope this helps you and others. Your coffee must be cold by now!

Thanks!

Dave T

Hello Dave,

Thank you for such a detailed reply. Let's study it.