Jump to content

kock

Members
  • Content Count

    69
  • Joined

  • Last visited

  • Days Won

    3

Reputation Activity

  1. Thanks
    kock got a reaction from Bhargav in Design IPXACT-adHocConnections-InternalPortReferences-left and right attributes   
    Hi Bhargav,
    In the 1685-2014 version, component wire ports can be multidimensional, i.e., it can have muliple arrays and multiple vectors. For this reason, a portReference must support multiple dimensions as well. This is done using the partSelect element. The partSelect element can contain a single range with left and right to support a single vector as before. Or it can contain can indices plus a range. The indices indicate which dimension the range applies to. If the indices contain more than one index then the first indices apply to the arrays and the last indices apply to the vectors.
    Best regards,
    Erwin



  2. Like
    kock got a reaction from Michael Tsurikov in Purpose of modifiedWriteValue = oneToSet?   
    Hi Michael,
    My understand is that oneToSet also means that writing a 0 has no effect.
    Best regards,
    Erwin
  3. Like
    kock got a reaction from Jorge.Rivas in Views in a component.model   
    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
  4. Like
    kock got a reaction from sumeetg in interested in knowing IPXACT   
    Hello,
     
    IP-XACT is an IEEE standard to enable IP reuse and to enable tool flows to easily work with IP. You can get a free copy of the standard using the link on http://www.accellera.org/downloads/ieee/. The standard provides two things. First it provides XML schemas that allow you to describe IP blocks; you can think of this as an electronic datasheet of an IP block. The XML schemas also allow you to describe designs in terms of IP block instances and interconnect between these instances. The information in the XML documents adhering to these XML schemas is called metadata. Second, the standard provides a tool interface called TGI (Tight Generator Interface) that allows you to work with this metadata. EDA vendor IP-XACT tools are able to load IP-XACT XML documents and you can access the metadata in the internal databases of these tools using TGI without the need to do all the XML parsing yourself.
     
    IP-XACT can be useful in SystemC modeling. You can package SystemC IP, i.e., create an IP-XACT component XML document for a SystemC IP. This IP-XACT component can then be used in several ways, for instance:
    Integration, i.e., instantiate the IP-XACT component in an IP-XACT design and generate a SystemC netlist from the IP-XACT design. Modeling, i.e., use the IP-XACT component with its register description to generate a skeleton SystemC IP implementation with for instance TLM2 interfaces and SCML registers. Verification, i.e., use the IP-XACT component with its register description to generate a UVM register model for a test bench. Documentation, i.e., generate a paper datasheet from the IP-XACT component.  
    IP-XACT is not similar to GREENSOC.
     
    Best regards,
    Erwin
  5. Like
    kock got a reaction from VKrishnamurthy in AddressMaps in IP-XACT Design file, Multiple BusInstances   
    Hello Venkatesh,
     
    Ad 1). The base address in an address block inside a memory map is an offset that is relative to the incoming address of the slave bus interface that references that memory map. So if you instantiate the slave module multiple times and connect the instances to a bus, then all slave instances will a different offset automatically depending on the addressing of that bus. There is no need to specify an (absolute) offset in a design. Having said that, it is not impossible since you can make the base address user resolved and set the configurable element value in the design.
     
    Ad 2). It is not possible to describe a parameterized number of bus interfaces. Hence, you need to make a different IP-XACT component for each bus configuration allowing you to connect N masters and M slaves. Of course, you can instantiate such a component multiple times. There is no need for separate busdef and absdef. Each of the master bus interfaces on your IP-XACT bus requires a reference to an address space in that component and a base address. These base addresses and address spaces links to ad 1) because they specify the bus addressing, i.e., the address space for each connected slave. Again the bus addressing is relative.
     
    Best regards,
    Erwin
  6. Like
    kock got a reaction from nbjessen in IP-XACT syntax   
    Hello Norbert,
     
    I will take an action point in the Accellera IP-XACT Working Group to see if we can post the XSL transforms on the Accellera website. Also I already upconverted the busdefs that you mentioned to 1685-2009. I will also see if we can make those available on the website.
     
    Best regards,
    Erwin
×
×
  • Create New...