VHDL: Architecture naming and interpretation

Question

Note: I am using Xilinx's ISE and have an FPGA board to work with (with switches and lights and so on), and I've hacked together some simple projects so far. At the same time I'm reading several tutorials to build a foundation for what I'm doing.

I've seen various entities and their architectures mentioned in the reference materials I've been going through, but the naming is often confusing. Often instead of "architecture rtl of.." or "architecture structural of..." I'll see "architecture foo of..." or even "architecture arch of..."

I realize (belatedly) that the architecture name is just as arbitrary as the entity naming, though there are style guides that suggest more consistent naming conventions can be used to avoid this issue. This leads me to a few questions:

• Looking at an entity, how can one determine the actual architectural model being used without hints from the architecture name? RTL, behavioral, structural... they appear to be quite similar to my learner's eye (assuming the examples I've seen were actually named correctly). A simple but obvious example would be helpful here (or a pointer to one).

• If specifying multiple architectures for a single entity (which I understand is possible) do you simply give the architectures different names in the same file or...?

• Are the architecture names confined to a given entity (that is, is there any problem with "namespaces" by using the same architecture name over multiple entities)?

Edit: and one more:

• It seems there is a distinction between RTL and behavioral, but as mentioned above I'm not really seeing it in the examples I've seen (often I only see one architecture being defined). Is one architecture more common than the others?

What I've been looking for is a comprehensive yet simple multi-component project (little components), written using best practices (proper naming, not all crammed into one file, etc.) but I've yet to find one. I find properly crafted sample projects very useful for illuminating basic principles and best practices. If you know of such an example project I'd be grateful for a pointer to that as well. (If nothing else, perhaps once I figure this out I can share one of my own...)

Answer 1

Here are the architecture types:

Behavioural:

General notes:

• Traditionally no heirarchy (only one file, no components instantiated) although this varies amongst tools.
• Very quick to simulate.
• Signals behaviours are defined.
• When behavioural is used for simulation only it may contain non-synthesizable code. Behavioural intended for synthesis must naturally be synthesizable.

Xilinx specific notes

• Generally core generator models are pre-synthesis .vhd files

Structural:

General definition

• Only instantiates components and wires them together (hierarchical).
• Slower to simulate than behavioural.
• No real signal behaviour definition in top level.
• Only synthesizable code.

Xilinx xpecific notes

• Core generator models don't take timing into account.
• Generally core generator models instantiate post-synthesis netlists

The above are basically the traditional main two animals of architecture. Very commonly a "mixed" definition is used, which contains properties of both.

RTL:

RTL what is actually put on the FPGA at the end of the day. So this is synthesizable code that defines the behaviour of the system and is made up of a code hierarchy:
The bottom layers will be synthesizable behavioural, where the nitty gritty of the signal behaviour is defined, and the upper levels will be structural, where the behavioural components are tied together to create a big top level "block diagram" if you will.

On to multiple architectures:

Architectures can be all in one file or in multiple files. The only important thing is that the entity is compiled first, and that the architecture to be used is specified.

This book is very handy and details this kind of thing quite well.

There is no hard and fast rule about how things should be done in terms of having distinct behavioural and structural models or just mixing them. Usually in huge firmware designs (or in big corporations where code is shared and re-used) it is useful to distinguish between the two to simplify matters, however at the end of the day it comes down to whatever works for you.

Answer 2

Looking at an entity, how can one determine the actual architectural model being used without hints from the architecture name?

You can't - when it is instantiated or configured the architecture can be specified (if there is more than one to choose from) or a default will be chosen for you.

If specifying multiple architectures for a single entity (which I understand is possible) do you simply give the architectures different names in the same file or...?

You give them different names. It doesn't have to be within the same file (in fact VHDL cares a lot less than you might think about what's in what file)

Are the architecture names confined to a given entity (that is, is there any problem with "namespaces" by using the same architecture name over multiple entities)?

They are "attached" to an entity, so can be reused.

I often use a1 as my architecture for everything synthesisable as

• rtl implies lower level (to many readers) than I write at.
• behavioural often implies non-synthesisable (to some readers)
• synth is used by the synthesiser for it's model (otherwise I'd have used that)

a1 has been non-conflicted so far and doesn't cause confusion ;)

If I actually have more than one architecture, I tend to name them verbosely (for example hard_multipliers and lut_multipliers for a filter which instantiates - or not - MUL18 blocks).

Very often you only have one architecture, so it doesn't matter. Good entity names are much more important.

It seems there is a distinction between RTL and behavioral, but as mentioned above I'm not really seeing it in the examples I've seen (often I only see one architecture being defined). Is one architecture more common than the others?

It's historical - you didn't used to be able to synthesise "behavioural" code (which at one point included things like adding!) - so you created an RTL version which instantiated adders and the like. (That's as I understand it - I've been writing behavioural (and yet still synthesisable) code since I started VHDLing in about 1999!)

Answer 3

First of all, real world architecture designs can't be strictly categorized like that. Why limit yourself? You may want to instantiate other entities and connect them "structurally", but add a process or concurrent assignment here and there to add some "rtl" logic, and perhaps use some "behavioral" coding patterns so that the synthesizer figures out some of the details that you don't care about (like adding without specifically instantiating an adder with area/pipelining/performance parameters), all in the same architecture.

More importantly, you must understand what is synthesizable in current asic/fpga technologies and what is not, and this is irrespective of the architecture model.

An entity can be implemented in multiple ways, even allowing slightly different behaviors, so you may have multiple architectures for the same entity. Additionally, you may have an architecture for simulation only (usually non-synthesizable) that may simulate quicker than the "real" version, which may come in handy when testbenching large designs as a whole. You would give these architectures names that help you remember what makes them different to the others, and simply bhv/str/rtl is usually not enough or accurate, given the hybrid nature of real world designs.

Regarding your specific questions, architecture declaration is tied to an entity name, so there is no namespace issues with architectures of the same name for different entities. Just use different names for architectures for the same entity.

Architectures can reside in different files, you just need to ensure that the entity declaration is compiled first.

You can select which architecture to use when instantiating the entity, or using configuration statements. If you don't, the default is 'usually' the last architecture that the compiler saw for a given entity declaration.