Rename signal as they are defined

[ungultig1]

Goog morning @jeremiah-c-leary,

I wonder, if the following feature can already be activated (and I missed it) or please could be implemented (?):

At the moment the signals-naming is defined by vsg as default.

Is there any possibility, that the signals-name are being formatted by looking at the definitions?

For instance:

architecture behaviour of example is
...
...

signal sl_mySignalNaming : std_logic; -- my defined signal-naming

begin

-- vsg-default after format:
sl_mysignalnaming <= '1'

-- Propose:
-- a setting, which allows to format the signals-naming as defined above:
sl_mysignalNaming <= '1' -- this is the wrong case while coding
-- after format, this will be corrected to:
sl_mySignalNaming <= '1' -- as defined above

end behaviour;

As i prefer the camel-case-notation and vsg of course couldn't know how to keep the correct naming, vsg could keep a look at the signals-name definition (also considered the definitions in record-, port- signal-namings etc.)

Big thanks to you.

Greetings,

[jeremiah-c-leary]

Morning @ungultig1 ,

There are two rules which work together to provide the feature you are looking for. Rule signal_004 enforces the case of the signal identifier and rule signal_014 which enforces the case of the signal identifier when used. Unfortunately, rule signal_004 does not support camelCase at this moment.

I am working on implementing support for camelCase in issue #924. It would be nice to have another voice in the discussion to help guide the implementation. I am currently adding support for prefixes and suffixes along with camelCase.

Meanwhile, if you use the following configuration:

rule:
  signal_004:
    disable: True

and run it against your example code:

  1 architecture behaviour of example is
  2
  3   signal sl_mySignalNaming : std_logic; -- my defined signal-naming
  4
  5 begin
  6
  7   -- vsg-default after format:
  8   sl_mysignalnaming <= '1';
  9
 10
 11   -- Propose:
 12   -- a setting, which allows to format the signals-naming as defined above:
 13   sl_mysignalNaming <= '1'; -- this is the wrong case while coding
 14   -- after format, this will be corrected to:
 15   sl_mySignalNaming <= '1'; -- as defined above
 16
 17
 18 end behaviour;

The code will be fixed to:

  1 architecture behaviour of example is
  2
  3   signal sl_mySignalNaming : std_logic; -- my defined signal-naming
  4
  5 begin
  6
  7   -- vsg-default after format:
  8   sl_mySignalNaming <= '1';
  9
 10   -- Propose:
 11   -- a setting, which allows to format the signals-naming as defined above:
 12   sl_mySignalNaming <= '1'; -- this is the wrong case while coding
 13   -- after format, this will be corrected to:
 14   sl_mySignalNaming <= '1'; -- as defined above
 15
 16 end architecture behaviour;

This would be a temporary fix until the other issue is implemented.

Regards,

--Jeremy

[ungultig1]

Hello @jeremiah-c-leary ,

yeah, deactivating signal_004-rule made the difference. Great, Thanks.

Unfortunately, it wont format the signal-names, when defined inside a record. There might be another rule?

Example:

architecture behaviour of example is
...
..
type t_myrec is record 
    sl_mySignalNaming : std_logic; -- my defined signal-naming
end record t_myrec;

constant myrec : t_myrec :=
(
    sl_mySignalnaming => '0' --- After Format, wont apply my defined signal-naming here.
);

signal   rec                           : t_myrec;

begin

-- After Format, wont apply my defined signal-naming here also:
rec.sl_mySignalnaming <= '1'

end behaviour;

maybe I'm missing here something else.

Thank you.

Greetings,

[jeremiah-c-leary]

Good Afternoon @ungultig1 ,

There are currently no rules to enforce consistent casing in your latest example. I currently do not have a rule similar to what you are requesting so it will take a bit to implement. I have to ensure I keep the scoping correct. I think I have to plan on how to do it.

--Jeremy

[ungultig1]

Hello @jeremiah-c-leary ,

yeah, deactivating signal_004-rule made the difference. Great, Thanks.

Unfortunately, it wont format the signal-names, when defined inside a record. There might be another rule?

Example:

architecture behaviour of example is
...
..
type t_myrec is record 
    sl_mySignalNaming : std_logic; -- my defined signal-naming
end record t_myrec;

constant myrec : t_myrec :=
(
    sl_mySignalnaming => '0' --- After Format, wont apply my defined signal-naming here.
);

signal   rec                           : t_myrec;

begin

-- After Format, wont apply my defined signal-naming here also:
rec.sl_mySignalnaming <= '1'

end behaviour;

maybe I'm missing here something else.

Thank you.

Greetings,

Good morning @jeremiah-c-leary,

were you able to create such rule? A rule, which does the name-formatting for used record signals as it is declared inside the record-structure?

Thank you. Greetings.

[jeremiah-c-leary]

Afternoon @ungultig1 ,

At the moment I am having an issue with scoping and ensuring a consistent case can be applied correctly when signals with similar names are used. I do not have a reasonable solution yet that does not require a significant update to the internal data structure.

I believe it is something that should be implemented, I'm afraid it will take awhile before it finally is implemented.

Regards,

--Jeremy

[jeremiah-c-leary]

Morning @ungultig1 ,

So I have been thinking about this a little more and it seems there are two parts you asking for:

1. control case and prefix/suffix of elements of a record
2. ensure the same case is applied throughout the code

I believe the first one should not be that hard, and I want to think the second would could be done with my existing data structure. I just need to think on it a little more.

Regards,

--Jeremy