kock

Members
  • Content count

    38
  • Joined

  • Last visited

About kock

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

364 profile views
  1. Hello, In case of viewRef, it may be that the different definitions can be factored out into a single definition. I agree with you that it would have been cleaner to have a single definition rather than duplicating the same definition multiple times. However, for accessHandles and ports there are really different definitions. A port in an abstractionDefinition is different from a port in a component. Hence, your translation to Python classes should include some use of scopes or namespaces. Best regards, Erwin
  2. Hi Justin, Sorry for my delayed response. The IP-XACT IEEE 1685-2014 contains Semantic Consistency Rule 1.2 (anyVLNVRefMustExist): Any VLNV in an IP-XACT document used to reference another IP-XACT document shall precisely match the identifying VLNV of an existing IP-XACT document. In the schema, such references always use the attribute group versionedIdentifier. So the standard defines that the component XML files of your sub-modules must exist if your instantiate them in a design. If you are only interested in managing the VLNVs, you can also consider using an IP-XACT catalog (new in IEEE 1685-2014). Best regards, Erwin
  3. Hello Justin, I do not know of freely available TGI implementations. There are commercial implementations available from IP-XACT EDA vendors. Best regards, Erwin
  4. Hi Justin, A design describes the instances and configuration of the sub-IPs and their interconnect. As you mention, these sub-IPs need to be described in IP-XACT. So this is not an appropriate way to handle sub-IPs not described in IP-XACT. I think the answer to your question depends on what you mean with "track". If you just want to track files of sub-IPs you can describe them in file sets of IP_A. Or you can describe sub-IPs in XML containing file sets only. So you can explain your goal a bit more? Thanks, Erwin
  5. Hi Ashwin, The Accellera standardization committee does not have a published guideline for this. Please check with your IP-XACT EDA vendor for a dedicated solution. Best regards, Erwin
  6. Hello Kenny, Indeed you found an inconsistency. The clockInterfaceRef and resetInterfaceRef are not part of the schema. The text should also be removed from the specification document. If you do not want to connect clock and reset ports using the addressable bus interface you can use the isInformative element in the portMap element. This allows you to make clock and reset ports part of the portMaps to get a reference for the other ports without physically connecting them through this interface. The clock and reset port itself can be mapped again in other dedicated clock and reset bus interface in order to create the physical connections. Best regards, Erwin
  7. Hi Eirik, Please send me an email (erwin.de.kock at nxp.com). Best regards, Erwin
  8. Hello Harsh, This is not a tool forum, but it seems that the IP-XACT XML file that you provide as argument is not valid because it does not contain a memoryMaps element. I cannot see the details because the attached XLSX file does not contain the XML file details. Best regards, Erwin
  9. Hi Tudor, The errata have been updated and your comments posted in this forum have been added. The new version is available at http://www.accellera.org/images/downloads/standards/ip-xact/IPXACT-2014-errata-2.pdf Thanks for your contributions, Erwin
  10. Hi Kenny, Yes, IEEE 1685-2014 supports RTL and TLM views in a single file. Please read this topic http://forums.accellera.org/topic/5070-views-in-a-componentmodel/ were the question was asked before. Best regards, Erwin
  11. Yes, indeed. People in the IP-XACT technical committee have noticed this too. We will add it to the errata: http://www.accellera.org/images/downloads/standards/ip-xact/IPXACT-2014-errata.pdf Thanks, Erwin
  12. Hello Gregoire, Thanks for addressing this topic. I think it is better to discuss it over the phone in a special interest meeting of the IP-XACT Technical Committee rather than have discussion in this forum. I will propose this in the next TC meeting. If we come to agreement then we can post the outcome here. Best regards, Erwin
  13. Hi, I am not sure to understand the problem but it seems that you need 4 views to describe all possible componentInstantiation/designConfigurationInstantiation pairs. Does that make sense? Erwin
  14. Hello Jorge, Yes it is possible to describe RTL and TLM within the same component using two different views. The motivation to have more than one view is that you can describe multiple implementations of an IP in the same IP-XACT component. The way to indicate if a port is present is a particular view is to use the wireTypeDefs (for wire ports) and transTypeDefs (for transactional ports). Each wireTypeDef and each transTypeDef contains zero or more viewRef elements. If there are zero viewRef elements then the type applies to all views (implying that the port is present is all views). If there are one or more viewRef elements then the type applies only to the views specified by the viewRef elements (implying that the port is not present in the views that are not specified). If a port does not have wireTypeDefs or transTypeDefs then the default type applies to all views (implying that the port is present in all views). I must admit that this is not very well described in the IEEE 1685-2014 document in Sections 6.12.9 and 6.12.19. Best regards, Erwin
  15. Hello Fred, Unfortunately there is no such document. Best regards, Erwin