AXI4.vhdl record Names do not match AXI4 interface names

[JimLewis]

I understand disliking some of the AXI4 naming methods - especially the AW, W, B, AR, R - however the record field names should match the suffix of the AXI interface - such as Addr and Prot.

By using aliases in the VC (or design), we can create short names almost identical to the actual AXI interface names:

process
  . . . 
  alias    AW    : AxiBus.WriteAddress'subtype is AxiBus.WriteAddress ;
 begin
  ... 
  AW.Addr <= ...
  AW.Prot <= ...

---

While today the AW and AR interfaces have the exact same fields, will it always be that way? Hint, although they are the same, they are specified separately in the AXI specification. This could be future proofed by doing:
type Axi4_Address_Interface is record
....
end record ;

subtype Axi4_Read_Address_Interface is Axi4_Address_Interface ;
subtype Axi4_Write_Address_Interface is Axi4_Address_Interface ;

That way designs that use Read_Address and Write_Address types are only minimally impacted if these were to change.

---

While the correct types for an interface implementation is std_ulogic and std_ulogic_vector, to support records of these without mode views requires the usage of std_logic_vector. For VC (or designs) that need to support both 2019 interfaces and older implementations, we either need two to separate the 2008 and 2019 implementations or separate the mode views from the record declarations and use std_logic and std_logic_vector - in either case to support both, two packages are needed - maybe three since synthesis needs to separate in and out record elements.

OSVVM is supporting both 2019 and 2008 implementations by keeping the 2019 implementations in the src directory and the 2008 implementations in a directory named src/deprecated.

[Paebbels]

[...] however the record field names should match the suffix of the AXI interface - such as Addr and Prot.

Abbreviating names is bad coding style and a coding smell since decades. I urge to not repeat mistakes done by ARM. It's about having clean and understandable interface descriptions. At best: No abbreviations, no guessing.

---

subtype Axi4_Read_Address_Interface is Axi4_Address_Interface;
subtype Axi4_Write_Address_Interface is Axi4_Address_Interface;

Yes, we can add these.

- subtype Axi4_Read_Address_Interface is Axi4_Address_Interface;
- subtype Axi4_Write_Address_Interface is Axi4_Address_Interface;
+ subtype Axi4_ReadAddress_Interface is Axi4_Address_Interface;
+ subtype Axi4_WriteAddress_Interface is Axi4_Address_Interface;

Do we need 2 views?
Or later in case both types diverge?

---

The idea is having clean and reliable interfaces. E.g. that tools give early feedback like multiple sources. If we go back to VHDL-2008 compatibility, we lose this essential feature.

Unfortunately, type generics have been broken (have been useless) in VHDL-2008. This was added in VHDL-2019, thus compatibility with VHDL-2008 can't be created using type generics in package generics ...

I think we also can't apply an element-wise resolution function to a record, so std_ulogic and similar types get resolved, right?

[NJDFan]

IMO, regardless of whether what ARM named the signals is a mistake or not, it's what the signals are named. If I'm heads down in a design trying to figure out whether the problem is that my code doesn't conform to spec or the simulation model doesn't conform to spec, and I'm flipping back-and-forth between the spec, the simulation, the code, and whatever barrage of messages I'm getting that day on unrelated issues, then every name remapping I need to keep track of in my head is one more mental load.

On the list of things offending me about the state of the modern world, the AXI abbreviated signal naming conventions are pretty far down the list.

[JimLewis]

@Paebbels

Abbreviating names is bad coding style ...

If this effort is to become a defacto standard, it needs to use at least the suffixes of the names as defined in the interface specification. If this was an IEEE standard, I would vote no on it for this reason.

I take conforming to the standard's interface naming over my own naming rules. ARM's AXI specification is the authoritative defacto standard for AXI.

---

Do we need 2 views?

Absolutely - they too can be aliases.

---

OSVVM creates two versions of packages: One for 2019 and one for earlier versions of VHDL. This is an OG brute force approach. Nothing fancy. Type generics and fancy resolution functions need not apply. 2019 version would use std_ulogic and std_ulogic_vecctor and have mode views. 2008 version would use std_logic and std_logic_vector and not have mode views - but may have additional functions to support initializing the interface with 'Z'. There are other ways to split the packages - however none the less it can get complicated real quick.

The earlier version is kept in a directory named deprecated. The compile script analyzes the appropriate package based on the VHDL version and if the simulator supports VHDL 2019 interfaces. Hence OSVVM's compile script does this:

if {$::osvvm::VhdlVersion >= 2019 && $::osvvm::Supports2019Interface}  {
  analyze Axi4InterfacePkg.vhd
} else {
  analyze deprecated/Axi4InterfacePkg.vhd 
}

[Paebbels]

If I'm heads down in a design trying to figure out whether the problem is that my code doesn't conform to spec or the simulation model doesn't conform to spec, and I'm flipping back-and-forth between the spec, the simulation, the code, and whatever barrage of messages I'm getting that day on unrelated issues, then every name remapping I need to keep track of in my head is one more mental load.

I don't believe this debugging concern is a valid concern. Once AXI is understood, it's about the concept and behavior of certain signals, not about there names. There is also no translation because Dest becomes Destination. When talking to colleagues we already use destination bits rather then dest bits.

---

If this effort is to become a defacto standard, it needs to use at least the suffixes of the names as defined in the interface specification.

Why?

If we follow that reasoning, then we also need to keep Master-In/Slave-Out signal names, but here it was requested to change them to other names not matching the convention. CIPO and COPI

I'm not renaming the record element to a different name like ID → Number. I just use the non-abbreviated form.

[Paebbels]

Clk → Clock
Addr → Address
Prot → Protect
Resp → Response
Dest → Destination
Len → Length
Strb → Strobe

Unchanged signals, because already non-abbreviated:

• Reset
• Valid
• Ready
• Last
• Size
• Cache
• Lock
• Burst
• Region

Signals up to 6 characters are kept as is, while

• strobe = 6
• length = 6
• clock = 5

get abbreviated.