2 replies
Technically, all of those keys can be extracted I believe. Not long ago, there was a paper about using Xilinx's own bitstream encryption mechanism for breaking the system. Unfortunately, those features are only legally usable for demo/academic purposes, not for practical uses.
The same applies to bitstream compression. There are several research groups and companies doing clever compression for dynamic partial reconfiguration purposes. Unfortunately, they cannot release the tools.
E.g., I know that https://github.com/khoapham/bitman might be released as a pre-built binary at some point, but the sources are unlikely to be published.
Users might provide GHDL the location of those keys (similarly to how vendor pre-compilde scripts are used). Yet, I believe that would still break the license.
I tried to compile quartus librarys like here https://ghdl.readthedocs.io/en/latest/getting/PrecompileVendorPrimitives.html
Start-PackageCompilation : Cannot bind argument to parameter 'VHDLVersion' because it is an empty string.
At C:\msys64\mingw64\lib\ghdl\vendors\compile-intel.ps1:261 char:105
+ ... nalyze_Parameters $DestinationDirectory $Library $VHDLVersion $Source ...
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Start-PackageCompilation], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Start-PackageCompilationfile read_file : bit_vector_file open read_mode is FileName;gives me
C:\Users\HendrikMennen\AppData\Roaming\VHDPlus\packages\ghdl\GHDL\0.37-mingw32-mcode\bin\ghdl.exe:internal error: file: IO error
C:\Users\HendrikMennen\AppData\Roaming\VHDPlus\packages\ghdl\GHDL\0.37-mingw32-mcode\bin\ghdl.exe:error: simulation failed
modelsim works though
just a few lines of rust to grab a binary file, split it into hex, and plop the string into a prebuilt ram module
One less step to run though
You should use a text file if you want to read a file generated by a tool.
in case you are interested
I ran into issues when reading a file if I read the last line, i.e. no newline at the end of the file.
@HendrikMennen see ghdl/ghdl#1758. As Tristan said, binary file formats are implementation dependent.
Therefore, you might need to read the BMP file in VHDL byte by byte.
Alternatively, you might want to have a look at co-simulation examples. My main motivation for using co-simulation is passing images/video/cubes between VHDL and C/Python.
That is, I use C/Python for reading/writing BMP, PNG, TIFF, any other image format; instead of writing those functions in VHDL.
As a matter of fact, I wanted to gather multiple examples about dealing with files (text, binary, CSV, hexdumps, etc.) in VHDL >=2008. However, I don't know where to put that content. I feel it doesn't fit in the GHDL docs, nor in the ghdl-cosim docs, or in OSVB... And currently I cannot handle maintaining yet another repo...
I was calling make with GNAT_BARGS="-bargs -E -static" GNAT_LARGS="-static -lz" to force a static link with zlib, is there a better way to do it? Perhaps I should just open a GH issue
in the meantime I might just patch it back in to get things building again
the linker flags I'm adding are very sensitive to ordering though because I'm adding -static so I was possibly never using it as intended
it doesn't help that I don't really understand all the details of gnatlink etc.
@edbordin: that one's on me, sorry about that, we could just revert that commit
or add a generic
GNAT_FLAGS variable
I will rebase ghdl/ghdl#1547, so we can use it as a reference for the windows builds. That covers all the working and non-working setups I could gather.
(I knew this was happening but wasn't sure what the timeline was)