add initial J1b support for ULX3S board #78
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stuij
force-pushed
the
ulx3s-support
branch
2 times, most recently
from
15cb1a3
to
4706049
Compare
This patch adds initial J1b support for the ULX3S board, which is based on the Lattice ECP5 FPGA and can be programmed with either the Trellis (Yosys) or Diamond (vendor) toolchain. Currently only the J1b core and UART are hooked up. So no LEDs, GPIO ports, buttons, SDRAM, etc.. support yet. You can connect to the core with the `shell.py` script, and you can replicate the bootstap process: compiling swapforth.fs, writing out a new nuc.hex file containing the new words and creating a new bitstream containing the new `.hex` file. Flashing that on the ULX3S seems to replicate a functioning Forth system. The `bram` and `ram16k` modules were split out from the `xilinx-top.v` file into `ram.v` to foster some code reuse. Thanks to improved handling of bram within Yosys, the modules could be reused as is. Note that the changes weren't tested on either the Diamond or Xilinx toolchains. The changes to Xilinx parts were minimal so hopefully no regression was introduced. As for Diamond, it made sense to me to include the Makefile-related parts needed to compile for Diamond to aid others wanting to make this work.
Also added to ULX3S readme for memory map layout updates and examples.
|
Added support for LEDs, GPIO ports, buttons. |
The ULX3S has 2x28 IO pins that can be used either individually or as differential pairs. Currently we're going to assume an individual setup (you can configure their behaviour in the .lpf file). The convention is to see them as gp[27] (GPIO positive) and gn[27] (GPIO negative) arrays; this is how they're numbered on the board itself. Note that positive and negative moniker are irrelevant in the current configuration as the ports aren't set up as differential pairs. To work with this convention, we split out the GPIO address space into 0x00XX and 0x02XX for setting in/output values of gp and gn pins respectively, and use 0x01XX and 0x3XX for setting the direction of the gn and gp pins.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch adds initial J1b support for the ULX3S board, which is based on the Lattice ECP5 FPGA and can be programmed with either the Trellis (Yosys) or Diamond (vendor) toolchain.
Currently only the J1b core and UART are hooked up. So no LEDs, GPIO ports, buttons, SDRAM, etc.. support yet.
You can connect to the core with the
shell.pyscript, and you can replicate the bootstap process: compiling swapforth.fs, writing out a new nuc.hex file containing the new words and creating a new bitstream containing the new.hexfile. Flashing that on the ULX3S seems to replicate a functioning Forth system.The
bramandram16kmodules were split out from thexilinx-top.vfile intoram.vto foster some code reuse. Thanks to improved handling of bram within Yosys, the modules could be reused as is.Note that the changes weren't tested on either the Diamond or Xilinx toolchains. The changes to Xilinx parts were minimal so hopefully no regression was introduced. As for Diamond, it made sense to me to include the Makefile-related parts needed to compile for Diamond to aid others wanting to make this work.