direct instantiation problem

[gbounce]

modelsim doesn't complain when i instantiate the clock buffer like this:

library axcelerator;
use axcelerator.hclkbuf;

---

inst_hclkbuf : entity axcelerator.hclkbuf
  port map (
    pad => clk_in,
    y   => clk_out
  );

when i go to synthesis using synplify, it errors out with the message: Instantiated entitty axcelerator.hclkbuf has not been analyzed.

if i change to whats below it works fine.

library axcelerator;
use axcelerator.hclkbuf;

---

component hclkbuf 
  port (
    pad : in  std_logic;
    y   : out std_logic
  );

----

inst_hclkbuf : hclkbuf
  port map (
    pad => clk_in,
    y   => clk_out
  );

synplify is linked to the axcelerator library properly and it shows up under the design hierarchy. it appears it should compile in the proper order. any ideas?

 

[TrickyDicky]

You have got the compile order wrong. You need to compile the hclkbuf entity first.

 

[atulaxc]

when synthesis works fine: I guess its still not reading the component from library. Instead its picking it from your component declaration. Are you sure the component resides within the library?

 

[K-J]

modelsim doesn't complain when i instantiate the clock buffer like this:

library axcelerator;
use axcelerator.hclkbuf;

---

inst_hclkbuf : entity axcelerator.hclkbuf
  port map (
    pad => clk_in,
    y   => clk_out
  );

when i go to synthesis using synplify, it errors out with the message: Instantiated entitty axcelerator.hclkbuf has not been analyzed.

if i change to whats below it works fine.

library axcelerator;
use axcelerator.hclkbuf;

---

component hclkbuf 
  port (
    pad : in  std_logic;
    y   : out std_logic
  );

----

inst_hclkbuf : hclkbuf
  port map (
    pad => clk_in,
    y   => clk_out
  );

synplify is linked to the axcelerator library properly and it shows up under the design hierarchy. it appears it should compile in the proper order. any ideas?

Modelsim doesn't complain because at some point you must have compiled the hclkbuf entity into the axcelerator library. That could have been two years ago, but as long as it can find the axcelerator library and the axcelerator.hclkbuf component it is happy. Synthesis though requires you to start with a clean slate on every run. Every entity needs to be defined in some source file prior to the point where you try to instantiate it. If you don't you get the error that you reported.

However, when you declare a component, what you're basically doing is creating an IOU of the entity. A component declaration basically says that the entity declaration can come later (or it may have already been compiled also), here is what it will look like when it does come along, so don't complain (i.e. flag an error) just yet. The reason is that when analyzing a source file, it simply needs to know the signal types and check that they match with the signals that you attach to the ports. It can do that when you declare the component or if it has already compiled the entity. In the end you will still need the entity and the architecture. Given only the component declaration, synthesis temporarily treats it like a black box...but in order to get a bitstream that programs a device that 'black box' needs to be implemented by something whether it is from your code or from some vendor's code.

The advantage of using a component is that if you declare them for every entity in your code, then there is absolutely no 'compile order' for the source files. They can be analyzed in any order. Sounds nice, but there are drawbacks and that 'compile order' is not that hard to get right, you only do it once (or whenever you add new files to the project) so it's not usually that big of an advantage.

