Correct way to use Components?

Hello,

to use a component a component, you have to instatiate it in sequential statement section of the architecture, the section after begin that is blank in your example. The component declaration is only to make the entities interface known. Additional, a syntax for "direct" instantiation of an VHDL entity exists, but it is rarely used.

In Quartus, you have HDL templates since V7.0, that shows e. g. the syntax for component instatiation.

You can use as many components in an architecture as you like to. Basically, the declaration section can contain declarations of types, signals, constants, functions, procedures and components in an arbitrary order. A component has to be declared once, but in many cases, multiple entity instances are referring the declaration, maybe instantiated automaticly in a generate loop.

You ask, how to use multiple components. Is there any reason to assume, that you're limited to one component declaration while you have e. g. multiple signals?

Multiplexers are possible in FPGA and widely used, e. g. for busses. But unlike busses used to interconnect individual logic devices, they have no partyline topology and thus don't use bus switches. They rather are unidirectional point-to-point connections, multiplexed at the receiver by AND/OR logic networks. In HDL, however you can treat them as they would be bidirectional busses connected by tristate drivers, using bidirectional INOUT port type. It is useful anyway to know the physical reality behind these HDL constructs.

Regards,

Frank

It wasn't compiling because I forgot to write "END COMPONENT".

Also I just ended up using tristate buffers to make a 2:1 mux

Thanks though

Don't forget that you can declare components in packages for better re-use. Essentially, a component is a useful abstraction between an instance and the underlying entity. The component declaration can define specific defaults for generics or input ports, omit generics and ports altogether to provide a simpler interface, etc. In most cases, the component binds to the entity of the same name but you can explicitly bind a component to another entity using a configuration. It's a pretty powerful feature of the language.

How low-level do you need to model your MUX? Altera devices don't have internal tri-states, so you probably don't want to implement a clever 2:1 MUX the way you might if you were designing an ASIC. If you can use behavior constructs, it's trivial

if(sel)
    o <= a
else
    o <= b;
end if;

If you need to model it at the structural level, then you just need to implement the boolean function a & sel | b & !sel in gates. :)

Hello,

a FPGA has no internal tristate-drivers, but you can use virtual tristate drivers and bidrectional busses for internal connections anyway. The HDL synthesizer converts them to multiplexers. The problem is, that a signal can't have more than one driver. This isn't actually different from real bidirectional busses, but the HDL synthesizer must be able to see at any time which signal drives the "bus" to infer a multplexer. A set of mutual exclusive "chip select" conditions can do.

Regards,

Frank

--- Quote Start ---

Hello,

to use a component a component, you have to instatiate it in sequential statement section of the architecture, the section after begin that is blank in your example. The component declaration is only to make the entities interface known. Additional, a syntax for "direct" instantiation of an VHDL entity exists, but it is rarely used.

--- Quote End ---

With respect, I use it all the time and so do many engineers. IMHO it's much better, saves you having to update the component every time your entity changes.

The only time I use COMPONENTS is when I want to use a configuration on them. I do this to run a particular testbench a number of times with different parameters.

Cheers,

Martin

Hello Martin,

I'll check out, if your suggestion could ease my work.

Thank you,

Frank

Please do give it a try, it makes an enormous difference! Even more so if (like the OP) your components are being placed in the architecture, rather than a package, so when an entity changes, you have to update it in lots of places...

Cheers,

Martin

The only problem with direct entity instantiation - it breaks incremental compilation flows quite easily, unless you religiously put your entity in a separate file from its architectures. With Quartus II Incremental Compilation, you'll be in a world of pain if you don't. When you directly instantiate the entity, the current architecture depends on the entity's source file. If the entity's source file also contains its architectures, then every time you change an architecture, you'll trigger recompilation of the parent. If you change a lower-level architecture, you can easily force re-compilation of all parent partitions.

Using a component breaks the dependency between the instantiation and the entity, unless you use configurations.

Speaking of Incremental Compilation, that's also why I don't like internal tri-states. Sure, they are convenient when multiplexing data from numerous hierarchies onto an internal bus without routing all the data signals to a common point and multiplexing explicitly.

However, you can easily partition a design in a way that triggers on error in Quartus II. For example, if your internal bus feeds partition boundary output or inout, then the tool creates an I/O driver, thinking you're possibly describing an actual top-level pin with tri-state behavior. It can't simply look up in the hierarchy for a top-level pin connection because that wouldn't be an incremental flow - you can't make synthesis decisions using information from other partitions, which should be able to vary independently. Or what if you tri-state bus is split across partition boundaries? Not exactly fun times, let me tell you from experience. :)

I imagine all tools have quirks in supporting internal tri-states.

Hello,

thanks for mentioning the incremental compilation aspect. I agree that a multiplexer if inferred from an internal tristate construct can't be precompiled. But I wonder, if this would be basically different with an Avalon bus, as long as the multiplexer making up a bus receiver isn't completely defined.

It's also true, that different tools are treating such contructs slightly different, e. g. to enable ModelSim simulation, the internal tristate ports have to be initialized to 'Z'. Such lack of clarity could be reason enough to avoid it. I'm far from recommending the technique for general use, just wanted to mention the option. Anyway I'm interested to learn different views on such techniques.

Regards,

Frank