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

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]

HansWernerMarschke@web.de wrote:

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

 

[Jonathan Bromley]

On Sat, 10 May 2008 05:24:55 -0700 (PDT),
HansWernerMarschke@web.de wrote:

I have one shared variable inside an architecture.
shared variable the_enigma : enigma_type;
I want to use this variable in some procedures
[...]
I´m lost in VHDL

As someone else has pointed out, you're acting like
a software person. That's fine if you want to
use VHDL as a concurrent programming language,
but it seems likely that you're trying to describe
hardware and so it is quite inappropriate to write
software-like descriptions.

A traditional program in a structured but non-OO
language, such as Pascal or C, will have a pool of
shared data (which you must take great care to
design sensibly, as you are evidently aware) and
a bunch of co-operating subprograms that can access
that pool of data whenever they happen to execute.

That model is disastrously inappropriate for hardware.

Since you're using ISE, you are presumably trying to
target Xilinx FPGAs. Like any other modern FPGAs, they
expect you to write logic that is mainly SYNCHRONOUS.
In other words, you describe hardware in terms of a
current-state/next-state model. There is a bunch of
storage which, in hardware, is distributed across the
chip; at each active clock edge, this storage is updated
to hold its new, next-state value. The next-state value
is computed from the current state and the inputs using
combinational logic, which you can describe in various
ways using VHDL.

If you're planning to model your Enigma machine in
hardware, you must decide how to think of it as a
current-state/next-state machine. What will happen
on each clock tick? And then you start making the
really hard choices - choices that form the real
meat of hardware design: Can you do one step of the
machine's operation on each clock tick? Or is that
operation sufficiently complicated that you must
spread each step of the conceptual machine's operation
across a number of clock ticks? If the latter, how
will you design the control state machine that will
orchestrate the various sub-steps in that operation?

Each rotor of the Enigma machine is an independent
piece of real hardware. Consider modelling it as such.
It has a fixed structure (its internal cross-connections)
and a state (its current position). At each stage of
the machine's operation, the current state of the machine
(positions of all rotors) and current inputs (keyboard) work
together, through a further computational step represented
by the plug-board, to determine a set of outputs (lighted
symbols). These outputs have two purposes: they provide
the real encrypted or decrypted output of the machine,
and they specify what the next state of the machine
(new position of the rotors) will be.

In other words, the set of rotors and their positions
is not a pool of data that your program should manipulate.
It is a collection of independent hardware functional
units, and should be modelled as such. That's the nature
of hardware design. Right now, the message is coming
across loud and clear that you are trying to translate
an existing piece of software into VHDL, and expecting it
somehow to map to hardware. The world doesn't work like
that; this is the reason why hardware design remains a
valuable skill. In a few well-defined areas such as
DSP filter design, tools exist that can map purely
software-like descriptions (often coded in C or C++)
to viable hardware. For general logic problems, however,
we are still a long way from that level of automation.

To answer (partly) your original question: shared
variables make little sense as a hardware idiom, although
some tools can support them in a few special cases.
Learn how to use signals and processes to model hardware
functional blocks, and learn how to use VHDL instance
hierarchy to model the organisation of multiple blocks
into a larger system. If you're trying to use a shared
variable in your hardware description, your design
strategy is fatally flawed and needs to be ripped up
and re-done.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Brian Drummond]

On Sat, 10 May 2008 22:06:32 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Sat, 10 May 2008 05:24:55 -0700 (PDT),
HansWernerMarschke@web.de wrote:

I have one shared variable inside an architecture.
shared variable the_enigma : enigma_type;
I want to use this variable in some procedures
[...]
I´m lost in VHDL

A traditional program in a structured but non-OO
language, such as Pascal or C, will have a pool of
shared data (which you must take great care to
design sensibly, as you are evidently aware) and
a bunch of co-operating subprograms that can access
that pool of data whenever they happen to execute.

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.

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.

(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.

Since you're using ISE, you are presumably trying to
target Xilinx FPGAs. Like any other modern FPGAs, they
expect you to write logic that is mainly SYNCHRONOUS.
In other words, you describe hardware in terms of a
current-state/next-state model.

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

It wakes up when the appropriate stimulus arrives (in the simplest
cleanest style, that is "rising_edge(clock)"), reads and processes new
input data on its input SIGNALS, updates internal variables, including
state variables, then it generates output SIGNALS (to communicate to
other processes), and at the appropriate time, it puts itself to sleep,
either by reaching its end, or by an explicit "wait" statement.
In the process, like any main event loop, it can call procedures and
functions, which have to obey sensible conventions regarding the
visibility of variables and signals.

With this in mind, read Jonathan's post carefully...

- Brian

 

[Mike Treseler]

That model is disastrously inappropriate for hardware.

Brian Drummond wrote:

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

>

 

On May 11, 12:27 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

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.
--
Jonathan Bromley
(out of reach of his usual news server).

 

[Brian Drummond]

On Sun, 11 May 2008 15:52:10 -0700 (PDT), spam@oxfordbromley.plus.com
wrote:

On May 11, 12:27 pm, Brian Drummond <brian_drumm...@btconnect.com
wrote:

(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

True ... but for this purpose, it is sufficient to say that's what
signals do; that is the key difference between them and variables.

Master them, and your approach of interacting functional blocks becomes
easy.

I wish I knew of a good introduction to the signal assignment and
scheduling rules, which (used with a synchronous process) guarantee
predictable communications. But this is one of the (IMO relatively small
set of) topics the OP needs to learn.

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.

True, and Mike's IRQ handler is a good example.
The VHDL process can also accept many different events (see "sensitivity
list") but for good synchronous (clocked) design style we restrict
ourselves to one "clock" event (and possibly "reset" for
initialisation). Having woken up, it can then inspect signals to decide
which of multiple events need processing. (like Mode 2 interrupts on a
Z80)

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 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...

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.

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

Brian, thanks for the thought-provoking post.

Thanks for your comments,

- Brian

 

[Mike Treseler]

Brian Drummond wrote:

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.

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.

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