The drawback of using components ('specially in the architecture of the code that is to instantiate that component) is that you have to manually maintain the source that declares the component to make it be the same as the entity. If there is a mismatch, the error messages that pop out of the tools come out further downstream and can be less than enlightening. In short, it's more tedious to find and fix the problem. Consider this scenario:
- Create your own wonderful reusable widget
- Use that widget in several source files (maybe in several projects)
- Change the interface to that widget by adding some additional signal or generic

Now you have to manually search for every instance where you used the widget (and therefore declared the component) to update the component definition that you have to add the additional signal or generic. Miss a file and it will analyze just fine, but get caught further dowstream with some form of 'missing component' error because you didn't fulfill the IOU because your entity doesn't match the component. In contrast, if you use direct entity instantiation, you simply 'compile all' and each source file that instantiates the component will be flagged and easily fixed. Much easier.

If you do choose to use component declarations anyway, the better method is to create a package and put the component declaration in the package which is preferably in the same file as the entity. Now when the interface changes, the single component declaration and the entity can be edited together in one file rather than many files. The code that instantiates the widget simply has a 'use work.my_widget.all' statement in it. Still better to use direct entity instantiation in synthesizable code but a dramatic improvement over defining the component in the architecture.

The bottom line is that using component declarations where they are not needed (i.e. to interface to vendor IP that you don't get source code for), you create a one time advantage (i.e. no compile order). But by doing so you create the potential for obscure errors throughout the entire lifetime of that code. The choice is yours.

Kevin Jennings

 

[gbounce]

well, i guess i left out a key piece of information.

my situation is different because we have special scripts and linked libraries depending on the fpga we're developing for. the problem is that the axcelerator library is not in my local directory with all the other files, but rather sitting on a server somewhere. from what i read it sounds like you can only perform a direct instantiation what is within one level of hierarchy of your local code.

if thats incorrect, please let me know. otherwise i think i'm stuck with declaring the component and then instantiating it later unless i create a local copy of the buffer component.

 

[TrickyDicky]

Direct instantiation can be done from any visible and compiled library. I can only assume you havent set the library up properly, or it is missing that entity.

 

[K-J]

well, i guess i left out a key piece of information.

my situation is different because we have special scripts and linked libraries depending on the fpga we're developing for.

What do you think is different? And why do you think that has any bearing on the problem you posted? (Hint: it doesn't)

the problem is that the axcelerator library is not in my local directory with all the other files, but rather sitting on a server somewhere.

Why do you think that is a problem? There is no requirement for any sim or synthesis tool that I'm aware of that requires files to be on the local PC.

from what i read it sounds like you can only perform a direct instantiation what is within one level of hierarchy of your local code.

Then you misread.
- You can only instantiate 'one level of hierarchy' no matter what. What does it even mean to instantiate a grandchild? You can only instantiate a child.
- What is 'local code'?

if thats incorrect, please let me know.

You're incorrect

otherwise i think i'm stuck with declaring the component and then instantiating it later unless i create a local copy of the buffer component.

And this action is not a solution anyway.

Unless you don't plan to simulate or synthesize the code, using components to 'fix' the problem that you posted will not fix anything. All it will do is delay the reporting of an error until further downstream as I mentioned in the previous post with various other consequences as well.
- You won't be able to simulate without a compiled entity and architecture in a library accessible to the simulator.
- You won't be able to produce the bitstream needed to program a part without the compiled netlist

Using 'components' does not address either of the missing items.

Kevin Jennings

 

[gbounce]

thanks tricky.

ya, it turns out the component declarations were sitting inside a package in the 'library' file i was trying to use. needed to tack on an extra name in the use line and take off the entity.axcelerator in the instantiation.

kevin,

i think what was confusing me is it was getting through synthesis/PAR with just the component declaration/instantiation, or if i call the library/package, just the entity instantiation. like you said, it would treat the buffer as a black box.

at what point in synthesis / PAR does the tool see the black box of a clock buffer and replace it with the real thing in the netlist? does synthesis actually do this or is it left up to the vendor's PAR tool? is the synthesis tool aware of all the clock buffers (or other primitives) entity names of the FPGA you're targeting?

 

[TrickyDicky]

There is no such thing as a "library" file. A library exists as a setup in the compiler, not in any file. entities and packages are added to a library. So what you had was a package full of components. If that library contains an entity you can always directly instantiate it.

If you have a component, it is treated as a black box during elaboration, and synthesis picks up the entity or netlist. This is why components can be annoying, because its not until synthesis any missmatches are picked up. WIth direct instantiation the connections are tested during the elaboration phase, and any problems are picked up very soon compared to the other method.

But you can only use direct instantiation when the entity you are instantiating is another peice of VHDL code. If its another HDL or a netlist, you have to use a component.