Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

VHDL Structural vs Behavioral

Tags:

vhdl

This is a question for those who have a good understanding of VHDL. I'm a newbie but so far I have been generating VHDL using a behavioral description. For me it is much easier to think about as it is similar to writing software. I am aware that a possible downfall is that behavioral 'executes' sequentially while structural executes concurrently within the design component/process..

So I'm just curious, if I have an architecture that uses a process for say an 8-bit shift register (SISO) and I want to create 4 instances of these (4x8-bit shift registers) would I create a component and 4 instances of the process?

Or would I generate 4 processes (executing in parallel to one another) and just call each process by a different name?

Also, just a general question to get a consensus of what good practices people use out there, which do you prefer: structural vs. behavioral?? When would be a good time to choose one over the other? I'm guessing their could be some benefits with 'faster' execution using components that allow internal concurrency vs. sequential execution in processes.. It sure does seem to me though that one could reduce the design time with behavioral designs..

Thanks! ~doddy

like image 690
doddy Avatar asked Nov 16 '12 19:11

doddy


1 Answers

For my money, the role of structural HDL nowadays is restricted to interconnecting tested working behavioral blocks (or connecting untested ones to their testbenches!) - I would agree with you about the superiority of behavioural VHDL in terms of design creation and test time.

I would also agree that writing a behavioural process is in some ways similar to writing software (over the screams of some that it isn't)

HOWEVER

do not fall into the trap of equating behavioural with sequential or slow!

Given your shift register, say

type reg_type is array(7 downto 0) of bit;
signal s_in, s_out : bit;

process(clk) is
variable reg : reg_type;
begin
   if rising_edge(clk) then
      s_out <= reg(7);
      reg   := reg(6 downto 0) & s_in;
   end if;
end;

I can trivially parallelise it as follows:

signal p_in, p_out : array(1 to 4) of bit;

process(clk) is
variable reg : array(1 to 4) of reg_type;
begin
   if rising_edge(clk) then
      for i in reg'range loop
         p_out(i) <= reg(i)(7);
         reg(i)   := reg(i)(6 downto 0) & p_in(i);
      end loop;
   end if;
end;

(And yes there are simpler ways to write this!) It is important to note that the loop does not take any longer to run : it just generates more hardware (in software terms, it is unrolled completely). Each iteration is completely independent of the others; if they weren't, things would be more complex.

Don't worry about the academic differences between structural and behavioral.

Worry about the difference between signal assignment scheduling and variable assignment scheduling in a process (learn what delta cycles and postponed assignment are - this is one of the key diffs from software, and arises because software only has variables, not VHDL's signals). That will explain why I implemented the pipeline upside down here (output first) - because I used a variable.

Worry about why so many people teach the idiotic 2-process state machine when the 1-process SM is simpler and safer.

Find and understand Mike Treseler's pages about single-process models (I hope they are still online)

like image 138
user_1818839 Avatar answered Oct 03 '22 07:10

user_1818839