Newbie. I´m not able to use shared variables !

[HansWernerMarschke]

I have one shared variable inside an architecture.

shared variable the_enigma : enigma_type;

I want to use this variable in some procedures located inside the
architecture.
I get the warning:Xst:1960
Xilinx says that there is a workaround:

7.1i XST - "WARNING:Xst:1960 - file.vhd line xx: Potential simulation
mismatch, variable yy declared in block blck1 is assigned in block
blck2"

Solution

To work around this issue, avoid sharing the variable with multiple
procedures inside a function. That is, pass the value of the variable
that is declared in the function to a variable that is declared
locally within the procedure.

But how should this help ? If I pass back the local variable to the
shared (global) one I get the same error.
So how can I use a procedure on a shared variable ?

I´m lost in VHDL

 

[Mike Treseler]

I have one shared variable inside an architecture.
shared variable the_enigma : enigma_type;

Learn about protected types.

To work around this issue, avoid sharing the variable with multiple
procedures inside a function. That is, pass the value of the variable
that is declared in the function to a variable that is declared
locally within the procedure.

In a single process, regular variables may be shared.

-- Mike Treseler

 

[Mike Treseler]

That model is disastrously inappropriate for hardware.

I disagree in this sense : it can be appropriate within a single
process, in hardware. And this is presumably Mike Treseler's rationale
for doing as much as possible within a single process.

Yes. Wires can't be avoided at the top,
but they are optional at the bottom.

In this sense hardware and software are more alike than you suggest :
the co-operating C or Pascal subprograms sharing data are also operating
within a single process - therefore the variables may be shared between
them; they are local to the process. This is like NON-shared variables
in VHDL.

And process variables provide 'wireless' communication
between procedures. Downstream procedures can
respond to a flag on the same clock edge.
Upsteam procedures will see it on the tick.

Writing a synchronous process for hardware is like writing an event loop
in software.

I'll be darned.
There is another fpga guy who has written an IRQ routine.
Thanks for the posting.

-- Mike Treseler

 

[Guest]

That [shared-data]
model is disastrously inappropriate for hardware.

I disagree in this sense : it can be appropriate within a single
process, in hardware. And this is presumably Mike Treseler's rationale
for doing as much as possible within a single process.

Fair enough.

In this sense hardware and software are more alike than you suggest :
the co-operating C or Pascal subprograms sharing data are also operating
within a single process - therefore the variables may be shared between
them; they are local to the process. This is like NON-shared variables
in VHDL.

A nice point.

(to Hans) If you are communicating between processes, in C, you cannot
simply share variables; you might open pipes between two processes. This
is (VERY roughly) equivalent to using signals in VHDL, though signals
are a lot easier to use.

Also a very nice point, although it opens what could turn into
a VERY long discussion of models of computation

Writing a synchronous process for hardware is like writing an event loop
in software.

Except that it's an event loop that knows about only one event,
whereas the software folk tend to use event loops when they
have lots of different events arriving at unpredictable times.
Nevertheless, it's a very helpful insight that I should have
mentioned myself - many thanks.

It's intriguing... I occasionally find myself teaching
hardware folk about event-driven programming, usually in
the context of writing Tcl/Tk scripts where the event
loop is a way of life. I generally find myself saying
"it's a bit like a state machine..." So I guess you're
right, there's more commonality than my earlier post
suggested.

I nevertheless stand by my advice to the OP that he
should try to think of the system as a bunch of
interacting functional blocks. I think it would help
him to get into a more hardware-friendly mindset.

Brian, thanks for the thought-provoking post.

 

[Mike Treseler]

I wonder if there is anything to learn in the other direction, now that
software engineers are being presented with multiple cores, but still
taught to program in a strictly serial paradigm.

Nearer home, won't it be nice when VHDL simulators start scheduling all
these processes we're writing across all available cores to speed up
simulation...

Modelsim combines processes that have
the same clock and reset structure.
While tracing code of my multiple clock processes,
I discovered this, and decided I ought to
just write my code this way in the first place.

Purchased cores vary widely on reset structure.
Some brand-X specific code avoids reset
to match LUT shifters.

No argument there! By pointing out where I see parallels with SW, I
hope to help him see how to get towards that mindset.

I may have this backwards, but this is why
I include rtl viewer schematics with my examples.

-- Mike Treseler