Add packageless intvector generic example (#5 c)

[radonnachie]

In order to create an easy ramp through the rest of the examples, it felt that an example of int array passing (with an interface generic defining the array size) without packages was needed.

This is #5 c

#6 (comment)

1. #5a (No packages, int array passing)
2. #5c (No packages, int array, generic passing)
3. quickstart/logicvector example (Bounded) #6 (No packages, logic array passing)
4. vhpidirect: add 'quickstart/package' #7 (Packages)
5. quickstart/matrices: 2D constrained/bound array of reals/doubles #10 (Packages real array passing)
6. quickstart/sharedvar Example (Set Package shared variable) #4 (Packages, shared integer access)
7. #5b (Generic Packages, int array passing)
8. cinterface/intro Example (Header intro) #8
9. Updated Header: std_u/logic, N Dim unconstrained arrays. #3

[radonnachie]

@umarcor Ah shucks.. this and #11 should have been against the ghdl/ghdl-cosim.... but it feels so unnatural to put it there. Does this just create more work for you? Because I can instead create the PR there... /:

[umarcor]

It's ok. Since we are making so much (justified) noise by cross-talking through multiple PRs, I prefer to have this set of PRs handled here. For other more general modifications, such as specifying that booleans are considered enums, you'd better target ghdl/ghdl-cosim, as it is easier for any other potential contributor to understand the context.

Regarding this specific issue, I think it fits together with 5a (#11). As I suggested in https://github.com/umarcor/ghdl-cosim/pull/11/files#r410413328, 5a should be the most compact way to share a constrained array, without defining any dimension in VHDL. 5aa would be the same, but using a main. This, would be the opposite: how to share a constrained array, without defining any dimension in C. Hence getIntArr_ptr would be allocateIntArr (which would malloc), and there would a separate function, say initRandomIntArr, to initialize the content of a given array from C.

[radonnachie]

Yeah, I like the idea of the Interface Generic setting the size of the C array... makes things more reasonable. Will work it.

I do feel that the allocateIntArr could just initialise the array with the classic 11*(i+1) jazz. I'll make it that subsequent calls will free the pointer and (if the size > 0) re-malloc, and re-fill.

Otherwise it feels like vhdl will be able to create more than one malloc'd array and each new one would need to be kept track of in a dynamic array of pointers, to be freed at the end. Possible but a little excessive when we are just trying to show generics defining vector bounds, no? Have I misread you completely?

See the caux.c file. I think you'll be happy with it.

[radonnachie]

Merged into #11

[umarcor]

I do feel that the allocateIntArr could just initialise the array with the classic 11*(i+1) jazz. I'll make it that subsequent calls will free the pointer and (if the size > 0) re-malloc, and re-fill.

This is a different (more advanced) use case, in the sense that two different features are merged in a single function. Users might want to allocate an array and fill data from VHDL only. By the same token, they might want to allocate the array in VHDL and have C fill the data for them. Having four different subprograms (allocate in VHDL, allocate in C, fill in VHDL, and fill in C), we can show multiple combinations. For now, we are covering "allocate in C and fill in C" only.

The case "allocate in VHDL and fill in VHDL" (but have access to it from C) is relevant for examples mmap2img or xvga from hwd-ide. In essence, everything should work as if no VHPIDIRECT resources were used. However, the buffer is accessed from C because we want to have "fancy printing" procedures (respectively, print buffer to RAW image file, or print buffer to X11 window). In this context, there is no point in C filling the buffer with any data at all.

Cases "allocate in C but fill in VHDL" and "allocate in VHDL but fill in C" might be suitable for complex co-execution schemes. For example, in VUnit/vunit#603 the discussion is about how to make those cases equivalent from the user's point of view. If not possible, which should be preferred.

NOTE: I will add (the content of) these paragraphs above to the docs of this example if you wish.

IIRC, there was some project that allowed to use C's printf from VHDL through VHPIDIRECT. It'd be interesting to find it.

Otherwise it feels like vhdl will be able to create more than one malloc'd array and each new one would need to be kept track of in a dynamic array of pointers, to be freed at the end.

Yes, I think that's the idea. If a single malloc was done and it didn't keep track of a list of pointers, I felt the example would be exactly the same as quickstart/sharedvar (https://github.com/umarcor/ghdl-cosim/pull/13/files#diff-f3a1cfe7331c38f78ff54bf8f3f2c1bc), but using a pointer to a bounded array instead of a pointer to an integer. However...

Possible but a little excessive when we are just trying to show generics defining vector bounds, no?

I see your point. Let's keep this example as is, just splitting allocation and initialization. Then, we can add a shintvectors as done with shint.

[radonnachie]

use C's printf from VHDL

Because the executable is compiled with the standard C libraries it would just be a vhpidirect declaration no?

okay

procedure printf(str: String) is
	begin
		assert false report "printf VHPI" severity failure;
	end printf;
	attribute foreign of printf: procedure is "VHPIDIRECT printf";

prints pure garbage.... But a defined char array is very clean...... must be those pesky bounds coming before the data array...

[umarcor]

On the one hand, there is the issue of unconstrained arrays (strings). That's why you get garbage, but it works with a "hardcoded" string. On the other hand, the complexity is not to map it, but how to handle the variable number of arguments that printf can accept. Definining different helper functions for different number and types of arguments seems not acceptable...

[umarcor]

@RocketRoss, see suoto/hdl_string_format.