Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Another missing feature in VHDL

Hello Peter,

yes, of course I have extended comments to explain the signal names like
-- Signal name mappings
SCLK -> Serial Clock
MOSI -> Master Out / Slave In

Nonetheless, these comments exist in a package, where the record is declared, but not where users use the type or a signal
of that type to connect wires to IP core ports. Of course, here we also could repeat the comments every time.

While this comment based explanation approach will work for 1-to-1 mappings, there are protocols that use multiple names.
E.g. with SPI, we have MOSI = SIMO =  Master Out / Slave In.

Thanks for point out the shorter form:
type T_I2C_PCB is alias T_I2C_FPGA record
  SCL is SerialClock;
  SDA is SerialData;
end record;  

As I wrote the email, I was initially thinking, if we could allow a composite alias, to grab elements from multiple types or signals.
But this idea was a mistake, but I didn't remove the duplication of  T_I2C_FPGA. For everything, that goes beyond, a pure alias,
we would need:
* signal assoziations (spaceship)
* entities to convert interfaces, or
* bidirectional conversion functions

Kind regards

Am Fr., 3. Juli 2020 um 12:36 Uhr schrieb peter flake <flake@xxxxxxx>:

Hi Patrick,


I would prefer not to write the same name twice, so I suggest:

-- naming like in most datasheets

type T_I2C_PCB is alias T_I2C_FPGA record
  SCL is SerialClock;
  SDA is SerialData;
end record;


Can the original problem be tackled by using the official naming with explanatory comments in the record declaration?




From: vhdl-200x@xxxxxxxxxxxxxxxxx <vhdl-200x@xxxxxxxxxxxxxxxxx> On Behalf Of Paebbels
Sent: 03 July 2020 10:45
To: P1076 Working Group <vhdl-200x@xxxxxxxx>
Cc: Lieven Lemiengre <lieven.lemiengre@xxxxxxxxxx>
Subject: Another missing feature in VHDL




I started working on our very old list of interfaces we collected, to check them with a vendor tool supporting interfaces (views) before I propose an open source release.


Take for example the I²C interface.

Some more official naming uses SCL and SDA, because it's used in IC datasheets and schematic designers are mainly non-programmers. They like short unreadable names in overfilled schematics.


On the other hand, we are ASIC or FPGA designers who write (hopefully) clean code. We would like to use a more descriptive name like SerialClock, SerialData. Or maybe, it's obvious that I²C is serial, so just Clock and Data.


My point is, we can't implement all different naming styles or ideas with VHDL interfaces, because it's based on records and each record type definition gives us an individual type. With Ryan's addition of closely related composites, we could convert two I²C naming variants.


-- signal fpga_signal : T_I2C_FPGA;

-- signal pcb_signal  : T_I2C_PCB;


fpga_signal <= (T_I2C_FPGA) pcb_signal;


BUT, this only works for records with all subelements with the same mode (same direction).


While this seems simple or overkill for an I²C interface, other interfaces like AXI are more complex.

1. one record for all signals with original unreadable names from ARM

2. 5 records in a top-record, one record per stream

3. full decomposition, so no repeated code/definitions


In VHDL, we can handle some of these problems with aliases.


What we currently can't do, is a "composite alias" or "record alias".

(I have currently no good name for it.)


-- long names

type T_I2C_FPGA is record

  SerialClock : std_logic;
  SerialData  : std_logic;
end record;  


-- naming like in most datasheets

type T_I2C_PCB is alias record
  SCL is T_I2C_FPGA.SerialClock;
  SDA is T_I2C_FPGA.SerialData;
end record;


Ideally, we could use a simple assignment:

fpga_signal <= pcb_signal;


In a more explicit way, we could use a conversion to apply this alias record

fpga_signal <= (T_I2C_FPGA) pcb_signal;  


Other use cases are:


* UART: RX,TX versus RxD, TxD


This idea is not about mapping interfaces of different sizes or amount of subelements. It's just naming.


Of course, you can also propose alternative ideas to solve the problem from above.


Kind regards



To unsubscribe from the VHDL-200X list, click the following link:

To unsubscribe from the VHDL-200X list, click the following link: