Josephblack wrote:
We should standardize how to write inputs/outputs that are active lows
in the library we have started.

I asked Timothy who wrote:
Apparently some do it with underscore prefix or suffix. In schematics,
people like to put a bar over the name of the signal, that's where
that is from. We should follow the convention used by FPGA and ASIC
vendors for their modules that have active-low I/Os.

I seem to remember VHDL doesnt like something with an underscore
prefix - but it has been a while - I will have to check.

What are your suggestions?


I think most of the code on OpenCores (both Verilog and VHDL from my recollection) uses a "_n" suffix (e.g., "rst_n").

The cores that come with Xilinx's EDK (VHDL) use the following:

-------------------------------------------------------------------------------
-- Naming Conventions:
--      active low signals:                     "*_n"
--      clock signals:                          "clk", "clk_div#", "clk_#x"
--      reset signals:                          "Rst", "rst_n"
--      generics:                               "C_*"
--      user defined types:                     "*_TYPE"
--      state machine next state:               "*_ns"
--      state machine current state:            "*_cs"
--      combinatorial signals:                  "*_com"
--      pipelined or register delay signals:    "*_d#"
--      counter signals:                        "*cnt*"
--      clock enable signals:                   "*_ce"
--      internal version of output port         "*_i"
--      device pins:                            "*_pin"
--      ports:                                  - Names begin with Uppercase
--      processes:                              "*_PROCESS"
--      component instantiations:               "<ENTITY_>I_<#|FUNC>
-------------------------------------------------------------------------------
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to