search

sifive / fpga-shells

131 stars 65 forks source link

"SPI Flash not functional" #163

Open michael-etzkorn opened 3 years ago

michael-etzkorn commented 3 years ago

I'm trying to understand FPGA-shells so I can add a PCIe to my SoC in Chipyard, but I was also thinking of adding SPI flash. While digging through VCU118NewShell.scala I saw that //SPI Flash not functional within VCU118ShellBasicOverlays() Is the overlay for SPI broken in some way?

mwachs5 commented 3 years ago

If I recall correctly, there isn't a simple SPIFlash on a VCUI118 board so the overlay would not have anything to connect to.

michael-etzkorn commented 3 years ago

Thanks for the reply! There's qspi flash that looks like it's usable for data storage. I'm still working my way through understanding overlays, but it looks like SPIFlashXilinxPlacedOverlay connects anSPI controller in the FPGA fabric to STARTUPE3 which is what would actually connect to the vcu118's QSPI Flash. From my eyes, it seems like you'd still have to call Overlay with SPIFlashXilinxPlacedOverlay or SPIFlashVCU118PlacedOverlay to actually connect the DigitalTop SPI controller to STARTUPE3.

erikdanie commented 3 years ago

Yeah, I had tried the STARTUPE3 SPI flash as an experiment a while ago and wasn't able to get it working. I didn't spend too much time on it after that, so it might be a small fix, but I haven't had time to look back at it since then

michael-etzkorn commented 3 years ago

With pcie hooked up, I'm now revisiting the idea of hooking up flash. I'm assuming the targetted toplevel for the spiflash controller is SPIFlash.scala in sifive-blocks. It looks like cs is active high here. FCS on STARTUPE3 is active low, so it'd have to be inverted. I'm not entirely sure if USRDONETS and KEYCLEARB need to be changed, but I don't see why we'd continuously clear the decryption keys from RAM or disconnect the board's DONE pin (even if we're not booting from flash). 

  val se3 = Module(new STARTUPE3())
      se3.io.USRDONEO   := true.B
      se3.io.USRDONETS  := false.B
      se3.io.USRCCLKO   := tlqspiSink.bundle.sck.asClock
      se3.io.USRCCLKTS  := false.B
      se3.io.FCSBO      := !tlqspiSink.bundle.cs(0) // I believe cs is active high in SPIFlash
      se3.io.FCSBTS     := false.B
      se3.io.DO         := Cat(tlqspiSink.bundle.dq.map(_.o))
      se3.io.DTS        := Cat(tlqspiSink.bundle.dq.map(_.oe))
      tlqspiSink.bundle.dq(0).i            := se3.io.DI(0)
      tlqspiSink.bundle.dq(1).i            := se3.io.DI(1)
      tlqspiSink.bundle.dq(2).i            := se3.io.DI(2)
      tlqspiSink.bundle.dq(3).i            := se3.io.DI(3)
      se3.io.GSR        := false.B
      se3.io.GTS        := false.B
      se3.io.KEYCLEARB  := true.B
      se3.io.PACK       := false.B

I'll have to hook up the SPIFlashMap to my design and take a look at this in simulation to confirm chip select is active high. I'll also have to look into the firmware commands for setting QSPI into quad lane data storage mode. Very limited resources on that outside of micron's datasheet, but I did find this forum post that outlines some steps I can try following.