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).
Using OPEN in port map
Started by ●July 16, 2009
Reply by ●July 17, 20092009-07-17
On Jul 16, 7:19=A0pm, rickman <gnu...@gmail.com> wrote:> Product(ProdHigh downto ProdHigh - MulOut'high) =3D> MulOut, > Product(ProdHigh - MulOut'high - 1 downto 0) =3D> OPEN,> According to Ben Cohen book, the product can not be split this way > using OPEN. =A0When I tried it with Synplicity it seems to accept this > syntax. =A0Ben's book is a bit older and refers to the '93 standard. =A0I > believe there is a newer VHDL standard, 200x. =A0Is this something that > has changed since '93 or is the Synplicity tool just being > magnanimous? =A0Should 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
Reply by ●July 17, 20092009-07-17
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? > > RickHi 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.
Reply by ●July 20, 20092009-07-20
Reply by ●July 21, 20092009-07-21
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
Reply by ●July 28, 20092009-07-28
> 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
Reply by ●July 30, 20092009-07-30
On Jul 28, 3:00=A0pm, 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? =A0I was looking through the bugzilla > database and could not find it. > > JimJim, 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
Reply by ●July 30, 20092009-07-30
On Jul 30, 9:31=A0am, KJ <kkjenni...@sbcglobal.net> wrote:> On Jul 28, 3:00=A0pm, 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 their=s> > > always VHDL 201x. > > > Kevin, > > Do you have a bug ID for it? =A0I was looking through the bugzilla > > database and could not find it. > > > Jim > > Jim, > > No I don't have a bug ID. =A0I 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? =A0FYI, 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. =A0When 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. =A0Back 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. =A0On that one I got a reply back that said > it had been assigned number 2132. =A0The 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. =A0If you need any more info, I can > forward you what I have on that one. > > Kevin JenningsHi 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
Reply by ●July 30, 20092009-07-30
On Jul 17, 4:37=A0am, Alan Fitch <alan.fi...@spamtrap.com> wrote:> rickman wrote: > > <snip> > > > > > > > =A0 Mul: multiply > > =A0 =A0PORT MAP ( > > =A0 =A0 =A0SysClk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> SysClk, =A0-- Sys=tem clock, 12.288 MHz?> > =A0 =A0 =A0Start =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D> Start, =A0 =A0-- =Load multiplican and init result> > =A0 =A0 =A0Multiplicand =A0=3D> LinDat, > > =A0 =A0 =A0Multiplier =A0 =A0=3D> std_logic_vector(AudioGain), > > =A0 =A0 =A0Product(ProdHigh downto ProdHigh - MulOut'high) =A0 =A0 =A0 ==3D> MulOut,> > =A0 =A0 =A0Product(ProdHigh - MulOut'high - 1 downto 0) =A0=3D> OPEN, > > =A0 =A0 =A0Done =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> Done > > =A0 =A0); > > > According to Ben Cohen book, the product can not be split this way > > using OPEN. =A0When I tried it with Synplicity it seems to accept this > > syntax. =A0Ben's book is a bit older and refers to the '93 standard. ==A0I> > believe there is a newer VHDL standard, 200x. =A0Is this something that > > has changed since '93 or is the Synplicity tool just being > > magnanimous? =A0Should I change it so that it will work with other tool=s> > or do most tools accept this? > > > Rick > > Hi Rick, > =A0 =A0it 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 > AlanHi 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
Reply by ●July 31, 20092009-07-31
On Jul 30, 4:09=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:> On Jul 30, 9:31=A0am, 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 :=3D '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
