OpenCores
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;
 
 

Compare with Previous | Blame | View Log

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.