i'm making a bo/bc college assignment in vhdl using modelsim, and inside my operational block i need to port map some of my components (register,adder and comparator)but when i compile all the files together, all the three components compile correctly but the bo dont, the compiler tell's me that for all the three components: " Identifier "registrador" does not identify a component declaration." for example.
heres my bo code:
https://goo.gl/oNFnd8
thanks for any help!
Since you haven't declared your components, you are presumably trying to use direct entity instantiation. The syntax for this is not:
reg : registrador port map (...);
Instead, it is:
reg : entity work.registrador port map (...);
(assuming you have already compiled "registrador" into library work. If you compiled it into another library, substitute that library's name).
Related
Like the title says, why would you not just always use 'mylib.mypkg.all'? In some code I see things like:
use mylib.mypkg.func1;
use mylib.mypkg.func2;
When I would think I could just do:
use mylib.mypkg.all
Is there an advantage or purpose in only selecting certain functions or components besides just being explicit?
I'm new to VHDL and 'use' seems very similar to '#include' from C for me, so correct me if that is a poor way of thinking.
I've searched other questions and elsewhere online and I can't seem to find any reason why I shouldn't just always use '.all'.
Using .all on a use clause will make everything in that package visible. Which may be fine.
But as an engineer picking a design up, imagine my horror when I see this:
use lib.pkg1.all;
use lib.pkg2.all;
use lib.pkg3.all;
use lib.pkg4.all;
use lib.pkg5.all;
use lib.pkg6.all;
use lib.pkg7.all;
...and so on
And then see this:
if some_sig = some_constant_from_a_package then
Its quite confusing keeping track of whats from which package, and then which package I need to modify, and I end up constantly using search to find where some constant is actually defined.
Luckily, VHDL allows direct referencing to make everyone's life easier. So you can do this:
if some_sig = lib.pkg4.some_constant then
It makes keeping track of where everything is much easier.
But sometimes its just easier to do a .all include. Certain operators are defined implicitly for all types. Which can lead to interesting and confusing errors
use lib.pkg.some_type;
signal a,b : some_type;
...
if a = b then
Here, you'll get an error because the "=" function that got declared implicitly with the type doesnt get included, and hence the compiler cannot see the function. You will need to either use a .all use, import the "=" function:
use lib.pkg."=";
or a direct reference:
if a lib.pkg."=" b then
There is a final problem - invisibility. If two packages declare items with the same name and you include both packages, the compiler doesn't know which one you mean and will make them both invisible. The most common way to do this is with the following includes:
use ieee.numeric_std.all;
use ieee.std_logic_arith.all;
Here, the vhdl standard package numeric_std and non-standard std_logic_arith both define signed and unsigned types. And hence the following will throw a syntax error:
signal a : unsigned(7 downto 0);
To get around this, you will need to directly reference which type you meant:
signal a : ieee.numeric_std.unsigned(7 downto 0);
signal b : ieee.std_logic_arith.unsigned(7 downto 0);
Remember, these types are not the same and hence not directly compatible.
I'm having some trouble designing a single port rom onto a spartan 6 board. I use the provided core generator to create block memory and choose single port rom with 32 bit width and 256 depth with a coe file that just counts from 0 to 255. I drop the rom into my vhdl as a component and add the XilinxCoreLib as a library. When I try to generate the programming file I get the translate error:
logical block 'rom1' with type 'rom' could not be
resolved. A pin name misspelling can cause this, a missing edif or ngc file,
case mismatch between the block name and the edif or ngc file name, or the
misspelling of a type name. Symbol 'rom' is not supported in target
'spartan6'.
I'm currently using Xilinx ISE 13.1 if that helps. I feel like this should be really easy to do but I haven't been able to find how to do it.
Edit: Thanks everyone, was a combination of things. Wrong speed grade, and didn't add a copy of the ngc file to my working directory. I'll use arrays in the future.
Easiest way is to forget the vendor tools altogether and simply declare a constant array!
If this is in a package separate from the rest of the design, a few lines of printf's or a simple script can generate the VHDL boilerplate around the contents, which come from your assembler or whatever tool creates the actual data
Since you're adding a Xilinx generated core to your design in ISE, you need to add both the VHD file and the NGC file via "Add Source" via the Project menu.
Even easier, depending on how large your ROM needs to be and what data goes into it, would be to not even bother with a Xilinx core, but to use pure VHDL to declare a constant array and initialization values right in your VHDL file. Here is an example:
type array_ROM is array (0 to NUMBER_OF_ROWS-1) of std_logic_vector (ROM_BITWIDTH-1 downto 0);
signal my_ROM : array_ROM
:=
(
x"12345678",
x"ABCDEF01",
...
x"01010101"
);
Now, you don't put the elipsis (...) in that initialization list, just put rows of constants with bit widths matching ROM_BITWIDTH. The NUMBER_OF_ROWS is the number of address locations you need in the ROM. In this example, ROM_BITWIDTH would have to be set to 32 as I've used 32-bit hexadecimal constants in the initialization list. Being a signal, it's actually modifiable, so if you need it to be constant, just use "constant" instead of signal.
I guess the problem is, as the message says, a misspelling. to get the correct component declaration/instantiation, select your rom.xco in the design-window of ISE. then select "view vhdl instantiation template" from process window. use the component declaration and instantiation described therein.
There are a number of things that can cause this problem, one is that you are using a blocck that was generated for another FPGA family and using it inside the Spartan6. the other is that you may have generated the ROM using an older version of the tool and the wrapper for the ROM has changed since then.
You can either generate a anrray like Brian suggested and forgetting about the tool specific ROM type, or re-generate the IP under your curernt project settings and see how it goes.
I have a state machine that uses a component that is a state machine by itself. To implement the state machine I'm using a new type:
type state_machine is
(
st_idle,
st_cycle_1,
...
st_cycle_17
);
that is defined inside the architecture of the inner state machine. Can I also define a type state_machine that will have other states in the architecture of the outside component without them clashing?
Yes you can. A type definition within an architecture is a local definition and can not be seen outside of that particular architecture.
Thus it is possible to use the same type name over and over again in all of your architectures, e.g. as FSM type. If this is reasonable is another question and can not be answered generally. I personally prefer to use self-documenting names for FSMs, because this can be a great help for others(and myself after a few weeks) looking at your code; for small FSMs or if there is only one FSM in the module(which itself is well documented) this is not as big a problem.
It is however possible that a type definition within an architecture collides with the type definition of an imported library. Just to mention it.
I have been trying to declare my type in a separate "mytypes.vhd" file as follows:
library ieee;
use ieee.std_logic_1164.all;
package mytypes is
type my_bus_array_type is array (0 to 3) of std_logic_vector(7 downto 0);
end package mytypes;
and then define an entity as follows:
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.mytypes.all;
entity my_entity is
port(
bus_array : in my_bus_array_type;
...
);
end my_entity;
Well, this is not working. When I try to add the component to my library with the Altera Qsys tool, I get the following error:
Error: Verilog HDL or VHDL XML Interface error at my_entity.vhd(41): port "bus_array" has an unsupported type File: /home/project/my_entity.vhd Line: 41
Please note that the problem is the fact that I am trying to define inside an entity an array of standard_logic_vector, i.e. a multidimensional array. This code works correctly if I define an array of std_logic instead.
You mentioned you're using Quartus, which can be picky about using std_logic_vectors as base types for other items.
I do what I think you're after in Quartus using subtypes:
mytypes.vhd file:
library ieee;
use ieee.std_logic_1164.all;
package mytypes is
subtype BYTE_T is std_logic_vector(7 downto 0);
type BYTE_A is array (natural range <>) of BYTE_T;
type my_bus_array_type is array (0 to 3) of BYTE_T;
end package mytypes;
my_entity.vhd file:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.mytypes.all
entity my_entity is
port (
my_bus_array1 : in BYTE_A(0 to 3);
my_bus_array2 : in my_bus_array_type;
...
It's up to you whether you want to define the array range in the entity (perhaps using a generic), or in your package.
I am not an expert in VHDL but I think you have to write your code like this :
I edited : try this instead :
package mytypes is
type my_bus_array_type is array (0 to 3) of std_logic_vector(7 downto 0);
end package mytypes;
entity my_entity is
port ( my_bus_array : in my_bus_array_type;
...);
end my_entity
You have to tell the compiler to use the types you created in the mytypes package:
use work.mytypes.all
entity my_entity is
port ( my_bus_array : in my_bus_array_type;
...
I've had similar problems, and it has had to do with handling of VHDL libraries. All HDL components in Qsys will be assigned a VHDL library with the library name set to the name of the Qsys project. Packages must be accessed with library explicitly (work. in your case) and this can mess things up. That being said, usually using packages in Qsys components has worked fine for me (including accessing them with work.).
To see how Quartus assigns and compiles into libraries, check "Design units" tab in Quartus. It lists units in folders of libraries. However, I've seen that packages will not be listed here, for some reason. Also see the .qip file of your Qsys project, where you can see exactly how Quartus has assigned your HDL files into a library.
The fact that your problem doesn't appear when instantiating your code directly in the Quartus project, rather than as a Qsys component, hints of the library issue being the explanation for this.
I've only found two references on the Qsys library handling:
http://www.alteraforum.com/forum/showthread.php?t=33605
http://www.alterawiki.com/wiki/New_Qsys_Issues (see section "Unavoidable design unit collisions")
(On a side note, I often use arrays of std_logic_vector in Qsys components and never experienced a problem with that.)
What you're trying to really define is a 2D array as a port. Unfortunately, QSYS does NOT support 2D arrays. No standard Qsys interfaces support anything more than a 1 dimensional port array. Hence you'd have to break the array apart in your top level entity, export the individual ports as conduits, and then reassemble them at a higher level back into an array. This is unfortunate but true.
I've been scratching my head since my first VHDL class and decided to post my question here.
Given that I have a declared entity (and also an architecture of it) and want to instantiate it inside another architecture, why is it that I seemingly have to redeclare the "entity" (component) inside this containing architecture before instantiating it?
Isn't the compiler smart enough to match an instantiation to its architecture just by its name? Where is the need for the component declaration?
You can directly instantiate the component, if desired:
MyInstantiatedEntity : entity work.MyEntity_E
generic map (
config => whatever)
port map (
clk => signal1,
clk_vid => signal2,
...
Creating a component declaration gives you the extra ability to change what gets bound to the instantiation via a configuration specification or similar.
Back when I did my VHDL assignments back when I was in school, I was required to have all our code all in one file so I don't remember whether or not you could write one file for each module and how it was done.
That being said, you would have to declare the entity you would use when defining the behavior, if you were using it much in the same way that you would define prototypes, structures, classes and whatnot in C or C++. The difference here is that you don't have the luxury of defining header files for this "redeclaration" in VHDL (at least I don't think there is an equivalent). So it seems perfectly reasonable to me to have to do this. Note that VHDL came out when C was very common and the compilers weren't "smart enough" as they are today.
A VHDL guru might have a definitive answer for this but this is how I understand it.