-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gowin: Himbaechel arch #1184
Merged
Merged
gowin: Himbaechel arch #1184
Changes from all commits
Commits
Show all changes
39 commits
Select commit
Hold shift + click to select a range
3bc88d0
wip start
yrabbit e54f7aa
generate bba
yrabbit 9139fef
gowin: Add himbaechel arch
yrabbit c344914
gowin: add global VCC and VSS networks
yrabbit 995fd23
gowin: add support for all DFF types
yrabbit fbae840
gowin: Himbaechel, fix style
yrabbit 3e4edfb
gowin: Himbaechel. Add a wideluts
yrabbit 8576708
gowin: Himbaechel. Add ALU.
yrabbit d101fe8
gowin: Himbaechel. Add the LUTRAM
yrabbit b4712ff
gowin: Himbaechel. Add a clock router.
yrabbit 27bfbbc
gowin: Himbaechel. Add bundle data generation.
yrabbit cf94939
gowin: Himbaechel. Add constraint file processing.
yrabbit c07f5ef
gowin: Himbaechel. Implement the GSR primitive
yrabbit 3b9ac71
gowin: Himbaechel. Use pin functions info
yrabbit 3522e00
gowin: Himbaechel. Implement PLLs
yrabbit 4f9919e
gowin: Himbaechel. Add extra chip data
yrabbit 91e09ef
gowin: Himbaechel. Add simplified IO
yrabbit 80a359b
gowin: Himbaechel. Add redundant checks
yrabbit c250bef
gowin: Himbaechel. Add SERDES and differential IO
yrabbit 41c328b
gowin: Himbaechel. Add OSER8
yrabbit cf5f952
gowin: Himbaechel. Add OSER10 and OVIDEO
yrabbit a8570f3
gowin: Himbaechel. Add IDES primitives
yrabbit bc1c67a
gowin: Himbaechel. Unify the creation of tail types
yrabbit eac2eb1
gowin: Himbaechel. Add OSER16 and IDES16
yrabbit 83835e4
gowin: Himbaechel. Add the GW1N-4 simple IOs
yrabbit 0c41254
gowin: Himbaechel. Fix DESER and PLL
yrabbit 422de29
Merge branch 'master' into h-gw
yrabbit 8925b86
gowin: Himbaechel. Refactor.
yrabbit a9f3bb2
gowin: Himbaechel. Improve error messages
yrabbit da2fc67
gowin: Himbaechel. Fix IO for GW1NZ-1
yrabbit e597fca
Merge branch 'master' into h-gw
yrabbit 7af5270
gowin: Himbaechel. Add rough CMake stuff
yrabbit cf7dd93
gowin: Himbaechel. Improve CMake thing a little
yrabbit 9bfb0cf
gowin: Himbaechel. Handling of disabled units
yrabbit 40e23a7
gowin: Himbaechel. Install bases
yrabbit 251e511
Merge branch 'master' into h-gw
yrabbit 44bd264
gowin: Himbaechel. Fix problems.
yrabbit 6fd0dab
Merge branch 'master' into h-gw
yrabbit 6a1842f
Merge branch 'master' into h-gw
yrabbit File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
message(STATUS "Configuring Himbaechel-Example uarch") | ||
|
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
message(STATUS "Configuring Himbaechel-Gowin uarch") | ||
cmake_minimum_required(VERSION 3.5) | ||
project(himbaechel-gowin-chipdb NONE) | ||
|
||
find_package(Python3 3.5 REQUIRED COMPONENTS Interpreter) | ||
set(ALL_HIMBAECHEL_GOWIN_DEVICES GW1N-1 GW1NZ-1 GW1NS-2 GW1N-4 GW1N-9 GW1N-9C GW1NS-4 GW2A-18 GW2A-18C) | ||
set(ALL_HIMBAECHEL_GOWIN_DEVICES "") | ||
set(HIMBAECHEL_GOWIN_DEVICES ${ALL_HIMBAECHEL_GOWIN_DEVICES} CACHE STRING | ||
"Include support for these Gowin devices (available: ${ALL_HIMBAECHEL_GOWIN_DEVICES})") | ||
message(STATUS "Enabled Himbaechel-Gowin devices: ${HIMBAECHEL_GOWIN_DEVICES}") | ||
|
||
set(chipdb_binaries) | ||
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/chipdb) | ||
foreach(device ${HIMBAECHEL_GOWIN_DEVICES}) | ||
if(NOT device IN_LIST ALL_HIMBAECHEL_GOWIN_DEVICES) | ||
message(FATAL_ERROR "Device ${device} is not a supported Gowin device") | ||
endif() | ||
|
||
set(device_bba chipdb/chipdb-${device}.bba) | ||
set(device_bin chipdb/chipdb-${device}.bin) | ||
add_custom_command( | ||
OUTPUT ${device_bin} | ||
COMMAND ${Python3_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/gowin_arch_gen.py -d ${device} -o ${device_bba} | ||
COMMAND bbasm ${BBASM_ENDIAN_FLAG} ${device_bba} ${device_bin}.new | ||
# atomically update | ||
COMMAND ${CMAKE_COMMAND} -E rename ${device_bin}.new ${device_bin} | ||
DEPENDS | ||
bbasm | ||
${CMAKE_CURRENT_SOURCE_DIR}/gowin_arch_gen.py | ||
${CMAKE_CURRENT_SOURCE_DIR}/constids.inc | ||
VERBATIM) | ||
list(APPEND chipdb_binaries ${device_bin}) | ||
endforeach() | ||
|
||
add_custom_target(chipdb-himbaechel-gowin ALL DEPENDS ${chipdb_binaries}) | ||
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/chipdb/ DESTINATION share/nextpnr/himbaechel/gowin | ||
PATTERN "*.bba" EXCLUDE) |
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we have this default to none for now so building nextpnr himbaechel doesn't require the gowin binary?
I still want to work a bit more on the user experience for building nextpnr-himbaechel and device databases, then maybe we can revisit this when nextpnr-himbaechel has replaced the old nextpnr-gowin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you tell me more about the build process of nextpnr-himbaechel and device databases? This is something I care about in YoWASP. It is not feasible to ship one binary that includes every binary and every chipdb due to size constraints (about 100 MB) and I would rather avoid configuring and building nextpnr several times if at all feasible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to provide a unified framework for arches to share one nextpnr binary with a reduced amount of per-arch code, and with a relatively compact deduplicated representation. Gowin will move there first and I will also look at xo2/3 moving to it. Longer term if it works out there will be more migrations and new arches using it.
It is going to have the chipdb binaries as data files (which should in every case be significantly less than 100MB). These will be configurable in the build process and in the next few days there should be a nice discovery process for those so you can pass the name of a device on the command line and it will load the right subarch and chipdb automatically (it'll be a relative path based approach similar to Yosys, I need to look exactly what we do for different arches and build environments there still).
I would guess, once it reaches a point of being end user ready (i.e. the legacy nextpnr-gowin is formally deprecated and then removed in favour of this), we'd have one nextpnr-himbaechel package and then another containing the chip databases per arch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Can you make sure every architecture (~ user-visible package) gets its own directory under
share/
and nothing outside of this directory is installed? Then I will be able to ship this nicely in YoWASP.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that matches what I was planning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic! Then what I will do in
yowasp-nextpnr-himbaechel
is to pull in all of the chipdbs thatyowasp-nextpnr-${ARCH}
have registered using the standard Python "entry points" (plugin) mechanism and mount them undershare/
. Ideally that in itself will be enough.Do you plan to have e.g. a
nextpnr-ecp5
runner that proxies tonextpnr-himbaechel --uarch ecp5
? This could be done by snoopingargv[0]
(checking if it ends with-ecp5
, etc) and it would greatly simplify migration for Amaranth.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this could definitely be done as part of the migration path. Although I realise a bit more work around the himbaechel startup and API is needed to support arbitrary command line arguments, which is needed both for backwards compatibility and a friendly CLI in general.