---------------------------------------------------------------------- -- -- -- -- Replace this sentence with a description of the entity. -- -- Replace all occurrences -- of the string... with... -- ----------------------- ---------------------------------------- -- -- name of design -- -- name of arch, e.g., "behavioral" -- or "structural" are common -- -- name of process. Each process must have -- different name, if they have a name at all. -- -- $Log$ -- ---------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; -- -- I believe this is how Synopsys intends the packages -- IEEE.std_logic_unsigned, IEEE.std_logic_signed, and -- IEEE.std_logic_arith to be used. Please let me know if you find -- out otherwise. -- -- If you'd like to be able to treat std_logic_vector quantities as -- unsigned binary integer values with the standard unsigned -- representation, and you have no use for representing signed -- quantities, then you should be able to use the package -- IEEE.std_logic_unsigned. This will define addition, subtraction, -- and comparison operators for std_logic_vector's that treat their -- contents as unsigned values. -- -- Conversely, if you want to treat std_logic_vector quantities as -- signed integer values represented using 2's complement encoding, -- and you have no use for representing unsigned quantities, then you -- can use the package IEEE.std_logic_signed. -- -- Note: The hardware to add/subtract two N-bit unsigned numbers each -- is *exactly the same* as the hardware to add/subtract two N-bit -- signed numbers represented in 2's complement. This is a nifty -- property of the 2's complement representation. However, -- less/greater than comparison logic is different. -- -- Finally, if you want to use both unsigned and 2's complement signed -- values in the same design, the easiest way appears to be to use the -- package IEEE.std_logic_arith, and then declare signed quantities as -- the type 'signed', and unsigned quantities as the type 'unsigned'. -- It is easy to convert signed and unsigned values to each other, or -- to and from std_logic_vector, but it is not automatically done for -- you. -- -- I haven't checked into this thoroughly, but I believe that using -- more than one of the packages below is problematic for the Synopsys -- VHDL Compiler. If it isn't problematic for the tool, it might be -- problematic for the person writing or maintaining the code. -- -- use ieee.std_logic_unsigned.all; -- use ieee.std_logic_signed.all; -- use ieee.std_logic_arith.all; entity is port ( -- Some example port definitions. Delete any you don't need, -- or copy, paste, and modify them to your heart's content. clk : in std_ulogic; reset_l : in std_ulogic; cell_clk : in std_ulogic; vector_in : in std_ulogic_vector (15 downto 0); vector_out : buffer std_ulogic_vector (15 downto 0); -- Remember that there should be semicolons between port -- definitions above, but the last one should _not_ have a -- semicolon. Silly, but a fact of VHDL syntax. ); end ; architecture of is signal mysig : std_ulogic; signal myvec : std_ulogic_vector (15 downto 0); begin -- When doing component instantiations, I think it is -- best always to use named association of ports, rather than -- association by the order that the signals are listed. It's -- just less prone to mistakes. -- A process that infers rising edge triggered flip-flops. There -- might be combinational logic driving the D inputs of these -- flip-flops, depending on whether there are "if" or "case" -- statements in the body of the process. -- Note that everything should work as expected if the process -- sensitivity list is left empty. It should not harm anything to -- have a non-empty sensitivity list, but it won't help, either. --: process begin wait until (clk'event and clk = '1'); -- signal assignments, if-then-else statements, case statements, etc. end process; -- end process ; -- Another process that infers rising edge triggered flip-flops. -- Whether you want to use the process template above or below for -- inferring flip-flops is simply a matter of taste. I don't care -- which is used. -- Note that the process sensitivity list should contain the clock -- signal for Leapfrog VHDL simulation to work properly. Synopsys -- synthesis will work fine without it, but it will give a warning -- message about the clock signal being absent from the -- sensitivity list (if you get one of these, _please_ fix it, so -- the same code will simulate properly with Leapfrog). -- It should not harm anything to have more signals in the -- sensitivity list, but it won't help, either. --: process (clk) begin if (clk'event and clk = '1') then -- signal assignments, if-then-else statements, case -- statements, etc. end if; end process; -- end process ; -- This kind of process infers rising edge triggered flip-flop, -- with either an asynchronous set, reset, or both such inputs. -- An asynchronous reset is used if the value assigned to a signal -- during reset is 0, an asynchronous set is used if the value -- assigned is 1, and both are used if the value assigned is not a -- constant (e.g., a signal). -- Note that the condition (reset_l = '0') can be replaced with more -- complex conditions, if desired. If so, then this will create -- combinational logic attached to the asynchronous set/reset -- inputs of the inferred flip-flops. Also remember to add all -- such signals to the sensitivity list of the process, for -- Cadence Leapfrog's benefit. -- If a value assigned during reset is not a constant, then that -- value must be in the sensitivity list in order for -- Cadence Leapfrog VHDL to simulate correctly. You do _not_ need -- to add signals to the sensitivity list if they are only read in -- the clocked part of the process. It is sufficient that clk is -- in the sensitivity list for that part of the process. -- WARNING: If you assign a value to a signal on a rising edge of -- clock, but not when reset_l is asserted, see the warning at URL -- http://www.arl.wustl.edu/~jaf/hardware/synopsys-gotchas.html#unusual-process --: process (reset_l, clk) begin if (reset_l = '0') then -- signal assignments elsif (clk'event and clk = '1') then -- signal assignments, if-then-else statements, case -- statements, etc. end if; end process; -- end process ; -- "Continuous signal assignments" like those below can be used to -- infer combinational logic, or just to hook signals together, -- with no combinational logic. -- -- Equivalent processes that infer the same combinational logic -- are also shown, in case you prefer that style. I personally -- find it more readable to use a process when the conditions -- being checked get even a little bit complicated. -- -- Here are some things to be careful of when writing processes -- that are intended to infer combinational logic. -- -- Avoid using the 'event attribute of any signals, put all -- signals that are read in the sensitivity list, and make sure -- that every signal assigned a value is assigned a value in every -- possible case. That is, if a signal is assigned a value in the -- THEN part of an IF statement, it should also be assigned a -- value in the ELSE part of an if statement. If you forget to do -- this, the process will infer sequential logic, perhaps a level -- sensitive latch. -- -- Another way to make sure that a signal is assigned a value in -- every possible case is to assign it a "default" value at the -- beginning of the process. This default value can be -- overwritten with different values later in the process, but -- then at least you are certain that the process won't infer a -- latch. I also find that it can enhance the readability of the -- code if there is such a default value, because then it isn't -- necessary to assign a value to the signal in every branch of IF -- or CASE statements. It is only necessary to assign values in -- those branches where the desired value is different than the -- "default" value. This technique can be useful for processes -- inferring flip-flops, too. -- user_data_cell <= not PT_XMIT_local(2); --: process (PT_XMIT_local(2)) begin user_data_cell <= not PT_XMIT_local(2); end process; -- end process ; -- Continuous signal assignment for driving aal5_cell. aal5_cell <= '1' when ( (bdi /= "00000000") and (user_data_cell = '1') ) else '0'; -- An process statement that is equivalent to the assignemnt -- above. --: process (bdi, user_data_cell) begin if ((bdi /= "00000000") and (user_data_cell = '1')) then aal5_cell <= '1'; else aal5_cell <= '0'; end if; end process; -- end process ; -- Another process statement that is equivalent, but uses the -- "default" value style mentioned in the comments above. The -- benefits of this style are not demonstrated fully by this -- example. Imagine that there were four or five different -- signals being driven in a process containing a case statement -- with 10 cases, and the default values assigned at the top were -- correct for all but a few of the cases. --: process (bdi, user_data_cell) begin aal5_cell <= '0'; if ((bdi /= "00000000") and (user_data_cell = '1')) then aal5_cell <= '1'; end if; end process; -- end process ; end; -- architecture of