Using OPEN in port map

R

rickman

Guest
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).
 
On Jul 16, 7:19 pm, rickman <gnu...@gmail.com> wrote:

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?
Click to expand...
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
 
rickman wrote:
<snip>
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
Click to expand...
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

--
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.
 
Unfortunately it is illegal (still) in 2008 revision.

Jim
SynthWorks VHDL Training
 
JimLewis wrote:

Unfortunately it is illegal (still) in 2008 revision.
Click to expand...
And can anyone explain to me - why????

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
 
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.
Click to expand...
Kevin,
Do you have a bug ID for it? I was looking through the bugzilla
database and could not find it.

Jim
 
On Jul 28, 3:00 pm, JimLewis <J...@SynthWorks.com> wrote:
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
Click to expand...
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
 
On Jul 30, 9:31 am, KJ <kkjenni...@sbcglobal.net> wrote:
On Jul 28, 3:00 pm, JimLewis <J...@SynthWorks.com> wrote:

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

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
Click to expand...
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
 
On Jul 17, 4:37 am, Alan Fitch <alan.fi...@spamtrap.com> wrote:
rickman wrote:

snip





  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

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
Click to expand...
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
 
On Jul 30, 4:09 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Jul 30, 9:31 am, KJ <kkjenni...@sbcglobal.net> wrote:
Hi KJ,
I think you are not only right on the output pins, but also right on
the input pins.
Click to expand...
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.
Click to expand...
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.

snip
It is a much clearer and clever idea to permit to use "OPEN" for input
signals to a module too.
Click to expand...
If you're talking about scalars and not vectors, then look into using
initializers on the input pins instead.

KJ
 
rickman wrote:
On Jul 17, 4:37 am, Alan Fitch <alan.fi...@spamtrap.com> wrote:
rickman wrote:

snip





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
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
Click to expand...
Hi Rick,
I don't know why it changed. The key phrase is at the end of section
1.1.1.2 in the VHDL93 standard

"It is an error if some of the subelements of a composite
formal port are connected and others are either unconnected or
unassociated."

I don't think it's to do with compilation and elaboration - you can
leave all elements of a composite port disconnected or not in different
parts of the design, it's just you can't leave some of them disconnected
and others not.

I had a quick look at the issue reports here:

http://www.vhdl.org/isac/IRs-VHDL-87/

but couldn't find the explanation for the change,

regards
Alan

--
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.
 
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
 
On Jul 31, 11:42 am, Andy <jonesa...@comcast.net> wrote:

Couldn't you use an unconstrained vector port?
Click to expand...
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.
Click to expand...
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.
Click to expand...
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
 
On Jul 31, 8:07 pm, KJ <kkjenni...@sbcglobal.net> wrote:
On Jul 31, 11:42 am, Andy <jonesa...@comcast.net> wrote:

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
Click to expand...
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
 
Kevin,
It is here:
https://bugzilla.mentor.com/show_bug.cgi?id=240

Note it is IR 2132, however it is bugzilla issue 240.


Best,
Jim
 
On Aug 6, 1:37 pm, JimLewis <J...@SynthWorks.com> wrote:
Kevin,
It is here:https://bugzilla.mentor.com/show_bug.cgi?id=240

Note it is IR 2132, however it is bugzilla issue 240.

Best,
Jim
Click to expand...
Bug #275 has been submitted as an enhancement to the language to allow
for opens on vector subelements.

Kevin Jennings
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top