Using OPEN in port map

R

rickman

I was reading in Ben Cohen's book that OPEN has some restrictions.
One is that it can not be used with a specified set of items in an
array when the other items are mapped to other signals. Here is an
example.

Mul: multiply
PORT MAP (
SysClk => SysClk, -- System clock, 12.288 MHz?
Start => Start, -- Load multiplican and init result
Multiplicand => LinDat,
Multiplier => std_logic_vector(AudioGain),
Product(ProdHigh downto ProdHigh - MulOut'high) => MulOut,
Product(ProdHigh - MulOut'high - 1 downto 0) => OPEN,
Done => Done
);

According to Ben Cohen book, the product can not be split this way
using OPEN. When I tried it with Synplicity it seems to accept this
syntax. Ben's book is a bit older and refers to the '93 standard. I
believe there is a newer VHDL standard, 200x. Is this something that
has changed since '93 or is the Synplicity tool just being
magnanimous? Should I change it so that it will work with other tools
or do most tools accept this?

Rick

PS Don't ask me the name of the book, I don't have it with me. It was
a larger book and consisted of many examples of specific aspects of
the language rather than a general explanation of the language. I
like paper books, but sometimes I like the portability of e-books
(pdf).
 
K

KJ

Product(ProdHigh downto ProdHigh - MulOut'high) => MulOut,
Product(ProdHigh - MulOut'high - 1 downto 0) => OPEN,
According to Ben Cohen book, the product can not be split this way
using OPEN.  When I tried it with Synplicity it seems to accept this
syntax.  Ben's book is a bit older and refers to the '93 standard.  I
believe there is a newer VHDL standard, 200x.  Is this something that
has changed since '93 or is the Synplicity tool just being
magnanimous?  Should I change it so that it will work with other tools
or do most tools accept this?

Modelsim 6.4 (which is not the latest/greatest) reports the following
(compiled with either VHDL '93 or '02)
Error: Formal "xyz" must not be associated with OPEN when subelements
are associated individually

On the other hand, this particular item is something that I submitted
to the VHDL standards group a few years back and was accepted at that
time as a 'good' idea...maybe it made it into VHDL '08...if not theirs
always VHDL 201x.

Kevin Jennings
 
J

JimLewis

Unfortunately it is illegal (still) in 2008 revision.

Jim
SynthWorks VHDL Training
 
J

JimLewis

On the other hand, this particular item is something that I submitted
to the VHDL standards group a few years back and was accepted at that
time as a 'good' idea...maybe it made it into VHDL '08...if not theirs
always VHDL 201x.

Kevin,
Do you have a bug ID for it? I was looking through the bugzilla
database and could not find it.

Jim
 
K

KJ

Kevin,
Do you have a bug ID for it?  I was looking through the bugzilla
database and could not find it.

Jim

Jim,

No I don't have a bug ID. I also haven't been able to locate anything
specific but I'm pretty darn sure I went through the eda-stds.org link
(http://www.eda-stds.org/vasg/#Enhancements) to submit the request.
Based on other bits and pieces, I believe the request was submitted in
2005.

Should another one be submitted to cover this case? FYI, as I
mentioned back in 2005, the place where I think opens in port maps are
most handy is when the VHDL code is generated by a CAD system and
represent a PCBA netlist. When designing a board, it certainly is the
case where you can legally have unconnected pins and those pins might
happen to be bits of some 'bus' of related pins. Back in 2005, I had
a device which happened to have a 24 bit data bus of which I was only
using 16 bits and the part had no requirement to drive unused pins on
that bus.

On a side note, I also submitted a request for a totally different
feature back in June 2008. On that one I got a reply back that said
it had been assigned number 2132. The Bugzilla.mentor.com site says
that bug #2132 does not exist so I have no idea what number that
request have been refiled under or if that request has been lost or
reached some other disposition. If you need any more info, I can
forward you what I have on that one.

Kevin Jennings
 
W

Weng Tianxiang

Jim,

No I don't have a bug ID.  I also haven't been able to locate anything
specific but I'm pretty darn sure I went through the eda-stds.org link
(http://www.eda-stds.org/vasg/#Enhancements) to submit the request.
Based on other bits and pieces, I believe the request was submitted in
2005.

Should another one be submitted to cover this case?  FYI, as I
mentioned back in 2005, the place where I think opens in port maps are
most handy is when the VHDL code is generated by a CAD system and
represent a PCBA netlist.  When designing a board, it certainly is the
case where you can legally have unconnected pins and those pins might
happen to be bits of some 'bus' of related pins.  Back in 2005, I had
a device which happened to have a 24 bit data bus of which I was only
using 16 bits and the part had no requirement to drive unused pins on
that bus.

On a side note, I also submitted a request for a totally different
feature back in June 2008.  On that one I got a reply back that said
it had been assigned number 2132.  The Bugzilla.mentor.com site says
that bug #2132 does not exist so I have no idea what number that
request have been refiled under or if that request has been lost or
reached some other disposition.  If you need any more info, I can
forward you what I have on that one.

Kevin Jennings

Hi KJ,
I think you are not only right on the output pins, but also right on
the input pins.

When a module is shared by several upper modules, there is a
possibility that each upper module may have specific input pins other
upper modules don't share, and when each upper module calls this
module, they can leave unused input signals in OPEN state. When VHDL
compiler meets input signals with open connection, reports an fatal
error.

This way more upper modules can share a based module with different
number of input signals. Currently I have to supply DUMMY inputs which
are ineffective in production, and non-productive in coding.

When an input signal is connected to "OPEN', it means this input is
never used in this module, and if used, it is a fatal error.

It is a much clearer and clever idea to permit to use "OPEN" for input
signals to a module too.

Weng
 
R

rickman

rickman wrote:

<snip>








Hi Rick,
   it was legal to do that (split an array up on the left of the
association and leave parts of it open) in VHDL 87. It was made illegal
in VHDL 93, i.e either the whole array may be left unconnected, or every
element of the array must be associated,

regards
Alan

Hi Alan,

I still have not had a chance (read that as "remembered") to look this
up in Ben's book. But I am surprised that it would have been legal in
'87 and made illegal in the '93 standard, unless there was some reason
for it. Is there any complication to the tools that allowing this use
of OPEN would create? I am not really familiar with the innards of
how the tools work, but I believe things like the widths of busses are
defined in an initial "compile" and then the modules are used in the
"elaborate" phase. It might be an issue where a given module needs to
be compiled once and then used in many places. I think the use of
OPEN would cause the associated inputs and outputs to be dropped which
can eliminate logic. Clearly you can't use a common module if
different uses have different logic.

Is that why using OPEN in this way was made illegal?

Rick
 
K

KJ

Hi KJ,
I think you are not only right on the output pins, but also right on
the input pins.

I was talking about inputs, outputs and inouts.
When a module is shared by several upper modules, there is a
possibility that each upper module may have specific input pins other
upper modules don't share, and when each upper module calls this
module, they can leave unused input signals in OPEN state. When VHDL
compiler meets input signals with open connection, reports an fatal
error.

Input pins in a module that are not part of a bus and that are not
used in certain applications simply need to have an initializer
applied to them.

xyz: in std_ulogic := '0';

If the user then does not connect up anything to 'xyz' it will be
treated as a '0' since that's what the initializer sets it to...no
errors. The problem comes in when 'xyz' is a *vector* and not all of
the bits in the vector are used in certain applications.
This way more upper modules can share a based module with different
number of input signals. Currently I have to supply DUMMY inputs which
are ineffective in production, and non-productive in coding.
It is a much clearer and clever idea to permit to use "OPEN" for input
signals to a module too.

If you're talking about scalars and not vectors, then look into using
initializers on the input pins instead.

KJ
 
A

Andy

Couldn't you use an unconstrained vector port? Of course whatever bits
you do want to hook up must be contiguous. And it does not help with
record types.

And if you did allow open portions of vectored port associations (in
some past/future version) would that work with unconstrained ports?
Maybe that's where it ran afoul in the first place.

Andy
 
K

KJ

Couldn't you use an unconstrained vector port?

Not when you don't have control of the design that you're interfacing
with that you also don't happen to want to connect up all the I/O to.
The specific example that I gave earlier in the thread is...

"When designing a board, it certainly is the case where you can
legally have unconnected pins and those pins might happen to be bits
of some 'bus' of related pins. Back in 2005, I had a device which
happened to have a 24 bit data bus of which I was only using 16 bits
and the part had no requirement to drive unused pins on that bus."

Since the VHDL file for the netlist for the PCBA is written by the
schematic capture ECAD tool, I don't have direct control of that VHDL
file other than to modify something on the schematic for the board.
One work around would be to make one pin nets for each of the pins
that are 'unused'. Now the ECAD tool will write out a netlist with
everything attached...the downside here is that when doing board
design, 'one pin nets' are usually a form of design error.
Intentionally adding noise to this check by creating one pin nets just
to satisfy a simulation tool is counter-productive. There are other
work arounds, with their own particular disadvantages as well.

One could also be further removed from the PCBA design in that maybe
you don't have design control of the PCBA, you're simply the recipient
of the design in which case the work around is manual edits to the
VHDL netlist for the board.
And it does not help with record types.

Record types don't need any help, they can be defaulted by the usual
method of supplying an initializer on the entity. The problem is with
vectors (of any type).
And if you did allow open portions of vectored port associations (in
some past/future version) would that work with unconstrained ports?
Maybe that's where it ran afoul in the first place.

Maybe...but in the process of making this change they created a
situation where a common hardware design situation (i.e. unconnected
pins on a chip) can not be modelled. Sometimes some may forget that
the 'H' in VHDL stands for hardware.

Kevin Jennings
 
A

Andy

Not when you don't have control of the design that you're interfacing
with that you also don't happen to want to connect up all the I/O to.
The specific example that I gave earlier in the thread is...

"When designing a board, it certainly is the case where you can
legally have unconnected pins and those pins might happen to be bits
of some 'bus' of related pins.  Back in 2005, I had a device which
happened to have a 24 bit data bus of which I was only using 16 bits
and the part had no requirement to drive unused pins on that bus."

Since the VHDL file for the netlist for the PCBA is written by the
schematic capture ECAD tool, I don't have direct control of that VHDL
file other than to modify something on the schematic for the board.
One work around would be to make one pin nets for each of the pins
that are 'unused'.  Now the ECAD tool will write out a netlist with
everything attached...the downside here is that when doing board
design, 'one pin nets' are usually a form of design error.
Intentionally adding noise to this check by creating one pin nets just
to satisfy a simulation tool is counter-productive.  There are other
work arounds, with their own particular disadvantages as well.

One could also be further removed from the PCBA design in that maybe
you don't have design control of the PCBA, you're simply the recipient
of the design in which case the work around is manual edits to the
VHDL netlist for the board.


Record types don't need any help, they can be defaulted by the usual
method of supplying an initializer on the entity.  The problem is with
vectors (of any type).


Maybe...but in the process of making this change they created a
situation where a common hardware design situation (i.e. unconnected
pins on a chip) can not be modelled.  Sometimes some may forget that
the 'H' in VHDL stands for hardware.

Kevin Jennings

Very good points, thanks. I was thinking of entities for custom stuff
that I wrote. There's usually other hacking involved anytime I've
tried to use a VHDL netlist of a board for anything.

Would it be legal to associate (others => 'Z') to those portions of
the port, instead of OPEN? It's been a while since I had to do
something like that.

Preference for resolved signals with tri-state values came about in
'93 I believe. IINM, it was at that time that guarded blocks and
disconnects were deprecated(?). Maybe the OPEN binding was abandoned
in favor of tri-state literals?

Andy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top