Unified fpga folders #2001
Unified fpga folders #2001
Conversation
|
You are welcome to add an entry to the CHANGELOG.md as well |
|
.... massive change .... I hope you have all devices to test it all on. |
|
I don't but you probably missed the "100% binary" section 'e' (the actual FPGA bitstream) before and after the change. You are welcome to verify, build the bitfiles before the change, build them after and compare, the only differences are in the header section a (stream name), c (date) and d (time) which is to be expected. Actual test only done on PM3GENERIC with 512K, but I must come back to the 100% binary... :) Ping me at d18... hotmail if you need to. |
|
Lets leave this one here until someone has time to test it properly. |
|
OK but I wonder if I'm failing to make my point clear. I went through great lengths to especially make sure that the FPGA bitstream remains unchanged at the binary level before and after the "big scary change" To put it another way, suppose you compile some code and you get blah.exe out and you use blah.exe for a while and all is good, then someone pushes a massive looking change to the code that somehow compiles to an identical blah.exe, same bits and bytes, same sha256 checksum, same same... Do you really need to put the new blah.exe through extensive tests to prove it doesn't break anything when it's the same identical file as before? The only problems I'm expecting is that someone doesn' t like this change at a conceptual level, because they prefer things one way as opposed to another. I could also split this big change into a number of tiny incremental changes that are not so scary but I feel that would drive you crazy getting to approve a whole bunch of small pull requests. I already feel like I was told off for not fixing the "big ticket" issues and instead submiting seemingly small inconsequential changes, even though in my personal opinion code tidy up is also important even if it doesn't fix bugs or add new features :) |
|
Interesting, running this PR doesn't generate the bit images, Another thing, why not just Out is full of these error messages. This needs to be addressed. |
|
Aha, if I use |
|
Why have zero sized files to start with? |
|
I’m just on a road trip to Stockholm but when I get back after the weekend I’ll take a look. I really don’t think I had those error messages about the DCM site during my compile and I certainly had the expected bitstream files being generated and matching the old bitstream that’s 100% sure. The reason for truncate is that if the file exists and somehow has some junk in it it will be zeroed (truncated) whereas touch will only touch the date stamp and not the contents and echo redirect to file will typically output some CR or LF rather that create a zero length file Finally the reason for the empty bitfiles, as far as I can understand is that icopyx uses a bigger fpga so they have managed to compile an “all in one” image. However the current code base assumes the fpga used is the original which can’t fit everything in one bitstream and expects 4 different files depending on what commands/features the user requests. In order to be compatible with that, the icopyx generate one proper bitstream (the one named *_hf) and three dummy zero length files so they avoid a compile error like bitstream file not found. If you look careful during compilation there are still three non fatal error messages like invalid bitstream caused by the empty files during compress. In any case for a icopyx fpga the valid fpga image is uploaded and configures the fpga proper and whenever fpga upload tries to send another image it sends the empty files which fail to configure the fpga due to no bitstream content so the fpga remains configured with the all-in-one bitstream. Hope that makes sense. |
|
tried even building on Ubuntu. I will have to revert this PR soon
|
|
Looks like my fpga build chains is messed up. |
|
From the error message it looks like it can’t find xst in the path which is the first Xilinx executable run during the build process. You could try checking if you can run xst manually at the shell prompt and maybe adjusting the path so it gets found. We can move this to Discord if you want. |
|
You may also try setting XILINX_TOOLS_PREFIX= at the top of the makefile if you don’t want to mess with adjusting your PATH |
OK this is what I was trying to do.
One FPGA folder, one makefile to generate all variants for PM3/RDV40 and ICOPYX.
Conditional compilation is enabled through defines passed from the Makefile to turn on and off different modules and features as needed by space constraints. Even that stupid EDGE_DETECT_THRESHOLD value is preserved at 3 for ICOPYX and 5 for PM3 :P
All compilation is done inside special build folders so it does not pollute the source directory, build directories are kept so one can inspect compilation logs and reports generated. Build folders can be easily deleted with make clean or just rm
Inter-module parameters are now passed "by name" instead of "by order" to avoid silly mistakes like accidentally swapping some parameters so they connect to the wrong ports.
Verification test 1: Generate all bitstream files and verify that all files are created. For PM3 we get fpga_pm3_felica.bit fpga_pm3_hf_15.bit fpga_pm3_hf.bit fpga_pm3_lf.bit and for ICOPYX we get fpga_icopyx_felica.bit fpga_icopyx_hf_15.bit fpga_icopyx_hf.bit fpga_icopyx_lf.bit where only the hf file is a real bitstream and the others are zero length (ICOPYX uses an "allinone" image)
Verification test 2: Generate all bitstream files before the change and save them as reference. Generate all bitstream files after the change and compare section 'e' to the reference files. Pass indicated by 100% binary match.