max14483 - maximum SPI Clk Frequency

Hi Pavan,

I can confirm that the MAX14483 will exceed your design requirements. The maximum data rate for the SPI channels is specified in the product datasheet.

The device can support 200Mbps (VDD = 2.25V to 5V) or 150Mbps (VDD = 1.71 to 5V)

Best Regards,

Ger

Hi PPMT, 

I'd just like to clarify your question on AN-1478. SPI communication is essentially two shift registers swapping bits synchronized by a clock signal. The typical SPI bus has a MCU that produces the clock signal, shifts data out on one clock edge (writes to MOSI), and then shifts data in on the opposite polarity (reads from MISO).

The time between those edges decreases as clock frequency increases. Any isolator inserted between the MCU and peripheral is going to add propagation delay to the signal. (Trace length on the PCB has an associated prop delay too, but the contribution of the isolator will be more significant on reasonably compact layouts.)

The MCU produces both the CLK and MOSI signal. Both of those signals get delayed by 1x the isolator's prop delay. Then the peripheral writes it's data to the MISO which is also routed back through the isolator to the MCU. So the MISO gets delayed by 1x delay also. 

Since the MCU is reading back the response based on its own CLK edge, we need to have valid data presented at the MCU's MISO pin at the instant that edge is produced. This is the half clock period > 2x prop delay relationship I described in the app note. 

35-40MHz is likely too fast for a "standard" isolated SPI implementation, by which I mean an MCU SPI port that reads in MISO data on its 2nd clock edge.

Often, designs will need some complication, like wrapping the CLK signal. That means send the CLK through the isolator twice so its coming back synchronized with the MISO produced by the peripheral device. Of course now you need an MCU that can read in data based on what is now essentially an external CLK signal.

However since this is an isolated DAC, you may be able to slow down the CLK rate only for reads from the DAC. When you're writing to the DAC, you probably don't care about what's on the SDO line. 

Regards,

Jason   

[Edited response after noticing this particular isolated bus is supporting a DAC]

Hi Jason,

Thanks for the reply.

jnaso said:

However since this is an isolated DAC, you may be able to slow down the CLK rate only for reads from the DAC. When you're writing to the DAC, you probably don't care about what's on the SDO line. 

We reached the same conclusion. As we are not reading anything back from DAC, we will just ignore the SDO line.

jnaso said:

Often, designs will need some complication, like wrapping the CLK signal. That means send the CLK through the isolator twice so its coming back synchronized with the MISO produced by the peripheral device. Of course now you need an MCU that can read in data based on what is now essentially an external CLK signal.

Yes, the external clk signal may require a second SPI (which we do not have spare in our design) or readback through the same spi by changing it to Target mode from controller mode( I am not sure if this will work and timing considerations between switching). 

jnaso said:

35-40MHz is likely too fast for a "standard" isolated SPI implementation, by which I mean an MCU SPI port that reads in MISO data on its 2nd clock edge.

Actually in our design there are multiple isolated DAC's on same SPI bus, so we would like to operate at max clk speed to get better throughput from all DAC's.

I guess I got confused with the terminology in the MAX14483 datasheet. The maximum data-rates are mentioned for each data/clk line, but it doesn't mention the maximum clk frequency for effective/error free SPI communication, which is limited by the propagation delays as mentioned in the app note. is this understanding correct? 

Thanks & Regards,

Pavan

Hi Ger,

Thanks for the reply.

Yes, the clk line will support the high data rate.

what we are worried about is whether effective SPI communication (both write and read mode) possible due to the propagation delays.

Thanks & Regards,

Pavan