AMBA5 AHB5 Initiator IP-XACT Bus Definition Compatibility Issues

AMBA5 AHB5 Initiator Bus Definition Revision Mismatch

The core issue revolves around the incompatibility between two revisions of the AMBA5 AHB5 Initiator bus definition in the IP-XACT format. The managed bus definition, which is currently in use, is based on revision 0, while the newly provided bus definition from ARM is based on revision 2. The primary concern is that these two revisions are not compatible, leading to potential integration issues in the existing SoC design. The managed bus definition has a VLNV (Vendor, Library, Name, Version) identifier of amba.com AMBA5 AHB5Initiator r0p0_0, while the new bus definition has a VLNV of amba.com AMBA5 AHB5Initiator_rtl r0p0_0 and amba.com AMBA5 AHB5Initiator_rtl r0p1_0. The revision numbers are 0 and 2, respectively, and the port lists and port element values differ significantly between the two revisions.

The managed bus definition is based on the ARM IHI 0033B.b specification, which includes updates to the AHBLite features released with AMBA3. It introduces improvements such as enhanced memory type support (HPROT on 7 bits), different schemes for asserting HMASTLOCK, and support for secured, locked, and exclusive transfers with additional signals. Atomicity is also introduced in this revision. On the other hand, the new bus definition is based on the ARM IHI 0033C specification, which is a more recent version of the AMBA AHB Protocol Specification. The new bus definition is intended to be used with interfaces associated with initiator device connections, specifically those between the master and the interconnect.

The incompatibility between the two revisions is primarily due to differences in the port lists and the values assigned to the port elements. For example, the managed bus definition includes ports such as HCLK, HCLKEN, HRESETn, HADDR, HBURST, HMASTLOCK, HPROT, HSIZE, HNONSEC, HEXCL, HMASTER, HTRANS, HWDATA, HWRITE, HRDATA, HREADYOUT, HRESP, HEXOKAY, HSELx, HREADY, HRUSER, HWUSER, HAUSER, HBUSER, HTRANSCHK, HADDRCHK, HCTRLCHK1, HCTRLCHK2, HPROTCHK, HWSTRBCHK, HWDATACHK, HRDATACHK, HREADYCHK, HRESPCHK, HAUSERCHK, HRUSERCHK, HWUSERCHK, and HBUSERCHK. The new bus definition, however, has a different set of ports, including HCLK, HCLKEN, HRESETn, HADDR, HBURST, HMASTLOCK, HPROT, HSIZE, HNONSEC, HEXCL, HMASTER, HTRANS, HWRITE, HWDATA, HWSTRB, HRDATA, HREADY, HRESP, HEXOKAY, HSELx, HAUSER, HWUSER, HRUSER, HBUSER, HTRANSCHK, HADDRCHK, HCTRLCHK1, HCTRLCHK2, HPROTCHK, HWSTRBCHK, HWDATACHK, HRDATACHK, HREADYOUTCHK, HREADYCHK, HRESPCHK, HSELxCHK, HAUSERCHK, HRUSERCHK, HWUSERCHK, and HBUSERCHK.

The key challenge here is that the existing IPs in the design are already based on the managed bus definition (revision 0), and changing the abstraction definition to revision 2 is not feasible without significant rework. This creates a situation where the new IPs provided by ARM, which are based on revision 2, cannot be directly integrated into the existing design without addressing the compatibility issues between the two revisions.

Revision 0 and Revision 2 Incompatibility and Port List Discrepancies

The incompatibility between revision 0 and revision 2 of the AMBA5 AHB5 Initiator bus definition stems from several factors, including differences in the port lists, port element values, and the underlying specifications (ARM IHI 0033B.b vs. ARM IHI 0033C). The managed bus definition (revision 0) is based on the ARM IHI 0033B.b specification, which introduces several new features and enhancements over the previous AMBA3 AHBLite specification. These enhancements include improved memory type support, additional signals for secured, locked, and exclusive transfers, and the introduction of atomicity.

In contrast, the new bus definition (revision 2) is based on the ARM IHI 0033C specification, which is a more recent version of the AMBA AHB Protocol Specification. This specification includes further refinements and updates to the protocol, which are reflected in the new bus definition. The differences between the two revisions are not merely cosmetic; they represent significant changes in the way the AHB5 Initiator interface is defined and implemented.

One of the most noticeable differences between the two revisions is the port list. The managed bus definition (revision 0) includes a comprehensive set of ports that cover all the necessary signals for the AHB5 Initiator interface. These ports include HCLK, HCLKEN, HRESETn, HADDR, HBURST, HMASTLOCK, HPROT, HSIZE, HNONSEC, HEXCL, HMASTER, HTRANS, HWDATA, HWRITE, HRDATA, HREADYOUT, HRESP, HEXOKAY, HSELx, HREADY, HRUSER, HWUSER, HAUSER, HBUSER, HTRANSCHK, HADDRCHK, HCTRLCHK1, HCTRLCHK2, HPROTCHK, HWSTRBCHK, HWDATACHK, HRDATACHK, HREADYCHK, HRESPCHK, HAUSERCHK, HRUSERCHK, HWUSERCHK, and HBUSERCHK. These ports are essential for the proper functioning of the AHB5 Initiator interface and are used to connect the master device to the interconnect.

