glob might be not recursive. Need to check that. :point_up: October 6, 2020 5:04 PM
glob("**.vhd", recursive=True and you'll get everything. Some sources are for any VHDL revision. Others are "duplicated" depending on the version. You can tell that from the namig. https://github.com/VUnit/vunit/tree/master/vunit/vhdl/data_types/src
glob is that you don't get any info about which library is each source expected to be built into.
You can use
glob("**.vhd", recursive=Trueand you'll get everything. Some sources are for any VHDL revision. Others are "duplicated" depending on the version. You can tell that from the namig. https://github.com/VUnit/vunit/tree/master/vunit/vhdl/data_types/src
Sweet, this is exactly what I was looking for. Thank you!
The issue with using
globis that you don't get any info about which library is each source expected to be built into.
For vunit this is fine since it's all one library. With OSVVM/JSON-for-VHDL in the vhdl dir I know I'll have to be careful.
are there files that are deprecated
The array package is deprecated, but not removed yet.
import vunit when I want to get the location using vunit.__file__ to figure out where it is if it is installed.
run.py script, and then add the libraries from vunit_out to GHDL through -P. That's not ideal, tho, because you actually need Python for building the libraries first.
Overall, the point is that VUnit's Python runner and VHDL helpers libs are not dependent. Using the Python runner while ignoring VHDL libs is a supported workflow, because of the non-intrusive philosophy. However, using VHDL helpers without Python is not explicitly supported/documented.
Gotcha, that makes sense. Yeah, I guess what I'm trying to do would benefit from this. I guess another benefit would be for vendors to test VUnit VHDL sources without needing python.
Other projects might want to import those libs only. I'm thinking about edalize, fusesoc, etc. Furthermore, OSVVM is providing a TCL based plumbing.
To preach to the quire, I think standardizing a JSON/similar format for HDL/IP files that can be used for building and simulating with multiple tools would be hugely beneficial. We've had this conversation multiple times, but this is just another thing that format would benefit.
We've had this conversation multiple times, but this is just another thing that format would benefit.
I've been lately looking into fusesoc more seriously. You know, always more things to do than spare time... But the point is that having any tool other than edalize use fusesoc would be the first step for making fusesoc's format that unified/standard JSON we need. That other tool can be GHDL, VUnit, tsfpga, PyFPGA, any...
type integer_array_t is array (natural range<>, natural range<>) of integer;? You cannot directly append a 1D array to that because it would be type integer_vector_t is array(natural range<>) of integer, but you could write a function/procedure to append.
If you use your vector type in the 2D declaration like this
type integer_vector is array(natural range<>) of integer;
type integer_vector_2d is array(natural range<>) of integer_vector;Then it would work, you could also do it with subtype. The above I'm pretty sure is only valid in 2008+.
Since VHDL does not allow dynamically changing the size of the objects, no matter how you do it, a new object needs to be created. Now, the question is: does VHDL provide enough language features for the following?
- Get the ranges of a multidimensional array.
- Create a new multidimensional array by adding the ranges of multiple existing multidimensional arrays.
- Traverse the rows/columns of a multidimensional array and assing them to another multidimensional array.
My understanding is that something similar to the following should be possible:
type integer_array_2D_t is array (natural range <>, natural range <>) of integer;
type integer_array_1D_t is array (natural range <>) of integer;
signal 2Darr : integer_array_2D_t(0 to 5, 0 to 10);
signal 1Darr : integer_array_1D_t(0 to 10);
signal merge : integer_array_2D_t(2Darr'range(0)'left to 2Darr'range(1)'right + 1, 2Darr'range(1));
begin
merge(2Darr'range(0), 2Darr'range(1)) <= 2Darr;
merge(2Darr'range(0)+1, 1Darr'range) <= 1Darr;If you wanted 2Darr to hold the new (larger) matrix, 2Darr would need to be an access type. Unfortunately, it is currently not possible to get an access from merge (IEEE-P1076/VHDL-Issues#14). Hence, that would also need to be an access type. All this makes it hard to track/understand for synthesis.
Nevertheless. Using accesses for having "dynamic arrays/vectors" is wat VUnit does internally. You have many examples about it in the codebase.
With regard to multidimensional arrays, slices, etc. see:
- ghdl/ghdl#1455
- IEEE-P1076/VHDL-Issues#15 (needs to be updated, since Patrick provided some guidelines about valid VHDL 2019 syntax for implementing some of the features mentioned there)