Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

using VHDL record type as port

Hi

In order to improve readability I want to use record types for buses so when I have a bus traversing across hierarchies, instead of declaring and mapping all of the signals, I will do it once for the bus.

Let's say I have an SPI master wrapped inside my top level entity (or even further down the hierarchy).

So I define an SPI bus

--- Quote Start ---

type SPI_bus is record

clk : STD_LOGIC;

cs: STD_LOGIC;

master_data: STD_LOGIC;

slave_data: STD_LOGIC;

end record;

--- Quote End ---

I want to avoid declaring separately clk cs master_data as outputs and slave_data as input, for my top level entity. is there a way to do it, other the defining a type for outputs and a type for inputs? maybe adding something to my type declaration?

Thanks in advance.

14 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    You cannot separate ins and outs within a record. The entire record has to be one direction.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    No, when you have a record type for an output, the synthesizer will create a driver for each member of the record. So you can't avoid using two records, one for inputs and one for outputs.

    It shouldn't be a problem in a testbench on the other hand. In that case you should be able to use a single record, declare it as inout on each entity, and drive the inputs members to high impedance.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    But that, IMO, would break the improved readability the OP was looking for. If I suddenly opened a peice of code with 'Z's all over ths shop, Id wonder if the previous engineer knew what he was doing.

    Personally, I think record types should be kept to a situation where you need to instantiate multiple buses that are identical. For the IO on a single entity, its clearer if you separate out all the ports, and keep your code well documented and segregated - handle each interface in its own set of processes etc.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Tricky and Daixiwen thanks for your input.

    Just to see if I understand what you are saying, I can define a default value of 'Z' (perhaps in the type deceleration,that I keep in a separate package), and define the bus as INOUT.

    But, as you see it, the readability of this style is poorer.

    I have to think about it, but as I see it, if I use a clear enough naming convention, it is improvement.

    any more thoughts \ ideas \ insights?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    like i said, i tend not to use them in normal designs so much. but can be v handy in testbenches for bfms and linked lists and stuff.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I don't see a particular advantage of using records for ports. I have std_logic_vectors for GPIO pins in some applications, that are declared as inout and get a pin-wise direction assignment in the respective design variant. The same method should work with records as well.

    But readbility surely isn't improved this way and you get some dummy warnings like "permanently enabled tri-state buffer" and similar.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I just pointed out what you could do if you really wanted to use a unique record as a port. But I'm not sure it's more readable, and the most important problem is that it's not synthesizable, so you can only use that in test benches.

    To use records you'll need to use two of them, one for inputs and one for outputs. But it can become a real mess if you have more than two components to connect together.

    What I usually do is use only regular types for ports (std_logic(_vector), boolean, (un)signed etc...) and regroup them by interfaces in my ports and signal definitions. I'm also using Doxygen to generate the code documentation, and when you use Doxygen group commands those signals can be nicely regrouped in the generated documentation.

    I find this solution a good compromise, even if it can mean a lot of ports and signals, and long code just to connect the pieces together.