Quad SPI Protocol, hardware validation.

[kr.mk1]

I write RTL  (Verilog )code for Quad SPI Protocol, on simulation its working . Can Anyone please suggest me the suitable hardware for the validation.

[zygot]

UltraScale is built in a more advanced fab technology that earlier families, which is what most of the PMODs were designed to work with. IO bank voltage ranges for UltraScale are lower. Just make sure that any hardware that you buy is capable of working with IOSTANDARD levels that the ZCU104 provides for its PMOD headers..

[edit] Some voltage translator devices have complicated application details to consider. It's wise to read the documentation for any particular device.

Edited July 31, 2023 by zygot

[D@n]

Most any of the FPGA boards (non-Zynq) should work.  They all need a flash to hold their configuration, and that flash is also made available to users to do ... whatever with.

Dan

[zygot]

9 hours ago, kr.mk1 said:

I am using ZYNQ UltraScale+ , Can u tell me how can i access the Qspi Falsh via EMIO or MIO with all 4 io line,  sclk and cs.

Gee, the little detail about using UtraScale+ didn't seem like an important thing to mention in your question?

The Xilinx UltraScale+ TRM (UG1085) has all of the information about how to use the EMIO QSPI through either the MIO pins or EMIO to the PL Consult the schematic for your platform.

Edited July 27, 2023 by zygot

[asmi]

9 hours ago, kr.mk1 said:

Thanks @D@n , I am using ZYNQ UltraScale+ , Can u tell me how can i access the Qspi Falsh via EMIO or MIO with all 4 io line,  sclk and cs.

Odds are the flash is connected to MIO pins (otherwise Zynq won't be able to boot from it), in this case this flash memory is not available to PL at all.

[D@n]

You could always buy a PMod flash, and use that.

Dan

[JColvin]

Hi @kr.mk1,

I'm not certain what platform you are using or what about your Quad SPI Protocol you are wanting to test (its general robustness? If it can communicate with some sort of external hardware successfully as a "real life test"? Something else?), but if you do not have direct access to using on-board flash as the test option, an external flash module that readily supports Quad SPI, like the Pmod Flash that D@n mentioned, https://digilent.com/reference/pmod/pmodsf3/start, (or whatever flash module, doesn't have to be Digilent made), would be one type of hardware to easily test your designed protocol on.

Thanks,
JColvin

[zygot]

41 minutes ago, JColvin said:

but if you do not have direct access to using on-board flash as the test option, an external flash module that readily supports Quad SPI

Your links do not refer to any UltraScale+ platform. Can you provide a link to using the PMOD that you refer to for one of Digilent's Genesys ZU boards? Do you provide timing constraints?

I advise that no one should think about buying hardware before they know that they can use it. In the case if ZYNQ, the TRM tells you how to use PS MIO pins and functions like GEM, QSPI UARTS, etc. as well as EMIO usage, where available, the limitations of EMIO functionality and the signals that connect the PS to the PL. That's the place to start.

Edited July 27, 2023 by zygot

[D@n]

@zygot,

You may have to explain this one to me.  If someone wants to build an RTL flash controller, and the Zynq EMIO functionality prevents them from interacting directly with the flash via EMIO, why wouldn't an external flash be useful?  Something that could be found on a PMOD, as @JColvin linked?  Indeed, I've used that device with great success for exactly this purpose.  Why would it make a difference if this test was done on a Zynq vs an Artix, if all the work is being done in the RTL?  Or, in the case of the Zynq, as an AXI slave of some type implemented in RTL?
Dan

[zygot]

1 hour ago, D@n said:

Why would it make a difference if this test was done on a Zynq vs an Artix, if all the work is being done in the RTL? 

Well, I suppose that Z7000 series and any Series 7 would work out pretty much as you suspect. The question is specifically about UltraScale+. I've done a bit of UltraScale and the IO has been radically changed from the Series 7 families, at least for advanced IO.

First, anyone interested in this thread should read the ZYNQ UltraScale+ TRM mentioned above. There is some serious mode limitations through the EMIO, so perhaps the low speed (12.5 MB/s SDR) only would be a HDL project that you are familiar with. As has been pointed out, some boards expose unused MIO pins, but there's no guarantee that the pinmux can connect those to the QSPI controller. Lastly, one could do higher speed DDR modes with PL logic and connect to the PS through one of the AXI busses. (These are considerably more complicated than the Z7000 devices as are the PS cores) Even DDR IO on UltraScale is more complicated than Series 7. Read the UltraScale+ IO User Guide for some light reading. It's a confusing document with quite a bit of ambiguity, especially for SERDES (DDR is SERDES in UltraScale+, and the tools translate SERDES into 'native mode'). If you use Vivado IP then perhaps the PL work might be fairly simple. If you roll your own Verilog then you might be in for a tussle.

I remember reading a previous post about Digilent QSPI IP and timing constraints, in which someone from Digilent said that they didn't supply timing constraints. I might be remembering this incorrectly, so I wouldn't be surprised if I get corrected about that...

Everything that I've posted here is intended only to tell people to do their homework before deciding on a plan of action. Perhaps a SDR QSPI PMOD can work out fine for certain UtraScale+ platforms .. gee, did I forget to mention IOSTANDARD?.. perhaps not. I'm not in a position to make that call.

[edit] UltraScale+ PS MIO pins are likely to be compatible with 1.8V logic or lower. I have a ZCU106 with a couple of PMODs connected through voltage translators. I have a cheap ZU3EG  that exposes 9 MIO pins for use with 1.8V logic. Your board may vary. I don't believe that the PMOD that Jon linked to supports 1.8V logic. I suspect that he didn't bother checking this.

Edited July 27, 2023 by zygot

