Changes

:''See also: [http://en.wikipedia.org/wiki/Code_monkey code monkey]''

{| align="right" width="100px" style="text-align:center" cellspacing="0"

| style="background:#ffff66" | [[VHDL: The real code|next >]]

 

Now we're going to start laying down some actual code.  This section develops the framework of a VHDL file and prepares your black box, which will be filled in by the next section.

== Some basics ==

== Some basics ==

Now we lay down some actual code.  First things first: comments!  If you've ever done any programming, you know how wonderful comments are.  If you've not done much coding, then remember that comments are not as pointless as they seem.  Add descriptive comments or be murdered in your sleep 15 years from now by an irate engineer who has to decipher your legacy code.  VHDL has no block comments, only line comments (the comment goes from the comment marker to the end of the line).  The comment marker is a double dash with no spacing between them.  Many development environments (for example Xilinx ISE) will auto-generate a large block of comments at the top of each file to be used to describe the file (who, what, where, when, why, how, and so on).

First things first: comments!  If you've ever done any programming, you know how wonderful comments are.  If you've not done much coding, then remember that comments are not as pointless as they seem.  Add descriptive comments or be murdered in your sleep 15 years from now by an irate engineer who has to decipher your legacy code.  VHDL has no block comments, only line comments (the comment goes from the comment marker to the end of the line).  The comment marker is a double dash with no spacing between them.  Many development environments (for example Xilinx ISE) will auto-generate a large block of comments at the top of each file to be used to describe the file (who, what, where, when, why, how, and so on).

Secondly are the libraries.  These are like the include statements in C/C++.  Honestly I forget which libraries have exactly what tools in them, but a standard block will cover mostly any design you work on:

Secondly are the libraries.  These are like the include statements in C/C++.  Honestly I forget which libraries have exactly what tools in them, but a standard block will cover mostly any design you work on:

== Coding your black box ==

== Coding your black box ==

Every VHDL file defines an '''entity'''.  Every entity has two parts to it: a ''port list'' and an ''architecture''.  The port list defines the black box of your component.  First you declare that you are defining an entity, then inside the entity you declare your ports.

Every VHDL file defines an '''entity'''.  Every entity has two parts to it: a ''port (pin) list'' and an ''architecture''.  The port list defines the black box of your component.  First you declare that you are defining an entity, then inside the entity you declare your ports.

As discussed above, there are three types of ports: in, out, inout.  There are also lines and buses.  A line is referred to as a '''STD_LOGIC''' and a bus is referred to as a '''STD_LOGIC_VECTOR'''.  There are also two flavors of STD_LOGIC_VECTORS: '''downto''' and '''to'''.  A "downto" bus has the most significant bit (MSB) associated with the largest subscript, and a "to" bus has the least significant bit (LSB) associated with the largest subscript.  A bus with N lines need not have subscripts running from 0 ''to'' N-1.  They can run from 1 ''to'' N or N+84 ''downto'' 85; there is complete freedom as to the subscript offset.  Most people who learned coding in C or Java or something similar will generally stick to 0 ''to'' N-1 or N-1 ''downto'' 0 out of habit unless the situation calls for something else (for clarity, usually).  Often an engineer will choose either "to" or "downto" (I happen to prefer "downto") and stick with it.  However mixing "to" and "downto" has it's uses; for example connecting a "downto" to a "to" will reverse the order of the bits in the bus.  For a beginner, I recommend picking one and sticking to it.

As discussed above, there are three types of ports: in, out, inout.  There are also lines and buses.  A line is referred to as a '''STD_LOGIC''' and a bus is referred to as a '''STD_LOGIC_VECTOR'''.  There are also two flavors of STD_LOGIC_VECTORS: '''downto''' and '''to'''.  A "downto" bus has the most significant bit (MSB) associated with the largest subscript, and a "to" bus has the least significant bit (LSB) associated with the largest subscript.  A bus with N lines need not have subscripts running from 0 ''to'' N-1.  They can run from 1 ''to'' N or N+84 ''downto'' 85; there is complete freedom as to the subscript offset.  Most people who learned coding in C or Java or something similar will generally stick to 0 ''to'' N-1 or N-1 ''downto'' 0 out of habit unless the situation calls for something else (for clarity, usually).  Often an engineer will choose either "to" or "downto" (I happen to prefer "downto") and stick with it.  However mixing "to" and "downto" has it's uses; for example connecting a "downto" to a "to" will reverse the order of the bits in the bus.  For a beginner, I recommend picking one and sticking to it.