Naming conventions for signals, ports, components, instances?

Discussion in 'VHDL' started by Torsten Landschoff, Feb 20, 2007.

  1. Hi again,

    Another thing that bothers me is the number of names that I have to
    introduce. For example, my current project is about controlling a LCD
    by the FPGA (without cheating by using a PicoBlaze core as in the
    starter kit reference designs).

    Basically, my main entity looks like this:

    entity lcdexample is
    port (
    -- System clock (50 MHz on starter board)
    clock : in std_logic;

    -- LCD signals
    lcd_enable : out std_logic;
    lcd_command : out std_logic;
    lcd_write : out std_logic;
    lcd_data : inout std_logic_vector(3 downto 0));
    end lcdexample;

    architecture beh of lcdexample is
    ...

    signal lcd_enable_req : std_logic;
    signal lcd_data_wr : unsigned(7 downto 0);
    signal lcd_command_wr : std_logic;
    signal lcd_ready : std_logic;

    begin
    ...
    lcd_driver0 : component lcd_driver
    port map (
    clock => clock, tick_us => tick_us,
    -- Internal interface
    data => lcd_data_wr, enable => lcd_enable_req, command =>
    lcd_command_wr,
    ready => lcd_ready,
    -- External interface (to real LCD)
    lcd_enable => lcd_enable, lcd_command => lcd_command,
    lcd_write => lcd_write, lcd_data => lcd_data);
    ...
    end beh;


    Coming from software development, a number of issues strike me:

    1) The lcdexample top entity knows about the outputs of the
    lcd_driver. If the external interface changes, both lcdexample and
    lcd_driver have to be adjusted. I could work around that by using the
    record type for the external interface of the LC display but I am not
    sure if it is supported by XST. Is there any way that lcd_driver can
    connect to external FPGA pins without passing the ports from the
    containing component?

    With this simple example it looks quite harmless but I wonder about
    the final application which could well use >100 of the I/O pins of the
    FPGA.

    2) Is there any naming convention for the input/output ports and local
    signals corresponding to those? I'd like to only have lcd_data,
    lcd_command and lcd_enable in lcdhello, which goes through the
    lcd_driver entity to the LCD. If there is no solution to (1), how do
    you work around that? Any proven naming conventions for ports and
    signals?

    3) Same goes for the lcd_driver instance. The component is named
    lcd_driver but I'd like to name the instance lcd_driver as well. What
    do you do for your designs?

    4) My little experience with VHDL tells me that the clock signal is
    needed just about anywhere, sometimes scaled, inverted or something.
    Is there any possibility to create a "singleton" clock source instance
    that I can access in the different components? Something like a global
    clock signal?

    Thanks for any hints!

    Friendly, Torsten
    Torsten Landschoff, Feb 20, 2007
    #1
    1. Advertising

  2. Torsten Landschoff

    KJ Guest

    "Torsten Landschoff" <> wrote in message
    news:...
    > Hi again,
    >
    > Another thing that bothers me is the number of names that I have to
    > introduce. For example, my current project is about controlling a LCD
    > by the FPGA (without cheating by using a PicoBlaze core as in the
    > starter kit reference designs).
    >
    > Basically, my main entity looks like this:
    >
    > entity lcdexample is
    > port (
    > -- System clock (50 MHz on starter board)
    > clock : in std_logic;
    >
    > -- LCD signals
    > lcd_enable : out std_logic;
    > lcd_command : out std_logic;
    > lcd_write : out std_logic;
    > lcd_data : inout std_logic_vector(3 downto 0));
    > end lcdexample;
    >
    > architecture beh of lcdexample is
    > ...
    >
    > signal lcd_enable_req : std_logic;
    > signal lcd_data_wr : unsigned(7 downto 0);
    > signal lcd_command_wr : std_logic;
    > signal lcd_ready : std_logic;
    >
    > begin
    > ...
    > lcd_driver0 : component lcd_driver
    > port map (
    > clock => clock, tick_us => tick_us,
    > -- Internal interface
    > data => lcd_data_wr, enable => lcd_enable_req, command =>
    > lcd_command_wr,
    > ready => lcd_ready,
    > -- External interface (to real LCD)
    > lcd_enable => lcd_enable, lcd_command => lcd_command,
    > lcd_write => lcd_write, lcd_data => lcd_data);
    > ...
    > end beh;
    >
    >
    > Coming from software development, a number of issues strike me:
    >
    > 1) The lcdexample top entity knows about the outputs of the
    > lcd_driver. If the external interface changes, both lcdexample and
    > lcd_driver have to be adjusted. I could work around that by using the
    > record type for the external interface of the LC display but I am not
    > sure if it is supported by XST.

    'Usually' most people standardize on std_logic(_vector) for all top level
    entities because it presents the least problems when someone else tries to
    reuse that entity. Not to say that you can't use record types but most
    don't. If you do, you'll find that you need to seperate the 'record' into
    one for each VHDL mode (i.e. one type for 'in', another for 'out' and a
    third for 'inout' if you have more than just 'out').

    If you're not sure about whether a tool accepts something or not, try it out
    first on something small and see whether or not you like the results. As a
    general statement you can probably expect the fitter to mush the names a bit
    if you come out with a record type (i.e. abc.xyz might become abc_xyz)
    because at some point you'll need to assign pin numbers to each of those
    record elements and abc.xyz will not be legit for most any downstream tool.

    > Is there any way that lcd_driver can
    > connect to external FPGA pins without passing the ports from the
    > containing component?

    No magic....and really I don't think you want any. You're assuming that
    just because your lower level component has the same port names as the top
    level that you will always want to connect them up to each other without any
    intervening logic. That is not always the case, if you want something
    connected it is much clearer to specify that connection in plain text (i.e.
    your code) rather than rely on some behind the scenes shenanigans.

    >
    > With this simple example it looks quite harmless but I wonder about
    > the final application which could well use >100 of the I/O pins of the
    > FPGA.

    Generally though, those 100 I/O pins may be mapped not to just one entity
    but to several at the top level....not always, but many times...unless that
    top level of the VHDL is a simple wrapper around something else.

    >
    > 2) Is there any naming convention for the input/output ports and local
    > signals corresponding to those? I'd like to only have lcd_data,
    > lcd_command and lcd_enable in lcdhello, which goes through the
    > lcd_driver entity to the LCD. If there is no solution to (1), how do
    > you work around that? Any proven naming conventions for ports and
    > signals?

    What exactly are you trying to 'work around'?

    >
    > 3) Same goes for the lcd_driver instance. The component is named
    > lcd_driver but I'd like to name the instance lcd_driver as well. What
    > do you do for your designs?

    I've started prepending 'The_' to the entity name (i.e. 'The_lcd_driver :
    lcd_driver...'. I saw that first with code that Altera's Quartus SOPC
    Builder tool generates. At first it struck me as kind of lame but then
    realized it was better than something like 'U1' and at least as good as
    something like 'lcd_driver0' which are both forms that I've seen and been
    known to use in earlier times.

    >
    > 4) My little experience with VHDL tells me that the clock signal is
    > needed just about anywhere, sometimes scaled, inverted or something.
    > Is there any possibility to create a "singleton" clock source instance
    > that I can access in the different components? Something like a global
    > clock signal?

    Not really.....clocks and resets tend to have to pass through the hierarchy.
    One one level it's a pain, but on another it makes everything a lot easier
    to look at later and see what the connections really are since they're in
    plain text in the code. Remember, you'll write the code once, but look at
    it many times....and sometimes the person looking at the code will not be
    you and relying on 'behind the scenes' action won't be appreciated by that
    person at that time.

    Kevin Jennings
    KJ, Feb 20, 2007
    #2
    1. Advertising

  3. Torsten Landschoff

    Peter Guest

    > 'Usually' most people standardize on std_logic(_vector) for all top level
    > entities because it presents the least problems when someone else tries to
    > reuse that entity. Not to say that you can't use record types but most
    > don't.


    Hi,

    using records in the top level entity, I once found that signal names
    were not preserved. The record was implemented as a very wide standard
    logic vector, making it impossible to identify specific signals in the
    place&route phase.

    /Peter
    Peter, Feb 20, 2007
    #3
  4. Torsten Landschoff

    KJ Guest

    "Peter" <> wrote in message
    news:...
    >> 'Usually' most people standardize on std_logic(_vector) for all top level
    >> entities because it presents the least problems when someone else tries
    >> to
    >> reuse that entity. Not to say that you can't use record types but most
    >> don't.

    >
    > Hi,
    >
    > using records in the top level entity, I once found that signal names
    > were not preserved. The record was implemented as a very wide standard
    > logic vector, making it impossible to identify specific signals in the
    > place&route phase.
    >


    The actual signal name mushing that goes on is synthesis tool specific but
    what you've seen doesn't surprise me.
    KJ, Feb 20, 2007
    #4
  5. Torsten Landschoff wrote:

    > Coming from software development, a number of issues strike me:
    >
    > Is there any way that lcd_driver can
    > connect to external FPGA pins without passing the ports from the
    > containing component?


    Yes. Crush the hierarchy and pull everything into
    the same process. This puts all the register
    variables into the same scope, and any register
    value can be assigned directly to a port.

    This would solve 1, 2 and 3.


    > 4) My little experience with VHDL tells me that the clock signal is
    > needed just about anywhere,


    Yes

    > sometimes scaled, inverted or something.


    Hopefully not.

    > Is there any possibility to create a "singleton" clock source instance
    > that I can access in the different components? Something like a global
    > clock signal?


    That's the way to do it.
    Put the fastest clock on the global lines
    and use clock enables for anything slower.

    -- Mike Treseler
    Mike Treseler, Feb 20, 2007
    #5
  6. Hi Mike,

    On 20 Feb., 19:44, Mike Treseler <> wrote:
    > > Is there any way that lcd_driver can
    > > connect to external FPGA pins without passing the ports from the
    > > containing component?

    >
    > Yes. Crush the hierarchy and pull everything into
    > the same process. This puts all the register
    > variables into the same scope, and any register
    > value can be assigned directly to a port.
    >
    > This would solve 1, 2 and 3.


    .... and make a huge mess of the whole design. Not sure if you are
    being ironic.

    > > 4) My little experience with VHDL tells me that the clock signal is
    > > needed just about anywhere,

    >
    > Yes
    >
    > > sometimes scaled, inverted or something.

    >
    > Hopefully not.


    I was referring to the timing control of my LCD driver which scales
    the clock signal down to micro seconds. I fully understand why the
    Xilinx examples use an microcontroller core for communicating with the
    slow device, but I still wanted to try it from VHDL.

    > > Is there any possibility to create a "singleton" clock source instance
    > > that I can access in the different components? Something like a global
    > > clock signal?

    >
    > That's the way to do it.
    > Put the fastest clock on the global lines
    > and use clock enables for anything slower.


    I am currently passing the global clock signal around and sometimes
    another "tick" signal which is just the clock scaled down (to avoid
    having multiple scaler circuits). It's just that I would have liked to
    remove the "noise" ports (clock, reset) which are always the same
    (with my current small design).

    There is no way around that and this is considered a good thing (TM),
    so I'll leave it at that.

    Greetings

    Torsten
    Torsten Landschoff, Feb 21, 2007
    #6
  7. Torsten Landschoff wrote:

    > ... and make a huge mess of the whole design. Not sure if you are
    > being ironic.


    I wasn't, but obviously I didn't communicate
    my idea well. Each entity interface and instance
    involve some coding overhead, and I like to fit as much
    as I can into each.

    >>> 4) My little experience with VHDL tells me that the clock signal is
    >>> needed just about anywhere,

    >> Yes
    >>
    >>> sometimes scaled, inverted or something.

    >> Hopefully not.

    >
    > I was referring to the timing control of my LCD driver which scales
    > the clock signal down to micro seconds. I fully understand why the
    > Xilinx examples use an microcontroller core for communicating with the
    > slow device, but I still wanted to try it from VHDL.


    I would too. However, it is standard
    practice in synchronous design to use
    a single clock and synchronous strobes
    rather than multiple clocks.

    > I am currently passing the global clock signal around and sometimes
    > another "tick" signal which is just the clock scaled down (to avoid
    > having multiple scaler circuits). It's just that I would have liked to
    > remove the "noise" ports (clock, reset) which are always the same
    > (with my current small design).


    That is part of the overhead I was talking about.

    -- Mike Treseler
    Mike Treseler, Feb 21, 2007
    #7
  8. Hi,

    On 20 Feb., 11:36, "Torsten Landschoff" <> wrote:

    > 1) The lcdexample top entity knows about the outputs of the
    > lcd_driver. If the external interface changes, both lcdexample and
    > lcd_driver have to be adjusted. I could work around that by using the
    > record type for the external interface of the LC display but I am not
    > sure if it is supported by XST. Is there any way that lcd_driver can
    > connect to external FPGA pins without passing the ports from the
    > containing component?


    That is a problem in actual VHDL. The simple sollution of defining
    your own data type called
    my_interface has some practical problems mostly introduced by tools
    not supporting this way. SystemVerilog uses interfaces to overcome
    this problem. AFAIK interfaces are discussed to be included in new
    versions of VHDL (200x), but that may not help until mainstream tools
    support interfaces.

    > 3) Same goes for the lcd_driver instance. The component is named
    > lcd_driver but I'd like to name the instance lcd_driver as well. What
    > do you do for your designs?


    I start each instance with i_ (i_lcd_driver) this is as good or bad as
    many other ways.

    bye Thomas
    Thomas Stanka, Feb 22, 2007
    #8
  9. Hi Kevin,

    On 20 Feb., 12:03, "KJ" <> wrote:
    > > 1) The lcdexample top entity knows about the outputs of the
    > > lcd_driver. If the external interface changes, both lcdexample and
    > > lcd_driver have to be adjusted. I could work around that by using the
    > > record type for the external interface of the LC display but I am not
    > > sure if it is supported by XST.

    >
    > 'Usually' most people standardize on std_logic(_vector) for all top level
    > entities because it presents the least problems when someone else tries to
    > reuse that entity. Not to say that you can't use record types but most
    > don't. If you do, you'll find that you need to seperate the 'record' into
    > one for each VHDL mode (i.e. one type for 'in', another for 'out' and a
    > third for 'inout' if you have more than just 'out').


    Good point. I found that creating record types for inputs and outputs
    is just not worth the hassle :(

    > > Is there any way that lcd_driver can
    > > connect to external FPGA pins without passing the ports from the
    > > containing component?

    >
    > No magic....and really I don't think you want any. You're assuming that
    > just because your lower level component has the same port names as the top
    > level that you will always want to connect them up to each other without any
    > intervening logic. That is not always the case, if you want something
    > connected it is much clearer to specify that connection in plain text (i.e.
    > your code) rather than rely on some behind the scenes shenanigans.


    I just want to get rid of three different names for basically the same
    signal: One for the pin going out of the FPGA, one for my local signal
    (which I need to monitor the signal) and one for the other side of the
    internal component it is connected to.

    But I am glad that I did not miss anything obvious.

    > Generally though, those 100 I/O pins may be mapped not to just one entity
    > but to several at the top level....not always, but many times...unless that
    > top level of the VHDL is a simple wrapper around something else.


    Sure, which makes me nervous already with only little functionality.
    Especially when they are mapped to different component depending on
    the system state.

    > > 2) Is there any naming convention for the input/output ports and local
    > > signals corresponding to those? I'd like to only have lcd_data,
    > > lcd_command and lcd_enable in lcdhello, which goes through the
    > > lcd_driver entity to the LCD. If there is no solution to (1), how do
    > > you work around that? Any proven naming conventions for ports and
    > > signals?

    >
    > What exactly are you trying to 'work around'?


    Having basically the same signal at different levels inside the same
    name space.

    For example, my LCD controller driver has an enable input but also has
    an enable output going to the real LCD controller outside the FPGA. At
    first, I called each of these signals "lcd_enable". (The LCD driver
    accepts 8 bit characters and outputs in 4 bit nibbles, which is why
    the enable signal going outside toggles a few times for each byte).


    Greetings, Torsten
    Torsten Landschoff, Feb 22, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =B=
    Replies:
    4
    Views:
    9,289
  2. Floppy Jellopy

    Namespaces and Naming conventions

    Floppy Jellopy, Jul 20, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    528
    Kevin Spencer
    Jul 21, 2005
  3. Josh  Wolf
    Replies:
    2
    Views:
    3,263
    Martin Robins
    Mar 31, 2006
  4. Roy  Assaly
    Replies:
    1
    Views:
    464
    Roy Assaly
    Apr 10, 2006
  5. mreister
    Replies:
    1
    Views:
    3,166
    mreister
    May 25, 2010
Loading...

Share This Page