problem with sll operator

[Marios Barlas]

Hello,

I am facing a pretty wierd error as regards an operation which is pretty crutial for my code.

I am trying to do a left shift operation on an unsigned vector. My NBITS is defined generically as natural and my delta vector is unsigned. All compiles well but when iŕm doing the simulation my delta_shifted receives X values. for me that seems to suggest that the sll operation is not performed. Any1 has an idea as to where the problem could be ?

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.ALL;

entity sqroot_comb is
generic (constant NBITS : natural := 8); --design implementation
port (
signal arg : in std_logic_vector(NBITS-1 downto 0);
signal roundup : in std_logic := '0'; --determine if roundup is done or not
signal sqroot : out std_logic_vector(NBITS/2 downto 0));
end entity sqroot_comb;

architecture rtl of sqroot_comb is
use ieee.std_logic_1164.all;
use ieee.numeric_std.ALL;

--Internal signal definitions
signal delta : unsigned(NBITS-1 downto 0);
signal delta_shifted : unsigned(NBITS-1 downto 0);
signal delta_shifted_prev : unsigned(NBITS-1 downto 0);
signal res : unsigned(NBITS-1 downto 0);
signal res_prev : unsigned(NBITS-1 downto 0);
signal sqroot_temp_prev : unsigned(NBITS-1 downto 0);
signal sqroot_temp : unsigned(NBITS-1 downto 0);

--Signal Assignments

begin