The new bus definition (revision 2), however, has a different set of ports. While some of the ports are the same as those in revision 0, there are significant differences in the port list. For example, the new bus definition includes ports such as HCLK, HCLKEN, HRESETn, HADDR, HBURST, HMASTLOCK, HPROT, HSIZE, HNONSEC, HEXCL, HMASTER, HTRANS, HWRITE, HWDATA, HWSTRB, HRDATA, HREADY, HRESP, HEXOKAY, HSELx, HAUSER, HWUSER, HRUSER, HBUSER, HTRANSCHK, HADDRCHK, HCTRLCHK1, HCTRLCHK2, HPROTCHK, HWSTRBCHK, HWDATACHK, HRDATACHK, HREADYOUTCHK, HREADYCHK, HRESPCHK, HSELxCHK, HAUSERCHK, HRUSERCHK, HWUSERCHK, and HBUSERCHK. The differences in the port list between the two revisions are not trivial and can lead to significant integration challenges when trying to use IPs based on different revisions in the same design.

Another critical aspect of the incompatibility between the two revisions is the differences in the port element values. The managed bus definition (revision 0) assigns specific values to the port elements, which are used to configure the behavior of the AHB5 Initiator interface. These values are based on the ARM IHI 0033B.b specification and are tailored to the specific requirements of the design. The new bus definition (revision 2), however, assigns different values to the port elements, reflecting the updates and refinements in the ARM IHI 0033C specification. These differences in port element values can lead to mismatches in the behavior of the AHB5 Initiator interface when using IPs based on different revisions.

The incompatibility between revision 0 and revision 2 is further compounded by the fact that the existing IPs in the design are already based on the managed bus definition (revision 0). Changing the abstraction definition to revision 2 would require significant rework of the existing IPs, which is not feasible in most cases. This creates a situation where the new IPs provided by ARM, which are based on revision 2, cannot be directly integrated into the existing design without addressing the compatibility issues between the two revisions.

Resolving AMBA5 AHB5 Initiator Bus Definition Compatibility Issues

To address the compatibility issues between revision 0 and revision 2 of the AMBA5 AHB5 Initiator bus definition, several steps can be taken to ensure that the new IPs based on revision 2 can be integrated into the existing design without requiring significant rework of the existing IPs. The following are some of the key steps that can be taken to resolve the compatibility issues:

1. Port Mapping and Signal Adaptation: One of the first steps in resolving the compatibility issues is to perform a detailed port mapping between the managed bus definition (revision 0) and the new bus definition (revision 2). This involves identifying the corresponding ports in both revisions and mapping them to each other. In cases where there are differences in the port names or signal types, signal adaptation logic can be implemented to bridge the gap between the two revisions. For example, if a port in revision 0 has a different name or signal type compared to the corresponding port in revision 2, a signal adaptation module can be created to convert the signals from one format to the other.

2. Abstraction Layer Implementation: Another approach to resolving the compatibility issues is to implement an abstraction layer that sits between the existing IPs (based on revision 0) and the new IPs (based on revision 2). This abstraction layer would act as a bridge between the two revisions, translating the signals and protocols from one revision to the other. The abstraction layer would need to be carefully designed to ensure that it correctly handles all the differences between the two revisions, including differences in port lists, port element values, and protocol behavior.

3. Custom Bus Definition Creation: In some cases, it may be necessary to create a custom bus definition that combines elements from both revision 0 and revision 2. This custom bus definition would be tailored to the specific requirements of the design and would include the necessary ports and signal types from both revisions. The custom bus definition would then be used as the basis for integrating both the existing IPs and the new IPs into the design. This approach requires a deep understanding of both revisions and the ability to create a bus definition that is compatible with both.

4. Verification and Validation: Once the compatibility issues have been addressed through port mapping, signal adaptation, abstraction layer implementation, or custom bus definition creation, it is essential to thoroughly verify and validate the design to ensure that the integration of the new IPs does not introduce any new issues. This involves running extensive simulation tests to verify that the signals and protocols are correctly translated between the two revisions and that the overall behavior of the design meets the required specifications. Any discrepancies or issues identified during verification should be addressed before proceeding to the next stage of the design process.

5. Documentation and Communication: Finally, it is crucial to document all the changes made to resolve the compatibility issues and communicate these changes to all stakeholders involved in the design process. This includes providing detailed documentation on the port mapping, signal adaptation, abstraction layer implementation, custom bus definition creation, and verification results. Clear communication ensures that all team members are aware of the changes and can work together effectively to integrate the new IPs into the design.

By following these steps, it is possible to resolve the compatibility issues between revision 0 and revision 2 of the AMBA5 AHB5 Initiator bus definition and successfully integrate the new IPs into the existing design. While this process may require significant effort, it is essential to ensure that the design meets the required specifications and functions correctly in the final implementation.