Variable is interpreted as signal ???

At the moment it is a little bit raw.
It´s my first try to program in VHDL.
See the lines below.
The architecture includes the following two lines.
I get the error message "Signal is not defined 'the_enigma'.
It is declared as shared variable.
So what is wrong ?
It is better to declare all ports only as std_logic or
std_logic_vector ?
Or is it also ok to use bit or character ?

Good night


the_enigma.alphabet := alphabet;
the_enigma.chars := alphabet'length;



library IEEE;
library STD;

use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_TEXTIO.ALL;

-- Don´t use this two one
-- use IEEE.STD_LOGIC_ARITH.ALL;
-- use IEEE.STD_LOGIC_UNSIGNED.ALL;
-- Instead use this
use IEEE.numeric_std.all;


entity enigma is
generic (wheel_one : in integer := 3; stepsize_one : in
integer := 2; start_one : in integer := 1;
wheel_two : in integer := 5; stepsize_two : in integer := 3;
start_two : in integer := 1;
wheel_three : in integer := 7; stepsize_three : in integer := 1;
start_three : in integer := 1);
port (input : in std_logic; output : out std_logic; mode : in
bit);

-- The wheel type
subtype char_index is integer range 0 to 30;
type wheel_string is array (char_index'left to char_index'right) of
character;
subtype wheel_index is integer range 0 to 11;
type wheel_array is array (wheel_index'left to wheel_index'right) of
wheel_string;

-- The rotor type
type rotor_type is
record
wheel_number : wheel_index;
wheel : wheel_string;
start : char_index;
stepsize : char_index;
position : char_index;
end record;

-- The rotor array
type rotor_array is array (0 to 2) of rotor_type;

-- The enigma type
type enigma_type is
record
chars : integer;
alphabet : wheel_string;
rotor : rotor_array;
end record;
-- This is the only global variable
-- Must be declared as "shared" to use it global
shared variable the_enigma : enigma_type;
end enigma;

 

[Brian Drummond]

On Fri, 9 May 2008 15:04:27 -0700 (PDT), HansWernerMarschke@web.de
wrote:

At the moment it is a little bit raw.
It´s my first try to program in VHDL.
See the lines below.
The architecture includes the following two lines.
I get the error message "Signal is not defined 'the_enigma'.
It is declared as shared variable.
So what is wrong ?
Variables - presumably including shared variables - can only be used

within a process. (Shared variables, obviously, can be accessed in
different processes). It looks as if these assignments are outside a
process.

You may find that the_enigma is better declared to be a signal.
Shared variables will work in simulation, but I don't know how well they
are supported for synthesis; that may depend on hte synthesis tool you
use. (XST sometimes supports features others don't; but the reverse is
more common)

It is better to declare all ports only as std_logic or
std_logic_vector ?
Or is it also ok to use bit or character ?

You can use any types in ports.

However, for the top level of an entity for synthesis (e.g. the entire
Enigma machine) it is normal to restrict port types to
std_logic[_vector], even over the numeric_std types. The main reason is
because the synthesis tool can generate another VHDL
entity/architecture, representing the same design after synthesis (or
another, after place&route), and in these versions, the port types will
be converted to std_logic[_vector]. They are called "gate level" or
netlists, because they describe the same function at the lowest level of
detail, in fundamental blocks like gates.

If you want to test the synthesised design, you can simply drop these
"gate level" architectures into your simulation and verify they work.

If you want to keep other port types at the top level, you can write a
wrapper entity/architecture for a clean interface between your ports and
the "gate level" std_logic_vector versions, but most people don't
bother.

- Brian

 

[Mike Treseler]

kennheinrich@sympatico.ca wrote:

VHDL is fundamentally a language for describing concurrent execution
of a model.

I disagree.
The hardware objects, the gates and flops, operate concurrently.
The *description* of this operation can be sequential or structural.
VHDL covers both description styles.

In VHDL, the language forces you to use shared variables or
signals ...

.... or a single clocked process.
Some examples:

http://mysite.verizon.net/miketreseler/


-- Mike Treseler

 

On Fri, 9 May 2008 15:04:27 -0700 (PDT), HansWernerMarsc...@web.de
wrote:

At the moment it is a little bit raw.
It´s my first try to program in VHDL.
See the lines below.
The architecture includes the following two lines.
I get the error message "Signal is not defined 'the_enigma'.
It is declared as shared variable.
So what is wrong ?

It's pretty clear that the OP has more software background than
hardware. So I'll try to slant an answer with a software aspect, to
both this and a previous post.

VHDL is fundamentally a language for describing concurrent execution
of a model. When written in a certain way, it can also lend itself to
synthesising hardware. If you intend it to go into an FPGA, you need
to limit yourself to certain "design patterns" within the language. If
you only want to go as far as simulation, you can take advantage of
the "more esoteric" language features. If you want to build an FPGA,
make sure you're clear in your posts that you want to synthesise the
code, not just simulate it.

