VHDL: Difference between revisions

From ift
No edit summary
 
(7 intermediate revisions by one other user not shown)
Line 76: Line 76:
end architecture struct;
end architecture struct;
</pre>
</pre>
===subprograms===
subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result.
====procedures====
variables etc. defined in the header are local variables.
<pre>
procedure proc_name is
variable total : real :=0.0; --this is a local variable!
begin
  for index in samples loop
  total = total +sample(index);
  end loop;
answer:=total;
end procedure proc_name;
</pre>
procedures without parameters is called by it's name from any place in architecture.
other procedures can also call procedures in their body.
<pre>
proc_name;
</pre>
it is possible to use procedures with parameters.
====functions====
generalization of expressions, combined values with operators and produce new values. the type of result is specified.
<pre>
function limit (val, min, max: integer) return integer is
begin
if val > max then
  return max;
elseif val < min then
  return min;
else
  return val;
end if;
end function;
</pre>
a function is called in the architecture like this:
<pre>
newval := limit(current_val, 10, 100);
newval2 := 2 + limit(current_val, 10, 100);
</pre>


===Packages===
===Packages===
Line 81: Line 127:
grouping  a collection of related declarations to serve common purpose.
grouping  a collection of related declarations to serve common purpose.
seperat design units that can be worked on independently, reused in different parts of design.  
seperat design units that can be worked on independently, reused in different parts of design.  
the can be written along with entities and architecture and are analyzed separately.
it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package.


the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''.
the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''.


the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. in the model then you just need to refer to the package:  
====package declaration====
the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model.
it defines the interface to a package. in the model then you just need to refer to the package:  
<pre>
<pre>
package yourpackagename is --declaration
package yourpackagename is --declaration
Line 101: Line 151:
end entity yourentityname;
end entity yourentityname;
</pre>
</pre>
====package body====
no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations.
items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly.
===components===
to build hierarchical designs, used to describe interconnections in subsystems in a design.
component declarations are written in the declarative part of the architecture (before the ''begin'').
it is an alternative to use entity declarations (see structural design).
an entity declaration defines a real module, it's a separate design. a component declaration defines a virtual module in the architecture  body. "for this architecture we assume there is a module specified by this component".
===configurations===
in a configuration file the declaration can be made in which case which entity is using which architecture. the architectures may vary e.g. in case of simulation or synthesis.
A '''configuration declaration''' is a design unit which can be compiled separately. In a configuration declaration the binding of all components which are part of a certain entity can be specified.
also generic maps can be set.
<pre>
configuration config_identifier of entity_name is
  for architecture_name
   
    for all : component_identifier
      use entity lib_name.entity_name2(architecture_name2); --binding_indication
    end for;
   
    for bgo_channel_1 : bgo_channel
      use entity mxgs_bgo_lib.bgo_channel(struct)
        generic map(
          g_bgo_channel => "01"
          );
    end for;
 
  end for;
end config_identifier;
</pre>
[[Category:Mikroelektronikk]] [[Category:VHDL]]

Latest revision as of 13:16, 15 September 2017

Modeling concept

there are 3 domains of modeling:

  • function
  • structure
  • geometry

each provides a basic modeling concept.

a module e.g. a register is an entity, it's inputs ans outputs are called ports. an architecture is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only processes, collection of actions which are executed in sequences.

types of action that can be performed:

  • evaluating expressions
  • assigning variables and values
  • conditional and repeated execution
  • subprogram calls

behavioral architecture: function of an entity is described in an abstract way. e.g.

entity srlatch is
port ( s,r : in  std_logic;
      q,qb : out std_logic);
end srlatch;

architecture behave of calc is
begin
 foo: process
 begin
    Q <= S nand QB;
    QB <= R nand Q;  
 end process  foo;
end architecture behave;

structural architecture: only interconnecting subsystems

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

entity nand2 is
port(
  a,b : in  std_logic;   
  q   : out std_logic);
end nand2;

architecture basic of nand2 is
begin
q <= a nand b after 2 ns;
end basic;
entity srlatch is
port( s,r: in  std logic; 
     q,qb: out std_logic);
end srlatch;

architecture struct of srlatch is
 begin
 sq: entity work.nand2(basic)
 port map (
   a => s,
   b => qb,
   q => q
 );

 rq: entity work.nand2(basic)
 port map (
   a => r,
   b => q,
   q => qb
 );

end architecture struct;

subprograms

subprograms are procedures, a collection of statements executed for their effect, and functions, a collection of statements to compute a result.

procedures

variables etc. defined in the header are local variables.

procedure proc_name is
 variable total : real :=0.0; --this is a local variable!
 begin
  for index in samples loop
   total = total +sample(index);
  end loop;
 answer:=total;
end procedure proc_name;

procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body.

proc_name;

it is possible to use procedures with parameters.

functions

generalization of expressions, combined values with operators and produce new values. the type of result is specified.

 
function limit (val, min, max: integer) return integer is
begin 
 if val > max then
  return max;
 elseif val < min then
  return min;
 else
  return val;
 end if;
end function;

a function is called in the architecture like this:

newval := limit(current_val, 10, 100);
newval2 := 2 + limit(current_val, 10, 100);


Packages

grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package.

the external view is specified in the package declaration, the implementation is defind in the package body.

package declaration

the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. it defines the interface to a package. in the model then you just need to refer to the package:

package yourpackagename is --declaration
 constant foo: std_logic_vector(7 downto 0) := X"01";
 type  foobar is array (foobar2) of somethingelse;
end package yourpackagename;
use yourpackagename.all;

entity yourentityname is
 port (
  fooport    : in work.yourpackagename.foo;
  foobarport : in work.yourpackagename.foobar;
 );
end entity yourentityname;

package body

no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations.

items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly.

components

to build hierarchical designs, used to describe interconnections in subsystems in a design. component declarations are written in the declarative part of the architecture (before the begin). it is an alternative to use entity declarations (see structural design). an entity declaration defines a real module, it's a separate design. a component declaration defines a virtual module in the architecture body. "for this architecture we assume there is a module specified by this component".

configurations

in a configuration file the declaration can be made in which case which entity is using which architecture. the architectures may vary e.g. in case of simulation or synthesis. A configuration declaration is a design unit which can be compiled separately. In a configuration declaration the binding of all components which are part of a certain entity can be specified. also generic maps can be set.

configuration config_identifier of entity_name is
  for architecture_name
    
    for all : component_identifier
      use entity lib_name.entity_name2(architecture_name2); --binding_indication
    end for;
    
    for bgo_channel_1 : bgo_channel
      use entity mxgs_bgo_lib.bgo_channel(struct)
        generic map(
          g_bgo_channel => "01"
          );
    end for;
  
  end for;
end config_identifier;