clocks on Zynq

[Myron King]

Hello All,

I'm trying to read/write an SPI slave interface in the FPGA fabric with the SPI0 IO peripheral on the PS7 using EMIO.   I have tested the SPI interface in Bluesim and am relatively confident that it works.  I have been trying to connect it to the PS7 for a while now and have so far not been successful in getting getting a clock signal.  I have a simple test (tests/test_spi0) which opens /dev/spidev2.0 (the device created by the Xilinx SPI kernel module) and writes a few words without reporting any errors.

Page 555 of the TRM shows how to connect the EMIO signals in the FPGA fabric.  When I initiate a transaction from the SW, I can see that the SCLKTN and MOTN signals are de-asserted.  The problem is that I cannot see any activity on the corresponding SCLKO and MO signals.   Because I am implementing only the slave functionality, these signals are being used directly without routing them through a tri-state buffer.  Is this a mistake?

There is also the question of the clock configuration itself.  Language on page 548 the TRM states that the SPI_Ref_Clk must be set to a higher frequency than the CPU_1x clock.   Reading the SPI_CLK_CTRL register, I can see that the reference clock source is set to 'IO PLL', the clock divisor is '63', and that the SPI 0 reference clock is enabled. Reading the APER_CLK_CTRL register, I can see that the SPI0_CPU_1XCLKACT field is enabled, I suppose if this weren't enabled I couldn't read any of SPI0's control registers...  Finally, the baud-rate divisor in the register at offset '0' in the SPI peripheral ((SPI) Config_reg0) is set to '000' (not supported, which I assume means that it is not used).  How do I determine the frequencies of the IO PLL and  CPU_1x??   If I knew these, I could figure out what the SPI0 clock should be (if I could detect it...).  

any suggestions would be greatly appreciated

thanks

--Myron

[Lawrence Stewart]

On 2015, Apr 28, at 6:22 PM, Myron King <mir...@gmail.com> wrote:

Hello All,

I'm trying to read/write an SPI slave interface in the FPGA fabric with the SPI0 IO peripheral on the PS7 using EMIO.   I have tested the SPI interface in Bluesim and am relatively confident that it works.  I have been trying to connect it to the PS7 for a while now and have so far not been successful in getting getting a clock signal.  I have a simple test (tests/test_spi0) which opens /dev/spidev2.0 (the device created by the Xilinx SPI kernel module) and writes a few words without reporting any errors.

Page 555 of the TRM shows how to connect the EMIO signals in the FPGA fabric.  When I initiate a transaction from the SW, I can see that the SCLKTN and MOTN signals are de-asserted.  The problem is that I cannot see any activity on the corresponding SCLKO and MO signals.   Because I am implementing only the slave functionality, these signals are being used directly without routing them through a tri-state buffer.  Is this a mistake?

Maybe.  The PS7 I2C, which is a different thing, I know, has SDAO and SCLO just tied low, and drives the actual data on SDATN and SCLTN - it is set up for external resistive pullup, with the wires driven low but left in high impedance for high.  Are the TN signals toggling or just static low?  The TRM says the SPI has a multi-master mode, but I would guess that the TN’s only switch

when changing masters, not between bits.  It seems more likely that the clock isn’t running.

While debugging the I2C stuff, I wound up using bluescopeeventpio to get traces, it is possible

that might be useful for you as well, see examples/fmcomms1

There is also the question of the clock configuration itself.  Language on page 548 the TRM states that the SPI_Ref_Clk must be set to a higher frequency than the CPU_1x clock.   Reading the SPI_CLK_CTRL register, I can see that the reference clock source is set to 'IO PLL', the clock divisor is '63', and that the SPI 0 reference clock is enabled. Reading the APER_CLK_CTRL register, I can see that the SPI0_CPU_1XCLKACT field is enabled, I suppose if this weren't enabled I couldn't read any of SPI0's control registers...  Finally, the baud-rate divisor in the register at offset '0' in the SPI peripheral ((SPI) Config_reg0) is set to '000' (not supported, which I assume means that it is not used).  How do I determine the frequencies of the IO PLL and  CPU_1x??   If I knew these, I could figure out what the SPI0 clock should be (if I could detect it...).  

Page 1489 of the TRM says that the three PLL’s are initially set to the same configuration, fwiw.

TRM Table 25-3 has typical setups for the IO_PLL.

A Divisor of 63 seems way too high.  If the cpu_1x clock is 33 or 50 MHz, and the IO_PLL is 

something like 200 or 125, then the divisor to get SPI_Ref_Clk should be more like 4 or 6?

I don’t think it would be too hard to write a frequency counter example that would measure

these things, using the 100 MHz clk0 as a reference. Or just a cycle counter on each one, readable

with an indication.

any suggestions would be greatly appreciated

Could you use the SPI Loopback mode in any way?

thanks

--Myron

--
You received this message because you are subscribed to the Google Groups "connectal" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connectal+...@googlegroups.com.
To post to this group, send email to conn...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jamey Hicks]

We have a FrequencyCounter that can be used to count transitions on the SPI Clock.

I2C is defined to use pull ups on the data line, so the data bits and clock end up on the tristate enable line. I suppose SPI could be the same way. So try the frequency counter on SCLKTN.

As a point of terminology, an active low signal such as SCLKTN is referred to as "asserted" when it is low and "deasserted" when it is high. I assume that is what you mean above.

