Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:45
    DanielG commented #2344
  • 15:42
    DanielG commented #2344
  • 15:40
    DanielG commented #2344
  • 14:18
    tgingold commented #2343
  • 14:15
    tgingold commented #2344
  • Feb 06 22:36
    JimLewis opened #2346
  • Feb 06 19:15
    dependabot[bot] commented #2345
  • Feb 06 19:15
    dependabot[bot] review_requested #2345
  • Feb 06 19:15
    dependabot[bot] review_requested #2345
  • Feb 06 19:15
    dependabot[bot] review_requested #2345
  • Feb 06 19:15

    dependabot[bot] on pip

    [Dependabot]: Bump pyvhdlmodel … (compare)

  • Feb 06 19:15
    dependabot[bot] opened #2345
  • Feb 06 15:20
    DanielG opened #2344
  • Feb 06 12:39
    yurivict opened #2343
  • Feb 06 08:40
    tgingold commented #2337
  • Feb 06 08:39
    creiter64 commented #2337
  • Feb 05 03:10
    r2com closed #2342
  • Feb 05 03:10
    r2com commented #2342
  • Feb 04 23:11
    r2com opened #2342
  • Feb 04 23:00
    r2com closed #2340
Unai Martinez-Corral
@umarcor
Some time, I will update https://ghdl.github.io/ghdl/getting.html with the explanations above. However, I cannot prioritise it at the moment. If any Windows user wants to propose a PR, I will be very glad to review and enhance it.
tgingold
@tgingold
@arnfol Encrypted IPs are a real problem. The encryption mechanism is public (IEEE1735), but the key is not.
I don't know how to deal with that.
Martin
@hackfin
@tgingold , I believe this was a hot topic on the icarus verilog side as well. Conclusion was, there is no opensource way of doing this legally. As always, those keys are buried somewhere, commercial SW just tries to hide them.
2 replies
Unai Martinez-Corral
@umarcor
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.
Martin
@hackfin
Vivado is not good at hiding them, I can tell. Check those PEMs..
Unai Martinez-Corral
@umarcor
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.
Martin
@hackfin
It would. At least Xilinx is pretty clear about that. Even if they put the key in front of you, it's like: You are not allowed to use that key or tell anyone how to use it. All github repos concerning this stuff have gotten a DCMA takedown notice..so..
Hendrik Mennen
@HendrikMennen
image.png
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-PackageCompilation
Hendrik Mennen
@HendrikMennen
file 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
tgingold
@tgingold
Was the file written by ghdl ?
vblanco20-1
@vblanco20-1
@nobodywasishere:eowyn.net i use a code generator to generate ram modules from binary files
just a few lines of rust to grab a binary file, split it into hex, and plop the string into a prebuilt ram module
nobodywasishere
@nobodywasishere:eowyn.net
[m]
I've done that before too.
One less step to run though
tgingold
@tgingold
But the format of the file is not defined, so the only way to generate it is through ghdl.
You should use a text file if you want to read a file generated by a tool.
Unai Martinez-Corral
@umarcor
@tgingold, my understanding is that @vblanco20-1 grabs a binary file (.bin, .hex) and it generates a VHDL source file, with the content hardcoded. He is not reading the binary file from VHDL. That's a different use case, the one @HendrikMennen asked about.
tgingold
@tgingold
You're right. Sorry for the confusion!
vblanco20-1
@vblanco20-1
thats indeed what im doing
in case you are interested
nobodywasishere
@nobodywasishere:eowyn.net
[m]
@HendrikMennen: what file are you reading?
nobodywasishere
@nobodywasishere:eowyn.net
[m]
I ran into issues when reading a file if I read the last line, i.e. no newline at the end of the file.
Hendrik Mennen
@HendrikMennen
@nobodywasishere:eowyn.net it is a .bmp file used for image processing
Unai Martinez-Corral
@umarcor
@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.
Michael Jørgensen
@MJoergen
I use a tool like xxd to convert a binary file to ASCII, and then use hread() to read it in VHDL.
eine
@eine
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...
nobodywasishere
@nobodywasishere:eowyn.net
[m]
VHDLref? ;)
eine
@eine
Might be :wink:
Ed Bordin
@edbordin
So, I finally got around to looking into why the fpga-toolchain builds were failing and I think it's because GNAT_LARGS was removed from Makefile.in due to being unused :/
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
tgingold
@tgingold
GNAT_BARGS still exists, but GNAT_LARGS has been replaced by LDFLAGS.
Ed Bordin
@edbordin
LDFLAGS didn't seem to quite behave the same
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
tgingold
@tgingold
Do not hesitate to propose a change!
Ed Bordin
@edbordin
I've run out of time today but yes, I agree I should collaborate with you rather than patching downstream!
it doesn't help that I don't really understand all the details of gnatlink etc.
xiretza
@xiretza:xiretza.xyz
[m]
@edbordin: that one's on me, sorry about that, we could just revert that commit
or add a generic GNAT_FLAGS variable
Unai Martinez-Corral
@umarcor
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.
tgingold
@tgingold
@edbordin For gnatlink, just use -v so that it displays how gcc is called. Then you need to narrow down which command is not correct and what would be the best order for the options.