VDHL initializing

[hvo]

Hello,

When initializing input/output signals in a multilevel VHDL design, is i
"better" to initiate the values in the component declaration in th
toplevel? or the submodule entity declaration? Does it make a difference?


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Mike Treseler]

On 8/16/2010 3:24 PM, hvo wrote:

When initializing input/output signals in a multilevel VHDL design, is it
"better" to initiate the values in the component declaration in the
toplevel? or the submodule entity declaration? Does it make a difference?

The module entities should drive their port outputs in response to
an active reset input. I use direct instances which do not
require component declarations. A properly bound component declaration
can override generic values but has no effect on reset values.

-- Mike Treseler

 

[Mark McDougall]

Mike Treseler wrote:

I use direct instances which do not
require component declarations.

Agreed. Component declarations are a PITA and a maintenance nightmare.
Avoid if you can.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

 

[Jonathan Bromley]

On Mon, 16 Aug 2010 17:24:00 -0500, "hvo" wrote:

When initializing input/output signals in a multilevel VHDL design, is it
"better" to initiate the values in the component declaration in the
toplevel? or the submodule entity declaration? Does it make a difference?

I guess you're talking about default values of input ports?

entity widget is
port (clk: in std_logic;
mode: in std_logic = '0'; -- like this?
count: out std_logic_vector);

That is not an initialisation in the ordinary sense;
it's a default value. It is used only if the port
is unconnected when you instance the entity, and
in that case the port acts as though it is permanently
driven with the default value. If there's no default,
an unconnected input port takes its "normal" default
value ('U' for std_logic, -huge for integer, etc, etc).

For synthesisable designs I generally agree with Mark
and Mike that components are not worth the trouble,
but if you do use components then you must be
careful about these default input values, because
you can get some slightly surprising results.

If you insist on using components, my standard
advice is to make the defaults the same on both
entity and component. At the end of this post
there's a long tedious ramble explaining why.

In theory there are some interesting creative
uses for defaults that differ between component
and entity. In practice I've never found a
situation where it was any use to me.

Finally, a word of caution. Default input values
are a pretty neat idea, but increasingly I choose
never to use them. There is very little additional
work in writing an explicit tie-off in the instance's
port connection list, and I think that makes my intent
much clearer. It also insulates me from the risk that
some well-meaning goon will change the entity default
in the future, and will fail to notice because all his
own tests use explicit connection to the port.

~~~~~~~~~~~~~~~~ long and boring bit ~~~~~~~~~~~~~~~

A default on an ENTITY's port is somewhat like an
internal pullup inside a chip. If you cut off the
chip's pin, the internal pullup will still work.

A default on a COMPONENT's port is like a pullup
built in to a socket. If you don't solder that
socket connection to the PCB, the pullup will
drive it and therefore will drive anything that
you plug in to the socket.

So, if you're using component instantiation,
it all depends on how you bind the entity to
the component.

- If you use default binding (in other words,
you don't write a configuration) then the
entity's ports exactly match the component's,
and default values on the entity's inputs
have no effect. However, if your component
instance has an unconnected port, that port
will use the default (if any) on the
COMPONENT. The entity's default is ignored.

- If you write a configuration, it is possible
to bind an entity to a component that has
different ports. In this case you may choose
to leave some of the entity's ports not bound
to ports on the component. These floating
entity ports will then take their entity
defaults. When you instance the component,
any floating component ports will take their
component defaults.

If you use direct instantiation, things are
simpler because there is no component to worry
about. Ports on the entity that are not
connected at instantiation will get their
default values.

~~~~~~~~~~~ end of long and boring bit ~~~~~~~
--
Jonathan Bromley

 

[hvo]

On Mon, 16 Aug 2010 17:24:00 -0500, "hvo" wrote:

When initializing input/output signals in a multilevel VHDL design, i
it
"better" to initiate the values in the component declaration in the
toplevel? or the submodule entity declaration? Does it make
difference?

I guess you're talking about default values of input ports?

entity widget is
port (clk: in std_logic;
mode: in std_logic = '0'; -- like this?
count: out std_logic_vector);

That is not an initialisation in the ordinary sense;
it's a default value. It is used only if the port
is unconnected when you instance the entity, and
in that case the port acts as though it is permanently
driven with the default value. If there's no default,
an unconnected input port takes its "normal" default
value ('U' for std_logic, -huge for integer, etc, etc).

For synthesisable designs I generally agree with Mark
and Mike that components are not worth the trouble,
but if you do use components then you must be
careful about these default input values, because
you can get some slightly surprising results.

If you insist on using components, my standard
advice is to make the defaults the same on both
entity and component. At the end of this post
there's a long tedious ramble explaining why.

In theory there are some interesting creative
uses for defaults that differ between component
and entity. In practice I've never found a
situation where it was any use to me.

Finally, a word of caution. Default input values
are a pretty neat idea, but increasingly I choose
never to use them. There is very little additional
work in writing an explicit tie-off in the instance's
port connection list, and I think that makes my intent
much clearer. It also insulates me from the risk that
some well-meaning goon will change the entity default
in the future, and will fail to notice because all his
own tests use explicit connection to the port.
--
Jonathan Bromley

Thanks for your explanation. I guess what most are saying is tha
default/initial values are not necessary when the ports are being use
externally. For example the following is unecessary:

entity thing is
Port(
Clk : in std_logic := '0';
A : in std_logic := '0';
B : in std_logic := '0';
O : out std_logic := '0'
);

Only when a port is unconnected externally then you would give it a defaul
value, but in that case, it is better to explicitly write tie-off to avoi
confusions.

In a multiple component design, it is also unecessary to give eac
component a default/initial value since it could introduce surprisin
results.


Please let me know if I mis-interpreted anything.
Thanks
hv


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Jonathan Bromley]

