Aliases for register bits in packages

[FpgaEE]

Hi all,

I'm not a new designer but am new here and hope someone might be able to help.

We have a design in which we'd like to pass the processors control (R/W) and status (R.O.) resisters around using two records: ControlRegisters and StatusRegisters.

Further assume ControlRegisters.TriggerControl(2) controls a trigger pulse that is used in several modules of the design and that the record ControlRegisters is brought into several components at the top level of the design. What we'd like to do is create an alias, call it MasterTrigger_A in a common place so that
1. Every module knows about this particular bit within ControlRegisters.TriggerControl
2. There is a single point of documentation and maintanance of that bit's definition

Initially, we created a package that defines ControlRegisters_type and StatusRegisters_type and the alias MasterTrigger_A defined as follows:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
type Control_Registers_type is record
    TriggerControl: std_logic_vector(15 downto 0);
    GpControl: std_logic_vector(15 downto 0);
end record;
 
Signal ControlRegisters : ControlRegisters_type;
MasterTrigger_A : std_logic is ControlRegisters.TriggerControl(2);

---

Note the signal declaration is necessary for VHDL to understand what "ControlRegisters" means but as it turns out that's a double edged sword. (More on this in a moment.)

Next in the various .vhd modules we referenced our MasterBlaster_pkg in work. All compiled fine. Except it did not work.

After some experimenting, we took the alias out of MasterBlaster_pkg and placed it in each module that referenced it and everything works fine. So... We believe the problem is that the alias in the package is referencing the signal in the package (same name) and not the signal within the module we were referencing it.

Is there a way to "fix" our approach?

Taking a step back, this CAN'T be all that unique of a requirement. What have you all done?

Thanks to all who take their time to consider this.

Tom

 

[FvM]

As far as I'm aware of, you can't define signals in packages in a meaningful way. So you neither can define aliases therein.

All signals have to be defined in actual design entities and aliases need to refer to it. Because VHDL doesn't know include files as Verilog does, you have to copy the alias definition as text to the design entities. You could also use functions or procedures to wrap the alias functionality. Not very straightforward, I fear.

But perhaps I'm also missing an ingenious way to implement the alias thing.

 

[std_match]

I have not tried it, but peter J. Ashenden says it is possible to define signals in a package:

https://books.google.se/books?id=Xb...nepage&q=vhdl "global signal" package&f=false

If it is synthesizeable, it could be useful for debug signals. If you have a debug connector, define signals for it in a package and connect them to the pins in the top entity. It should then be possible to route any signal deep down in the design to a debug pin without changing any entity declarations. I learned that probing signals in sub-blocks is possible in VHDL-2008, but I don't know if it is synthesizeable, we are still using VHDL-93 at work!

 

[K-J]

Here are some comments:
- If the various entities really do need access to all or a substantial chunk of these registers, then they should simply be made as inputs to the various entities and connected at the top level.
- The register bit definitions in the record should be defined in a package seperate to all of the entities. The actual signal that is of that record type is declared at the top level so that it can then be passed around to everybody that needs it.
- Your use of 'MasterTrigger_A : std_logic is ControlRegisters.TriggerControl(2)' says to me that your statement "Every module knows about this particular bit within ControlRegisters.TriggerControl" is not really true. If it was true, there would be no need for the alias. It looks to me like every module has a 'master trigger' input signal. If so, then you can simply connect that input to ControlRegisters.TriggerControl(2) via the port map to the entity.
- Your use of 'ControlRegisters.TriggerControl(2)' to have a meaning of 'MasterTrigger_A' says to me that the 'TriggerControl' field is not properly defined. That field should be broken down further so that 'bit 2' is in fact called 'MasterTrigger_A'. Then the port map of this signal to all of the entities would look like this: "MasterTrigger => ControlRegisters.MasterTrigger_A,". I highly suspect that the (2) that you used is simply because that is where it happens to be in the bit definitions rather than because you have three levels of master trigger (i.e. 0, 1 and 2).

All for now.
Kevin Jennings

 

[TrickyDicky]

In VHDL, there is nothing wrong with signals in packages, and then defining aliases on them should also be fine.
But the big stumbling block is that Quartus will refuse to compile a design with a signal in a package. On raising a support request about this, they flat out refuse to support it.

So, for synthesisable code, dont put a signal in a package.

 

[FvM]

Signals in packages are permitted by the VHDL specification and, as I notice, also in IEEE 1076.6 (Standard for RTL synthesis). In so far there's no doubt that it can be synthesized in pre-2008 VHDL. It's working isn't specified in the standard, but I understand it as design global signal, visible to all entities that import the package, as described by std_match in the debug signal example. This means, it would act similar to a bidirectional "bus" connecting a signal in the top entity through the design hierarchy. Of course a global signal of this kind easily brings up "multiple net driver" issues if not used well-considered. Thus I can imagine why Altera didn't want to implement it.

But I have to agree with the previous statements: Package signals (together with respective aliases) are synthesizable and should be supported by the synthesis tools. Does anyone knows which tools actually do?