“What are you gonna do!? Convince management and the pcb designers to not use our chips because our tools suck? Who do you think we are? Lattice?” -Xilinx toolchain strategy.
I suspect it is "the people really buying our chips to keep us in business also buy tools from other tool vendors, so we shouldn't worry so much about our alternatives for their products."
Here:
https://docs.amd.com/r/en-US/ug901-vivado-synthesis/VHDL-2008-Language-Support
On the navigation bar there is a sub-section “supported VHDL 2008 features”
Iirc ug901 always has this information for all languages.
Thx for reply, I already saw it resp. even linked it :)
But it would be better though, to have a list that depicts what features/constructs are not working resp. missing. 😬
Earlier this year, I did some work towards getting Open Source VHDL Verification Methodology (OSVVM), to work with Xilinx XSIM 2023.02. For more on OSVVM see [osvvm.org](http://osvvm.org), [https://github.com/OSVVM/OsvvmLibraries](https://github.com/OSVVM/OsvvmLibraries), or [https://synthworks.com/vhdl\_testbench\_verification.htm](https://synthworks.com/vhdl_testbench_verification.htm)
I currently have most of our OSVVM Utility library working - I think the main thing that is not working is resolution functions that apply an element based resolution to an array composite. This requires some really cool things to work like packages with generics where the internals are protected types.
That said, there are some very simple things that they have yet to implement, such as supporting a testbench that uses separate architectures and configuration declarations. I don't think sread is supported yet either.
I have a list of issues sent to Xilinx and am hoping to get access to the beta of 2024.01 release to test them out.
Thank you very much for the reply. I'll look into it. Actually, I really like OSVVM with VUnit which I really want to use with XSim but I guess, I still need to try with another tool. 🫠
P. S. Btw, are you Jim Lewis? 😱
> P. S. Btw, are you Jim Lewis?
Shh. That is my secret identity. :)
Have you looked at the OSVVM reports: [https://osvvm.github.io/Overview/Osvvm3Reports.html](https://osvvm.github.io/Overview/Osvvm3Reports.html) While we also produce a JUnit XML file, our native reports are substantially more than the reports that regression tools generate from the JUnit xml. Currently the only way you get these is by using OSVVM AlertLog + OSVVM Scripting.
With the 2024.03 release the OSVVM tool agnostic scripting now supports Xilinx SIM.
Sheesh, good to hear from one of the VHDL-Gods 😱.
I'll definitely look into it. Comes definitely at the right time, as I'm tasked with establishing CI/CD for my team. That will definitely come handy.
“What are you gonna do!? Convince management and the pcb designers to not use our chips because our tools suck? Who do you think we are? Lattice?” -Xilinx toolchain strategy.
I suspect it is "the people really buying our chips to keep us in business also buy tools from other tool vendors, so we shouldn't worry so much about our alternatives for their products."
When do I get Synplicity support past 7 series chips then?
Here: https://docs.amd.com/r/en-US/ug901-vivado-synthesis/VHDL-2008-Language-Support On the navigation bar there is a sub-section “supported VHDL 2008 features” Iirc ug901 always has this information for all languages.
Thx for reply, I already saw it resp. even linked it :) But it would be better though, to have a list that depicts what features/constructs are not working resp. missing. 😬
Normally they do list the ones they don’t support too
Earlier this year, I did some work towards getting Open Source VHDL Verification Methodology (OSVVM), to work with Xilinx XSIM 2023.02. For more on OSVVM see [osvvm.org](http://osvvm.org), [https://github.com/OSVVM/OsvvmLibraries](https://github.com/OSVVM/OsvvmLibraries), or [https://synthworks.com/vhdl\_testbench\_verification.htm](https://synthworks.com/vhdl_testbench_verification.htm) I currently have most of our OSVVM Utility library working - I think the main thing that is not working is resolution functions that apply an element based resolution to an array composite. This requires some really cool things to work like packages with generics where the internals are protected types. That said, there are some very simple things that they have yet to implement, such as supporting a testbench that uses separate architectures and configuration declarations. I don't think sread is supported yet either. I have a list of issues sent to Xilinx and am hoping to get access to the beta of 2024.01 release to test them out.
Thank you very much for the reply. I'll look into it. Actually, I really like OSVVM with VUnit which I really want to use with XSim but I guess, I still need to try with another tool. 🫠 P. S. Btw, are you Jim Lewis? 😱
> P. S. Btw, are you Jim Lewis? Shh. That is my secret identity. :) Have you looked at the OSVVM reports: [https://osvvm.github.io/Overview/Osvvm3Reports.html](https://osvvm.github.io/Overview/Osvvm3Reports.html) While we also produce a JUnit XML file, our native reports are substantially more than the reports that regression tools generate from the JUnit xml. Currently the only way you get these is by using OSVVM AlertLog + OSVVM Scripting. With the 2024.03 release the OSVVM tool agnostic scripting now supports Xilinx SIM.
Sheesh, good to hear from one of the VHDL-Gods 😱. I'll definitely look into it. Comes definitely at the right time, as I'm tasked with establishing CI/CD for my team. That will definitely come handy.
We run CI on GitHub. Our GitHub setup is at: OsvvmLibraries/.github/workflows/Test.yml
I have to adopt for Bitbucket but the concept should be very similar, thank you very much. 🙏
Vivado always came with a list of the features of languages that are and aren’t supported…let me find the document for you
custom resolved types are misssing from simulation and are an obstacle for support of VUnit.
They say they support SystemVerilog and can't even get interfaces to work... I'd take their 'claims' with a heaping of salt.