Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

VHDL STD_LOGIC_VECTOR (+ '1') vs UNSIGNED (+ 1)

Status
Not open for further replies.
I was talking from a compiler POV, not a language point of view. The question was why Quartus allowed a component with an unsigned type port to map to the entity that was declared with a std_logic_vector, without any conversion done anywhere. Hence my reference to Quartus treating everything like a std_logic_vector during mappings (probably because of the cross language support required).

And yes, I meant closly related type - so type conversion can be done as you stated, rather than requiring a conversion function.
 

TrickyDicky said:
I was talking from a compiler POV, not a language point of view. The question was why Quartus allowed a component with an unsigned type port to map to the entity that was declared with a std_logic_vector, without any conversion done anywhere. Hence my reference to Quartus treating everything like a std_logic_vector during mappings (probably because of the cross language support required).
Click to expand...

What code are you talking about and what version of Quartus are you using?

Quartus does not allow an entity with an unsigned type to map to a std_logic_vector signal. The code posted below, compiled with Quartus 10.0 SP1 produces the following errors (as it should). If you move the comments on the posted code to use the port maps that have the conversion functions, it will compile just fine (again, as it should).

Code: 
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity widget is port(
	inp_unsigned:	in	unsigned(15 downto 0);
	out_unsigned:	out	unsigned(15 downto 0));
end widget;
architecture rtl of widget is
begin
	out_unsigned <= inp_unsigned;
end rtl;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity top is port(
	inp_slv:	in	std_logic_vector(15 downto 0);
	out_slv:	out	std_logic_vector(15 downto 0));
end top;
architecture rtl of top is
begin
	dut : entity work.widget port map(
	inp_unsigned => inp_slv,
--	inp_unsigned => unsigned(inp_slv),
	out_unsigned => out_slv);
--	std_logic_vector(out_unsigned) => out_slv);
end rtl;
Error (10476): VHDL error at Junk.vhd(11659): type of identifier "inp_slv" does not agree with its usage as "UNSIGNED" type
Error (10476): VHDL error at Junk.vhd(11661): type of identifier "out_slv" does not agree with its usage as "UNSIGNED" type
Error (10558): VHDL error at Junk.vhd(11661): cannot associate formal port "out_unsigned" of mode "out" with an expression
Error: Quartus II Analysis & Synthesis was unsuccessful. 3 errors, 0 warnings
Error: Peak virtual memory: 229 megabytes
Error: Processing ended: Thu Jan 26 08:07:55 2012
Error: Elapsed time: 00:00:03
Error: Total CPU time (on all processors): 00:00:02
Error: Quartus II Full Compilation was unsuccessful. 5 errors, 0 warnings

Kevin Jennings
 

I was talking about using components, not direct instantiation. (And it wasnt me that brought it up, but FvM)

this code compiles fine in Quartus 11.1SP1:

Code: 
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity widget is port(
	inp_unsigned:	in	unsigned(15 downto 0);
	out_unsigned:	out	unsigned(15 downto 0));
end widget;

architecture rtl of widget is
begin
	out_unsigned <= inp_unsigned;
end rtl;


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity top is port(
	inp_slv:	in	std_logic_vector(15 downto 0);
	out_slv:	out	std_logic_vector(15 downto 0));
end top;
architecture rtl of top is
  component widget is port(
	  inp_unsigned:	in	std_logic_vector(15 downto 0);
	  out_unsigned:	out	std_logic_vector(15 downto 0));
  end component;
  
begin
	dut : widget port map(
	inp_unsigned => inp_slv,
--	inp_unsigned => unsigned(inp_slv),
	out_unsigned => out_slv);
--	std_logic_vector(out_unsigned) => out_slv);
end rtl;


---------- Post added at 15:39 ---------- Previous post was at 15:22 ----------

PS: FvM - I dont think you got this code through modelsim, as it reports a type missmatch when you try and run it.
 
  • Like
Reactions: FvM

    FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
TrickyDicky said:
I was talking about using components, not direct instantiation. (And it wasnt me that brought it up, but FvM)

this code compiles fine in Quartus 11.1SP1:
Click to expand...
Then it should be opened as a ticket/bug report to Altera regarding Quartus since it is a language non-compliance thing. So to answer your question from a post or two back, the reason Quartus accepts differences between entity and component, is because it is a bug in Quartus.

Off topic, but this example also demonstrates why components are not really a 'good' thing to use. Creating the component involves replicating stuff that can diverge unintentionally (i.e. unintended differences between the entity and component declaration). Even worse is when the component declaration is placed in the architecture where the component is instanced. Now the entity and component are (likely) in different files to be edited...the component might be instanced in more than one architecture...on and on it goes. The only place I've found a need for a component is in a testbench where I wanted to override the entity or architecture from the default binding.

Kevin Jennings
 

Hello Kevin,

I don't see at first sight, which language specification is violated by Quartus when it's tolerating "equivalent" types in components. I won't be surprized, if it's explicitely mentioned in the VHDL standard, but where?

The case, where I've been using components with equivalent types is in fact opposite to your example. It's to interface vendor IP, that uses slv for numeric quantities, e.g. Altera MegaFunctions like NCO. So the intention isn't to confuse VHDL types but to use clear numeric types throughout the application.

Frank
 

FvM said:
Hello Kevin,

I don't see at first sight, which language specification is violated by Quartus when it's tolerating "equivalent" types in components. I won't be surprized, if it's explicitely mentioned in the VHDL standard, but where?
Click to expand...
First off, I'm not a LRM wonk or a compiler person, I am a user of the language. But section 4.5 of the spec seems to not allow the generic/signal in the component declaration to be any different than they are for the entity. That section states:
A component declaration declares an interface to a virtual design entity that may be used in a component instantiation statement. A component configuration or a configuration specification can be used to associate a component instance with a design entity that resides in a library.

component_declaration ::=
component identifier [ is ]
[ local_generic_clause ]
[ local_port_clause ]
end component [ component_simple_name ] ;
Each interface object in the local generic clause declares a local generic. Each interface object in the local port clause declares a local port. If a simple name appears at the end of a component declaration, it must repeat the identifier of the
component declaration.
Click to expand...

One can use conversion functions when a component is instanced, but the above definition (if you trace through the entire tree of definitions in the spec), does not allow for any conversion functions on the component declaration. Since VHDL does not allow different base types to be assigned directly to each other (and 'unsigned' and 'std_logic_vector' are different base types by the way) then it follows that the generic and signal types defined on the entity must match those on the component; only default values may be changed between entity and component declarations.

The case, where I've been using components with equivalent types is in fact opposite to your example. It's to interface vendor IP, that uses slv for numeric quantities, e.g. Altera MegaFunctions like NCO. So the intention isn't to confuse VHDL types but to use clear numeric types throughout the application.
Click to expand...
Yes, I agree it is somewhat of a shame that vendor IP defaults top levels to slv rather than the correct intended type. On the other hand, you could view my example as maybe what those vendors put down as their top level in order to convert everything to the inappropriate but expected std_logic_vector type.

Thanks for your feedback.
Kevin

By the way, I submitted this as a bug report to Altera.
 
Last edited:
  • Like
Reactions: FvM

    FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top