Jonas wrote:Hello,
There are things that I think are missing in VHDL or that may be good features to be added to VHDL.
Maybe some of them are not good ideas. Then I would like to have your opinions, and also what do you think can be missing in VHDL.
First off, this is probably not the best place to post this. its not a very popular forum and generally only read by beginners. Try comp.lang.vhdl newsgroup instead - some of the standards creaters post and read that.
* Possibility to overload entities as it is possible to do with procedures and functions
As a silly example, let's say we want to do an entity for a And gate that can have Std_Logic or
Std_Logic_Vector inputs and outputs.
Currently we would have to write the entity declaration so :
entity And is
port (A1_i, A2_i : in Std_Logic;
B_o : out Std_logic );
end And2;
entity And_SLV is
port (A1_i, A2_i : in Std_Logic_Vector;
B_o : out Std_logic_Vector );
end And_SLV;
But with entity overloading, we would be able to do :
entity And is
port (A1_i, A2_i : in Std_Logic;
B_o : out Std_logic );
end And;
entity And is
port (A1_i, A2_i : in Std_Logic_Vector;
B_o : out Std_logic_Vector );
end And;
However, when we do the architecture declaration it is still needed to find a way to tell for which
entity it is.
This is not a very good example. You could quite easily use generics and use those to set the size of std_logic_vector, which can have a 'length of 1 (0 downto 0). If you are changing the interface, you're probably also changing the function, and with VHDL's strong typing rules, the architecture code would have to be different for each overloaded entity, so you end up with a new architecture anyway.
* Named constants
Here is for example a named number declaration in Ada :
Avogadros_Number : constant := 6.022137 * 10**23;
If a similar feature would be available in VHDL, then it would be able to declare a constant like that :
constant Litteral := "0111";
This constant Litteral can be used as std_logic_vector, bit_vector, signed, unsigned or string without
any type conversion, because we define a litteral but we don't specify yet in which type it has to be
considered, but that will only be known when it will be used.
Actually this feature already exist in VHDL, but only in a limited way. We can see for example the
following declarations in the standard package :
type integer is range -2147483648 to 2147483647;
type real is range -1.0E308 to 1.0E308;
type time is range -2147483647 to 2147483647
The type of the number litterals are not indicated because they are named numbers. Then there is
something I don't understand :
- If it is a bad feature, why is it used in the standard package ?
- If it is a good feature, why is it very uncompletely implemented in VHDL ?
Again, this is down to strong typing. I think if you wanted to do this you would end up breaking the type system of VHDL.
* Derivated types
In Ada, it is possible to create a new type from another one that will inherit all of its functions and
procedures but are incompatible from the former type because it is not one of its subtype.
Unfortunately, this feature in not available in VHDL.
I think you are forgetting the main purpose of VHDL - to simulate digital systems, which at the end of the day are just a load of bits. A digital system has no knowledge that one number is complety separate from another - it can add any two numbers it likes. Its down to the engineer to make sure the algorithm performs correctly.
* A different handling of range directions
In the following link :
http://tams-www.informatik.uni-hamburg. ... directions,
It is told that it is not allowed to write something like that :
signal r3, r4: Bit_Vector(3 downto 0);
...
r3(0 to 1) <= r4(0 to 1);
Because the directions of slices must be the same as the directions of the array being sliced.
However the signals r3 and r4 have both representation and associated funtions and
procedures known by the fact they are declared as Bit_Vector. For me, their range of direction is only a
matter of view point. Like we can write :
constant A : Integer := 6;
or
constant A : Integer := 2#110#;
Because 6 and 2#110# represent the same integer number but under a different view.
This is because of the endianness of computers. some are designed as big endian (so the MSB represents the highest power of 2) and little endian (where the LSB represents the highest power of 2). You dont have this problem in software (like ADA) because the compiler takes care of all of that.
This can also lead to problems when we use unconstrained array in entities, because it is also not
possible to indicate the range direction of an unconstrained array.
For example, if we have :
entity Example is
port (A_i : in Std_Logic_Vector;
B_i : in Std_Logic_Vector;
C_o : out Std_Logic_Vector );
end Example
architecture Example_RTL of Example is
signal Internal_s : Std_Logic_Vector (A_i'Range);
begin
Internal_s (1 downto 0) <= B_i (1 downto 0);
(...)
If you're specifying ranges inside a vector when you left the input unconstrained, you're doing it wrong. The whole point about leaving it unconstrained is that you dont really have any knowledge of size or direction. But if you really need to, all types and arrays have an attribute 'ascending that tells you if the vector is a "to" or a "downto". You can use this to change your choice of to or downto if you really need to.
Suppose that the Example entity is mapped so in the higher level block.
* If generate also on packages and declarations
I am currently working on a projet in VHDL for a motor regulation. I have several packages that contains
constants. These constants can vary depending :
- If we are doing a simulation or a synthesis
- The type of the simulated motor
- The kind of the wanted simulation test if we are doing a simulation
- The motor control board used
Because I don't want to multiply the files that contain the constants packages for all the possible
combinaisons, I had to make a Select_Val function overloaded as much as needed and used for example so :
constant My_Constant := Select_Val (Environnment = Synthesis,
Val_True => 1000,
Val_False => 0 );
I can live with that, but why not to allow something like that ?
if Environnment = Synthesis generate
constant My_Constant := 1000;
else
constant My_Constant := 0;
end generate;
VHDL 2008 allows generics on packages. But for years people have been using TCL scripts to set up generic packages. You set up the constants in the project, and the TCL script outputs a VHDL package that contains all of the setup constants for that setup.
* Unions
For enum types, there are attributes for Xilinx ISE called enum_encoding and fsm_encoding that can define
the encoding of an enum type. However, this is not normalized and for a different synthesis tool, these
attributes may exist under a different name.
So for example, it is possible to write :
type Ty_State is (Zero, Start, Running, Stop, Stopped, Reset);
attribute enum_encoding : string;
attribute enum_encoding of Ty_State : type is "001 010 100 110 111 101";
signal Present_State_s, Next_State_s : Ty_State;
attribute fsm_encoding : String;
attribute fsm_encoding of Present_State_s : signal is "User";
This is because the synthesis tool is usually better at chosing the encoding than the human. If you absolutly HAVE to specify the states, and make it portable across vendors, why not define a subtype of std_logic_vector and create a load of constants. Its not really a lot different:
subtype my_state_t is std_logic_vector(3 downto 0);
constant STATE_0 : my_state_t := "0000";
constant STATE_1 : my_state_t := "0001";
--etc.
* Views
If we declare the following signal :
A_s : Signed (3 downto 0);
The numeric_std package was written, so that it is easy to do arithmetics on signed type signals with
decimal litteral, see for example :
A_s <= A_s + 3;
But it is impossible to do that :
A_s <= 3;
Instead, it has to be done this way;
A_s <= To_Signed (3, A_s'Length);
It seems to me a little illogical to be able to do
A_s <= A_s + 3;
on a signal but not
A_s <= 3;
I guess the reason was because it would be needed to overload the assignation operator so that it can
assign an integer number to a signed number. But this is not allowed (to my knowledge) to overload an
assignation operator in VHDL. I think the reason is that the assignation of a signal of one type to a
signal of another type doesn't sound good in a strongely typed language.
Exactly right. In the + function, the 3 is converted to signed type then the arithmatic is completed. The lack of the ability to overload the assignment function has annoyed some people for a while, but has never really posed a problem for most people.
But why not say that 3 is not of type integer, but of type signed ? After all in this context, it can be
just another way to write "0011", like 2#0110# and 6 are only a different view on the same value.
However, it seems to be impossible to do that in VHDL, because the type signed is defined so :
type Signed is array (Natural range <>) of Std_Logic;
and Std_Logic :
type std_ulogic IS ( 'U', -- Uninitialized
'X', -- Forcing Unknown
'0', -- Forcing 0
'1', -- Forcing 1
'Z', -- High Impedance
'W', -- Weak Unknown
'L', -- Weak 0
'H', -- Weak 1
'-' -- Don't care
);
subtype std_logic is resolved std_ulogic;
Then it seems at first glance that it is impossible to make 3 and "0011" a different view on the same
value.
At the end of the day, VHDL is simulating real hardware that is all about bits rather than software where you can encapsulate things however you want. And with the typing system you need to be explicit about what you mean.
* Automatic inclusion of the IEEE packages
Except maybe for testbenches, I can't rememeber of having written an entity and architecture without
having included the std_logic_1164 package and most of the time I also include the numeric_std package.
Why not to say for the next revision of VHDL that those packages would be automatically included and that
it is time for the 15 years (!) obsolete packages std_logic_(arith/signed/unsigned) to die ?
I hope that this post was not too long to read for you.
Jonas
Because you might not want them.
Alot of your ideas seem to come from the fact that because VHDL was based on ada, it should take all the features with it. You have to remember the destination for the VHDL - digital logic.