Jump to content

kock

Members
  • Content Count

    69
  • Joined

  • Last visited

  • Days Won

    3

kock last won the day on January 17

kock had the most liked content!

About kock

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,272 profile views
  1. Hi Kushi, In IP-XACT, an interconnect connects the logical port bits that are mapped in the connected bus interfaces. The direction of those logical bits does not matter. So the direction can be in on all end points, and also the component port bits mapped to these logical port bits can all have direction in. In an HDL netlist, this would translate to a net with all inputs at its ends. It depends on the netlister tool that you use whether such a net is actually generated or not. Typically your netlister tool generates a warning or error that you have undriven inputs. However, there is no semantic rule in IP-XACT that forbids undriven inputs. In order to drive such a net, it is sufficient in IP-XACT to connect it somehow to a component output port. This can be done with adhoc connections, additional bus interface connections, and/or phantom ports. This is completely free to decide depending on which IP-XACT design-style you wish to use. Best regards, Erwin
  2. Hi Kushi, The Accellera bus definitions contains files for I2C. There are two: one for I2C internal (uni-directional signals) and one for I2C external (bidirectional signals). They allow you to make direct connections from master to slave. A bus does not have to be symmetric to support direction connections. The bus definition property directConnection determines if you are allowed to make direct master to slave connections or not. Best regards, Erwin
  3. Hi Kushi, The additional system interfaces allow you to make (clock, reset, sideband) connections in addition to the master/slave connections. So you can separately handle your clock/reset/sideband connectivity. The system group names are not relevant for netlisting. They provide additional checking capabilities in IP-XACT. Best regards, Erwin
  4. Hi Kushi, As I mentioned earlier ( https://forums.accellera.org/topic/6446-interface-mode-mirroredmaster-mirroredslave/ ) my advice is to map clock and reset signals in interfaces. However, this is an advice. Other ways of working are to handle clock and reset with adhoc connections or dedicated clock and reset bus interfaces. The IP-XACT standard does not enforce a particular way of working. The official AMBA bus definitions contain clock and reset in master and slave interfaces. They are optional to allow people to decide for themselves whether they want to map clock and reset in those interfaces. In my environment, we choose to make those signals required because we want to enforce a certain way of working. Best regards, Erwin
  5. Hi Kushi, Clock and reset have direction in because that is the direction from the protocol point of view. Clock and reset signals are generated by clock and reset generators. If you map clock and reset in your master and slave bus interfaces, you need to drive the clock and reset signals. You can do this by inserting a so-called phantom component on the interconnection. A phantom component is a component that only has phantom ports (ports with direction phantom). Here is an example with clock only: Component A with input port clk mapped in AMBA master bus interface m Component B with input port clk mapped in AMBA slave bus interface s Design with instance a of component A and instance b of component B and interconnection from a.m to b.s If you netlist the design you will a get a net between a.clk and b.clk but this net is not driven since both ends of the net are inputs. Now lets assume you also have Component C (clock generator) with output port clk mapped in CLOCK master bus interface clock. As integrator, you can now make an integration specific phantom component and change the design as follows: Component I with phantom port clk that is mapped in three three bus interfaces CLOCK slave bus interface clock AMBA slave bus interface s AMBA master bus interface m Design as before with the interconnection and additional instance c of Component C and instance i of Component I and interconnections a.m to i.s i.m to b.s c.clock to i.clock If you now netlist this design you will get a net between c.clk (driver) and a.clk and b.clk. Instance i will not appear in the netlist as a module instance since it only has phantom ports. In my opinion, the use of a phantom component is the cleanest way to do this. Alternative ways are to connect c.clk via an adhoc connection to a.clk and/or b.clk, or to add additional clock slave interfaces to A or B such that you can connect c.clock to those interfaces. However, you then add additional interfaces only for integration purposes. There is an example in the user guide ( https://accellera.org/images/downloads/standards/ip-xact/IP-XACT_User_Guide_2018-02-16.pdf ) of a phantom component for I2S. You can make similar components for AMBA protocols and other Serial protocols. Best regards, Erwin
  6. Hi Kushi, A system bus interface must be connected to a mirrored system bus interface. Sometimes, system interfaces are used to connect clock and reset signals or side-band signals. An EDA tool behaves the same for system interfaces as for master/slave interfaces. It maps component ports onto logical ports, wires the logical port bits, and infers from that which ports from which component instances need to be wired in a generated netlist. There is no addressing associated with system interfaces. Personally, I do no use system interfaces. In my opinion, the better approach is to map clock and reset in master and slave interfaces. This allows the use of abstractors to bridge between RTL and TLM descriptions. Clock and reset are needed at the RTL side but they are abstracted at the TLM side. This is not possible with system interfaces. In general, to enable IP re-use, i.e. in IP-XACT terms to enable IP-XACT component reuse, an IP-XACT component shall not have bus interfaces specifically tailored to way the IP-XACT component is integrated in its context. I think this is a good way of thinking while creating IP-XACT components. Best regards, Erwin
  7. Hi Kushi, In an abstraction definition, you can describe the properties of logical ports for master, slave, and system interface. For wire ports, the properties are presence, width, and direction. In a bus interface, the component ports mapped onto the logical ports have to obey the semantic consistency rules concerning the directions (SCR 6.* in IEEE 1685-2014). For instance, SCR 6.5, a logical port with direction in can only be mapped onto a component port with direction in, inout, or phantom. For a mirrored bus interface, the direction of the logical port must be reversed. If an abstraction definition contains logical ports such that for each logical port the direction in a master is mirrored compared to the direction in a slave, and also presence and width are identical in a master and a slave, then from the netlisting point of view there is no difference between a master interface and a mirrored slave interface and also no difference between a slave interface and mirrored master interface. Such an abstraction definition is sometimes called symmetric. However, if an abstraction definition is asymmetric, then SCRs 6.* imposes different constraints for master/mirrored slave interfaces and slave/mirrored master interfaces. A typical example is a logical clock port (see all AMBA bus definitions). The logical ports PCLK, HCLK, and ACLK have direction in for master and slave interfaces. Another example is IEEE 1149.1 JTAG (see https://www.accellera.org/images/busdefs/busdef_SpiritCons_Accellera_1685-2009_final.zip) where logical ports TDI and TDO have a width of 1 in slave interfaces and no width in master interfaces. As a result you can mapped multiple TDI/TDO bits in a mirrored master interface but only 1 bit in a slave interface. The use of mirrored and non-mirrored interfaces is not only relevant for connectivity but also for internal addressing in a component. If you use mirrored interfaces then the internal addressing can only be expressed using channels (from mirrored master to mirrored slave). If you use non-mirrored interfaces then the internal addressing can only be expressed using bridges (from slave to master). It is not possible to describe internal addressing with a combination of mirrored and non-mirrored interfaces (e.g. addressing from a mirroredMaster to a master). As a result, it is not possible to cascade components that use channels for addressing. Hence, my advice is always to use bridges for addressing in combination with non-mirrored interfaces. In my opinion, the use of mirrored interfaces only makes sense in combination with non-addressable bus definitions that are asymmetric. Typically, these are serial protocols such as JTAG, but also I2C, I2S, SPI, and so on. Often they have an output enable logical port with direction out for master and slave interfaces. In that case, you functional IO muxing component needs mirrored master and slave interface to allow the output enable signal to be input. Please see the above referenced accellera.org bus definitions. Best regards, Erwin
  8. Hi Bhargav, Yes, this fragment is valid and it means what you indicated. You can perform a schema check using the schema hosted on the Accellera website: http://www.accellera.org/XMLSchema/ Best regards, Erwin
  9. Hi Bhargav, Glue logic is not covered by the IP-XACT standard. Perhaps your IP-XACT EDA vendor can offer a vendor-specific solution on top of the standard using vendor extensions or vendor-specific parameter conventions. Best regards, Erwin
  10. Yes, there are companies that leverage both IP-XACT and PSS. I cannot provide company names. Please talk to EDA vendors.
  11. Hi Bhargav, Your IP-XACT fragment translates to input [32:0] port [3:0][7:0][4:0] in SystemVerilog. So the part in ipxact:vector is packed (left of the port name) and the part in ipxact:array is unpacked (right of the port name). If you want to represent input [32:0][3:0][7:0][4:0] port then all dimensions must go into ipxact:vectors and each dimension is a separate ipxact:vector. Best regards, Erwin
  12. Hi Bhargav, The purpose of arrays is to describe arrays of ports. For instance, in SystemC you can write sc_out< sc_lv<32> > my_port[10]. Your IP-XACT fragment would translate to SystemC as sc_in< sc_lv< 33 > > TAR_PRI_RD[6]. Best regards, Erwin
  13. Hello Harshita, Please see the discussion in this topic: Best regards, Erwin
  14. Hi Bhargav, This is not allowed by SCR 6.25 on page 203 of the IEEE std. 1685-2014: "All ports referenced in an ad hoc connection shall reference the same number of bits. If no range is specified for a nonscalar port, then the full range from the port definition is presumed." Best regards, Erwin
  15. Hi Bhargav, In case of your example connecting A[2:0][2:0] to B[5:3][6:4] there is no need to describe the partSelect. If there is no partSelect then automatically the full range is connected. If you want to create connections different from A[x][y] -> B[x+3][y+4], let's say A[x[[y] -> B[y+3][x+4], then you can use two adhoc connections: <ipxact:adHocConnections> <ipxact:adHocConnection> <ipxact:name>adhoc1</ipxact:name> <ipxact:portReferences> <ipxact:internalPortReference componentRef="cA" portRef="A"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>0</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>2</ipxact:left> <ipxact:right>0</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> <ipxact:internalPortReference componentRef="cB" portRef="B"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>1</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>6</ipxact:left> <ipxact:right>4</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> </ipxact:portReferences> </ipxact:adHocConnection> <ipxact:adHocConnection> <ipxact:name>adhoc2</ipxact:name> <ipxact:portReferences> <ipxact:internalPortReference componentRef="cA" portRef="A"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>1</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>2</ipxact:left> <ipxact:right>0</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> <ipxact:internalPortReference componentRef="cB" portRef="B"> <ipxact:partSelect> <ipxact:indices> <ipxact:index>0</ipxact:index> </ipxact:indices> <ipxact:range> <ipxact:left>5</ipxact:left> <ipxact:right>3</ipxact:right> </ipxact:range> </ipxact:partSelect> </ipxact:internalPortReference> </ipxact:portReferences> </ipxact:adHocConnection> </ipxact:adHocConnections> Best regards, Erwin
×
×
  • Create New...