On Tue, 17 Aug 2010 12:28:25 -0500, "hvo" wrote:

In a multiple component design, it is also unecessary to give each
component a default/initial value since it could introduce surprising
results.

That was not exactly what I intended to say.

My point was that IF you use VHDL components then it is a
good idea to ensure that any input port defaults are the
same on a component as on the matching entity that will
bind to it. If the component and the entity have
different defaults, you may find the results are
not quite what you expect.

Most people use direct entity instantiation and do not use
components, so the problem does not arise.

Apologies if I was unclear earlier.

Since this is a pure VHDL question, you are more likely to
get good answers on comp.lang.vhdl.
--
Jonathan Bromley

 

[hvo]

On Tue, 17 Aug 2010 12:28:25 -0500, "hvo" wrote:

In a multiple component design, it is also unecessary to give each
component a default/initial value since it could introduce surprising
results.

That was not exactly what I intended to say.

My point was that IF you use VHDL components then it is a
good idea to ensure that any input port defaults are the
same on a component as on the matching entity that will
bind to it. If the component and the entity have
different defaults, you may find the results are
not quite what you expect.

Most people use direct entity instantiation and do not use
components, so the problem does not arise.

Apologies if I was unclear earlier.

Since this is a pure VHDL question, you are more likely to
get good answers on comp.lang.vhdl.
--
Jonathan Bromley

Thanks for the answer. I just wanted to establish a good rule of thumb t
go by for setting the default values of IO signals.




---------------------------------------
Posted through http://www.FPGARelated.com

 

[RCIngham]

[snip]

Most people use direct entity instantiation and do not use
components, so the problem does not arise.

[snip]

My experience is that most people DO use components, some in packages, and
some not. I am trying to educate them to use direct entity
instantiation...

Few use port default values. I tend to avoid these for code that I intend
to synthesize, but it is a useful feature for testbench models.

Cheers!


---------------------------------------
Posted through http://www.FPGARelated.com

 

[hvo]

Few use port default values. I tend to avoid these for code that I intend
to synthesize, but it is a useful feature for testbench models.

That's exactly why I started using default values in the first place.
Besides being useful for testbench models, I get the sense that most peopl
don't use default values too much. Is it just a pain in the butt for mos
people? or could it lead to unintended results if one is not careful?

I find default values some-what useful because I can leave a signal open
i.e.

 

[hvo]

Few use port default values. I tend to avoid these for code that
intend
to synthesize, but it is a useful feature for testbench models.


That's exactly why I started using default values in the first place.
Besides being useful for testbench models, I get the sense that mos
people
don't use default values too much. Is it just a pain in the butt fo
most
people? or could it lead to unintended results if one is not careful?

I find default values some-what useful because I can leave a signal open,
i.e.

mysignal(0) => someothersignal,
mysignal(3 downto 1) => open,



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Mike Treseler]

On 8/18/2010 9:19 AM, hvo wrote:

Few use port default values. I tend to avoid these for code that I intend
to synthesize, but it is a useful feature for testbench models.

That's exactly why I started using default values in the first place.
Besides being useful for testbench models, I get the sense that most people
don't use default values too much. Is it just a pain in the butt for most
people? or could it lead to unintended results if one is not careful?

