Hello Jonas, I was just saying that VHDL has capabilities to create bigger integer numbers. That doesn't imply that I like or teach that one should use INTEGERs for hardware design. I'm using INTEGERs only for constants and generic parameters. Even if you could specify a new integer with the range of a 64-, 128- or 256-bit INTEGER, that's not enough for some calculations. So a SIGNED/UNSIGNED might be more flexible.
> type My_FSM is (Init, Start, Stop) with
> Init'Logic => "001", Start'Logic => "010", Stop'Logic => "100";
You can specify enum and FSM encoding in VHDL by using attributes.
Unfortunately, these attribute
names and their content is not specified, but most vendors and tools use
similar names.
attribute fsm_encoding : string;
attribute fsm_encoding of state : signal is "gray";
or
attribute enum_encoding : string;
attribute enum_encoding of My_FSM : type is "001 010 110";
attribute fsm_encoding : string;
attribute fsm_encoding of state : signal is "user"; -- use the encoding of
state's type
> Ok. In the adder example above, the endianness was important because we
> interface an external
> entity, but thanks to the conversion to std_logic_vector, endianness is
> specified, so you must b
> right : endianness is not important on integers.
The endian problem was introduced by architectures which have a bigger bus
transfer/register size
(lines/words) compared to the smallest addressable memory unit (byte). This
problem does not
occur for pure numbers and registers.
Are you referring to the bit-order (MSB/LSB on right/left)?
This is solved by VHDLs to/downto ranges.
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden
Tel.: +49 351 463-38451
Fax: +49 351 463-38324
Raum: APB-1020
E-Mail: patrick.lehm...@tu-dresden.de
WWW: http://vlsi-eda.inf.tu-dresden.de
-----Original Message-----
From: Ghdl-discuss [mailto:ghdl-discuss-boun...@gna.org] On Behalf Of Jonas
Baggett
Sent: Wednesday, July 27, 2016 9:43 PM
To: ghdl-discuss@gna.org
Subject: Re: [Ghdl-discuss] Better way for integer handling in VHDL ?
Hello Patrick,
> you can define own integers in VHDL:
>
> type myint is range -12 to 32234324;
Ok. When I am doing testbench code, I use integer types as much as possible.
But for synthetizable code, I am not used to use integer signals, but to use
signed/unsigned from numeric_std. That's the way I have been teached to follow,
so I have never even thought about using integer signals in synthetizable code,
but it may be a good option. So when you have to do an adder, would you write
it that way ? :
entity My_Adder is
port (A, B : in Integer range 0 to 2**N - 1;
C : out Integer range 0 to A'High + B'High);
end My_Adder
architecture My_Adder_RTL of My_Adder_RTL is
begin
C <= A + B;
end My_Adder_RTL;
-- Interfaces My_Adder to an external entity
entity Top_Adder is
port (A, B : in Std_Logic_Vector (N - 1 downto 0);
C : out Std_Logic_Vector(N downto 0);
end Top
architecture Top_Adder_RTL of Top_Adder_RTL is
-- It's probably useless to specify again the integer ranges
signal A_Int, B_Int, C_Int : Integer;
begin
A_Int <= To_Integer (Unsigned (A));
B_Int <= To_Integer (Unsigned (B));
My_Adder_Inst : entity Work.My_Adder port map (A => A_Int,
B => B_Int,
C => C_Int);
C <= Std_Logic_Vector (To_Unsigned (C_Int, C'Length));
end Top_Adder_RTL;
Maybe it isn't even needed to specify the integers range as the synthetizer
could guess their needed bit size.
> The languages doesn't forbid large integers, but must tools are
> restricted in handling such large literals/signals/variables. You
> could create your own
> "64 bit" integer:
>
> constant BITS : positive := 64;
> type long is range -2**(BITS-1)+1 to 2**(BITS-1) - 1;
The restrictions of these tools makes integers less attractive. It's not cool
when you have to use larger numbers than expected and then have to rewrite you
code because you have to switch from Integers to IEEE signed/unsigned. And for
modulo numbers, IEEE signed/unsigned seem to be a better choice.
> Integers are numbers and are not related to logic states. It is false
> to infer any physical representation from an integer type (e.g.
> endian, 2s complement, bit count, ...). If you need a physical
> representation, you can use signed/unsigned and convert a generic
> number (integer) to a specific number (e.g. signed) with 2s complement
> arithmetic.
But IEEE signed/unsigned are numbers with a defined physical representation,
isn't it ?
Ok, let's say you have just made a nice entity that calculates the cubic root
(let's call it cubic_root_calc) of an integer number and put it in your
personal library. Then every time you need to calculate the cubic root of an
internal signal in one of your project, you could just use cubic_root_calc. But
let's say that one day you have some VHDL code interfacing an external entity
which has a register that represents a signed number and you wish to read that
value, calculate it's cubic root and write it back to the register. Then you
will first think about cubic_root_calc, but you have to be aware on how the
register value is physically represented and if you have no luck and the
representations differ, I see 2 options : add some code to transform the number
from one representation to another, or create a new compatible version of
cubic_root_calc in order to avoid the performance penalty due to the conversion.
If you just could specify the physical representation of an integer type, then
you specify it to match the register value physical representation and that's
it.
> The endianness of a word is an memory, bus transfer and addressing
> issue it is not related to numbers and integers. So it's no property of a
> number.
Ok. In the adder example above, the endianness was important because we
interface an external entity, but thanks to the conversion to std_logic_vector,
endianness is specified, so you must be right :
endianness is not important on integers.
> Here is a list of Integer proposal from the IEEE p1076 working group:
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ArbitraryIntegers
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/LongIntegers
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ModularTypes
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/IntegerOperators
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ImplicitConversionNume
> ric http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ExtendedIntegers
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/PhysicalTypeRange
>
> If you want to participate in these discussions, please visit:
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/WebHome
> and register for TWiki and the IEEE reflector (mailing list).
Thanks for the links ! I should better have a look on them.
Have a nice evening,
Jonas
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