delta <= to_unsigned(2**(NBITS-2),delta'length);
sqroot_temp <= to_unsigned(0,delta'length);
sqroot_temp_prev <= to_unsigned(0,delta'length);
delta_shifted_prev <= to_unsigned(0,delta'length);
res_prev <= to_unsigned(0,delta'length);

delta_shifted <= (delta sll NBITS-2); -- shifted // temp = delta^(NBITS-2)
res <= unsigned(arg);

process( arg, roundup )

--Internal variable definitions
--variable delta_int : integer := 1;
--variable sqroot_int : integer :=0;
--variable res_int : integer := to_integer(unsigned(arg));

begin

for i in 0 to 2*NBITS-1 loop
if (delta_shifted >= 1) then
if ( (sqroot_temp + delta_shifted) <= res ) then
res <= res -(sqroot_temp + delta_shifted);
sqroot_temp <= sqroot_temp + 2*delta_shifted;
else
sqroot_temp <= sqroot_temp_prev;
res <= res_prev;
delta_shifted <= delta_shifted_prev;
end if;
end if;

sqroot_temp <= sqroot_temp/2;
delta_shifted <= delta_shifted/4;

--Update previous values of sqroot and residual
sqroot_temp_prev <= sqroot_temp;
res_prev <= res;

end loop;

if ( (roundup = '1') and (res > sqroot_temp) ) then
sqroot_temp <= sqroot_temp + 1;
else
sqroot_temp <= sqroot_temp_prev;
end if;

sqroot <= std_logic_vector(resize( sqroot_temp,sqroot'length ));

end process;

end architecture rtl;

 

[Marios Barlas]

Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:

Hello

Le 14/11/2014 21:22, Marios Barlas a ĂŠcrit :
Hello,

I am facing a pretty wierd error as regards an operation which is pretty crutial for my code.

I am trying to do a left shift operation on an unsigned vector. My NBITS is defined generically as natural and my delta vector is unsigned. All compiles well but when iĂ m doing the simulation my delta_shifted receives X values. for me that seems to suggest that the sll operation is not performed. Any1 has an idea as to where the problem could be ?

You have a conflict on delta_shifted. You have a concurrent assignment
(6th assignment after the architecture's "begin") and you assign values
to it in the process.
You're from a computer programming background, aren't you ?

Nicolas

Thanks for your answer. Sadly nope. I'm a physicist but I'm finishing a 2 years master's in nanotechnology the last semester of which is in microelectronics. As a result us stupid physics people lack a good deal of background that others have for granted. This is my first bit of code in VHDL. Apologizing for my ignorance in advance, I am guessing you are referring to

delta_shifted <= delta sll NBITS-1

but this is exactly what I would like to do, shift the bits of my vector representation to the left. I was under the impression that sll would basically shift the bits to the left adding zeros on the right-most columns. Also the comment above seems logical, I probably need more bits so that I won't lose information, right ?

 

[GaborSzakacs]

Marios Barlas wrote:

Hello,

I am facing a pretty wierd error as regards an operation which is pretty crutial for my code.

I am trying to do a left shift operation on an unsigned vector. My NBITS is defined generically as natural and my delta vector is unsigned. All compiles well but when iŕm doing the simulation my delta_shifted receives X values. for me that seems to suggest that the sll operation is not performed. Any1 has an idea as to where the problem could be ?

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.ALL;

entity sqroot_comb is
generic (constant NBITS : natural := 8); --design implementation
port (
signal arg : in std_logic_vector(NBITS-1 downto 0);
signal roundup : in std_logic := '0'; --determine if roundup is done or not
signal sqroot : out std_logic_vector(NBITS/2 downto 0));
end entity sqroot_comb;

architecture rtl of sqroot_comb is
use ieee.std_logic_1164.all;
use ieee.numeric_std.ALL;

--Internal signal definitions
signal delta : unsigned(NBITS-1 downto 0);
signal delta_shifted : unsigned(NBITS-1 downto 0);
signal delta_shifted_prev : unsigned(NBITS-1 downto 0);
signal res : unsigned(NBITS-1 downto 0);
signal res_prev : unsigned(NBITS-1 downto 0);
signal sqroot_temp_prev : unsigned(NBITS-1 downto 0);
signal sqroot_temp : unsigned(NBITS-1 downto 0);

--Signal Assignments

begin

delta <= to_unsigned(2**(NBITS-2),delta'length);
sqroot_temp <= to_unsigned(0,delta'length);
sqroot_temp_prev <= to_unsigned(0,delta'length);
delta_shifted_prev <= to_unsigned(0,delta'length);
res_prev <= to_unsigned(0,delta'length);

delta_shifted <= (delta sll NBITS-2); -- shifted // temp = delta^(NBITS-2)
res <= unsigned(arg);

process( arg, roundup )

--Internal variable definitions
--variable delta_int : integer := 1;
--variable sqroot_int : integer :=0;
--variable res_int : integer := to_integer(unsigned(arg));

begin

for i in 0 to 2*NBITS-1 loop
if (delta_shifted >= 1) then
if ( (sqroot_temp + delta_shifted) <= res ) then
res <= res -(sqroot_temp + delta_shifted);
sqroot_temp <= sqroot_temp + 2*delta_shifted;
else
sqroot_temp <= sqroot_temp_prev;
res <= res_prev;
delta_shifted <= delta_shifted_prev;
end if;
end if;

sqroot_temp <= sqroot_temp/2;
delta_shifted <= delta_shifted/4;

--Update previous values of sqroot and residual
sqroot_temp_prev <= sqroot_temp;
res_prev <= res;

end loop;

if ( (roundup = '1') and (res > sqroot_temp) ) then
sqroot_temp <= sqroot_temp + 1;
else
sqroot_temp <= sqroot_temp_prev;
end if;

sqroot <= std_logic_vector(resize( sqroot_temp,sqroot'length ));

end process;

end architecture rtl;

The first thing I noticed is that delta_shifted doesn't have enough bits
to represent the shifted value. Maybe that has something to do with it?

--
Gabor

 

[Nicolas Matringe]

Hello

Le 14/11/2014 21:22, Marios Barlas a ĂŠcrit :

Hello,

I am facing a pretty wierd error as regards an operation which is pretty crutial for my code.

I am trying to do a left shift operation on an unsigned vector. My NBITS is defined generically as natural and my delta vector is unsigned. All compiles well but when iĂ m doing the simulation my delta_shifted receives X values. for me that seems to suggest that the sll operation is not performed. Any1 has an idea as to where the problem could be ?

You have a conflict on delta_shifted. You have a concurrent assignment
(6th assignment after the architecture's "begin") and you assign values
to it in the process.
You're from a computer programming background, aren't you ?

Nicolas

 

[Brian Drummond]

On Fri, 14 Nov 2014 14:40:25 -0800, Marios Barlas wrote:

Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas
Matringe έγριψξ:
Hello

Le 14/11/2014 21:22, Marios Barlas a ĂŠcrit :
Hello,

but when iĂ m doing the simulation my
delta_shifted receives X values.

You have a conflict on delta_shifted. You have a concurrent assignment
(6th assignment after the architecture's "begin") and you assign values
to it in the process.
Apologizing for my ignorance in advance, I am guessing you are
referring to

delta_shifted <= delta sll NBITS-1

but this is exactly what I would like to do, shift the bits of my vector
representation to the left.

No, you missed Nicolas' point.

You have created two pieces of circuitry driving delta_shifted - one is
the process, the other is the concurrent statement
delta_shifted <= (delta sll NBITS-2); -- shifted // temp =

These two circuits have their outputs short circuited to each other, and
that short circuit creates the Xes, not the shift operation itself.

The usual solution is to decide which circuit should be permitted to
drive delta_shifted, and eliminate the other. (Usually, keep the process,
and move the other statement to an appropriate part of the process.)

- Brian

 

[Nicolas Matringe]

Le 14/11/2014 23:40, Marios Barlas a ĂŠcrit :

Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
[...]
You're from a computer programming background, aren't you ?
Thanks for your answer. Sadly nope. I'm a physicist but I'm finishing a 2 years master's in nanotechnology the last semester of which is in microelectronics. As a result us stupid physics people lack a good deal of background that others have for granted. This is my first bit of code in VHDL.

Sorry for my wrong guess, then. You wrote your VHDL like you'd write a
program in C for example. It doesn't work like that.

VHDL is a description language, not a programming language. It is like a
schematics, except it is in text form. Concurrent expressions (i.e. that
are outside of processes) are independent blocks in your schematics.
This also means that their order in the code doesn't matter at all.
As Brian explained, concurrently assigning something to a signal is like
connecting the output of a logic function to this signal. Concurrently
assigning several times to the same signal is connecting several outputs
together. You usually don't want to do that (this causes your Xs in
simulation)
You seem to assume your code is executed from top to bottom. It is not.
It is not even executed, since VHDL is not a programming language. What
you want is a block that takes a number and, after several iterations,
outputs its square root, am I right ? So you want to initialize some
internal signals or variables then step by step compute the square root
and finally output the result. So you need some simple sequencer (a
counter will do), and a clock to make it run.

Nicolas

 

[Marios Barlas]

Τη Σάββατο, 15 Νοεμβρίου 2014 10:50:10 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:

Le 14/11/2014 23:40, Marios Barlas a ĂŠcrit :
Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
[...]
You're from a computer programming background, aren't you ?
Thanks for your answer. Sadly nope. I'm a physicist but I'm finishing a 2 years master's in nanotechnology the last semester of which is in microelectronics. As a result us stupid physics people lack a good deal of background that others have for granted. This is my first bit of code in VHDL.

Sorry for my wrong guess, then. You wrote your VHDL like you'd write a
program in C for example. It doesn't work like that.

VHDL is a description language, not a programming language. It is like a
schematics, except it is in text form. Concurrent expressions (i.e. that
are outside of processes) are independent blocks in your schematics.
This also means that their order in the code doesn't matter at all.
As Brian explained, concurrently assigning something to a signal is like
connecting the output of a logic function to this signal. Concurrently
assigning several times to the same signal is connecting several outputs
together. You usually don't want to do that (this causes your Xs in
simulation)
You seem to assume your code is executed from top to bottom. It is not.
It is not even executed, since VHDL is not a programming language. What
you want is a block that takes a number and, after several iterations,
outputs its square root, am I right ? So you want to initialize some
internal signals or variables then step by step compute the square root
and finally output the result. So you need some simple sequencer (a
counter will do), and a clock to make it run.

Nicolas

Thanks for the reply Nicolas. Finally I wrote my code in dataflow using stages and it works perfectly. But I'll write it again with a process and clock! thanks for your feedback !

 

[Marios Barlas]

Τη Κυριακή, 16 Νοεμβρίου 2014 9:00:12 μ.μ. UTC+1, ο χρήστης rickman έγραψε:

On 11/16/2014 4:44 AM, Marios Barlas wrote:
Τη Σάββατο, 15 Νοεμβρίου 2014 10:50:10 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
Le 14/11/2014 23:40, Marios Barlas a ĂŠcrit :
Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
[...]
You're from a computer programming background, aren't you ?
Thanks for your answer. Sadly nope. I'm a physicist but I'm finishing a 2 years master's in nanotechnology the last semester of which is in microelectronics. As a result us stupid physics people lack a good deal of background that others have for granted. This is my first bit of code in VHDL.

Sorry for my wrong guess, then. You wrote your VHDL like you'd write a
program in C for example. It doesn't work like that.

VHDL is a description language, not a programming language. It is like a
schematics, except it is in text form. Concurrent expressions (i.e. that
are outside of processes) are independent blocks in your schematics.
This also means that their order in the code doesn't matter at all.
As Brian explained, concurrently assigning something to a signal is like
connecting the output of a logic function to this signal. Concurrently
assigning several times to the same signal is connecting several outputs
together. You usually don't want to do that (this causes your Xs in
simulation)
You seem to assume your code is executed from top to bottom. It is not..
It is not even executed, since VHDL is not a programming language. What
you want is a block that takes a number and, after several iterations,
outputs its square root, am I right ? So you want to initialize some
internal signals or variables then step by step compute the square root
and finally output the result. So you need some simple sequencer (a
counter will do), and a clock to make it run.

Nicolas

Thanks for the reply Nicolas. Finally I wrote my code in dataflow using stages and it works perfectly. But I'll write it again with a process and clock! thanks for your feedback !

I'm curious about the course where you are learning VHDL. I remember
about a million years ago when I was in college that I took a my first
computer programming course. It was one part of six in a lab course in
chemistry. I believe it was just two weeks. I now know they were doing
their students a huge disservice by giving them such a limited amount of
training and then releasing them into the world to write their own
programs.

I'm wondering if you are learning VHDL in a similar manner. VHDL is not
a terrible language to learn, but any HDL is a bit different from
computer programming in that they are inherently parallel rather than
sequential. Computer programming languages come naturally because they
are sequential reading the same as a recipe. HLDs are describing the
functionality of hardware with it working in parallel. So there are
different rules to it than you may be used to in software.

--

Rick

The program I'm following is called "master Nanotech". It's a bit unorthodox in the sense that it's mainly 1 year of applied physics / SC technology in master's level and 6 months in pure electronics. Now we are having two courses on VHDL one which is theoretical + small exercises like the one you saw above and then a lab which is split in 3 parts ( Full custom design in + layout in digital and analog electronics and semi-custom design in VHDL + place and route in Synopsis. ) The problem is that the courses take for granted some background in electronics and this is something lacking to ppl like me that come from applied physics. So, even if you are comfortable with programming wrapping your mind around parallel execution is somewhat alien in the beginning.

 

[Marios Barlas]

Τη Κυριακή, 16 Νοεμβρίου 2014 9:00:12 μ.μ. UTC+1, ο χρήστης rickman έγραψε:

On 11/16/2014 4:44 AM, Marios Barlas wrote:
Τη Σάββατο, 15 Νοεμβρίου 2014 10:50:10 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
Le 14/11/2014 23:40, Marios Barlas a ĂŠcrit :
Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
[...]
You're from a computer programming background, aren't you ?
Thanks for your answer. Sadly nope. I'm a physicist but I'm finishing a 2 years master's in nanotechnology the last semester of which is in microelectronics. As a result us stupid physics people lack a good deal of background that others have for granted. This is my first bit of code in VHDL.

Sorry for my wrong guess, then. You wrote your VHDL like you'd write a
program in C for example. It doesn't work like that.

VHDL is a description language, not a programming language. It is like a
schematics, except it is in text form. Concurrent expressions (i.e. that
are outside of processes) are independent blocks in your schematics.
This also means that their order in the code doesn't matter at all.
As Brian explained, concurrently assigning something to a signal is like
connecting the output of a logic function to this signal. Concurrently
assigning several times to the same signal is connecting several outputs
together. You usually don't want to do that (this causes your Xs in
simulation)
You seem to assume your code is executed from top to bottom. It is not..
It is not even executed, since VHDL is not a programming language. What
you want is a block that takes a number and, after several iterations,
outputs its square root, am I right ? So you want to initialize some
internal signals or variables then step by step compute the square root
and finally output the result. So you need some simple sequencer (a
counter will do), and a clock to make it run.

Nicolas

Thanks for the reply Nicolas. Finally I wrote my code in dataflow using stages and it works perfectly. But I'll write it again with a process and clock! thanks for your feedback !

I'm curious about the course where you are learning VHDL. I remember
about a million years ago when I was in college that I took a my first
computer programming course. It was one part of six in a lab course in
chemistry. I believe it was just two weeks. I now know they were doing
their students a huge disservice by giving them such a limited amount of
training and then releasing them into the world to write their own
programs.

I'm wondering if you are learning VHDL in a similar manner. VHDL is not
a terrible language to learn, but any HDL is a bit different from
computer programming in that they are inherently parallel rather than
sequential. Computer programming languages come naturally because they
are sequential reading the same as a recipe. HLDs are describing the
functionality of hardware with it working in parallel. So there are
different rules to it than you may be used to in software.

--

Rick

The program I'm following is called "master Nanotech". It's a bit unorthodox in the sense that it's mainly 1 year of applied physics / SC technology in master's level and 6 months in pure electronics. Now we are having two courses on VHDL one which is theoretical + small exercises like the one you saw above and then a lab which is split in 3 parts ( Full custom design in + layout in digital and analog electronics and semi-custom design in VHDL + place and route in Synopsis. ) The problem is that the courses take for granted some background in electronics and this is something lacking to ppl like me that come from applied physics. So, even if you are comfortable with programming wrapping your mind around parallel execution is somewhat alien in the beginning.

 

[rickman]

On 11/16/2014 4:44 AM, Marios Barlas wrote:

Τη Σάββατο, 15 Νοεμβρίου 2014 10:50:10 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
Le 14/11/2014 23:40, Marios Barlas a ĂŠcrit :
Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
[...]
You're from a computer programming background, aren't you ?
Thanks for your answer. Sadly nope. I'm a physicist but I'm finishing a 2 years master's in nanotechnology the last semester of which is in microelectronics. As a result us stupid physics people lack a good deal of background that others have for granted. This is my first bit of code in VHDL.

Sorry for my wrong guess, then. You wrote your VHDL like you'd write a
program in C for example. It doesn't work like that.

VHDL is a description language, not a programming language. It is like a
schematics, except it is in text form. Concurrent expressions (i.e. that
are outside of processes) are independent blocks in your schematics.
This also means that their order in the code doesn't matter at all.
As Brian explained, concurrently assigning something to a signal is like
connecting the output of a logic function to this signal. Concurrently
assigning several times to the same signal is connecting several outputs
together. You usually don't want to do that (this causes your Xs in
simulation)
You seem to assume your code is executed from top to bottom. It is not.
It is not even executed, since VHDL is not a programming language. What
you want is a block that takes a number and, after several iterations,
outputs its square root, am I right ? So you want to initialize some
internal signals or variables then step by step compute the square root
and finally output the result. So you need some simple sequencer (a
counter will do), and a clock to make it run.

Nicolas

Thanks for the reply Nicolas. Finally I wrote my code in dataflow using stages and it works perfectly. But I'll write it again with a process and clock! thanks for your feedback !

I'm curious about the course where you are learning VHDL. I remember
about a million years ago when I was in college that I took a my first
computer programming course. It was one part of six in a lab course in
chemistry. I believe it was just two weeks. I now know they were doing
their students a huge disservice by giving them such a limited amount of
training and then releasing them into the world to write their own
programs.

I'm wondering if you are learning VHDL in a similar manner. VHDL is not
a terrible language to learn, but any HDL is a bit different from
computer programming in that they are inherently parallel rather than
sequential. Computer programming languages come naturally because they
are sequential reading the same as a recipe. HLDs are describing the
functionality of hardware with it working in parallel. So there are
different rules to it than you may be used to in software.

--

Rick

 

[rickman]

On 11/16/2014 3:56 PM, Marios Barlas wrote:

Τη Κυριακή, 16 Νοεμβρίου 2014 9:00:12 μ.μ. UTC+1, ο χρήστης rickman έγραψε:
On 11/16/2014 4:44 AM, Marios Barlas wrote:
Τη Σάββατο, 15 Νοεμβρίου 2014 10:50:10 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
Le 14/11/2014 23:40, Marios Barlas a ĂŠcrit :
Τη Παρασκευή, 14 Νοεμβρίου 2014 10:43:19 μ.μ. UTC+1, ο χρήστης Nicolas Matringe έγραψε:
[...]
You're from a computer programming background, aren't you ?
Thanks for your answer. Sadly nope. I'm a physicist but I'm finishing a 2 years master's in nanotechnology the last semester of which is in microelectronics. As a result us stupid physics people lack a good deal of background that others have for granted. This is my first bit of code in VHDL.

Sorry for my wrong guess, then. You wrote your VHDL like you'd write a
program in C for example. It doesn't work like that.

VHDL is a description language, not a programming language. It is like a
schematics, except it is in text form. Concurrent expressions (i.e. that
are outside of processes) are independent blocks in your schematics.
This also means that their order in the code doesn't matter at all.
As Brian explained, concurrently assigning something to a signal is like
connecting the output of a logic function to this signal. Concurrently
assigning several times to the same signal is connecting several outputs
together. You usually don't want to do that (this causes your Xs in
simulation)
You seem to assume your code is executed from top to bottom. It is not..
It is not even executed, since VHDL is not a programming language. What
you want is a block that takes a number and, after several iterations,
outputs its square root, am I right ? So you want to initialize some
internal signals or variables then step by step compute the square root
and finally output the result. So you need some simple sequencer (a
counter will do), and a clock to make it run.

Nicolas

Thanks for the reply Nicolas. Finally I wrote my code in dataflow using stages and it works perfectly. But I'll write it again with a process and clock! thanks for your feedback !

I'm curious about the course where you are learning VHDL. I remember
about a million years ago when I was in college that I took a my first
computer programming course. It was one part of six in a lab course in
chemistry. I believe it was just two weeks. I now know they were doing
their students a huge disservice by giving them such a limited amount of
training and then releasing them into the world to write their own
programs.

I'm wondering if you are learning VHDL in a similar manner. VHDL is not
a terrible language to learn, but any HDL is a bit different from
computer programming in that they are inherently parallel rather than
sequential. Computer programming languages come naturally because they
are sequential reading the same as a recipe. HLDs are describing the
functionality of hardware with it working in parallel. So there are
different rules to it than you may be used to in software.

--

Rick

The program I'm following is called "master Nanotech". It's a bit unorthodox in the sense that it's mainly 1 year of applied physics / SC technology in master's level and 6 months in pure electronics. Now we are having two courses on VHDL one which is theoretical + small exercises like the one you saw above and then a lab which is split in 3 parts ( Full custom design in + layout in digital and analog electronics and semi-custom design in VHDL + place and route in Synopsis. ) The problem is that the courses take for granted some background in electronics and this is something lacking to ppl like me that come from applied physics. So, even if you are comfortable with programming wrapping your mind around parallel execution is somewhat alien in the beginning.

When I learned VHDL I wasn't "comfortable" with the parallel nature of
it. I had been programming in conventional languages for a number of
years. However, I was familiar with logic design and once it was
explained to me how the HDL mapped to logic it helped a lot. I always
think of my design in terms of the hardware and then code that hardware
in the HDL.

In your theoretical course they should have taught you that a signal can
not be assigned in more than one process without a resolution function.
In theory std_logic is resolved, so it is not an error to have
multiple drivers. But unless you are describing a tristated bus it is
not synthesizable and tristated buses are not used very often. So they
give you a warning. Try this with std_ulogic and you will get an error.

--

Rick

 

[Andy]

There's a very fine line between what a parallelizing compiler can do for SW, and what a synthesis tool does for HDL. Both understand how to transform sequential statements into parallel threads based on dependency.

Once you understand the HDL behavior (not the template) that synthesizes to registers vs combinatorial logic, then you are free to code your HDL at the behavioral level, on a clock-cycle by clock-cycle basis, and let the synthesis tool worry about the HW. If the synthesis results won't run with a fast enough clock, then (and only then) start thinking/coding at a lower level. Often the "cure" for slow HW is to do something more often, not less often. In SW we are taught not to perform a task if it is not needed. In HW, we learn to perform the task all the time, and only use the results if we need to. That takes less logic (and ns) than the decision whether to do the task or not. In practice, this is nothing more than reducing dependency, which aids in parallelizing.

I have always thought VHDL should be taught using variables first (use signals only for inter-process communication), so the student can fully understand what constitutes the behavior of a register, or storage of any kind (latches, ram, etc.) Once you fully understand that, you can reliably use storage, or avoid unwanted storage.

Andy