«

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?
>

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

Unfortunately it is illegal (still) in 2008 revision.

Jim
SynthWorks VHDL Training

JimLewis wrote:

> Unfortunately it is illegal (still) in 2008 revision.

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.

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

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

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

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.
>

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.
>
<snip>
> 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

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