VHDL language design question

[Neil Zanella]

Hello,

I would like to know how come the VHDL language was designed in such a way
that entity statements don't have the begin keyword after the is keyword
but architecture statements do require it. Is there any particular reason
for such a design decision when the VHDL language was standardized?

Thanks,

Neil

 

[Mike Treseler]

Neil Zanella wrote:

I would like to know how come the VHDL language was designed in such a way
that entity statements don't have the begin keyword after the is keyword
but architecture statements do require it.

BEGIN is optional for an entity,
but is only required to introduce a process.

An entity containing a process is as rare
as an architectures without one, so the
difference in syntax makes sense.


-- Mike Treseler

 

[Thomas Stanka]

Neil Zanella <nzanella@cs.mun.ca> wrote:

I would like to know how come the VHDL language was designed in such a way
that entity statements don't have the begin keyword after the is keyword
but architecture statements do require it. Is there any particular reason
for such a design decision when the VHDL language was standardized?

You are wrong. There is allways a BEGIN between the "declarative"
part[1] and the "executable" part[2] of an entity or an architecture
(or package). But you don't need an BEGIN if you don't have an
executable part.
A normal entity has only a declarative part so you don't need to write
BEGIN.
On the other hand it is very unusual to have a architecture without an
executable part so you will allways use the BEGIN in an architecture.

bye Thomas

[1] port description, generic description, function, type, signal
declarations,...
[2] processes, structural and concurent statements

 

[Neil Zanella]

Thanks,

I was not aware about the fact that entities could have a block of code
following the begin keyword just like architectures do. It must indeed
be a seldomly used features since I have not seen any examples around
that actually make use of it.

Regards,

Neil

usenet_10@stanka-web.de (Thomas Stanka) wrote in message:

You are wrong. There is allways a BEGIN between the "declarative"
part[1] and the "executable" part[2] of an entity or an architecture
(or package). But you don't need an BEGIN if you don't have an
executable part.
A normal entity has only a declarative part so you don't need to write
BEGIN.
On the other hand it is very unusual to have a architecture without an
executable part so you will allways use the BEGIN in an architecture.

bye Thomas

[1] port description, generic description, function, type, signal
declarations,...
[2] processes, structural and concurent statements

 

[VhdlCohen]

I was not aware about the fact that entities could have a block of code
following the begin keyword just like architectures do. It must indeed
be a seldomly used features since I have not seen any examples around
that actually make use of it.

Per LRM
entity_declaration ::= entity identifier is
entity_header
entity_declarative_part
[begin
entity_statement_part ]
end [entity] [entity _simple_name ] ;

entity_statement ::=
concurrent_assertion_statement
|passive _concurrent_procedure_call
| passive_process_statement
All such statements must be passive (see 9.2). Such statements may be used to
monitor the operating conditions or characteristics of a design entity.

Thus, what's in the entity statement cannot make active assignments. It can
only monitor.
Typically, this feature is not often used in the entity.
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

 

[Allan Herriman]

On 19 Oct 2003 06:58:13 GMT, vhdlcohen@aol.com (VhdlCohen) wrote:

I was not aware about the fact that entities could have a block of code
following the begin keyword just like architectures do. It must indeed
be a seldomly used features since I have not seen any examples around
that actually make use of it.


Per LRM
entity_declaration ::= entity identifier is
entity_header
entity_declarative_part
[begin
entity_statement_part ]
end [entity] [entity _simple_name ] ;

entity_statement ::=
concurrent_assertion_statement
|passive _concurrent_procedure_call
| passive_process_statement
All such statements must be passive (see 9.2). Such statements may be used to
monitor the operating conditions or characteristics of a design entity.

Thus, what's in the entity statement cannot make active assignments. It can
only monitor.
Typically, this feature is not often used in the entity.

I have put assert statements in the entity. (Umm, perhaps once or
twice.) This was to check some odd requirements on interactions
between generics.
I put the assert statements in the entity rather than the architecture
to make them more visible to other designers wanting to instantiate my
module.

Regards,
Allan.

 

[VhdlCohen]

Typically, this feature is not often used in the entity.

I have put assert statements in the entity. (Umm, perhaps once or
twice.) This was to check some odd requirements on interactions
between generics.
I put the assert statements in the entity rather than the architecture
to make them more visible to other designers wanting to instantiate my
module.

Regards,
Allan.

Obviously, that can be done, but this is not widely used.
By putting assertions in the architecture, they can be placed closer to the
source.
Putting assertions in the entity ignores any architectural issues.
Some assertions may not necessarily be valid for all architecture, unless they
relate
to the interfaces only. Also, assertions at the entity level have no
visibility into
architectural objects.

As we move toward assertion-based verification with PSL Property Specification
Language,
PSL properties and assertions are either put in the architecture of in separate

verification units (called vunit). There are not put in entities.
This policy reaffrms the trend!
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

 

[Marcus Harnisch]

vhdlcohen@aol.com (VhdlCohen) writes:

