cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
7,075 Views
Registered: ‎08-05-2012

Cannot parse AR47511

Hello, I am trying to drive SPI1 peripheral on my Zedboard (which has the engineering sample Zynq chip: XC7Z020-1CLG484CES).  While searching for how to probe the HW, I ran into a forum discussion on a known issue with slave select 0 pin.  I read the 2 posts multiple times, but I still cannot understand either the problem description or the solution/workaround.  Can you please clarify the following confusions:

 

  • What chip does the problem affect?  AR 47511 does not qualify the problem as chip specific, but put a note at the end only for the production silicon.  But the solution for the production silicon is the same as the general recommendation in the AR.  So why then would the problem be silicon version (production or engineering sample) specific?  To add to the confusion, another user concludes that he does NOT have to worry about the problem (in this forum discussion) because he is on MicroZed, which is using the production silicon.  When I read AR 47511, I come to the OPPOSITE conclusion: that SS0 IS affected on production silicon (not sure about the engineering sample).
  • I do NOT understand the proposed solution in AR 47511: "When interfacing via MIO or EMIO, do NOT enable SS0 on any of the MIO pins".  The AR does NOT explain how to do this!  In Vivado (2014.2 or 2014.4), I do NOT see a way to disable SS0!  (See below)Snapshot.png
  • The solution does not seem to be necessary.  If the problem is that SS0 should not go low (again, the explanation of the problem was unsatisfactory), then why not just tell users to tie it to VCC?  The VHDL code snippet given in the AR seems to be a way to achieve that without reworking any boards.  Don't you think it's more understandable this way?

 

0 Kudos
Reply
10 Replies
Highlighted
Scholar
Scholar
7,065 Views
Registered: ‎11-09-2013

just make sure SS0 input sees high, does not matter how you achieve it. then all just works. simple...
0 Kudos
Reply
Highlighted
Adventurer
Adventurer
7,062 Views
Registered: ‎08-05-2012

Thank you for the quick reply!

I was planning on wiring SS0 to 3.3V on the Zedboard; I think this is what you are recommending.

I am amazed that other people like you can parse the AR that I had so much trouble understanding.

Merry X-mas!

0 Kudos
Reply
Highlighted
Scholar
Scholar
7,044 Views
Registered: ‎11-09-2013

no wiring, in VHDL inside PL, no need to use any real wires..

0 Kudos
Reply
Highlighted
Adventurer
Adventurer
6,995 Views
Registered: ‎08-05-2012

Thank you; I understand I have to tie SS0 to VCC somehow.

Before I do that, I wanted to see if I can write a valid DTS for SPI1.  I see you've posted on Zynq SPI questions before, and everything is working for you.  I wanted to make sure that the master SPI driver (xlnx,zynq-spi-r1p6, which is the same as cdns,spi-r1p6 according to the cdns_spi_of_match of_match_table) is probed.  But so far, I have not seen the my breakpoint in cdns_spi_probe getting hit.  I believe the DTS I copied from you and others are roughly correct; and I don't think that I have to even mention spidev for the master device driver to be probed (because it's a platform device).  Nevertheless, to debug, I would like to try what you did.  From the Pandaboard example I understand that I need to call spi_register_board_info() in my mach initialization code.  Can I please see your mach-zynq code for SPI registration?  I think I have all the necessary kernel config:

 

CONFIG_SPI=y
CONFIG_SPI_MASTER
CONFIG_SPI_CADENCE=y
CONFIG_SPI_XCOMM=y
CONFIG_SPI_AD9250FMC=y
CONFIG_SPI_XILINX=y
CONFIG_SPI_ZYNQ_QSPI=y
CONFIG_SPI_SPIDEV=y

 

Thank you for your helpful comments!

0 Kudos
Reply
Highlighted
Adventurer
Adventurer
6,971 Views
Registered: ‎08-05-2012

I got the drivers to probe by removing bus-num from DTS.  I found that I do NOT have to modify the mach-zynq files to probe the Cadence SPI master device or the spidev device that uses the master driver with the following DTS.  I saw the spi-cadence.c ISR hitting in JTAG debugger too, so the interrupt settings are correct too.

 

/dts-v1/;
/include/ "zynq-zed-adv7511.dtsi"

/ {
  axi: amba@0 {
    spi1: ps7-spi@e0007000 {
        #address-cells = <1>;
       #size-cells = <0>;
        compatible = "xlnx,zynq-spi-r1p6";
        clock-names = "ref_clk", "pclk";
        clocks = <&clkc 26>, <&clkc 35>;
        interrupt-parent = <&gic>;
        interrupts = <0 49 4>;
        num-cs = <3>;
        reg = <0xe0007000 0x1000>;
        speed-hz = <50000000>;

 

        spidev@0 {
          compatible="spidev";
          reg = <1>; //chipselect
          spi-max-frequency= <800000>;
       };
    };
  };
};

 

To verify that the HW is shaking CLK, SS1, and MOSI correctly, I need to tie SS0 to 3.3V according to AR# 47511, which is talking about tying EMIO (shouldn't this be a generic EMIO/MIO case?) SS0 to VCCin MHS.  But I've converted to Vivado, and there doesn't seem to be an MHS file anywhere in my project folder.  In Vivado, is there an alternative to modifying MHS?  Not knowing the details, I was wondering if I should just modify the top level Verilog (system_top.v) to something like

 

assign FIXED_IO_mio[13] = b'1;

 

Can anyone comment on the proposed alternative?

 

P.S. It would be really nice if Xilinx can respond to this thread.  Wrting a confusing and incomplete AR is already pretty bad, but not even responding to the confused users on forum when it's the only avenue for support (not that webcase has been cut off) is egregious...

 

0 Kudos
Reply
Highlighted
Scholar
Scholar
6,962 Views
Registered: ‎11-09-2013

OMG

 

you add IP "constant" and wire it to SS0 that it there is no MHS file and none is needed

0 Kudos
Reply
Highlighted
Adventurer
Adventurer
6,925 Views
Registered: ‎08-05-2012

Thanks.  I finally looked up the constant block.  As suspected, it seems to be nothing more than an assign, in which case I'd rather just write that myself in the top level HDL, without bothering with the IP block.  In fact, since this is all because of a HW bug, I don't mind working around that by shorting the SS[0] to VCC, which I've done and documented in my blog entry on this subject.

0 Kudos
Reply
Highlighted
Scholar
Scholar
6,908 Views
Registered: ‎11-09-2013

yes, if you are modding toplevel then yes

 

but you should avaid at all causes to modify the top level by hand and let vivado to manage it.. saves so much hassle and time, but yes requires the IPI work flow

0 Kudos
Reply
Highlighted
Adventurer
Adventurer
6,899 Views
Registered: ‎08-05-2012

Thanks for the tip; I never thought the top level HDL special in that way. I thought that because that is where everything is stiched together, I should put my application specific (integration) code THERE. But I did always wonder about how to keep the top HDL in sync with port changes in monster IPs like DDR. I guess you should create an IP that does the application specific stuff, and connect the IPs in the integrator view, drawing wires from 1 module to another. I don't know whether this was possible in the ISE days, but I certainly did not use any such feature.
0 Kudos
Reply
Highlighted
Scholar
Scholar
3,740 Views
Registered: ‎11-09-2013

correct, this is how you should work.

 

you package anything you make, be it single inverter, into own IP and just "integrate" it with IPI

 

there is an enourmous benefit:

1) IP Packager will force some automatic docu for your IP :)

2) IP Packager will autoincrement version numbers

3) you can put the IP easily into version system, SVN, GIT..

0 Kudos
Reply