port list order
titi
Is this better to put them in the same order?
Is it possible/good idea to not use every signal in a component?
For exemple:
entity something is
port( abc, def : in std_logic_vector (15 downto 0); re : in
std_logic;
....
and in another file:
component something
port(re : in std_logic;
abc : in std_logic_vector(15 downto 0);
def : in std_logic_vector(15 downto 0);
...
KJ
> Should port list be in the same order in entity and component declartion?
> Is this better to put them in the same order?
That would depend on your definition of 'better', the bottom line is
that it doesn't matter to the tools so it can only be 'better' in a
cosmetic sense (which is an individual decision).
>
> Is it possible/good idea to not use every signal in a component?
Unneeded outputs can be left unconnected. Inputs must be connected,
or the entity must define what the default value for that input is.
As a general guideline, it is easier to maintain code that does NOT
use component declarations at all. Instead you use direct entity
instantiation. Using your example entity....
>
> For exemple:
>
> entity something is
> port( abc, def : in std_logic_vector (15 downto 0); re : in
> std_logic;
> ....
You would use (i.e. instantiate) this in your code like this...
My_Something : entity work.something
port map(
abc=>abc_signal,
def=>def_signal);
The 'problem' with component declarations is that (in case you haven't
noticed) you've got the exact same information (i.e. the entity name,
the generics and the signals) now in at least two places. If you
change something (add/remove a signal for example) in one place YOU
need to make sure that you update it every other place, the tools tend
to not provide any information about differences between the entity
and the component. When you forget to do this you tend to get strange
errors when you just try to invoke the simulator that make you scratch
your head wondering what the heck is going wrong.
Kevin Jennings
Torsten Landschoff
> The 'problem' with component declarations is that (in case you haven't
> noticed) you've got the exact same information (i.e. the entity name,
> the generics and the signals) now in at least two places. If you
> change something (add/remove a signal for example) in one place YOU
> need to make sure that you update it every other place, the tools tend
> to not provide any information about differences between the entity
> and the component. When you forget to do this you tend to get strange
Good point. My VHDL book says that the split component/entity is an
advantage of VHDL, supporting top down design. I was always wondering
where the improvement is. My C/C++ experience tells me that redundant
interface information calls for trouble.
Anybody having an idea why VHDL does it this way?
Greetings, Torsten
KJ
"Torsten Landschoff" <t.land...@gmx.de> wrote in message
news:1172350375.9...@m58g2000cwm.googlegroups.com...
some pieces were missing (i.e. the pieces where you know what the interface
is but the detailed design does not yet exist). That's how VHDL was back in
1987 when it was first released as a language. Since VHDL is based heavily
on Ada I suspect that this might have been thought to be a 'good thing' for
Ada as well, but I don't know. In any case, you can't get very far in
simulating and testing 'the rest of the design' if all you have is the
interface to it (whether it is in the form of a component declaration or an
entity). In either case though you can write and compile all the code for
'the rest of the design'.
In 1993 VHDL was heavily revised and direct entity instantiation was added
so that, you could completely avoid the component declaration. But even
now, 14 years later, most people seem to still use component
declarations...no doubt because books tell you it's a 'good idea' but don't
explain why or explain how it's in any way better than using the entity
declaration (hint, it's not better). You can get exactly to the same point
in being able to do 'the rest of the design' given the entity declaration as
you can with the component declaration.
The idea that you can write code that instantiates a box long before the box
has been designed is a good one. The method you use to accomplish that idea
should not introduce easy ways to make stupid mistakes. Both direct entity
instantiation and component declaration accomplishes the same goal....the
component declaration method introduces the potential for introducing
'stupid mistakes'.....between 1987 and 1993, the committee of people working
on refining VHDL saw this and fixed it...14 years later the textbooks and
professors are still stuck.
Kevin Jennings
JK
> "Torsten Landschoff" <t.landsch...@gmx.de> wrote in message
>
> - Show quoted text -
KJ,
Thank you - its a new point for me.
But what if my design is a mixed one... means it has both verilog &
vhdl files.
And top level file is a vhdl file. But some of its modules are in
verilog.
When I tried to instantiate them as entities(eg., entity work.clk_hf),
I got errors in syntax check..
ERROR:HDLParsers:709 - "D:/Users/JK/xilinx_prj/clockManager.vhd" Line
498. clk_hf is not an entity name
ERROR:HDLParsers:709 - "D:/Users/JK/xilinx_prj/clockManager.vhd" Line
537. clk_lf is not an entity name
Regards,
JK
KJ
"JK" <krishna.j...@gmail.com> wrote in message
news:1172403589....@8g2000cwh.googlegroups.com...
>
> Thank you - its a new point for me.
> But what if my design is a mixed one... means it has both verilog &
> vhdl files.
> And top level file is a vhdl file. But some of its modules are in
> verilog.
> When I tried to instantiate them as entities(eg., entity work.clk_hf),
> I got errors in syntax check..
>
> ERROR:HDLParsers:709 - "D:/Users/JK/xilinx_prj/clockManager.vhd" Line
> 498. clk_hf is not an entity name
> ERROR:HDLParsers:709 - "D:/Users/JK/xilinx_prj/clockManager.vhd" Line
> 537. clk_lf is not an entity name
>
entities). Have you checked to see that the file(s) that contain clk_hf
(and clk_lf) get compiled before the entity that instantiates them
(clockManager.vhd)? If the software has not parsed/analyzed the file that
defines the interface for clk_hf (and clk_lf) when it runs across your code
trying to use that component it will give an error (regardless of the
language in which they were written). Re-ordering the file list so that
those files get parsed earlier may be the fix. This is no different than in
any software language where there are file compile order dependencies.
If the ordering is not the problem and clk_hf (and clk_lf) are the Verilog
modules than it could be that the software doesn't like using VHDL direct
entity instantiation of a Verilog module (might also want to verify if it
works for VHDL instantiating another VHDL module). Consult the
documentation for how they would like you to instantiate the Verilog
component. In general, you 'should' be able to instantiate a Verilog module
inside VHDL without really having to know that it's Verilog....but that
statement is very tool dependent. In Modelsim for example, this is exactly
what you do, nothing special (other than you have to of course have paid the
$$ for VHDL and Verilog support).
If it turns out that the tool does not support simple direct entity
instantiation when crossing language boundaries (or definitely if it's all
VHDL) then feel free to open a feature request to the supplier grumbling
about the lack of support of this method. In the mean time, trudge on with
whatever works but also evaluate other tools/suppliers that do support this
and other features that you deem useful. Use these things as metrics to
judge the usefulness of the tools down the road...in other words, if one
supplier cripples you on this project maybe on the next one you'll choose to
use something better. Having said that, I wouldn't let support for any
single particular feature be the litmus test on choosing or not choosing a
tool or device but keeping your eyes open about which vendors support
particular standards, and which ones just say they do is good to know.
Kevin Jennings
JK
> "JK" <krishna.januman...@gmail.com> wrote in message
Hi KJ,
Sorry - I forgot to inform that clk_hf & clk_lf are verilog modules
and top-level entiity clockManager is a vhdl file. And I am using
Xilinx - XST for synthesis.
It is not compilation issue as XST is first compiling all verilog
files in design and then vhdl files.. clk_hf.v & clk_lf.v files are
compiled..
It seems XST wont support this kind of instantiation. I found this in
XST user guide.
"... .Component instantiation based on default binding is used for
binding Verilog modules to a VHDL design unit.
Configuration specification, direct instantiation and component
configurations are not supported for a Verilog module instantiation in
VHDL...."
This is true that a single feature should not be the litmus test for
choosing a tool but I think SynplifyPro is a better choice for
synthesis.
Any way KJ, Thank you.
Regards,
JK
Andy
There are a lot of coding styles/features that Synplify accepts, but
XST will not. In my experience with both, SynplifyPro is much better
in both vhdl language coverage and quality of results than XST.
When using entity instantiations, you can also specify the
architecture name to use for the entity:
u1: entity work.something(some_arch_name)
Component instantiations are very powerful in test benches etc. where
you may be switching out different types of models, and need to do
that in a controlled manner without hacking the "source".
Configurations let you do this. Also, if you are instantiating
anything for which you do not have vhdl source (i.e. black boxes,
etc.) you need to use a component instantiation for that. Then when
you simulate it, you can either use a configuration to bind it to a
simulation model, or use default binding to get you there. These are
the only two times I use component declarations and instantiations any
more.
When using direct entity instantiation, the order of compilation
becomes important. The entity and architecture must be compiled before
the architecture that instantiates them is compiled.
Andy
Mike Treseler
> In any case, you can't get very far in
> simulating and testing 'the rest of the design' if all you have is the
> interface to it (whether it is in the form of a component declaration or an
> entity). In either case though you can write and compile all the code for
> 'the rest of the design'.
I agree. A null entity works just as well
as an unbound component for the purposes
of blocking out a "top-down" design structure.
As Andy said, this requires that I compile
the little boxes before the big ones.
For me, this is much less trouble than
keeping entity and component declarations
in synch.
I use components for synthesis, only
to infer a vendor specific structure
like a PLL, that has no synthesizable
HDL description.
-- Mike Treseler
Colin Paul Gloster
Sat, 24 Feb 2007 23:15:33 GMT, "KJ" <kkjen...@sbcglobal.net> posted:
""Torsten Landschoff" <t.land...@gmx.de> wrote in message
news:1172350375.9...@m58g2000cwm.googlegroups.com...
> On 23 Feb., 18:17, "KJ" <Kevin.Jenni...@Unisys.com> wrote:
>> The 'problem' with component declarations is that (in case you haven't
>> noticed) you've got the exact same information (i.e. the entity name,
>> the generics and the signals) now in at least two places. If you
>> change something (add/remove a signal for example) in one place YOU
>> need to make sure that you update it every other place, the tools tend
>> to not provide any information about differences between the entity
>> and the component. When you forget to do this you tend to get strange
>
> Good point. My VHDL book says that the split component/entity is an
> advantage of VHDL, supporting top down design. I was always wondering
> where the improvement is. My C/C++ experience tells me that redundant
> interface information calls for trouble.
>
In 1993 VHDL was heavily revised and direct entity instantiation was added
so that, you could completely avoid the component declaration. But even
now, 14 years later, most people seem to still use component
declarations...no doubt because books tell you it's a 'good idea' but don't
explain why or explain how it's in any way better than using the entity
declaration (hint, it's not better). You can get exactly to the same point
in being able to do 'the rest of the design' given the entity declaration as
you can with the component declaration.
The idea that you can write code that instantiates a box long before the box
has been designed is a good one. The method you use to accomplish that idea
should not introduce easy ways to make stupid mistakes. Both direct entity
instantiation and component declaration accomplishes the same goal....the
component declaration method introduces the potential for introducing
'stupid mistakes'.....between 1987 and 1993, the committee of people working
on refining VHDL saw this and fixed it...14 years later the textbooks and
professors are still stuck.
Kevin Jennings"
In defense of people who have not realized that they should not teach the
COMPONENT keyword like that, even the quite critical Oz Levia, Serge Maginot,
Jacques Rouillard, "Lessons in Language Design: Cost/Benefit Analysis of
VHDL Features", Design Automation Conference 1994 in which additions from
VHDL93 are mentioned does not seem to disparage components (I have just
glanced at some of the paper, but I did explicitly check for COMPONENT
and ENTITY) for general use.
Also, the search string
(( ( vhdl<in>metadata ) <and> ( entity<in>metadata ) )<and> (component<in>metadata ) ) <and> (pyr >= 1989)
for IEEE Xplore seems to reveal nothing against COMPONENT in the merely
eight documents found, but Andrew Guyler, "VHDL 1076-1992 Languages
Changes", EURO-DAC1992 does have advice against COMPONENT (which is
unfortunately not followed enough in the document itself) and can be
found
not by the search string above but can be found by the search string
(guyler a.<in>au)
, though I originally found it by
+VHDL +component +entity
and restricting to "Published since January 1992 and Published before
December 1994" on HTTP://Portal.ACM.org .