By putting assertions in the architecture, they can be placed closer to the
source.
Putting assertions in the entity ignores any architectural issues.
Some assertions may not necessarily be valid for all architecture, unless they
relate
to the interfaces only. Also, assertions at the entity level have no
visibility into
architectural objects.

Which might be exactly what you want for, say, protocol monitors. An
interface has to obey the same timing rules for all architectures. So
putting these assertions into the entity makes immediately clear which
ones are protocol assertions and which ones are implementation
specific. I very nice feature I must say.

Best regards,
Marcus
--
"Requires IE because of the security reasons"
-- from PC Depot

Mint Technology, a division of LSI Logic
Marcus Harnisch <marcus_harnisch@mint-tech.com>
Tel: +1-781-768-0772
200 West Street, Waltham, MA 02431

 

[VhdlCohen]

Putting assertions in the entity ignores any architectural issues.
Some assertions may not necessarily be valid for all architecture, unless
they
relate
to the interfaces only. Also, assertions at the entity level have no
visibility into
architectural objects.

Which might be exactly what you want for, say, protocol monitors. An
interface has to obey the same timing rules for all architectures. So
putting these assertions into the entity makes immediately clear which
ones are protocol assertions and which ones are implementation
specific. I very nice feature I must say.

Best regards,
Marcus

Excellent point! But with many many howevers ...
Protocols are temporal, and in VHDL you'll need FSM (i.e., writing to
local signals and variables, which you can't do in processes in entities.
Thus, the types of protocol checking is very very limitied.
Typically, verification engineers put all that protocol checking in
testbenches.
ABV in architural code is great for documentation and verification.
PSL uses a short notation. For example, to state that when you have a
new request (req and no ack), an ack should be received within 4 cycles after
the req"
-- PSL code
-- psl sequence qACTIVE_REQUEST is {req and not ack};
-- psl property REQ_ACK_EVENTUALLY_IN_4_CYCLES is
-- always ({qACTIVE_REQUEST} |=> {[*0 to 3]; ack}
-- abort (not reset_n or cancel));
VHDL qould require an FSM for that test.
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

 

[Allan Herriman]

On 20 Oct 2003 05:36:04 GMT, vhdlcohen@aol.com (VhdlCohen) wrote:

Typically, this feature is not often used in the entity.

I have put assert statements in the entity. (Umm, perhaps once or
twice.) This was to check some odd requirements on interactions
between generics.
I put the assert statements in the entity rather than the architecture
to make them more visible to other designers wanting to instantiate my
module.

Regards,
Allan.

Obviously, that can be done, but this is not widely used.

Actually, I think I may have (synthesis) tool problems, which caused
me to drop the approach.

Regards,
Allan.

 

[Thomas Stanka]

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

On 20 Oct 2003 05:36:04 GMT, vhdlcohen@aol.com (VhdlCohen) wrote:

Typically, this feature is not often used in the entity.

I have put assert statements in the entity. (Umm, perhaps once or
twice.) This was to check some odd requirements on interactions
between generics.
I put the assert statements in the entity rather than the architecture
to make them more visible to other designers wanting to instantiate my
module.

Obviously, that can be done, but this is not widely used.

Actually, I think I may have (synthesis) tool problems, which caused
me to drop the approach.

A simple synthesis_on/off pragma would help .
We use a process in each entity (and architecture/package as well) to
log the used entity (a version control string) in a file during
simulation and I had never ever problems with any tools (even the
worst vhdl-parser seems to get along with this process).

bye Thomas

 

[Marcus Harnisch]

Ben,

vhdlcohen@aol.com (VhdlCohen) writes:

Protocols are temporal, and in VHDL you'll need FSM (i.e., writing to
local signals and variables, which you can't do in processes in entities.
Thus, the types of protocol checking is very very limitied.

That is unfortunately true if you consider current VHDL. I heard that
some people are working on fitting PSL into VHDL assertions. At least
this is what I understood. Now with (possibly PSL enriched) 'assert's
being a legal construct in an entity that would be a Really Cool
Thing(tm).

Typically, verification engineers put all that protocol checking in
testbenches.

Just because it's being done that way doesn't make it better. Designs
(including their entity) are usually better suited for reuse than a
testbench. So shipping the design with embedded protocol checker means
a less cluttered testbench and immediate availability of essential
verification code.

I agree and this is why I am looking forward to the VHDL-200x efforts
of integrating PSL into VHDL. Hopefully as a real language element,
rather that hiding it in comments.

VHDL qould require an FSM for that test.

Can you not have a passive process in the "statement part"? In most
cases PSL would of course be the more elegant way to describe
things. Just like in most cases textual regular expressions are more
elegant than coding the equivalent parser state machine by hand.

Regards,
Marcus
--
"Requires IE because of the security reasons"
-- from PC Depot

Mint Technology, a division of LSI Logic
Marcus Harnisch <marcus_harnisch@mint-tech.com>
Tel: +1-781-768-0772
200 West Street, Waltham, MA 02431

 

