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

Re: Another missing feature in VHDL

Hi Patrick,
I would postulate that the problem is already solved.

With VHDL portmaps, conversions on bidirectional ports are
supported.   Hence, with that and VHDL-2019 extension to
records and closely related, the following is legal:

port map (
    . . .
) ;

Best Regards,

Hello Jim,

I choose a syntax based on the keyword is, because this is used in alias definitions. I already had => in my mind, but
it's a linking in types not objects (link in port maps, where you link signals, which are objects).

Yes, spaceship (rejected from VHDL-2019) would be needed plus bidirectional conversion functions. The idea was to
not use a heavy entity instantiation to connect simple interfaces just because of naming rules.

For your initial question why we need it:
  • For naming conventions that differ between PCB schematic and IC internals.
    We should keep the top-level interface as close to the names in the schematic, so we can debug easier from
    code to schematic and vice versa.
  • IP cores use different names like Tx or TxD or DataOut.
    In a clean design, our coding style rules will specify how to write our own code, but we would like to easily
    connect (third party) IP cores with their style to our harness.
That's why I was initially thinking about using aliases for this purpose.

Now it looks like we definitely need conversions and spaceships together.

Kind regards

Am Sa., 4. Juli 2020 um 00:23 Uhr schrieb Jim Lewis <jim@xxxxxxxxxxxxxx>:
Hi Patrick,
I understand the syntax you are proposing, but I am not
understanding the use model.

What I understand is that in the FPGA design, we have
T_I2C_FPGA defined in FpgaPkg.vhd:
type T_I2C_FPGA is record
  SerialClock : std_logic;
  SerialData  : std_logic;
end record;

In the PCB design, in  PcbPkg.vhd, we have:
-- naming like in most datasheets
type T_I2C_PCB is record
   SCL : std_logic ;
   SDA : std_logic ;
end record;

OOPs.  Now we need to rectify the situation to allow integrating
the PCB with the FPGA.   So in PcbPkg.vhd, we change the
definition of T_I2C_PCB to:
-- naming like in most datasheets
type T_I2C_PCB is alias T_I2C_FPGA record
  SCL is SerialClock;
  SDA is SerialData;
end record;

Is this what you are trying to accomplish?  

Is this better than simply applying a type conversion
in the board level harness/netlist in the association (spaceship)?

signal  I2C_FPGA : T_I2C_FPGA ;
signal  I2C_PCB   : T_I2C_PCB ;

-- This follows existing type conversions for inout ports:

If you like your proposed alias method, we probably want
something that is similar to the existing alias syntax.  
alias T_I2C_PCB is
   SerialClk  => SCL,
   SerialData => SDA
 ) ; 

I am wondering if SerialClk would on the left since
it is a formal of T_I2C_FPGA the thing we are associating
with or SCL on the left since it is the resulting formal
of the derived type.  

Maybe this is part of the derived types and we do something like:
type T_I2C_PCB is new T_I2C_FPGA record
   alias SCL : std_logic is SerialClk ;   -- association
   alias SDA : std_logic is SerialData ;
   Fred : std_logic ;                     --  Extension

 ) ;

I would not want to solve this one without looking at a larger
scope - including derived record types similar to SUAVE.

OTOH, it would be nice to be able to create derivative subprograms
of the form:
  procedure Alert(
    AlertLogID   : AlertLogIDType ;
    Message      : string ;
    Level        : AlertType := ERROR
  ) ;
  procedure Alert( Message : string ; Level : AlertType := ERROR ) 
    is new Alert(AlertLogID => BASE_ID, Message => Message, Level => Level) ; 


On 7/3/2020 2:25 PM, Paebbels wrote:
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:

Jim Lewis                                  Jim@xxxxxxxxxxxxxx
VHDL Training Expert             
IEEE VHDL Working Group Chair                      
OSVVM, Chief Architect and Cofounder

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

Jim Lewis  
VHDL Training Expert, SynthWorks
IEEE 1076 VHDL Working Group Chair
Open Source VHDL Verification Methodology (OSVVM), Chief Architect and Co-founder


VHDL Training on leading-edge, best coding practices for hardware design and verification.

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