Menu
▾
▴
#65 Best-Practice : Specifying Interface modes
In section 6.2.1 Direct interface modes it is noted that a master interface is the interface mode that initiates a transaction (like a read or write) on a bus (tends to have address spaces) while s slave interface terminates or consumes a transaction initiated by a master interface (often contains information about the registers), while a system interface ie is neither a master nor slave interface.
The question is - What is the best-practice guideline for specifying if an interface is master/slave/system?
For instance, we see examples in 1.2/1.4 of an interrupt port being modelled as MASTER/SLAVE as opposed ot SYSTEM/MIRROED_SYSTEM. Is this to the best practice, and why? What about the following interfaces UART? SPI? I2C?JTAG?
So how do you spec something like ethernet or serial where either side can initiate a transfer? Is that a system interface?
We have a similar problem that, I believe points out the lack of support in IP-XACT for "peer-to-peer" interfaces or interfaces where a particular component can play both the master and slave roles (e.g. DMA controller).
For peer-to-peer interfaces where you don't need to capture address and memory maps (like enet, perhaps), it would seem like you could get away with defining leaf components as masters and let the interconnect network have either mirroredMaster or slaves and the routing/bridging functionality is done opaquely in the network fabric.
However, for peer-to-peer connections where you do need address and memory maps (say, connecting multiple CPU subsystems that each have shared mailbox memory or configuration registers that can be access by the other CPUs), I don't know of a clean solution. If you make the connection a master, you can't represent the address map for the local memory and registers. If you make the connection a slave, you can't represent the address map.
Another related peer-to-peer issue is where you want to be able to direct connect 2 peers. In this case, you would want to "cross wire" the peers (i.e. data-out of peerA gets connected to data-in of peerB, etc). There really is no way to express this in IP-XACT, that I know of.
The DMA case is one that I would have thought would be pretty common and so I am surprised there doesn't seem to be a solution for it, but I haven't heard of one. The scenario is where a component has a single interface to a multi-master interconnect system. A CPU in the system writes to the DMAs registers to tell the DMA what to do (i.e. the DMA is a slave to register writes), then the DMA initiates read/write requests (i.e. the DMA is a master) to other peripherals and/or slave memory. This is a very common scenario in my experience, yet I don't know how to correctly model the DMAs dual behavior without forcing it to have 2 interfaces (which is really ugly in netlist generation).
Hi David,
I am not sure if it is a solution, but what about using a localMemoryMap inside an address space? All bus interface masters referring to this address space can access the local memory map. External bus interfaces cannot access the local memory map. For your peer-to-peer (multiple CPU) scenario this seems to make sense. Each CPU has at least one master and one slave interface to the other CPU.
Furthermore, I do not understand your remark that modeling DMA's with 2 interfaces is really ugly for netlist generation. Netlist generation is about connecting component ports (physical ports). Interfaces are mappings between logical and physical ports. It is perfectly fine to map physical ports in multiple interfaces. So a typical DMA in my case has an APB slave interface for programming registers and an AHB master interface to initiate data transfers.
Does this help?
Best regards,
Erwin
Erwin, Sorry, I just noticed your response here.
The localMemoryMap does not work for my case because the CPU clusters are external to each other. Example: Each cluster includes 2 CPUs plus scratchpad/mailbox memory and/or configuration registers. These clusters are connected via a single split-transaction interface to a northbridge device. At boot time, the designated main CPU writes to the configuration registers of all of the other clusters to initialize them. During normal operation, clusters send messages to each other by writing to each others mailbox memories. All of this is communicated over a single bi-directional messaging interface.
In your second case, does your APB slave and AHB master share the same physical ports? Do you have 2 interface connections to your interconnect network, with only 1 physical connection? If so, this would seem that your interface-level description loses some of its accuracy in representing the shared nature of this link, doesn't it? Do your APB and AHB connections now become non-shared in TLM level simulations, for instance? In our world, we try to make sure that these interface-level abstractions accurately represent this kind of shared link.
Am I missing something?
Thanks,
David
Correction, I just re-read my prior comment...
In my example, *each* CPU cluster is connected to the northbridge via it *own* bidirectional, split-transaction interface where requests and responses can travel in each direction. The northbridge routes the requests/responses to the appropriate destination.
My prior description made it sound like they were using some kind of shared connection ...
thanks,
David
Hi David,
In my case, the APB and AHB interfaces have different physical ports. Hence, my example is not relevant for you.
If I understand your description correctly then you have multiple CPUs connected to memory or other devices via a northbridge. All of these components would be separate IP-XACT components. I think that the bi-directional connection between a CPU and the northbridge can be modeled only by using a master and a slave interface on both the CPU and the northbridge. The northbridge would contain IP-XACT bridges to model the internal connectivity and addressing. The IP-XACT bridges specify the internal connections between slave interfaces to master interfaces in your northbridge. Each slave interface would contain a bridge to its corresponding master interface connected to the same CPU. In addition that slave interface can contain bridges to other master interfaces depending on your interconnect.
The master/slave pair interfaces on each CPU and on the northbridge would map the same physical ports. This is valid as long as each logical connection results in the same physical connection. Otherwise you would get multiple drivers on your inputs.
I agree with you that this modeling style is questionable. On the other hand, you should interpret bus interfaces and bus interface connections as logical entities. They do not necessarily reflect the physical interconnect.
Please let me know if you want some help to work out an example in detail.
Best regards,
Erwin