Hi, Given an array of enums, it is clearer if COUNT and LENGTH are distinct. I do not think either of them should apply to integer. Peter From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jim Lewis Sent: 26 June 2015 18:55 To: vhdl-200x@eda.org Subject: Re: [vhdl-200x] Updated Enum Attributes twiki page Hi Patrick, WRT 'LENGTH vs 'COUNT: David's comment is that 1076 currently uses 'LENGTH only for arrays. This does not preclude us from extending its meaning. David expressed a concern about integer'left being implementation dependent. I don't think this impacts LENGTH/COUNT as integer'LENGTH will be out of integer range. I did not see any other technical arguments against LENGTH/COUNT did you? Jim On 6/26/2015 7:48 AM, Lehmann, Patrick wrote: Hello, after my question: “VHDL: Why is ‘length not defined for enums†on stackoverflow, Jim Lewis encouraged me to update the proposal on addition attributes for enum types. http://stackoverflow.com/questions/31032446/vhdl-why-is-length-not-defined-for-enums http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/EnumAttributes Here are some additional thoughts to the updated twiki page. This email is also indented to be the basis for a discussion, regarding my twiki extensions. The following sections are numbered for better reference. 1) The ‘old’ proposal requested an additional attribute named ‘LENGTH. I added ‘COUNT as an alternative name for ‘LENGTH, because LENGTH is currently used to get the number of elements in an array. So maybe it’s better to use ‘COUNT to get the number of enum members. 2) I added two use cases on the twiki page section ‘Use Model’. Both examples perform some sort of serialization task, which need ‘COUNT as an integral part of the algorithm. Insertion: Why do we need serialization? ============================== Serializing and de-serializing enumerated types to binary representations is a common use case in simulation and synthesis code. While VHDL does not support type generics to describe generic RAMs, FIFOs or cross-clock synchronizers, a 'serialization' functionality is needed to convert enum values into a common binary representation. These converted values (e.g. of type STD_LOGIC_VECTOR) can be passed to a FIFO. It's also possible to convert these STD_LOGIC_VECTOR values back to a enum value. Example 1 - Serializing enum values to std_logic_vector and vice versa for using with generic VHDL components: type T_STATUS is ( STATUS_IDLE, STATUS_TRANSMITTING, STATUS_COMPLETE, STATUS_ERROR ); function log2(value : NATURAL) return POSITIVE; -- returns log2 of value function str_len(value : STRING) return NATURAL; -- returns the length of a NUL terminated string function str_trim(value : STRING) return STRING; -- returns a trimmed string without trailing NUL characters function serializeStatus(value : T_STATUS) return STD_LOGIC_VECTOR is begin return std_logic_vector(to_unsigned(T_STATUS'pos(value), log2(T_STATUS'pos(T_STATUS'high) + 1))); end function; function deserializeStatus(slv : STD_LOGIC_VECTOR) return T_STATUS is begin if (to_integer(unsigned(slv)) <= T_STATUS'pos(T_STATUS'high)) then return T_STATUS'val(to_integer(unsigned(slv))); else return STATUS_ERROR; end if; end function; This could be shortened to this, if enum types support 'COUNT: function serializeStatus(value : T_STATUS) return STD_LOGIC_VECTOR is begin return std_logic_vector(to_unsigned(T_STATUS'pos(value), log2(T_STATUS'count))); end function; function deserializeStatus(slv : STD_LOGIC_VECTOR) return T_STATUS is begin if (to_integer(unsigned(slv)) < T_STATUS'count) then return T_STATUS'val(to_integer(unsigned(slv))); else return STATUS_ERROR; end if; end function; It’s also possible to use the serialization function to connect signals based on enumerated types to Integrated logic analyzers like ChipScope. signal Status : T_STATUS; signal Debugger_Data : STD_LOGIC_VECTOR(15 downto 0); Debugger_Data(1 downto 0) <= serializeStatus(Status) Example 2 - Exporting/writing enum values and member names into files for external tools Some simulation and synthesis tools support I/O functions to read and write files from the host's file system. While this feature is massively used in simulation environments it's rarely used in synthesis environments. Synthesis tools generate large reports, which include state encodings for enum based FSMs. But it's not common to report other encodings for e.g. enum based signals. These string representations can be read back by external tools like waveform viewers or debuggers to show captured signals with it's member name instead of it's binary representation. A simple export format could be: - one member per line - separated by semi-colons Example of a simple format: STATUS_IDLE;STATUS_TRANSMITTING;STATUS_COMPLETE;STATUS_ERROR; procedure str_append(StringBuffer : inout STRING; value : STRING) is constant BufferEnd : POSITIVE := str_len(StringBuffer); begin StringBuffer(BufferEnd + 1 to BufferEnd + str_len(value)) := value; end procedure; function encodeStatus return string is variable StringBuffer : STRING(1 to (64 * T_STATUS'count)) := (others => NUL); begin for member in T_STATUS loop str_append(StringBuffer, (T_STATUS'image(member) & ';'); end loop; return str_trim(StringBuffer); end function; A external script can transform this enum member list into other file formats like ChipScope's token files (*.tok) or GTKwaves data format filter files. It's even possible to export these file formats directly. An advantage is to generate up-to-date encoding files for external tools without complex synthesis report parsing. 3) I introduced two new attributes ‘SERIALIZE and ‘DESERIALZIE, which serialize enum values to a common binary representation and vice versa. This would reduce the amount of user written code, because the current approach needs one conversion function per type and direction. It should be possible to define such attributes and the underlying conversion function by the language itself like it’s done for operators or ‘IMAGE. These new attributes allow a much shorter usage like this: Debugger_Data(1 downto 0) <= T_STATUS'serialize(Status); Open questions: 4) What type should be used as a common binary representation? - BIT_VECTOR - STD_LOGIC_VECTOR - … 5) Which encoding should be used for the binary representation? - positive binary numbers - gray encoding - one-hot / one-cold encoding - … My current example uses to_unsigned as a encoding function to convert the enum member position into a binary representation. While this is a good choise in many use cases, it could be necessary to choose another encoding schema to reduce logic or increase timing. So should it be possible to pass an encoding parameter to ‘SERIALIZE? Example: type T_ENCODING is (BINCODE, GRAYCODE, ONEHOTCODE); Debugger_Data(3 downto 0) <= T_STATUS'serialize(Status, ONEHOTCODE); 6) Regarding some comments on stackoverflow, there are also interests for - type generics - record serialization / de-serialization 7) Please, feel free to correct the twiki page for any misspelling or other language fault J. Regards Patrick -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, and is believed to be clean. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Jim@SynthWorks.com VHDL Training Expert http://www.SynthWorks.com IEEE VHDL Working Group Chair OSVVM, Chief Architect and Cofounder 1-503-590-4787 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Jun 27 05:49:27 2015
This archive was generated by hypermail 2.1.8 : Sat Jun 27 2015 - 05:49:54 PDT