Default values for ports and signals
are irrelevant and possible harmful in synthesis code.
Default values are ignored for synthesis, but may mask
an initialization problem when such synthesis code is tested.

I find default values some-what useful because I can leave a signal open,

I sometimes find default signal values convenient for testbench
stimulus signals.

-- Mike Treseler

 

[hvo]

On Aug 18, 12:32=A0pm, "hvo" <hai.vo@n_o_s_p_a_m.n_o_s_p_a_m.synrad.com
wrote:

I find default values some-what useful because I can leave a signa
open=
,
i.e.

mysignal(0) =3D> someothersignal,
mysignal(3 downto 1) =3D> open,


Actually that example is illegal. You can't have a vector that is
partially assigned and partially opened. I opened a feature
suggestion to the VHDL standards group several years back to have that
changed.

KJ

Wouldn't the open port vectors just take on their default value? Th
"open" just tells that I am not connecting anything to it.

I am using Xilinx ISE 10.1 and I was able to implement my design wit
something similar to above.






---------------------------------------
Posted through http://www.FPGARelated.com

 

[KJ]

On Aug 18, 12:32 pm, "hvo" <hai.vo@n_o_s_p_a_m.n_o_s_p_a_m.synrad.com>
wrote:

I find default values some-what useful because I can leave a signal open,
i.e.

mysignal(0) => someothersignal,
mysignal(3 downto 1) => open,

Actually that example is illegal. You can't have a vector that is
partially assigned and partially opened. I opened a feature
suggestion to the VHDL standards group several years back to have that
changed.

KJ

 

[KJ]

On Aug 18, 4:25 pm, "hvo" <hai.vo@n_o_s_p_a_m.n_o_s_p_a_m.synrad.com>
wrote:

On Aug 18, 12:32=A0pm, "hvo" <hai.vo@n_o_s_p_a_m.n_o_s_p_a_m.synrad.com
wrote:

I find default values some-what useful because I can leave a signal
open> >,
i.e.

mysignal(0) =3D> someothersignal,
mysignal(3 downto 1) =3D> open,

Actually that example is illegal.  You can't have a vector that is
partially assigned and partially opened.  I opened a feature
suggestion to the VHDL standards group several years back to have that
changed.

KJ

Wouldn't the open port vectors just take on their default value?  The
"open" just tells that I am not connecting anything to it.  

Not if the compiler follows the VHDL language specification. Per the
language specification VHDL-2002, section 1.1.1.2 Ports..."It is an
error if some of the subelements of a composite formal port are
connected and others are either unconnected or unassociated".

Sample code demonstrating this is shown below (1)

I am using Xilinx ISE 10.1 and I was able to implement my design with
something similar to above.  

If true, this would be a bug in ISE 10.1. On the other hand, it might
also be an example of brand X getting ahead of the curve and
implementing something ahead of a requested (and apparently lost)
change to the language standard (2)

Kevin Jennings

(1) Sample code showing usage of opens on vector subelements

--- START OF CODE
entity Widget is port(
Some_Input: in bit_vector(1 to 10) := (others => '0'));
end Widget;

entity Use_A_Widget is port(
Some_Input: in bit_vector(1 to 3));
end Use_A_Widget;

architecture RTL of Use_A_Widget is
begin
The_Widget : entity work.Widget port map(
Some_Input(1 to 3) => Some_Input(1 to 3),
Some_Input(4 to 10) => open);
end RTL;
---END OF CODE

Because the language standard demands it, Modelsim appropriately
produces the following error when compiling the above code

# ** Error: C:/Tools/Quartus.900/quartus/Junk/Junk.vhd(446):
(vcom-1046) Formal "some_input" must not be associated with OPEN when
subelements are associated individually.
# ** Error: C:/Tools/Quartus.900/quartus/Junk/Junk.vhd(446): VHDL
Compiler exiting
# C:/Tools/modeltech_pe_6.4/win32pe/vcom failed.

(2) This feature to allow opens on subelements has been submitted to
the VHDL language standards people as an enhancement request to the
language. This was done back ~2005 and subsequently lost. It was
resubmitted as bug #275 in August, 2009 and seems to have been lost
yet again....sigh...

Reference to the thread when I created the bug #275 request in August
2009 as a replacement for the lost one from 2005
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/bb6a2156d4de81ac/fe0fb11716a8baa1?hl=en&lnk=gst&q=Kevin+Jennings+Bugzilla#fe0fb11716a8baa1