[asmi]

6 hours ago, zygot said:

First, anyone interested in this thread should read the ZYNQ UltraScale+ TRM mentioned above. There is some serious mode limitations through the EMIO, so perhaps the low speed (12.5 MB/s SDR) only would be a HDL project that you are familiar with.

Maybe you should read it again, because it seems that you've got this whole EMIO thing the wrong way around - it's purpose is to route PS peripherals to PL pins (because there are much more PS peripherals than there are MIO pins in a package), and not MIO pins to PL peripherals. As far as I know, there is no way to route MIO pins to PL at all. Therefore if flash device is connected to MIO pins (which all Zynq boards I know of do), you can't access it from PL (aside from going through AXI bus and a PS QSPI controller of course).

Edited July 28, 2023 by asmi

[zygot]

7 hours ago, asmi said:

Maybe you should read it again, because it seems that you've got this whole EMIO thing the wrong way around - it's purpose is to route PS peripherals to PL pins (because there are much more PS peripherals than there are MIO pins in a package), and not MIO pins to PL peripherals. As far as I know, there is no way to route MIO pins to PL at all.

What lead you to believe that anything that I posted suggested that you could route interfaces connected to PS MIO pins to the PL? There are 2 SD Controllers in the ZYNQ UltraScale PS ( like most PS functions ) so one could use the normal MIO connected FLASH for booting and the other, unused controller, for experimentation with a custom interface using one of the many options that I laid out.

Edited July 28, 2023 by zygot

[asmi]

54 minutes ago, zygot said:

What lead you to believe that anything that I posted suggested that you could route interfaces connected to PS MIO pins to the PL?

How else would you test a QSPI controller HDL if not by connecting it to actual QSPI device?

54 minutes ago, zygot said:

There are 2 SD Controllers in the ZYNQ UltraScale PS ( like most PS functions ) so one could use the normal MIO connected FLASH for booting and the other, unused controller, for experimentation with a custom interface using one of the many options that I laid out.

That is irrelevant as the goal is to test his own QSPI controller, and not expose PS controller outside. And a side question - what does SD controller have to do with QSPI?

[zygot]

 

25 minutes ago, asmi said:

what does SD controller have to do with QSPI?

Nothing, typo. There are 2 QSPI controllers in the UltraScale+ PS also. I meant to refer to those....

OP's question was" "I am using ZYNQ UltraScale+ , Can u tell me how can i access the Qspi Falsh via EMIO or MIO with all 4 io line,  sclk and cs."

I would imagine ( hope) that he's off doing some reading and not paying much attention to what being discussed by the rest of us, which is mostly speculation as to what he actually wants to do. No mention of an actual platform has been provided yet. Still, some of the 'helpful' posts have introduced more confusion to the topic in general, so it's kind of evolved ahead of the original question. That's typical of questions to the Digilent Forums.

Edited July 28, 2023 by zygot

[zygot]

41 minutes ago, asmi said:

How else would you test a QSPI controller HDL if not by connecting it to actual QSPI device?

Indeed, but you don't need PS QSPI controllers or MIO pins or the EMIO either. The confusion about how the project is to implemented is in the information provided by the person asking for help. Sometimes you can ask questions and sometimes you get a meaningful reply. Sometimes speculative discussion helps the person wanting help; sometimes not.  The person who controls the discussion around a thread is the one starting it; or usually they don't. It's hard to be helpful to someone who doesn't help you understand what it is that they are trying to accomplish. It's not unusual that questions don't get resolved but someone ends up doing the research that should have proceeded the post.

Edited July 28, 2023 by zygot

[kr.mk1]

Thanks @D@n , I am using ZYNQ UltraScale+ , Can u tell me how can i access the Qspi Falsh via EMIO or MIO with all 4 io line,  sclk and cs.

when i am enabling the qspi flash and spi IO i am only able to pin out the standard spi interface pin like , sclk, miso, mosi and cs.

 

thanks and regards

 

[kr.mk1]

On 7/27/2023 at 10:20 PM, JColvin said:

Hi @kr.mk1,

I'm not certain what platform you are using or what about your Quad SPI Protocol you are wanting to test (its general robustness? If it can communicate with some sort of external hardware successfully as a "real life test"? Something else?), but if you do not have direct access to using on-board flash as the test option, an external flash module that readily supports Quad SPI, like the Pmod Flash that D@n mentioned, https://digilent.com/reference/pmod/pmodsf3/start, (or whatever flash module, doesn't have to be Digilent made), would be one type of hardware to easily test your designed protocol on.

Thanks,
JColvin

 

On 7/27/2023 at 10:20 PM, JColvin said:

If it can communicate with some sort of external hardware successfully as a "real life test"? ,

Hi @JColvin thanks 

I am Using the https://www.xilinx.com/products/boards-and-kits/zcu104.html FPGA Board ,i just want to validate the design with some real hardware 

[D@n]

@kr.mk1,

On 7/27/2023 at 1:54 AM, kr.mk1 said:

Thanks @D@n , I am using ZYNQ UltraScale+ , Can u tell me how can i access the Qspi Falsh via EMIO or MIO with all 4 io line,  sclk and cs.

Unfortunately, no.  While I have built several QSPI flash controllers in my time, I haven't ever had to work through EMIO or MIO to do so.

In this case, I'd suggest you follow @zygot's advice and search the TRM.  You might find that you cannot access these pins directly from RTL.  I just don't know.  It's been a long time since I looked through the Ultrascale+'s TRM.

Dan

[zygot]

14 minutes ago, D@n said:

You might find that you cannot access these pins directly from RTL.

No ARM FPGA device that I know of lets you control external devices attached to MIO pins directly with PL logic.