-
Notifications
You must be signed in to change notification settings - Fork 17
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
numerous changes and restructuring for target independent build #33
Conversation
* Removed hardcoding of filename variables in ps and xsdk scripts
Conflicts: targets/PandABox/Makefile
* Removed PCAP including DMA block * posbus size=32, 2 blocks BITS, CLOCKS * Removal of Slow FPGA form Makefile * Removal of CLOCK_DEDICATED_ROUTE + inclusion of BUFG
* Full PCAP, 2 soft blocks (BITS, CLOCKS) * posbus size=1, 0 used * ZedBoard demo block in target.ini * Meets timing comfortably
… zedboard Conflicts: Makefile common/python/generate_app.py common/templates/slow_top.files.jinja2 common/templates/soft_blocks.vhd.jinja2 targets/PandABox/Makefile
* Move u-boot build from rootfs to FPGA repo
Conflicts: CONFIG.example targets/ZedBoard/hdl/ZedBoard_top.vhd
* To avoid repetition of code for different targets
* Necessary as not all IP can be targeted to all platforms. * For example, ZedBoard has no MGTs. * Also, fixed paths in hard block rst files.
* To simplify the ZedBoard example and avoi polluting the IP repo.
* Passed MODE and TERM signals and wstbs to system block to create tlp * System block only sees its own write_strobe * Added ttlin_block and conencted ttlin_ctrl for consistency
Issue with encoder and ttlin block depending on slow_fpga has been addressed by passing the relevant parameters (ENC_MODE, and TTL_TERM) and their respective WSTBs from the encoder block to the system block, where the tlp packet for the Spartan is generated. This should be checked with the hardware to verify it still functions correctly. |
Now passing python tests and hdl_timing build |
* U-boot script generated in PandABlocks-rootfs repo
* Decided to keep this in the server repo as compiler toolchain * needs to match that used for the rootfs.
* Moved changes for FPGA Manager bin file to fpga sub-make * Replicated changes for list and loading file for * PandABox and ZedBoard targets
* Unnecessary in 'batch' mode and leaves projects available * interactively in 'tcl' and 'gui' mode
* EXT_DTB option no longer works for ZedBoard, but kept as an * option for PandABox. * Added target platform-top.dts as a prerequisite for Make.
* to support targets that don't have a CLKMUX. * Can also remove the 'add' and 'master_clock' parameters
* to keep Vivado happy in gui mode.
* U-boot would not boot into linux with 'picozed' dts
Upgrade to Vivado 2020.2. All tests pass and zpackages build okay, minimally tested on PandABox and ZedBoard targets. Issue discovered with PCAP not re-arming correctly, however this problem is also present in the destination branch (master @ v2.2a1). |
This branch contains many changes to the build system for target independence including generation of target specific FSBL and devicetree from within the FPGA repo, using 'make boot'. It also allows build to an arbitrary build location (this did not work previously).
There are several items to note/ things still to do:
Currently fails 'python_tests' and 'hdl_test'
Hardware blocks, previously under 'targets//' now moved to 'modules' directory. I made some hacky changes to the paths in several python files to make this work (and left the previous lines commented out). There may be a neater way to make these changes; also we now have directories for inenc, outenc (needed by the python code), and 'encoders' (needed for the hdl) - this need to be tidied up.
Encoder and TTL blocks now have dependencies on the slow FPGA (which is target specific).
Several area could do with more jinja templating: for example 'load-panda_firmware' script, which also loads the slow FPGA firmware.
IP build: we currently build all IP for a given target regardless of the app being built. Alternatively, we could the build the IP as and when required but this would require make to have knowledge of the target/app. At the moment there is a clear separation between the 'make' system and the autogenerated parts.