Hello,

When initializing input/output signals in a multilevel VHDL design, is it"better" to initiate the values in the component declaration in thetoplevel? or the submodule entity declaration?  Does it make a difference?	  
					
---------------------------------------		
Posted through http://www.FPGARelated.com

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

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

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

>On Mon, 16 Aug 2010 17:24:00 -0500,
"hvo" wrote:
>
>>When initializing input/output signals in a multilevel VHDL design, isit
>>"better" to initiate the values in the component declaration in the
>>toplevel? or the submodule entity declaration?  Does it make adifference?	
>
>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 thatdefault/initial values are not necessary when the ports are being usedexternally.  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 defaultvalue, but in that case, it is better to explicitly write tie-off to avoidconfusions.  

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


Please let me know if I mis-interpreted anything.
Thanks
hv
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

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

>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 togo by for setting the default values of IO signals.


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

[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, andsome not. I am trying to educate them to use direct entityinstantiation...

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

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

>
>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 peopledon't use default values too much.  Is it just a pain in the butt for mostpeople? 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. 

>>
>>Few use port default values. I tend to avoid these for code that Iintend
>>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 mostpeople
>don't use default values too much.  Is it just a pain in the butt formost
>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