amaranth-boards
amaranth-boards copied to clipboard
butterstick: add board defn for r1.0
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.
Urgh, syntax issues I've missed a commit will fix asap.
cc @GregDavill
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?
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.
@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.
@gregdavill can help clean this up if you want.
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 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.
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?
Looks like it would be useful to have an -R in there as well, to reset out of DFU mode when programming is done.
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.
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 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.
@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.

@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.
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.
@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.