amaranth-boards icon indicating copy to clipboard operation
amaranth-boards copied to clipboard

butterstick: add board defn for r1.0

Open TomKeddie opened this issue 4 years ago • 16 comments
trafficstars

I've prepared this carefully (the connector defns were parsed out of the kicad netlist) but I don't yet have hardware to test this on.

TomKeddie avatar Mar 07 '21 23:03 TomKeddie

Urgh, syntax issues I've missed a commit will fix asap.

TomKeddie avatar Mar 07 '21 23:03 TomKeddie

cc @GregDavill

whitequark avatar Mar 09 '21 13:03 whitequark

This has been on my list to do for awhile. So Tom took the lead, I'll go through and review later. I can do tests on hardware too.

One question I have @whitequark, the RGB LEDs are multiplexed. Would it be appropriate to include a module in this board definition that handles the de-multiplexing? Or leave that code to exist in users code?

gregdavill avatar Mar 09 '21 22:03 gregdavill

Would it be appropriate to include a module in this board definition that handles the de-multiplexing? Or leave that code to exist in users code?

At the moment this is expected to be handled in user code, though this may change in the future.

whitequark avatar Mar 09 '21 22:03 whitequark

@gregdavill I have defaulted the cathodes to on so the leds can be used as 6 individuals LEDs. Not sure if this is contraversial or not.

TomKeddie avatar Mar 09 '21 23:03 TomKeddie

@gregdavill can help clean this up if you want.

TomKeddie avatar Nov 20 '21 03:11 TomKeddie

Sure! Here is a good reference for all the SYZYGY pins: https://github.com/butterstick-fpga/test-fixture-sw/blob/main/gateware/rtl/platform/butterstick_r1d0.py#L52-L54

This is what I'll be basing the LiteX boards platform file on.

gregdavill avatar Nov 20 '21 03:11 gregdavill

@gregdavill I updated the change to more closely match the litex version. Am working on a luna definition next so I plan to test the ulpi first. The rest is untested at this point.

TomKeddie avatar Dec 01 '21 01:12 TomKeddie

Hi @TomKeddie, I really appreciate you putting this together. I just gave this a shot with an r1.0 board (python -m nmigen_boards.butterstick) and noticed that the program step failed because dfu-util wasn't automatically selecting the alt=0 altsetting. I did the following to fix it:

diff --git a/nmigen_boards/butterstick.py b/nmigen_boards/butterstick.py
index fb1100b..bab55c2 100644
--- a/nmigen_boards/butterstick.py
+++ b/nmigen_boards/butterstick.py
@@ -147,7 +147,7 @@ class ButterStickPlatform(LatticeECP5Platform):
     def toolchain_program(self, products, name):
         dfu_util = os.environ.get("DFU_UTIL", "dfu-util")
         with products.extract("{}.bit".format(name)) as bitstream_filename:
-            subprocess.check_call([dfu_util, "-D", bitstream_filename])
+            subprocess.check_call([dfu_util, "-a", "0", "-D", bitstream_filename])


 if __name__ == "__main__":

Now when programmed the lights don't blink, but pressing BTN0 does drop back into DFU mode. I think this is expected currently?

gkelly avatar Dec 04 '21 15:12 gkelly

Looks like it would be useful to have an -R in there as well, to reset out of DFU mode when programming is done.

gkelly avatar Dec 04 '21 21:12 gkelly

I spent some more time working on this today. Pressing BTN0 is actually not expected to reset to DFU on the blinky program, it turned out! With the following patch I can now run simple test programs that use the LEDs:

diff --git a/nmigen_boards/butterstick.py b/nmigen_boards/butterstick.py
index fb1100b..fe8d6f6 100644
--- a/nmigen_boards/butterstick.py
+++ b/nmigen_boards/butterstick.py
@@ -11,16 +11,16 @@ __all__ = ["ButterStickPlatform"]


 class ButterStickPlatform(LatticeECP5Platform):
