URL
https://opencores.org/ocsvn/p9813_rgb_led_string_driver/p9813_rgb_led_string_driver/trunk
Subversion Repositories p9813_rgb_led_string_driver
[/] [p9813_rgb_led_string_driver/] [trunk/] [rtl/] [VHDL/] [ascii_pack.vhd] - Rev 2
Compare with Previous | Blame | View Log
-------------------------------------------------------------------------- -- Package -- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; use IEEE.MATH_REAL.ALL; package ascii_pack is -- Component declarations not provided any more. -- With VHDL '93 and newer, component declarations are allowed, -- but not required. -- -- Please to try direct instantiation instead, for example: -- -- instance_name : entity work.entity_name(beh) -- end ascii_pack; ------------------------------------------------------------------------------- -- Parallel ASCII CRLF resolver ------------------------------------------------------------------------------- -- -- Author: John Clayton -- Date : Feb. 12, 2014 Conceived of this module, and began coding it. -- Wrote description. -- Feb. 13, 2014 Added synchronous reset input. -- -- -- Description ------------------------------------------------------------------------------- -- This module addresses the question of which character is to be expected at -- the end of an ascii character command line. Is it to be '\n' or '\r'? -- Perhaps both? A quick survey will reveal that the answer varies depending -- on the details and importunate vagaries of the situation, including the -- operating system at hand, program used &c. For instance, telnet uses -- '\n' only by default, while a terminal emulator may use '\r'. In fact, -- these programs can probably be configured to send both ('\r\n', or is it -- '\n\r'?) So, when hardware is processing a stream of characters which -- originate from a command line, it is unclear which character or set of -- characters to expect at the end of the line. Moreover, sending both -- characters is not a "clean" solution either, since the occurrence of the -- second character can cause difficulties as, for example, the second -- character may needlessly request access to a bus through a bus arbiter, -- while the command is being executed due to the arrival of the first -- character. It's just not "atomic," you understand? -- -- So, in summary, it would be most agreeable if one could know for certain -- which character to expect to use for initiating execution of an ASCII -- command line, and also to know for certain that the expected character -- will not be followed by any other "dangling" command line termination type -- characters. -- -- This module was conceived in order to address these challenges. But how, -- you may ask? Gentle friend, read on, I pray, as an attempt will be made -- at providing the answer to just such a question! -- -- Quite simply, the module does a "consumptive substition with -- acknowledgement." -- -- In other words, it looks for any of the characters in the following -- "substitution list": -- -- <CR> (Carriage Return, which is 0x0D, sometimes written '\r') -- <LF> (Line Feed, which is 0x0A, sometimes written '\n') -- SUB_CHAR (generic, e.g. Null, which is 0x00, sometimes written '\0') -- -- The generic setting "SUB_CRLF" controls whether or not <CR> and <LF> -- are included in the substitution list. -- -- When it finds one of these characters, it substitutes the chosen EMIT_CHAR -- at char_o, in place of the one given at char_i, and then it enters its -- "consumptive mode," wherein any and all immediately subsequent characters -- which are also in the substitution list are "eaten up" without being -- passed on. Consumptive mode is exited whenever a character is presented -- for writing that is not in the substitution list. -- -- The user is thus permitted to choose which character to expect at the end -- of a command line, simply by setting EMIT_CHAR according to his (or her) -- whims. Isn't that marvelous?! -- -- Hopefully this descriptive explication makes sense. I've used what I at -- the time considered to be fairly clear English, and my apologies are given -- for those for whom this arrangement is in some way inconvenient or -- incomprehensible. -- -- The sys_rst_n input is an asynchronous reset. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; use IEEE.MATH_REAL.ALL; entity parallel_ascii_crlf_resolver is generic( SUB_CRLF : integer := 1; -- Set nonzero to substitute for CR and LF. SUB_CHAR : unsigned(7 downto 0) := "00000000"; -- character to be substituted EMIT_CHAR : unsigned(7 downto 0) := "00001101" -- character which is emitted ); port ( -- System Clock and Clock Enable sys_rst_n : in std_logic; sys_clk : in std_logic; sys_clk_en : in std_logic; -- Synchronous reset clear_i : in std_logic; -- Input Port char_i : in unsigned(7 downto 0); we_i : in std_logic; ack_o : out std_logic; -- Output Port char_o : out unsigned(7 downto 0); we_o : out std_logic; ack_i : in std_logic ); end parallel_ascii_crlf_resolver; architecture beh of parallel_ascii_crlf_resolver is -- Constants constant VAL_CR : integer := 13; -- 0x0D constant VAL_LF : integer := 10; -- 0x0A -- Functions & associated types -- Signal Declarations signal hit_list : std_logic; signal consumptive_mode : std_logic; begin hit_list <= '1' when (char_i=SUB_CHAR or (char_i=VAL_CR and SUB_CRLF/=0) or (char_i=VAL_LF and SUB_CRLF/=0)) else '0'; process (sys_clk, sys_clk_en, sys_rst_n) begin if (sys_rst_n='0') then consumptive_mode <= '0'; elsif (sys_clk'event and sys_clk='1') then if (sys_clk_en='1') then -- Handle entering consumptive mode if (consumptive_mode='0' and hit_list='1' and we_i='1' and ack_i='1') then consumptive_mode <= '1'; end if; -- Handle exiting consumptive mode if (consumptive_mode='1' and hit_list='0' and we_i='1') or clear_i='1' then consumptive_mode <= '0'; end if; end if; -- sys_clk_en end if; -- sys_clk end process; -- Reflect acknowledge at the input port. ack_o <= ack_i when consumptive_mode='0' and hit_list='1' and we_i='1' else -- First character is emitted. ack_i when consumptive_mode='1' and hit_list='0' and we_i='1' else we_i when consumptive_mode='1' else ack_i; -- Provide output char_o <= EMIT_CHAR when (hit_list='1' and we_i='1') else char_i; we_o <= we_i when consumptive_mode='0' and hit_list='1' and we_i='1' else -- First character is emitted. we_i when consumptive_mode='1' and hit_list='0' and we_i='1' else '0' when consumptive_mode='1' else we_i; end beh;