Clock and reset handling in abstraction definition

[Khushi]

Hello

I am referring to selction 5.13 Clock and reset handling in IEEE 1685-2009. With this I have few questions.

I have a bus protocol for which I need to create a busdef/absdef pair.  For example lets say I am creating AXI busdef/absdef pair. In my component I have an AXI master and a AXI slave interface.  The clock and reset for both the interfaces have common driver.  In this context, I am not sure

- if I should list clock and reset in corresponding absdef or not. If yes should I leave them un-mapped in corresponding bus interface in component so that these are not connected when I connect  this bus interface to other side ?

- in the component IP-Xact should I create a separate bus inteface for reset and clock ?

In general almost all protocols are dependents on clock and reset. In this case what are the general guidelines and recommended ways for clock and reset handling.

Thanks

Khushi

[kock]

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

[Khushi]

On 11/12/2019 at 12:57 AM, kock said:

The official AMBA bus definitions contain clock and reset in master and slave interfaces. They are optional

Hi Erwin,

If I see the AMBA busdef AMBA_IP-XACT-1.4_BusDefinitions_2011_10_21\amba.com\AMBA4\AXI4\r0p0_0, I see for both ACLK and ARESETn, the  presence element is required in both onMaster and onSlave

Here you want to say something else ?

===========================================================

To summarize my understanding regarding the clock and reset stuff.

-a) We should list the clock and reset in protocol abstraction definition

-b) We should set presence => optional for both clock and reset in both onMaster and onSlave

-c) In component businterface,  we can either map the physical clock and reset to busdef logical ports or not

1) if we map, then we should use phantom component strategy as you explained in ( https://forums.accellera.org/topic/6446-interface-mode-mirroredmaster-mirroredslave/ ) 

2) if we not map, then either we connect clock and reset as adhoc or create clock and reset businterface in component and create interface connections for clock and reset (what is recommended here ??)

 

Please let me know if my understanding is correct.

Thanks

Khushi

[edankert]

Hello Khushi,

Please use the following link for the latest versions of the AMBA bus-definitions:

https://silver.arm.com/browse/AR500

In general I agree with the steps you highlight, our IPs are packaged mapping the clocks and resets in the interface.

However I don't believe that this necessarily means that phantom ports or components would be required to be able to connect the clocks and resets for these interfaces, however care must be taken.

Kind regards,

Edwin

[Khushi]

Hi Edwin

Thanks for your comment and links to ARM busdefs.

I didn't understand the following

7 minutes ago, edankert said:

However I don't believe that this necessarily means that phantom ports or components would be required to be able to connect the clocks and resets for these interfaces,

Normally both clock and reset are "in" on both master and slave interfaces. So when you connect master to slave then

- either the tool reports an error saying can not connect two ports with same direction

- or ther tool just skip the connections with a warning and later we can do some adhoc connections

In your environment, you mentioned the clock and reset physical ports are mapped in component master/slave bus interface with other protocol signals. In this case how you connect these with clock and reset driver without a phantom port ?

Thanks

Khushi

[Edwin Dankert]

Hello Kushi,

13 minutes ago, Khushi said:

Normally both clock and reset are "in" on both master and slave interfaces. So when you connect master to slave then

- either the tool reports an error saying can not connect two ports with same direction

- or ther tool just skip the connections with a warning and later we can do some adhoc connections

I am not sure I understand why the tool would report an error?

Let's say I have instance interface A.a connected to instance interface B.b and I have connected interface B.c to interface c on the top.

A specifies clock signal clockA, B specifies clock signal clockB (both interface B.b and B.c map this clock signal) and interface c maps to signal clockTop.

This means that clockA is connected to clockB and clockB is connected to clockTop all signals share the direction 'in' which means that clockTop drives this connection (perfectly valid and no need for phantom ports or components).

Kind regards,

Edwin

[Khushi]

Hi Edwin,

I understand your point but if both A.a and B.b map the clock signal and if we just connect A.a to B.b,should the tool connect the clock or not ? with error or without error ?.

In general during interface connections, what happens to pins which has same direction on both sides ? Should tool connect them ? or left them unconnected ? with or without error/warning?

Thanks

Khushi

[kock]

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

[Edwin Dankert]

17 hours ago, Khushi said:

In general during interface connections, what happens to pins which has same direction on both sides ? Should tool connect them ? or left them unconnected ? with or without error/warning?

I would suggest to leave this up to the tool vendor. (I don't believe IP-XACT provides any guidelines around this)

However I think any tool should only consider optimisation (or/and reporting errors) after all the connections (including inter-connections) have been fully resolved.

Kind regards,

Edwin