[VhdlCohen]

Marcus,
....

Thus, the types of protocol checking is very very limitied.

That is unfortunately true if you consider current VHDL. I heard that
some people are working on fitting PSL into VHDL assertions. At least
this is what I understood. Now with (possibly PSL enriched) 'assert's
being a legal construct in an entity that would be a Really Cool
Thing(tm).
The way I see it (I am on that committee) is that VHDL200x will integrate PSL

into VHDL
without having the comments. I don't believe that the PSL used in the VHDL200x
will be any (or that much) different than the latest version of PSL, at the
time VHDL200x is released for approval.
However, when will VHDL200x be approved? When will vendors fully suppport it?

This may be years from now.

Typically, verification engineers put all that protocol checking in
testbenches.

Just because it's being done that way doesn't make it better. Designs
(including their entity) are usually better suited for reuse than a
testbench. So shipping the design with embedded protocol checker means
a less cluttered testbench and immediate availability of essential
verification code.
There is something positive to be said about having separate engineers work on

verification, including protocol checking, thatn on the RTL design. Thus
having verification done in testbench environment is good. I also like
embedded assertions (more easily expressed in PSL) because they can document
the design, and can detect errors closer the source (whitebox verification).
For testbench and protocol checks, I prefer seeing an external module (or
testbench) that uses PSL. That model shold be written by a separate
verification engineer.

[lots of PSL praising]
Are you surprised? Am working on a second edition of current book to be

released next year.
PSL is pretty cool!

I agree and this is why I am looking forward to the VHDL-200x efforts
of integrating PSL into VHDL. Hopefully as a real language element,
rather that hiding it in comments.
You could also write separate vunits. Embedded assertion as comments is OK

though.
A PSL smart compiler recognized the PSL described as comments. No big deal!
This should not be a reason for not using PSL, and for salivating for
VHDL200x...
... your mouth would be dry by then...

VHDL qould require an FSM for that test.

Can you not have a passive process in the "statement part"?
I am not sure if you can write into variables of a process embedded in an

entity.
But you definitely cannot assign values onto signals local to an entity.

In most

cases PSL would of course be the more elegant way to describe
things. Just like in most cases textual regular expressions are more
elegant than coding the equivalent parser state machine by hand.

True

----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

 

[Jim Lewis]

.... SNIP ...

I heard that some people are working on fitting PSL into VHDL assertions.

VhdlCohen wrote:

The way I see it (I am on that committee) is that VHDL200x will integrate PSL
into VHDL
without having the comments. I don't believe that the PSL used in the VHDL200x
will be any (or that much) different than the latest version of PSL, at the
time VHDL200x is released for approval.
However, when will VHDL200x be approved?

I believe assertions are planned for VHDL-200X's fast track.
This would mean the target for getting these integrated into
the language and ready for balloting is Q1/Q2 of 2004.

When will vendors fully suppport it?

This may be years from now.

Interesting question. I don't think the pessimism is warranted.
Mentor/ModelTech are providing strong support to the VHDL-200X
effort. Cadence is providing strong support for PSL.
My belief is that both companies will be early adopters of
the integration of PSL into VHDL (possibly even before the
specification balloting finishes).


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Marcus Harnisch]

Ben,

vhdlcohen@aol.com (VhdlCohen) writes:

There is something positive to be said about having separate engineers work on
verification, including protocol checking, thatn on the RTL design. Thus
having verification done in testbench environment is good. I also like
embedded assertions (more easily expressed in PSL) because they can document
the design, and can detect errors closer the source (whitebox verification).
For testbench and protocol checks, I prefer seeing an external module (or
testbench) that uses PSL. That model shold be written by a separate
verification engineer.

Sorry that was a misunderstanding on my side. I was somehow
associating the word 'testbech' with the top level, tying verification
environment and DUT together. This would certainly get very ugly if
you'd slap everything in there...

In fact I prefer the 'separate verification engineer' model. But that
doesn't have to mean people cannot have access to the same file
(especially to the functionally isolated entity). But I guess a
passive 'shadow component' would be a better way. It could be hooked
up to the same signals and contained only the verification code. Plus,
you can bill the customer twice

Is anybody working on Aspect Oriented VHDL?

Are you surprised?

Not at all. I didn't have the chance to use PSL, yet, but I am
certainly looking forward to it. What I like most (from looking at the
LRM) is 'abort', which doesn't exist in e temporal expressions for
instance. There are workarounds though. (don't want to get too
off-topic...)

This should not be a reason for not using PSL, and for salivating for
VHDL200x...
... your mouth would be dry by then...

I am afraid that is true. I get some hope from the fact that the 'x'
is only in the last digit.

Regards,
Marcus
--
"Requires IE because of the security reasons"
-- from PC Depot

Mint Technology, a division of LSI Logic
Marcus Harnisch <marcus_harnisch@mint-tech.com>
Tel: +1-781-768-0772
200 West Street, Waltham, MA 02431