ULX3S: Adding spiflash, U3 pinout error about litex-boards HOT 9 CLOSED

Thanks for the feedback @blakesmith.

When adding the following code to the ULX3S target:

from litex.build.generic_platform import Pins, IOStandard
platform.add_extension([("dummy", 0, Pins("U3"), IOStandard("LVCMOS33"))])
self.comb += platform.request("dummy").eq(1)

./ulx3s.py --cpu-type=None --toolchain=trellis --build fails while
./ulx3s.py --cpu-type=None --toolchain=diamond --build succeeds.

So there indeed seems to be an issue in the Trellis Database. This should probably be reported to https://github.com/YosysHQ/prjtrellis or https://github.com/YosysHQ/nextpnr.

from litex-boards.

@enjoy-digital Thank you for helping me verify that! I probably need to just get the Lattice diamond toolchain setup, but I was hesitant to go through the full vendor sign-up, give them all my information, and download gigabytes of stuff, if it wasn't going to be useful - so thank you for helping me with that piece.

I will open an issue with prjtrellis and reference this issue. Thanks again for LiteX!

from litex-boards.

The solution here is to use a USRMCLK primitive - happy to be corrected but I think Diamond only works because it trims away the unused I/O, it would also fail if you actually tried to do anything with pin U3.

EDIT: I see you are actually able to use U3, this needs further investigation

from litex-boards.

@daveshah1 I was just about to add a comment on YosysHQ/prjtrellis#138, do you think it's a related issue, or separate? Happy to open a separate issue on prjtrellis if you think that's the right path forward.

from litex-boards.

The workaround for now is to use a USRMCLK primitive. For some reason I thought you had to use this primitive in order to use the CLK pin (because the Lattice docs imply this) but evidently that isn't the case.

from litex-boards.

@blakesmith: sorry I haven't seen it was related the SPIFlash Clock when I did my first answer. Adding the USRMCLK should be handled in by the SPIFlash core: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/spi_flash.py#L73-L77.
I'll have a closer look to understand why it does not seem to be the case here.

from litex-boards.

@blakesmith: In fact you just need to comment or remove the clk in the pads definition. When provided, LiteX will try to use it, otherwise it will use the primitive of the device to drive the clock (https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/spi_flash.py#L53) If you want an example on ECP5, you can look at the ECP5-EVN: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/ecp5_evn.py#L55-L67

from litex-boards.

@enjoy-digital That did the trick! The bitstream is now compiling. I didn't realize that removing the clk in the pads definition would make it use the internal USRMCLK primitive instead - sorry I missed that one when reading through the SPIMaster core!

I won't have my ULX3S board in hand to test for awhile. Once I do, I can verify that this actually works on the board.

I don't want this addition to be backwards incompatible with people who are already compiling this SoC in the field, who might be counting on stable addresses in the memory map. I'm going to see if I can try to get this added without "breaking" the locations in the memory map. If not, I'm considering putting a with_spiflash optional flag that defaults to false. I'll play with it some more, and once I have a board in hand to test, I can put this up for a PR.

Thanks again for the help @enjoy-digital and @daveshah1! The future of open source FPGA toolchains is incredibly bright, thanks to your hard work, and I really appreciate it!

from litex-boards.

Closing in favor of #155, everything is working now on my board. Thanks for the help @enjoy-digital and @daveshah1!

from litex-boards.