-    device      = "LFE5U-85F"
+    device      = "LFE5UM5G-85F"
     package     = "BG381"
     speed       = "8"
     default_clk = "clk30"
     resources   = [
         Resource("clk30", 0, Pins("B12", dir="i"),
-                 Clock(30e6), Attrs(IO_TYPE="LVCMOS33")),
+                 Clock(30e6), Attrs(IO_TYPE="LVCMOS18")),

         # LED Anodes
-        *LEDResources(pins="C13 D12 U2 T3 D13 E13 C16", attrs=Attrs(IO_STANDARD="LVCMOS33")),
+        *LEDResources(pins="C13 D12 U2 T3 D13 E13 C16", attrs=Attrs(IO_TYPE="LVCMOS33")),

         # LED Cathodes. Use invert to default as on to allow LEDs to be used in white with single bit IO
         RGBLEDResource(0, r="T1", g="R1", b="U1", invert=True, attrs=Attrs(IO_TYPE="LVCMOS33")),
@@ -135,7 +135,7 @@ class ButterStickPlatform(LatticeECP5Platform):
         return super().command_templates + [
             r"""
             {{invoke_tool("dfu-suffix")}}
-                -v 1209 -p 5af0 -a {{name}}.bit
+                -v 1209 -p 5af1 -a {{name}}.bit
             """
         ]

@@ -147,7 +147,7 @@ class ButterStickPlatform(LatticeECP5Platform):
     def toolchain_program(self, products, name):
         dfu_util = os.environ.get("DFU_UTIL", "dfu-util")
         with products.extract("{}.bit".format(name)) as bitstream_filename:
-            subprocess.check_call([dfu_util, "-D", bitstream_filename])
+            subprocess.check_call([dfu_util, "-a", "0", "-D", bitstream_filename, "-R"])


 if __name__ == "__main__":

I haven't at all experimented with any of the fancier peripherals, but this at least got the barebones system working.

gkelly avatar Dec 05 '21 00:12 gkelly

One thing that doesn't work perfectly is the exit from the dfu-util invocation. It return 251 after the reset, so the board gets programmed and starts the loaded gateware but the command fails with a python stack trace...

gkelly avatar Dec 05 '21 00:12 gkelly

@gkelly Thanks for all the awesome patches. I haven't put enough time into this as you can tell. I've added you as a collaborator. Let me know if you'd prefer I applied the patches or if you want to commit to the branch. I'm fine either way.

An alternative would be for you to take the changes into your own fork and we can kill this pr. Again I'm fine either way, I don't have a ton of time to commit to this unfortunately.

TomKeddie avatar Dec 05 '21 01:12 TomKeddie

@gkelly Can you help me with the motivation to change the clock to 1.8v? As far as I can tell it's 3.3v but I'm ready to be wrong. Thanks. I've added all your other changes in a commit. image

TomKeddie avatar Dec 05 '21 13:12 TomKeddie

@gkelly Can you help me with the motivation to change the clock to 1.8v? As far as I can tell it's 3.3v but I'm ready to be wrong. Thanks. I've added all your other changes in a commit. image

Good catch! This came from me reading https://github.com/butterstick-fpga/butterstick-bootloader/blob/main/gateware/rtl/platform/butterstick_r1d0.py and https://github.com/butterstick-fpga/verilog-examples/blob/main/blink/ButterStick_r1.0.pcf#L7, however looking at https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/gsd_butterstick.py#L16 and the schematic it appears that this was perhaps an error.

gkelly avatar Dec 05 '21 17:12 gkelly

@whitequark thanks for the repo rename, I'm move this over shortly.

I want to add some code to this platform to provide an object to control vccio. I don't see this in any other platforms so I'm looking for some guidance on how you'd prefer to see this (or not at all?). Thanks.

TomKeddie avatar Dec 11 '21 18:12 TomKeddie