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
Added Arty S7 support #101
Conversation
For openFPGALoader to work it needs this PR to work. |
I played around a little and I think I can make the programming also work through a vivado script. |
PR for generic vivado FPGA programming script: amaranth-lang/amaranth#468 |
I'd prefer if you put the |
But I think it comes down to duplcating the same code for all boards using Vivado as toolchain. I would think centralizing it make it more maintainable. |
I disagree that it improves maintainability. Because we can not automatically test changes to the common, factored-out code (as doing it faithfully requires hardware unique to that board, and the likelihood of anyone changing the factored-out code having all of this hardware approaches zero as the amount of boards grows), it is better to duplicate code, and have the peace of mind that any changes have in fact been tested by the person making the change.
We don't yet have a clear policy for this. It's clear to me that the default option would be whatever the board vendor suggests; so for Digilent Xilinx boards it should be Vivado. But it's also clear that a single option wouldn't suffice (especially seeing as many people are not fond of proprietary toolchains). So we probably should work out a way to support multiple programmers, but in the meantime, Vivado will do. |
Related: I have changed my local board file to work with the Vivado programmer for the arty z7 board in a similar way to what you are suggesting, because I could not get xc3sprog to work (because of reasons I wont discuss here). While this approach did work, Vivado takes a few seconds to start before it can even start programming. this is very slow and I doubt xc3sprog requires that long to start up (because it doesn't have to start the tcl interpreter and what not). while having that option be in the board file might be a good idea, for those like me who cant use the free programmer, I am not sure that using vivado as the default is the best idea for programming the bitstream of the board even if diligent suggests that. |
For me the use case for the build in nmigen board programming function is programming the board after you build the bitstream with nmigen. In that respect I see the extra two seconds that is added to the whole Vivado flow as negligible and people will have Vivado installed anyway. |
OK, squashed the commits. |
Thanks. Everything looks good (aside from minor PEP8 violations, which I'll just fix when merging), except for one thing: I'm not quite sure what are you doing with |
The Arty has two 'reset' signals, one connected to the program pin of the FPGA the other to an IO. Pressing the former will reload the bitstream from Flash and thus can be seen as hard reset. The latter is called cpu_reset. The name I took over from Arty A7 but I made it the default reset. This makes the blinky test react to the reset button. |
Would you say that, based on your experience (presumably you use these Xilinx devboards--I don't, although I do own several), you'd expect |
Yes, and now I see that in the Digilent schematic for Arty S7 the second reset is called 'ck_rst' which I assume stands for circuit reset. So maybe I should name the resource just rst ? |
Yes, according to our conventions it would be just |
This is based on Arty A7 file. Some things are handled differently: * Rename cpu_reset resource to rst and use it as default circuit reset. * Use Vivado for programming the board. * Don't overload .bin generation; it does not seem to make a difference. * Generate also mcs file. This is used by openFPGALoader for programming into SPI Flash. Arty S7-50 has been tested on the board by blinky test; Arty S7-25 only bitstream generation, not on the board.
Renamed cpu_reset -> rst; also corrected wrongly deleted toochain_prepare() in previous push. |
Thanks! |
This is based on Arty A7 file. Some things are handled differently:
into SPI Flash.
Arty S7-50 has been tested on the board by blinky test; Arty S7-25 only
bitstream generation, not on the board.