[John Ankcorn]

Myron,

I suspect that you are running into this problem:
http://www.xilinx.com/support/answers/47511.html
I ran into this with imageon, which had me stumped/frustrated for quite a while.

jca

[John Ankcorn]

Also... I would recommend looking at this page often:
http://www.xilinx.com/support/answers/47916.html
Yuk!
jca

[Myron King]

Hi Larry,

thankssomuch! comments/questions inlined below:

On Tue, Apr 28, 2015 at 8:28 PM, Lawrence Stewart <lste...@gmail.com> wrote:

On 2015, Apr 28, at 6:22 PM, Myron King <mir...@gmail.com> wrote:

Hello All,

I'm trying to read/write an SPI slave interface in the FPGA fabric with the SPI0 IO peripheral on the PS7 using EMIO.   I have tested the SPI interface in Bluesim and am relatively confident that it works.  I have been trying to connect it to the PS7 for a while now and have so far not been successful in getting getting a clock signal.  I have a simple test (tests/test_spi0) which opens /dev/spidev2.0 (the device created by the Xilinx SPI kernel module) and writes a few words without reporting any errors.

Page 555 of the TRM shows how to connect the EMIO signals in the FPGA fabric.  When I initiate a transaction from the SW, I can see that the SCLKTN and MOTN signals are de-asserted.  The problem is that I cannot see any activity on the corresponding SCLKO and MO signals.   Because I am implementing only the slave functionality, these signals are being used directly without routing them through a tri-state buffer.  Is this a mistake?

Maybe.  The PS7 I2C, which is a different thing, I know, has SDAO and SCLO just tied low, and drives the actual data on SDATN and SCLTN - it is set up for external resistive pullup, with the wires driven low but left in high impedance for high.  Are the TN signals toggling or just static low?  The TRM says the SPI has a multi-master mode, but I would guess that the TN’s only switch

when changing masters, not between bits.  It seems more likely that the clock isn’t running.

I don't completely understand what you are saying about I2C.  does this mean that to transmit '0', the SDA line is actively driven low, but that to transmit '1', it is not actively driven at all, relying instead on an external source to pull it high?

In the case of SPI0, the TN signals transition from high to low when the software starts the SPI write transaction and then back to high when it completes.  Multi-master functionality is enabled using the 3-bit wide SSON selector.  I can see that bit 0 is low and all the rest are high (before I open the device in SW, all the SSON bits are high, so I think this is correctly selecting slave0)

 

While debugging the I2C stuff, I wound up using bluescopeeventpio to get traces, it is possible

that might be useful for you as well, see examples/fmcomms1

I will take a look at these examples.  I have been using Jamey's frequency counter to detect transitions on various wires, but I might try this approach as well.

[Jamey Hicks]

On Wed, Apr 29, 2015 at 10:13 AM Myron King <mir...@gmail.com> wrote:

Hi Larry,

thankssomuch! comments/questions inlined below:

On Tue, Apr 28, 2015 at 8:28 PM, Lawrence Stewart <lste...@gmail.com> wrote:

On 2015, Apr 28, at 6:22 PM, Myron King <mir...@gmail.com> wrote:

Hello All,

I'm trying to read/write an SPI slave interface in the FPGA fabric with the SPI0 IO peripheral on the PS7 using EMIO.   I have tested the SPI interface in Bluesim and am relatively confident that it works.  I have been trying to connect it to the PS7 for a while now and have so far not been successful in getting getting a clock signal.  I have a simple test (tests/test_spi0) which opens /dev/spidev2.0 (the device created by the Xilinx SPI kernel module) and writes a few words without reporting any errors.

Page 555 of the TRM shows how to connect the EMIO signals in the FPGA fabric.  When I initiate a transaction from the SW, I can see that the SCLKTN and MOTN signals are de-asserted.  The problem is that I cannot see any activity on the corresponding SCLKO and MO signals.   Because I am implementing only the slave functionality, these signals are being used directly without routing them through a tri-state buffer.  Is this a mistake?

Maybe.  The PS7 I2C, which is a different thing, I know, has SDAO and SCLO just tied low, and drives the actual data on SDATN and SCLTN - it is set up for external resistive pullup, with the wires driven low but left in high impedance for high.  Are the TN signals toggling or just static low?  The TRM says the SPI has a multi-master mode, but I would guess that the TN’s only switch

when changing masters, not between bits.  It seems more likely that the clock isn’t running.

I don't completely understand what you are saying about I2C.  does this mean that to transmit '0', the SDA line is actively driven low, but that to transmit '1', it is not actively driven at all, relying instead on an external source to pull it high?

Exactly. The pull up resistors are part of the I2C electrical spec.

The note that John pointed to indicated that SPI multi master uses a similar mechanism to detect contention on the wires, hence the need to drive the SSO input high, simulating a pull up.

[Myron King]

I have a rule in my code which writes '1' to the SSIN signal (the note on page 555 of the TRM says something similar to John's pointer).  Will this tie the signal to net_vcc?

In any case, this doesn't seem to make any difference (I actually put it in a while back) in my quest to get a clock signal.   I also changed the .dts file so that I could load the kernel module manually AFTER I had programmed the fabric, hoping that initializing the SPI peripheral once the SSIN signal was high would fix things, but that also didn't work..

hmm...

[Jamey Hicks]

I would look at mkZynqTop.v and verify the ports are connected as you expect.