<vipqp>
hi, i'm just starting to build to hardware now and have some questions about the role of amaranth board definitions
<whitequark>
go ahead
<vipqp>
if nextpnr requires the constraint files then what is the purpose of the board definitions in amaranth? is that just for checking for conflicts before trying to PnR?
<galibert[m]>
for cyclone v at least it gives better names for the peripheral I/O
<whitequark>
it generates the constraint file for nextpnr from the board file
<vipqp>
oh!
<vipqp>
I didn't try to run it yet.. so it produces .xdc or similar files when you run the top file?
<whitequark>
yes
<vipqp>
wow that's a lot simpler than I was thinking it could be! great thank you for the help
<galibert[m]>
The amaranth environment is designed so that you don't need anything else visible to generate bitstreams
<galibert[m]>
there are tools underneath (yosys, nextpnr, vendor suites, etc) but you don't directly interact with them
<vipqp>
maybe I have been spending too much time on github, haha. I saw all the tools underneath and was thinking that I have to make some shell scripts to run them sequentially with all the required files. not having to do that is really nice
<vipqp>
I didn't look too closely before because I was mostly simulating, but getting onto hardware is really exciting.
<whitequark>
nice!
<vipqp>
ok, so if I want to use openxc7 instead of vivado, in the board definition file I should use toolchain_prepare() to create the bitstream (with prjxray) and then something like openfpgaloader in toolchain_program()?
<vipqp>
that might be outside the scope of amaranth.. but the move from verilog to bitstream inside the board definition is a bit abstract to me. but it's all contained in those two toolchain functions right?
<whitequark>
yeah
<whitequark>
well
<whitequark>
you're interested in amaranth/build/plat.py
<whitequark>
the build method orchestrates it all
<whitequark>
it calls prepare, which calls toolchain_prepare
<whitequark>
toolchain_prepare gives the platform hooks to emit verilog or rtlil