Variables and signals are two different but related concepts in VHDL.
They're so different that they even get different assignment symbols
= vs <=).

Variables are like regular variables in "C" or some other language,
but since every VHDL process is analagous to a concurrent thread (or
process) in S/W, you get all sorts of problems if you have multiple
processes accessing them (race conditions, non-atomiticity, etc). In
software you use locks or semaphores or mutextes to make things work
right. In VHDL, the language forces you to use shared variables or
signals. With a shared variable, you might expect the compiler to
insert some mechanism of mutex or just do the right thing for you. A
VHDL *simulator* can usually do the right ting with shared vars, but
most synthesisers don't have a way to turn your intent into a real
hardware interlock. Plus, you still have the simulation issue of non-
deterministic execution order of processes. So we come to signals.

Signals are more like an interprocess communication channel. In
simulation, this means all sorts of fancy semantics about handling
mutiple assignments, and resolving multiple process writes, etc. But
the rules are geared toward a hardware-centric view of the world, so
that in most cases the signal resolves to what is logically nothing
more than a wire. This is usually all you need to think of when
writing code.

The poster asked "So what is wrong?". Assuming you want to synthesise
the code:

- figure out the dataflow timing of your circuit
- use signals and one master clock to make the data flow, instead of
global variables. Read up on "synchronous design" and "synchronous
state machine".
- as mentioned, make the top level of your herarchical design have
std_logic(_vector) ports. If you think you might need to simulate sub-
blocks are a low level for testing, make sure they have std_logic
based ports as well

As a software habit, it's good to bundle all of your data into one
nice record as shown (like "the_enigma"). The trade-off you make in
VHDL is that you will have to update the entire signal in one process,
which makes it more difficult to construct a modular sub-component
based design without doing a certain amount of wrapping and
unwrapping. If you want both a single record type to encapsulate the
state, and modular design, you may have to take the modules'
individual outputs on separate signals and then merge them together in
one wrapper process to generate the updated state record signal.

Hope this helps,

- Kenn

 

[Mike Treseler]

kennheinrich@sympatico.ca wrote:

Point taken. What I was trying to convey, is that VHDL has the normal
sequential stuff of most imperative programming languages, but whose
main extension beyond this is support for concurrent constructs
required to model real hardware.

What I am trying to convey is that concurrent constructs
are *not* required to model or synthesize real hardware.
I can put an entire design in one process
if I so choose.

This extension (or more properly, the
concurrency that most hardware guys understand in their gut from day
one) is where the "I know C, I'll just rewrite it in VHDL" software
types often get tripped up.

The C guy needs to understand the synthesis objects.
The hardware guy needs to understand
variables, functions and procedures.

-- Mike Treseler

 

On May 10, 11:14 am, Mike Treseler <mtrese...@gmail.com> wrote:

kennheinr...@sympatico.ca wrote:
VHDL is fundamentally a language for describing concurrent execution
of a model.

I disagree.
The hardware objects, the gates and flops, operate concurrently.
The *description* of this operation can be sequential or structural.
VHDL covers both description styles.

Point taken. What I was trying to convey, is that VHDL has the normal
sequential stuff of most imperative programming languages, but whose
main extension beyond this is support for concurrent constructs
required to model real hardware. This extension (or more properly, the
concurrency that most hardware guys understand in their gut from day
one) is where the "I know C, I'll just rewrite it in VHDL" software
types often get tripped up.

- Kenn

 

Thank's for all answers.
My view was that a signal is only something analog but not a complex
data structure.
So a signal can also be a data structure ?
No, I think that is also wrong.
I feel a little bit confused.
Till now I haven´t seen some kind of interaction or conversion from a
signal to a data structure.
The most examples handle something like shift register, adders,
comparators where you don´t need a data structure.
I hope it will get clearer if I own the book of Peter Ashenden, the
2008 version of Designers Guide to VHDL.
At the moment I´m running a simulation with the Xilinx ISE simulator
and try to understand what is happening.
For what do I need a clock ??

Hardware is really hard to understand.

 

[Mike Treseler]

HansWernerMarschke@web.de wrote:

So a signal can also be a data structure ?

package stack_pkg is
constant reg_len_c : positive := 32;
constant array_len_c : positive := 32;
subtype reg_t is std_logic_vector(reg_len_c-1 downto 0);
type regs_t is array (0 to array_len_c-1) of reg_t;
constant reg_init_c : reg_t := (others => '0');
end package stack_pkg;

A data structure is a type.
A signal or variable *has* a type.
A signal or variable of type regs_t
could represent a set of 32 bit registers.

For what do I need a clock ??

To make a synchronous process.

-- Mike Treseler