Naming conventions for signals, ports, components, instances?

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

"Torsten Landschoff" <> wrote in message
news: ps.com...
> 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

> '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" <> wrote in message
news: ups.com...
>> '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.

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

Hi Mike,

On 20 Feb., 19:44, Mike Treseler <mike_trese...@comcast.net> 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 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

Hi,

On 20 Feb., 11:36, "Torsten Landschoff" <t.landsch...@gmx.de> 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

Hi Kevin,

On 20 Feb., 12:03, "KJ" <kkjenni...@sbcglobal.net> 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