Skip to content

[2/3] Add external modes to string_ptr and integer_vector_ptr (through VHPIDIRECT) #476

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
eine merged 4 commits into from
Oct 28, 2019
Merged

[2/3] Add external modes to string_ptr and integer_vector_ptr (through VHPIDIRECT) #476

eine merged 4 commits into from
Oct 28, 2019

Conversation

@umarcor
Copy link
Member

@umarcor umarcor commented Apr 15, 2019 •
edited
Loading

Based on #482 and #507.
Refs #462, #465, #470.

@kraigher wrote:
So in this case the first task becomes to add a dynamic byte array data type to VUnit that can have an external implementation in a C-object. It is easier to review if such a task is done in isolation as a separate PR.

In this PR, external modes are added to integer_vector_ptr.vhd, following the same approach as in #507.

In order to support using *_ptr with or without VHPI, two different implementations of the external resources are provided. One of them, external_*_pkg-vhpi.vhd, declares the functions/procedures as external; therefore, C implementations must be provided. The other one, external_*_pkg-novhpi.vhd does not declare the functions/procedures as external; C implementations are not required, but it is not possible to create vectors with id/=0 (an assertion of level error is raised).

The list of objects is added through set_sim_option("ghdl.elab_flags", ["-Wl," + " ".join(files)]).

An example is added, external_buffer, to test accessing the same external buffer/array using two methods. The external C application allocates a buffer of length 15 and writes to the first 5 positions. In the VHDL testbench, two integer_vector_ptr are created. The first one is used to copy the first five elements to positions 5-9. And the second one is used to copy data from positions 5-9, to positions 10-14. The C application prints all the positions before and after the execution of the simulation.

deallocate, reallocate and resize are not implemented for external models. For the case id>0, it would be easy to implement it. Since the 'connection' is a pointer, it is possible to use malloc or mmap in the C implementation. Coherently, it would be possible to update the length in the VHDL model according to the actual size in the C app.

However, when extfnc, it can be complex or not possible. Since read_byte/write_byte can be used to interact with external services/processes through pipes, sockets, packets, messages, etc., the implementation is likely to be very specific. Nonetheless, in this example the implementation can be the same for both 'access' modes.

ghdl/ghdl#797

@umarcor umarcor force-pushed the feat-external-arrays branch from 3176f13 to 9b78114 Compare April 15, 2019 04:07
@umarcor umarcor mentioned this pull request Apr 15, 2019
Draft
kraigher
kraigher requested changes Apr 15, 2019
View reviewed changes
@umarcor umarcor force-pushed the feat-external-arrays branch from 7a87834 to 3ab1f43 Compare April 16, 2019 06:18
@umarcor umarcor mentioned this pull request Apr 17, 2019
Closed
3 tasks
@umarcor umarcor force-pushed the feat-external-arrays branch 6 times, most recently from 40fbe06 to 4cc4cd9 Compare April 19, 2019 05:06
@umarcor
Copy link
Member Author

umarcor commented Apr 19, 2019

@kraigher, I am having problems to automatically load the data types when the user does not do it neither explicitly (add_external_arrays()) nor implicitly (through add_verification_components()).

Currently, only the first call to add_external_arrays() is effective; all other calls are ignored. When the user calls it explicitly, the user settings are used. When it is called implicitly through add_verification_components(), *-novhpi.vhd versions are used.

I tried to add self._add_external_arrays() in add_vhdl_builtins(). The issue is that this is executed as soon as the vu instance is created in the run.py, so later explicit or implicit calls by the user are ignored. As a results *-novhpi.vhd are always used.

Where should I add builtins._add_external_arrays() so it is always executed before vu.main() but after the user has optionally configured it?

@umarcor umarcor force-pushed the feat-external-arrays branch 4 times, most recently from fc6d8b4 to 2db197b Compare April 20, 2019 05:03
This was referenced Apr 20, 2019
Closed
Draft
@umarcor umarcor force-pushed the feat-external-arrays branch from 2db197b to 8bea441 Compare April 20, 2019 21:42
@umarcor
Copy link
Member Author

umarcor commented Apr 20, 2019 •
edited
Loading

Where should I add builtins._add_external_arrays() so it is always executed before vu.main() but after the user has optionally configured it?

I solved it by saving and checking self._compile_builtins = compile_builtins.

This PR is now based on #482.

@umarcor umarcor force-pushed the feat-external-arrays branch 6 times, most recently from 9a9b74b to b93d64b Compare April 21, 2019 10:29
@umarcor umarcor mentioned this pull request Apr 21, 2019
Closed
@umarcor umarcor force-pushed the feat-external-arrays branch 3 times, most recently from 6ae075b to eb9c94d Compare April 22, 2019 09:18
@umarcor umarcor force-pushed the feat-external-arrays branch 11 times, most recently from 88441e4 to a5ef2cb Compare September 13, 2019 03:07
@umarcor umarcor mentioned this pull request Sep 17, 2019
Merged
@umarcor umarcor force-pushed the feat-external-arrays branch 2 times, most recently from de9113e to abc4b53 Compare October 7, 2019 03:16
@umarcor umarcor force-pushed the feat-external-arrays branch 2 times, most recently from 464afc7 to f8f2351 Compare October 13, 2019 04:16
@umarcor
Copy link
Member Author

umarcor commented Oct 13, 2019 •
edited
Loading

Now that #507 is merged, I moved all the content related to VUnitCoSim to #568, so this PR is just a follow-up:

Note that vhpidirect_user.h is the API for foreign processes (Python, Octave, etc.) loading the binary generated by GHDL. Future contributions might add alternative external*.vhd and matching reference C sources for other simulators, such as ModeSim/QuestaSim's FLI, which match the API.

@umarcor umarcor marked this pull request as ready for review October 13, 2019 04:29
@umarcor umarcor mentioned this pull request Oct 13, 2019
Draft
1 task
@umarcor umarcor force-pushed the feat-external-arrays branch from f8f2351 to bec5fe9 Compare October 13, 2019 18:08
@umarcor umarcor requested a review from kraigher October 21, 2019 12:47
@umarcor umarcor force-pushed the feat-external-arrays branch from bec5fe9 to 4e9b786 Compare October 28, 2019 01:08
@umarcor umarcor force-pushed the feat-external-arrays branch from 4e9b786 to 2b002fc Compare October 28, 2019 01:14
@eine eine merged commit edc7609 into VUnit:master Oct 28, 2019
@umarcor umarcor deleted the feat-external-arrays branch October 28, 2019 02:02
@eine eine added the CoSim label Feb 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@kraigher kraigher Awaiting requested review from kraigher

Assignees

No one assigned

Labels

CoSim

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@umarcor @kraigher @eine