Le 2014-04-11 09:57, Martin Strubel a écrit :
Hi there,
Hallo Martin !
just a follow up, I've been experimenting on this field
Tell us more about it :-)
and found no way
to access a shared variable array either.
it's surprising.
When you know the address of the shared variable, you can do what
you want. The latest messages on the list should give you enough
informations.
So the workaround was, to
emulate it all in C. Typical use case is a virtual RAM, which
initializes like:
----------------------------------------------------
type rambuf_t is access integer;
...
process
begin
ram_handle := ram_new(simulation'path_name, , ADDR_W);
...
----------------------------------------------------
you could just use a "new", all in VHDL.
you should know however that GHDL's arrays are actually descriptors
(a small "record") that gives the bounds, as well as the pointer
to the actual data.
Inside the clock sensitive process are calls to a ram_write() and
ram_read() function implemented in C. So the rambuf_t is just a
anonymous handle (C world: pointer) to VHDL.
if you use the "new", all-VHDL approach, you spare ram_write() and
ram_read() :-)
Now comes the question of providing the address of the VHDL function
to
signal(), without objdump.
That sounds like much digging in the dirt :-)
at least something I'm good at ;-)
I think that doing the framebuffer and the environment variable code
was way worse, but the payoffs are great.
I've had issues with a crashing GHDL at some point when manipulating
stuff from another thread through the VPI interface. So the only stable
variant for me turned out to separate the C / VHDL stuff as much as
possible and use some variable exchange procedures as interface that
are
guarded by mutexes. Actually, this would be a nice starting point to
think about multithreading tricks with GHDL (that best being another
'thread' :-) )
I think you found the hard way that GHDL is not thread-safe ;-)
This is why I go to these extreme dirt-digging exercises,
I add a high-level communication protocol (with timing management)
and I do all I can to keep the whole program in one thread.
As a result, I do some manual "multitasking" but at least I'm sure
I don't create race conditions and I avoid any interference with the
GRT.
Hopefully it will be published within a few months and everybody
will enjoy it :-)
Greetings,
thanks for the follow up :-)
- Martin
yg
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
