Partially Connected Vectors on port map

Proposal Details

  • Who Updates: Kevin Jennings
  • Date Proposed: August 2007, August 2009 on Bugzilla. December 2012 e-mail post to reflector, April 4, 2013 on twiki
  • Date Last Updated: April 4, 2013
  • Priority:
  • Complexity:
  • Focus:

Also see Bugzilla 275 and ISAC IR2041

Language Change Specification Link

LCS-2016-001

Current Situation

Language does not allow for vectors to be partially connected in the port map. The following is an example

U1 : Some_Device port map(
Some_Bus(15 downto 0) => Some_Signal,
Some_Bus(31 downto 16) => open);

Requirement

Allow for vectors to be partially connected in the port map

Implementation details

Unknown

Code Examples

Use Cases

U1 : Some_Device port map(
Some_Bus(15 downto 0) => Some_Signal,
Some_Bus(31 downto 16) => open);

Arguments FOR

Where this is as an issue is generally when I use a VHDL netlist produced by a CAD program as part of a simulation model. If the spec for the physical part indicates that unused pins can (or sometimes 'should be') left open and the PCBA design is not using the entire bus than those unused pins on the physical part will be left with no connection (which is correct per design) but the resulting VHDL model complains when compiled because the 'Some_Bus' pins must either all be assigned or all left open.

In certain situations, there are some simple work arounds (mentioned below) but if the language handled the above mentioned port map (which reflects the reality of the desired PCBA design) things would be much cleaner. The model would also not have the situation dependent
drawbacks associated with each of the work arounds.

- Work around #1: If the PCBA design itself is stable and not changing, then simply edit the VHDL model for the offending schematic
pages and move on.

- Work around #2: If the PCBA design is still evolving then see if it's possible to get a resistor on to the schematic to drive the 'unused' pins.

Arguments AGAINST

General Comments

I'm all for this concept, as it maps directly to hardware. However, does anyone know why this restriction was placed on port mappings in the first place? Does it relate to the fact that port mappings (generally) incur no delta delays? -- BAH

When I first proposed this back in 2007 the same question about the source of the restriction was asked but, to my knowledge, no answer was ever produced. The folks who might know the answer may have long since retired or moved on to other endeavors since the language was 20 years old at that point. In any case, it would be nice to know if there is any reason for the restriction now 26 years later. -- KevinJennings - 2013-04-05

It should be optional to apply `open` for unused output bits in a vector, in order to allow for change of output vector length, just like other output ports can be added without having to update all the module that does not use that output. -- MortenZilmer - 2015-01-21

Current Status (June 8, 2016)

Meeting on December 17, 2015 (http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/2015_MeetingDecember17) decided "will the intent be covered by interfaces, and hence, not needed or re-ranked". I don't believe that the the intent of this proposal is in fact covered by interfaces, but since interfaces is not complete it is not possible to say for sure. The LRM change required to implement this proposal is now attached. It strikes out one sentence.

Supporters

-- KevinJennings - 2013-04-04

-- Brent Hayhoe -2013-04-04

-- MortenZilmer - 2014-01-27

-- PatrickLehmann - 2016-02-19

-- MartinZabel - 2016-07-04

-- DanielKho - 2017-01-19

I Attachment Action Size Date Who Comment
Microsoft Word filedocx LRM_Mods_Partially_Connected_Vector_Port_Map.docx manage 11.2 K 2016-06-08 - 12:54 KevinJennings LRM changes required to implement partially connected vectors on port map
PDFpdf LRM_Mods_Partially_Connected_Vector_Port_Map.pdf manage 239.9 K 2016-10-12 - 16:53 KevinJennings  
Topic revision: r17 - 2020-02-17 - 15:34:36 - JimLewis
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback