I hate VHDL!!!

Discussion in 'VHDL' started by Weng Tianxiang, Jun 3, 2004.

  1. Hi,
    I hate VHDL!!!
    I one person had developed a large VHDL design. Now because PCB
    reasons, the project has to be divided into 2 subdesigns: 95% are the
    same with 30 pins different in interfaces.

    So I naturally hope to write the code like this:
    In entity part:
    if ChipA = true, do following
    signal ... : inout ...
    signal ... : inout ...
    ....
    else
    signal ... : inout ...
    signal ... : inout ...
    ....
    end if;

    In signal declaration part:
    if ChipA = true, do following
    signal ...
    signal ...
    ....
    else
    signal ...
    signal ...
    ....
    end if;

    In process part:
    if ChipA = true, do following
    process(...)(...)
    process(...)(...)
    ....
    else
    process(...)(...)
    process(...)(...)
    ....
    end if;

    But I cannot do that.

    If it were in C or C++, #define and #undefine conditional statements
    are so easy to use, we programmers can never imagine such beautiful
    things are never permitted in VHDL!!!

    Another problem of VHDL is the following:
    In my PCI/PCI-X development, when a transaction address appears on
    bus, I have to test 3 space addresses in a state machine to see what
    type of actions I should take:
    if(BusAddress = 32-bit-Address1) then
    NextState <= stateX1;
    elsif(BusAddress = 32-bit-Address2) then
    NextState <= stateX2;

    elsif(BusAddress = 32-bit-Address3) then
    NextState <= stateX3;
    end if;

    Did you notice that in goto stateX3 statement it contains two other
    unnecessary comparisons:
    BusAddress = 32-bit-Address1
    BusAddress = 32-bit-Address2

    It just wastes resources!!!

    Any comments are welcome.

    Weng
    Weng Tianxiang, Jun 3, 2004
    #1
    1. Advertising

  2. Weng Tianxiang

    Symon Guest

    Symon, Jun 3, 2004
    #2
    1. Advertising

  3. Weng Tianxiang

    paris Guest

    "Weng Tianxiang" <> escribió en el mensaje
    news:...

    <snip>

    > If it were in C or C++, #define and #undefine conditional statements
    > are so easy to use, we programmers can never imagine such beautiful
    > things are never permitted in VHDL!!!
    >


    indeed, C was meant for programmers: "soft"ware, and VHDL was meant for EE
    engineers: "hard"ware :)
    though i guess that if you put the entity and the architecture in different
    files, you could use different entities and use the generate keyword on the
    architecture, then a configuration file.
    I recall using different files for entities, architectures and then
    configurations when i first learnt VHDL, but i havent designed that way
    since then.

    > Another problem of VHDL is the following:
    > In my PCI/PCI-X development, when a transaction address appears on
    > bus, I have to test 3 space addresses in a state machine to see what
    > type of actions I should take:
    > if(BusAddress = 32-bit-Address1) then
    > NextState <= stateX1;
    > elsif(BusAddress = 32-bit-Address2) then
    > NextState <= stateX2;
    >
    > elsif(BusAddress = 32-bit-Address3) then
    > NextState <= stateX3;
    > end if;
    >
    > Did you notice that in goto stateX3 statement it contains two other
    > unnecessary comparisons:
    > BusAddress = 32-bit-Address1
    > BusAddress = 32-bit-Address2
    >


    isnt "goto" bad-practice? :)
    you want the comparisons to take place in parallel?

    > It just wastes resources!!!
    >
    > Any comments are welcome.
    >
    > Weng
    paris, Jun 4, 2004
    #3
  4. Weng Tianxiang a écrit:

    > if(BusAddress = 32-bit-Address1) then
    > NextState <= stateX1;
    > elsif(BusAddress = 32-bit-Address2) then
    > NextState <= stateX2;
    > elsif(BusAddress = 32-bit-Address3) then
    > NextState <= stateX3;
    > end if;
    >
    > Did you notice that in goto stateX3 statement it contains two other
    > unnecessary comparisons:
    > BusAddress = 32-bit-Address1
    > BusAddress = 32-bit-Address2
    >
    > It just wastes resources!!!


    Well known fact. This is not a language problem, only a hardware
    description problem. If you hated VHDL a bit less and decided to learn
    it a bit more you would discover the fantastic 'case' statement:

    case BusAddress is
    when Address1_32_bit => NextState <= stateX1;
    when Address2_32_bit => NextState <= stateX2;
    when Address3_32_bit => NextState <= stateX3;
    when others => null;
    end case;

    --
    ____ _ __ ___
    | _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
    | | | | | (_| |_| | Invalid return address: remove the -
    |_| |_|_|\__|\___/
    Nicolas Matringe, Jun 4, 2004
    #4
  5. Hi,
    You are not correct.

    Their address widths are not same:
    Give you an example: one is 2-bits, second 24-bits, third 12-bits in
    my case, and in the future, 4th 32-bits.

    Weng

    Nicolas Matringe <> wrote in message news:<>...
    > Weng Tianxiang a écrit:
    >
    > > if(BusAddress = 32-bit-Address1) then
    > > NextState <= stateX1;
    > > elsif(BusAddress = 32-bit-Address2) then
    > > NextState <= stateX2;
    > > elsif(BusAddress = 32-bit-Address3) then
    > > NextState <= stateX3;
    > > end if;
    > >
    > > Did you notice that in goto stateX3 statement it contains two other
    > > unnecessary comparisons:
    > > BusAddress = 32-bit-Address1
    > > BusAddress = 32-bit-Address2
    > >
    > > It just wastes resources!!!

    >
    > Well known fact. This is not a language problem, only a hardware
    > description problem. If you hated VHDL a bit less and decided to learn
    > it a bit more you would discover the fantastic 'case' statement:
    >
    > case BusAddress is
    > when Address1_32_bit => NextState <= stateX1;
    > when Address2_32_bit => NextState <= stateX2;
    > when Address3_32_bit => NextState <= stateX3;
    > when others => null;
    > end case;
    Weng Tianxiang, Jun 4, 2004
    #5
  6. Weng Tianxiang

    Tom Hawkins Guest

    (Weng Tianxiang) wrote in message news:<>...
    > Hi,
    > I hate VHDL!!!
    > I one person had developed a large VHDL design. Now because PCB
    > reasons, the project has to be divided into 2 subdesigns: 95% are the
    > same with 30 pins different in interfaces.


    Consider using GENERATE. Based on a generic, your entity could be
    configured for either design_A or design_B.

    Or better yet, look to Confluence, where every datatype is a
    configuration parameter. Think of it #defines on steriods. Off hand
    I can think of a slew of possibilities for abstracting out the
    commonality between your two parts.

    [snip]

    >
    > Another problem of VHDL is the following:
    > In my PCI/PCI-X development, when a transaction address appears on
    > bus, I have to test 3 space addresses in a state machine to see what
    > type of actions I should take:
    > if(BusAddress = 32-bit-Address1) then
    > NextState <= stateX1;
    > elsif(BusAddress = 32-bit-Address2) then
    > NextState <= stateX2;
    >
    > elsif(BusAddress = 32-bit-Address3) then
    > NextState <= stateX3;
    > end if;


    As another poster pointed out, there are cleaner ways to express this.
    Here's another option:

    NextState <= stateX1 when BusAddress = 32-bit-Address1 else
    stateX2 when BusAddress = 32-bit-Address2 else
    ...

    Whether you choose if, case, or when, the results are more or less the
    same.

    >
    > Did you notice that in goto stateX3 statement it contains two other
    > unnecessary comparisons:
    > BusAddress = 32-bit-Address1
    > BusAddress = 32-bit-Address2
    >
    > It just wastes resources!!!


    It may appear so, but put a little trust in the compiler. Conditional
    tree structures are extremely common. Synthesis optimizations will
    clean it right up.

    -Tom

    >
    > Any comments are welcome.
    >
    > Weng
    Tom Hawkins, Jun 4, 2004
    #6
  7. Thank you very much. What you described is what I really and
    desperately want.

    One question:
    Why cannot VHDL specs include the definition of #if, #ifdef... and let
    all users share the greatness, easiness and beautifulness of part of C
    grammar instead of letting me ask software engineers to manufacture a
    make file to call other applications (C preprocessor and make
    application) that doesn't belong to vhdl compiler? And I don't know
    why its committee spends a lot of time doing the most frivolous
    changes, but not investing time to do most important one: add
    definitions of #if, #ifdef... ?

    Weng

    "Symon" <> wrote in message news:<>...
    > Weng,
    > Do you know how to Google? I guess not or you would've found this:-
    > http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#cond_compile
    >
    > and this
    >
    > http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#case
    >
    > Could've saved yourself all thet typing. When someone hates with that much
    > energy, it's something inside they're hating.
    >
    > cheers, Syms.
    Weng Tianxiang, Jun 4, 2004
    #7
  8. Weng Tianxiang wrote:


    > Why cannot VHDL specs include the definition of #if, #ifdef...


    VHDL has a similar construct:

    gen1_name : if (... some_condition...) generate
    end generate;

    gen2_name: for N in 0 to 7 generate
    end generate;

    Note: "some_condition" has to be static.
    These constructs allow fine-grain configuration of the architectures.

    Example: Depending on a constant (provided as generic parameter or
    manually set) I want to switch between latch-based and flipflop-based
    registers:

    constant impl_ff : integer:=1;
    -- 1 for FFs, 0 for latches

    .....

    gen_reg_latch : if implf_ff=0 generate
    process(reset,enable,data_in)
    begin
    if (reset='1') then
    reg<='0';
    elsif (enable='1') then
    reg<=data_in;
    end if;
    end process;
    end generate;

    gen_reg_ff : if implf_ff=1 generate
    process(reset,enable,data_in)
    begin
    if (reset='1') then
    reg<='0';
    elsif rising_edge(enable) then
    reg<=data_in;
    end if;
    end process;
    end generate;


    Unfortunately there is no

    if (..condition...) generate
    ...
    else generate
    ...
    end generate


    and you cannot modify an entity, whitch is the biggest disadvantage. But
    in all other cases, generate statements are very useful and as you can
    see very similar to #ifdef ... .


    Ralf
    Ralf Hildebrandt, Jun 4, 2004
    #8
  9. Weng Tianxiang

    Jim Lewis Guest

    Weng,
    There is no reason you can't use CPP in your design flow.

    Cheers,
    Jim

    > Thank you very much. What you described is what I really and
    > desperately want.
    >
    > One question:
    > Why cannot VHDL specs include the definition of #if, #ifdef... and let
    > all users share the greatness, easiness and beautifulness of part of C
    > grammar instead of letting me ask software engineers to manufacture a
    > make file to call other applications (C preprocessor and make
    > application) that doesn't belong to vhdl compiler? And I don't know
    > why its committee spends a lot of time doing the most frivolous
    > changes, but not investing time to do most important one: add
    > definitions of #if, #ifdef... ?
    >
    > Weng
    >
    > "Symon" <> wrote in message news:<>...
    >
    >>Weng,
    >>Do you know how to Google? I guess not or you would've found this:-
    >>http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#cond_compile
    >>
    >>and this
    >>
    >>http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#case
    >>
    >>Could've saved yourself all thet typing. When someone hates with that much
    >>energy, it's something inside they're hating.
    >>
    >>cheers, Syms.



    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Jun 4, 2004
    #9
  10. Weng Tianxiang

    Jim Lewis Guest

    Weng,
    > And I don't know why its committee spends a
    > lot of time doing the most frivolous changes,


    This type of remark will not make you many friends.

    I take this a little personally. For the past two
    years, I have been working on VHDL-200X to make
    sure the next VHDL several revisions deliver
    high value. Perhaps you should review the
    current proposals before you make such a statement.
    See:

    http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/proposals.html


    Regards,
    Jim Lewis
    P.S.
    You might remember my name. I was the one who reviewed
    and helped you revise your DVCon paper a couple of years
    ago.
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    > Thank you very much. What you described is what I really and
    > desperately want.
    >
    > One question:
    > Why cannot VHDL specs include the definition of #if, #ifdef... and let
    > all users share the greatness, easiness and beautifulness of part of C
    > grammar instead of letting me ask software engineers to manufacture a
    > make file to call other applications (C preprocessor and make
    > application) that doesn't belong to vhdl compiler? And I don't know
    > why its committee spends a lot of time doing the most frivolous
    > changes, but not investing time to do most important one: add
    > definitions of #if, #ifdef... ?
    >
    > Weng
    >
    > "Symon" <> wrote in message news:<>...
    >
    >>Weng,
    >>Do you know how to Google? I guess not or you would've found this:-
    >>http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#cond_compile
    >>
    >>and this
    >>
    >>http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#case
    >>
    >>Could've saved yourself all thet typing. When someone hates with that much
    >>energy, it's something inside they're hating.
    >>
    >>cheers, Syms.
    Jim Lewis, Jun 4, 2004
    #10
  11. The website statements are exciting:
    "In order to achieve the same functionality as the "#if" and "#ifdef"
    constructs of C/C++, the macro processor of an ordinary C compiler may
    be used. Usually, C compiler have a special command line switch to
    stop compilation after the preprocessing stage (e.g., "-E" for the GNU
    C/C++ compiler). Hence, VHDL source code can be augmented with C
    macros or "#ifdef...#endif" statements and then preprocessed with a C
    compiler before it is compiled with a VHDL compiler. A "make" tool may
    help to automate this two-stage approach."

    But results are bad:
    One of our company software engineers met a lot of errors using
    suggested method due to inconsistent vhdl/C grammars and abandoned the
    method and suggested to write a C program to handle the situations,
    but I have to wait until the end of the month!

    I will write the software & provide source code here when I finish and
    test it to benefit all vhdl programmers.

    You can use the program to filter vhdl file by adding #define, #undef,
    #endif, #ifdef and add those statements anywhere in a vhdl file where
    you want and the output file will contain correct output file name to
    reflect what variables are used to avoid any inconsistency.

    The following is the file specification:

    Specification of C program VhdlFilter

    It is used to get input vhdl file and output vhdl file, filtering all
    unnecessary statements.

    C statement key words used for VhdlFilter:
    #define
    #endif
    #ifdef
    #ifndef

    1. All key words above use C definitions and practice.
    2. '#' of all C key words above is only located at 1st character
    position in a line to facilitate handling;
    3. #ifdef, #ifndef and #endif can be nested.

    Specifications for vhdl VhdlFilter:
    1. Input command format: VhdlFilter inputname.vhd
    2. Output file: inputname-X-Y.vhd in the same directory as input file
    with same file extension;
    3. X is the last character of variable defined in first #define
    statement if the variable ends with "-X";
    or its full name of the variable if there is no '-' in it.
    4. Y is the last character of variable defined in first #define
    statement if the variable ends with "-y";
    or its full name of the variable if there is no '-' in it.

    Example:
    Input file name: 7460-X.vhd
    Variable name defined in first #define statement: Chip-A
    Variable name defined in 2nd #define statement: debug

    Then the output file name would be: 7460-X-A-debug.vhd
    If no second #define statement
    Then the output file name would be: 7460-X-A.vhd
    if first variable is defined as debug without imbedded '-', then the
    output file name would be 7460-X-debug.vhd

    The following is my vhdl file entity and you may see how it is easy to
    use.
    I want to generate 4 versions:
    Chip-A-debug.vhd
    Chip-A.vhd
    Chip-B-debug.vhd
    Chip-B.vhd

    Now what I have to do is to change #define statements in the first
    part of design. That's it.

    By the way, my design is 15,000 line long. So one person team can be
    capable of coding and simulations.

    -------------------------------------------------------------------

    #define Chip-A;
    --#define Chip-B;
    --#define debug;

    -------------------------------------------------------------------
    entity PCI_CORE is
    port(
    CLK66M : in std_logic;
    nRESET : in std_logic;
    M66EN : in std_logic;
    AD : inout std_logic_vector(63 downto 0);
    nC_BE : inout std_logic_vector(7 downto 0);
    PAR : inout std_logic;
    PAR64 : inout std_logic;
    nFRAME : inout std_logic;
    nIRDY : inout std_logic;
    nTRDY : inout std_logic;
    nSTOP : inout std_logic;
    nDEVSEL : inout std_logic;
    IDSEL : in std_logic;
    nREQ : out std_logic;
    nGNT : in std_logic;
    nREQ64 : inout std_logic;
    nACK64 : inout std_logic;
    nPERR : inout std_logic;
    nSERR : out std_logic;
    nCS : out std_logic_vector(31 downto 0);
    DQM : out std_logic_vector(15 downto 0);
    CKE : inout std_logic_vector(15 downto 0);
    A0 : out std_logic_vector(12 downto 0);
    A1 : out std_logic_vector(12 downto 0);
    A2 : out std_logic_vector(12 downto 0);
    A3 : out std_logic_vector(12 downto 0);
    BA0 : out std_logic_vector(1 downto 0);
    BA1 : out std_logic_vector(1 downto 0);
    BA2 : out std_logic_vector(1 downto 0);
    BA3 : out std_logic_vector(1 downto 0);
    nRAS : out std_logic_vector(3 downto 0);
    nCAS : out std_logic_vector(3 downto 0);
    nWE : out std_logic_vector(3 downto 0);
    nData74Read : out std_logic_vector(3 downto 0);
    DQ : inout std_logic_vector(71 downto 0);
    SCL : out std_logic_vector(1 downto 0);
    SDA : inout std_logic_vector(1 downto 0);
    nFail5V : in std_logic;
    nFail3V : in std_logic;
    nPowerReady : in std_logic;

    #ifdef Chip-A
    nINTA : out std_logic;
    RTC_SCL : out std_logic;
    RTC_SDA : inout std_logic;
    RTC_Square : in std_logic;
    ROM_WriteProtect : out std_logic;
    PowerState : out std_logic;
    MicroCtrl : out std_logic;
    PowerDownMode : out std_logic;
    PowerLED : out std_logic;
    InitializeTo74 : out std_logic_vector(1 downto 0);
    InitializeFrom74 : in std_logic_vector(1 downto 0);
    LEDClock : out std_logic;
    BatteryClock : in std_logic;
    BatteryAD : in std_logic;
    BatteryData : in std_logic
    #ifdef debug
    ; -- not the last statements in entity
    #endif; -- debug
    #endif; -- Chip-A

    #ifdef Chip-B
    nPCIBUS31_IntA : in std_logic;
    nPCIBUS31_IntB : in std_logic;
    nPCIBUS31_IntC : in std_logic;
    nPCIBUS31_IntD : in std_logic;
    nPCIBUS32_IntA : in std_logic;
    nPCIBUS32_IntB : in std_logic;
    nPCIBUS32_IntC : in std_logic;
    nPCIBUS32_IntD : in std_logic;
    nPCIBUS1_Bridge1_Int : in std_logic;
    nPCIBUS2_Bridge1_Int : in std_logic;
    nPCIBUS2_Bridge2_Int : in std_logic;
    nPCIBUS31_Bridge2_Int : in std_logic;
    nPCIBUS2_Bridge3_Int : in std_logic;
    nPCIBUS32_Bridge3_Int : in std_logic;
    nPCIBUS1_Processor_Int : in std_logic;
    nPCIBUS1_Gigabit_Int : in std_logic;
    nPCIBUS1_SATA_Int : in std_logic;
    nPCIBUS1_PMC_Int : in std_logic;
    nPROC_IRQ_0 : out std_logic;
    nPROC_IRQ_1 : out std_logic;
    nPROC_IRQ_2 : out std_logic;
    nPROC_IRQ_3 : out std_logic;
    nPROC_IRQ_4 : out std_logic;
    nPROC_NMI : out std_logic;
    DONE : in std_logic;
    RTC_RSTn : in std_logic;
    PROC_SA11 : in std_logic;
    LINK_1000n : in std_logic;
    LINK_100n : in std_logic;
    LINKn : in std_logic;
    SDMA12_RESET : in std_logic;
    SDMA13 : in std_logic;
    SDMA14_CHKSTOP_INn : in std_logic;
    PROC_FLASH_PE : in std_logic;
    RCS0n : inout std_logic;
    RCS1n : in std_logic;
    RCS2n : in std_logic;
    RCS3n : in std_logic;
    JTAG_TRSTn : in std_logic;
    JTAG_HRESETn : in std_logic;
    PCIBUS1_RSTn : out std_logic;
    PROC_SA0 : out std_logic;
    PROC_SA1 : out std_logic;
    PROC_DQ32 : out std_logic;
    ROM_CEn : out std_logic;
    ROM_FOEn : out std_logic;
    LINK_10n : out std_logic;
    ROM_A21 : out std_logic;
    ROM_A22 : out std_logic;
    ROM_A23 : out std_logic;
    ROM_A24 : out std_logic;
    PCIBUS1_REQ64n : out std_logic;
    PCIBUS2_REQ64n : out std_logic;
    PCIBUS31_REQ64n : out std_logic;
    PCIBUS32_REQ64n : out std_logic;
    CPU_RSTn : out std_logic;
    TRSTn : out std_logic
    #ifdef debug
    ; -- not the last statements in entity
    #endif; -- debug
    #endif; -- Chip-B

    #ifdef debug
    FeedDataToDQ : out std_logic;
    SDRAMIsReady : out std_logic;
    DMASDRAMWait : out std_logic;
    DMASemaphoreWait : out std_logic;
    DMADescriptorWait : out std_logic;
    ClockSerialA : in std_logic;
    SDRAMPtrLoad_O : out std_logic;
    SDRAMPtr35_3_O : out std_logic_vector(34 downto 3);
    RTC_SDA_In_Enable : out boolean;
    RTC_SDA_Latch_Enable : out boolean;
    SDA_In_Enable : out boolean;
    SDA_Latch_Enable : out boolean
    #endif; -- debug
    );
    end PCI_CORE;

    Any comments are welcome.

    Weng

    "Symon" <> wrote in message news:<>...
    > Weng,
    > Do you know how to Google? I guess not or you would've found this:-
    > http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#cond_compile
    >
    > and this
    >
    > http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#case
    >
    > Could've saved yourself all thet typing. When someone hates with that much
    > energy, it's something inside they're hating.
    >
    > cheers, Syms.
    Weng Tianxiang, Jun 5, 2004
    #11
  12. Weng Tianxiang

    Symon Guest

    Hi Weng,
    I don't want to upset you or your software guys and I know you want to
    "share the greatness, easiness and beautifulness of part of C grammar" but
    it strikes me that I could write a Perl script to do that in about a hour,
    certainly in less than a day.
    Oranges aren't the only fruit...
    cheers, Syms.
    Symon, Jun 5, 2004
    #12
  13. Weng Tianxiang

    Jim Lewis Guest

    Weng,
    I just tried the CPP version that comes with cygwin.
    You have some syntax problems with your cpp
    directives that you need to fix. Once I fixed them
    everything seems to work fine. Oh CPP had some annoying
    status output that starts with #, that you will need to
    deal with. Sum total about 10 minutes of time.

    BTW, CPP could care less about VHDL syntax. It is your
    directives that have the errors that you need to fix.

    Want the file? You need to learn to be less
    insulting when you have a problem. I work in that
    standards group that you took your frustration out on.
    Perhaps I would be a little nicer about sharing if
    you appologized. Otherwise, do your own debugging.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



    Weng Tianxiang wrote:
    > The website statements are exciting:
    > "In order to achieve the same functionality as the "#if" and "#ifdef"
    > constructs of C/C++, the macro processor of an ordinary C compiler may
    > be used. Usually, C compiler have a special command line switch to
    > stop compilation after the preprocessing stage (e.g., "-E" for the GNU
    > C/C++ compiler). Hence, VHDL source code can be augmented with C
    > macros or "#ifdef...#endif" statements and then preprocessed with a C
    > compiler before it is compiled with a VHDL compiler. A "make" tool may
    > help to automate this two-stage approach."
    >
    > But results are bad:
    > One of our company software engineers met a lot of errors using
    > suggested method due to inconsistent vhdl/C grammars and abandoned the
    > method and suggested to write a C program to handle the situations,
    > but I have to wait until the end of the month!
    >
    > I will write the software & provide source code here when I finish and
    > test it to benefit all vhdl programmers.
    >
    > You can use the program to filter vhdl file by adding #define, #undef,
    > #endif, #ifdef and add those statements anywhere in a vhdl file where
    > you want and the output file will contain correct output file name to
    > reflect what variables are used to avoid any inconsistency.
    >
    > The following is the file specification:
    >
    > Specification of C program VhdlFilter
    >
    > It is used to get input vhdl file and output vhdl file, filtering all
    > unnecessary statements.
    >
    > C statement key words used for VhdlFilter:
    > #define
    > #endif
    > #ifdef
    > #ifndef
    >
    > 1. All key words above use C definitions and practice.
    > 2. '#' of all C key words above is only located at 1st character
    > position in a line to facilitate handling;
    > 3. #ifdef, #ifndef and #endif can be nested.
    >
    > Specifications for vhdl VhdlFilter:
    > 1. Input command format: VhdlFilter inputname.vhd
    > 2. Output file: inputname-X-Y.vhd in the same directory as input file
    > with same file extension;
    > 3. X is the last character of variable defined in first #define
    > statement if the variable ends with "-X";
    > or its full name of the variable if there is no '-' in it.
    > 4. Y is the last character of variable defined in first #define
    > statement if the variable ends with "-y";
    > or its full name of the variable if there is no '-' in it.
    >
    > Example:
    > Input file name: 7460-X.vhd
    > Variable name defined in first #define statement: Chip-A
    > Variable name defined in 2nd #define statement: debug
    >
    > Then the output file name would be: 7460-X-A-debug.vhd
    > If no second #define statement
    > Then the output file name would be: 7460-X-A.vhd
    > if first variable is defined as debug without imbedded '-', then the
    > output file name would be 7460-X-debug.vhd
    >
    > The following is my vhdl file entity and you may see how it is easy to
    > use.
    > I want to generate 4 versions:
    > Chip-A-debug.vhd
    > Chip-A.vhd
    > Chip-B-debug.vhd
    > Chip-B.vhd
    >
    > Now what I have to do is to change #define statements in the first
    > part of design. That's it.
    >
    > By the way, my design is 15,000 line long. So one person team can be
    > capable of coding and simulations.
    >
    > -------------------------------------------------------------------
    >
    > #define Chip-A;
    > --#define Chip-B;
    > --#define debug;
    >
    > -------------------------------------------------------------------
    > entity PCI_CORE is
    > port(
    > CLK66M : in std_logic;
    > nRESET : in std_logic;
    > M66EN : in std_logic;
    > AD : inout std_logic_vector(63 downto 0);
    > nC_BE : inout std_logic_vector(7 downto 0);
    > PAR : inout std_logic;
    > PAR64 : inout std_logic;
    > nFRAME : inout std_logic;
    > nIRDY : inout std_logic;
    > nTRDY : inout std_logic;
    > nSTOP : inout std_logic;
    > nDEVSEL : inout std_logic;
    > IDSEL : in std_logic;
    > nREQ : out std_logic;
    > nGNT : in std_logic;
    > nREQ64 : inout std_logic;
    > nACK64 : inout std_logic;
    > nPERR : inout std_logic;
    > nSERR : out std_logic;
    > nCS : out std_logic_vector(31 downto 0);
    > DQM : out std_logic_vector(15 downto 0);
    > CKE : inout std_logic_vector(15 downto 0);
    > A0 : out std_logic_vector(12 downto 0);
    > A1 : out std_logic_vector(12 downto 0);
    > A2 : out std_logic_vector(12 downto 0);
    > A3 : out std_logic_vector(12 downto 0);
    > BA0 : out std_logic_vector(1 downto 0);
    > BA1 : out std_logic_vector(1 downto 0);
    > BA2 : out std_logic_vector(1 downto 0);
    > BA3 : out std_logic_vector(1 downto 0);
    > nRAS : out std_logic_vector(3 downto 0);
    > nCAS : out std_logic_vector(3 downto 0);
    > nWE : out std_logic_vector(3 downto 0);
    > nData74Read : out std_logic_vector(3 downto 0);
    > DQ : inout std_logic_vector(71 downto 0);
    > SCL : out std_logic_vector(1 downto 0);
    > SDA : inout std_logic_vector(1 downto 0);
    > nFail5V : in std_logic;
    > nFail3V : in std_logic;
    > nPowerReady : in std_logic;
    >
    > #ifdef Chip-A
    > nINTA : out std_logic;
    > RTC_SCL : out std_logic;
    > RTC_SDA : inout std_logic;
    > RTC_Square : in std_logic;
    > ROM_WriteProtect : out std_logic;
    > PowerState : out std_logic;
    > MicroCtrl : out std_logic;
    > PowerDownMode : out std_logic;
    > PowerLED : out std_logic;
    > InitializeTo74 : out std_logic_vector(1 downto 0);
    > InitializeFrom74 : in std_logic_vector(1 downto 0);
    > LEDClock : out std_logic;
    > BatteryClock : in std_logic;
    > BatteryAD : in std_logic;
    > BatteryData : in std_logic
    > #ifdef debug
    > ; -- not the last statements in entity
    > #endif; -- debug
    > #endif; -- Chip-A
    >
    > #ifdef Chip-B
    > nPCIBUS31_IntA : in std_logic;
    > nPCIBUS31_IntB : in std_logic;
    > nPCIBUS31_IntC : in std_logic;
    > nPCIBUS31_IntD : in std_logic;
    > nPCIBUS32_IntA : in std_logic;
    > nPCIBUS32_IntB : in std_logic;
    > nPCIBUS32_IntC : in std_logic;
    > nPCIBUS32_IntD : in std_logic;
    > nPCIBUS1_Bridge1_Int : in std_logic;
    > nPCIBUS2_Bridge1_Int : in std_logic;
    > nPCIBUS2_Bridge2_Int : in std_logic;
    > nPCIBUS31_Bridge2_Int : in std_logic;
    > nPCIBUS2_Bridge3_Int : in std_logic;
    > nPCIBUS32_Bridge3_Int : in std_logic;
    > nPCIBUS1_Processor_Int : in std_logic;
    > nPCIBUS1_Gigabit_Int : in std_logic;
    > nPCIBUS1_SATA_Int : in std_logic;
    > nPCIBUS1_PMC_Int : in std_logic;
    > nPROC_IRQ_0 : out std_logic;
    > nPROC_IRQ_1 : out std_logic;
    > nPROC_IRQ_2 : out std_logic;
    > nPROC_IRQ_3 : out std_logic;
    > nPROC_IRQ_4 : out std_logic;
    > nPROC_NMI : out std_logic;
    > DONE : in std_logic;
    > RTC_RSTn : in std_logic;
    > PROC_SA11 : in std_logic;
    > LINK_1000n : in std_logic;
    > LINK_100n : in std_logic;
    > LINKn : in std_logic;
    > SDMA12_RESET : in std_logic;
    > SDMA13 : in std_logic;
    > SDMA14_CHKSTOP_INn : in std_logic;
    > PROC_FLASH_PE : in std_logic;
    > RCS0n : inout std_logic;
    > RCS1n : in std_logic;
    > RCS2n : in std_logic;
    > RCS3n : in std_logic;
    > JTAG_TRSTn : in std_logic;
    > JTAG_HRESETn : in std_logic;
    > PCIBUS1_RSTn : out std_logic;
    > PROC_SA0 : out std_logic;
    > PROC_SA1 : out std_logic;
    > PROC_DQ32 : out std_logic;
    > ROM_CEn : out std_logic;
    > ROM_FOEn : out std_logic;
    > LINK_10n : out std_logic;
    > ROM_A21 : out std_logic;
    > ROM_A22 : out std_logic;
    > ROM_A23 : out std_logic;
    > ROM_A24 : out std_logic;
    > PCIBUS1_REQ64n : out std_logic;
    > PCIBUS2_REQ64n : out std_logic;
    > PCIBUS31_REQ64n : out std_logic;
    > PCIBUS32_REQ64n : out std_logic;
    > CPU_RSTn : out std_logic;
    > TRSTn : out std_logic
    > #ifdef debug
    > ; -- not the last statements in entity
    > #endif; -- debug
    > #endif; -- Chip-B
    >
    > #ifdef debug
    > FeedDataToDQ : out std_logic;
    > SDRAMIsReady : out std_logic;
    > DMASDRAMWait : out std_logic;
    > DMASemaphoreWait : out std_logic;
    > DMADescriptorWait : out std_logic;
    > ClockSerialA : in std_logic;
    > SDRAMPtrLoad_O : out std_logic;
    > SDRAMPtr35_3_O : out std_logic_vector(34 downto 3);
    > RTC_SDA_In_Enable : out boolean;
    > RTC_SDA_Latch_Enable : out boolean;
    > SDA_In_Enable : out boolean;
    > SDA_Latch_Enable : out boolean
    > #endif; -- debug
    > );
    > end PCI_CORE;
    >
    > Any comments are welcome.
    >
    > Weng
    >
    > "Symon" <> wrote in message news:<>...
    >
    >>Weng,
    >>Do you know how to Google? I guess not or you would've found this:-
    >>http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#cond_compile
    >>
    >>and this
    >>
    >>http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#case
    >>
    >>Could've saved yourself all thet typing. When someone hates with that much
    >>energy, it's something inside they're hating.
    >>
    >>cheers, Syms.
    Jim Lewis, Jun 5, 2004
    #13
  14. This seem definetely OT.

    should be posted in comp.lang.perl

    No need for obfuscated assembler here.

    ;-)

    bax

    "Weng Tianxiang" <> schrieb im Newsbeitrag
    news:...
    > The website statements are exciting:
    > "In order to achieve the same functionality as the "#if" and "#ifdef"
    > constructs of C/C++, the macro processor of an ordinary C compiler may
    > be used. Usually, C compiler have a special command line switch to
    > stop compilation after the preprocessing stage (e.g., "-E" for the GNU
    > C/C++ compiler). Hence, VHDL source code can be augmented with C
    > macros or "#ifdef...#endif" statements and then preprocessed with a C
    > compiler before it is compiled with a VHDL compiler. A "make" tool may
    > help to automate this two-stage approach."
    >
    > But results are bad:
    > One of our company software engineers met a lot of errors using
    > suggested method due to inconsistent vhdl/C grammars and abandoned the
    > method and suggested to write a C program to handle the situations,
    > but I have to wait until the end of the month!
    >
    > I will write the software & provide source code here when I finish and
    > test it to benefit all vhdl programmers.
    >
    > You can use the program to filter vhdl file by adding #define, #undef,
    > #endif, #ifdef and add those statements anywhere in a vhdl file where
    > you want and the output file will contain correct output file name to
    > reflect what variables are used to avoid any inconsistency.
    >
    > The following is the file specification:
    >
    > Specification of C program VhdlFilter
    >
    > It is used to get input vhdl file and output vhdl file, filtering all
    > unnecessary statements.
    >
    > C statement key words used for VhdlFilter:
    > #define
    > #endif
    > #ifdef
    > #ifndef
    >
    > 1. All key words above use C definitions and practice.
    > 2. '#' of all C key words above is only located at 1st character
    > position in a line to facilitate handling;
    > 3. #ifdef, #ifndef and #endif can be nested.
    >
    > Specifications for vhdl VhdlFilter:
    > 1. Input command format: VhdlFilter inputname.vhd
    > 2. Output file: inputname-X-Y.vhd in the same directory as input file
    > with same file extension;
    > 3. X is the last character of variable defined in first #define
    > statement if the variable ends with "-X";
    > or its full name of the variable if there is no '-' in it.
    > 4. Y is the last character of variable defined in first #define
    > statement if the variable ends with "-y";
    > or its full name of the variable if there is no '-' in it.
    >
    > Example:
    > Input file name: 7460-X.vhd
    > Variable name defined in first #define statement: Chip-A
    > Variable name defined in 2nd #define statement: debug
    >
    > Then the output file name would be: 7460-X-A-debug.vhd
    > If no second #define statement
    > Then the output file name would be: 7460-X-A.vhd
    > if first variable is defined as debug without imbedded '-', then the
    > output file name would be 7460-X-debug.vhd
    >
    > The following is my vhdl file entity and you may see how it is easy to
    > use.
    > I want to generate 4 versions:
    > Chip-A-debug.vhd
    > Chip-A.vhd
    > Chip-B-debug.vhd
    > Chip-B.vhd
    >
    > Now what I have to do is to change #define statements in the first
    > part of design. That's it.
    >
    > By the way, my design is 15,000 line long. So one person team can be
    > capable of coding and simulations.
    >
    > -------------------------------------------------------------------
    >
    > #define Chip-A;
    > --#define Chip-B;
    > --#define debug;
    >
    > -------------------------------------------------------------------
    > entity PCI_CORE is
    > port(
    > CLK66M : in std_logic;
    > nRESET : in std_logic;
    > M66EN : in std_logic;
    > AD : inout std_logic_vector(63 downto 0);
    > nC_BE : inout std_logic_vector(7 downto 0);
    > PAR : inout std_logic;
    > PAR64 : inout std_logic;
    > nFRAME : inout std_logic;
    > nIRDY : inout std_logic;
    > nTRDY : inout std_logic;
    > nSTOP : inout std_logic;
    > nDEVSEL : inout std_logic;
    > IDSEL : in std_logic;
    > nREQ : out std_logic;
    > nGNT : in std_logic;
    > nREQ64 : inout std_logic;
    > nACK64 : inout std_logic;
    > nPERR : inout std_logic;
    > nSERR : out std_logic;
    > nCS : out std_logic_vector(31 downto 0);
    > DQM : out std_logic_vector(15 downto 0);
    > CKE : inout std_logic_vector(15 downto 0);
    > A0 : out std_logic_vector(12 downto 0);
    > A1 : out std_logic_vector(12 downto 0);
    > A2 : out std_logic_vector(12 downto 0);
    > A3 : out std_logic_vector(12 downto 0);
    > BA0 : out std_logic_vector(1 downto 0);
    > BA1 : out std_logic_vector(1 downto 0);
    > BA2 : out std_logic_vector(1 downto 0);
    > BA3 : out std_logic_vector(1 downto 0);
    > nRAS : out std_logic_vector(3 downto 0);
    > nCAS : out std_logic_vector(3 downto 0);
    > nWE : out std_logic_vector(3 downto 0);
    > nData74Read : out std_logic_vector(3 downto 0);
    > DQ : inout std_logic_vector(71 downto 0);
    > SCL : out std_logic_vector(1 downto 0);
    > SDA : inout std_logic_vector(1 downto 0);
    > nFail5V : in std_logic;
    > nFail3V : in std_logic;
    > nPowerReady : in std_logic;
    >
    > #ifdef Chip-A
    > nINTA : out std_logic;
    > RTC_SCL : out std_logic;
    > RTC_SDA : inout std_logic;
    > RTC_Square : in std_logic;
    > ROM_WriteProtect : out std_logic;
    > PowerState : out std_logic;
    > MicroCtrl : out std_logic;
    > PowerDownMode : out std_logic;
    > PowerLED : out std_logic;
    > InitializeTo74 : out std_logic_vector(1 downto 0);
    > InitializeFrom74 : in std_logic_vector(1 downto 0);
    > LEDClock : out std_logic;
    > BatteryClock : in std_logic;
    > BatteryAD : in std_logic;
    > BatteryData : in std_logic
    > #ifdef debug
    > ; -- not the last statements in entity
    > #endif; -- debug
    > #endif; -- Chip-A
    >
    > #ifdef Chip-B
    > nPCIBUS31_IntA : in std_logic;
    > nPCIBUS31_IntB : in std_logic;
    > nPCIBUS31_IntC : in std_logic;
    > nPCIBUS31_IntD : in std_logic;
    > nPCIBUS32_IntA : in std_logic;
    > nPCIBUS32_IntB : in std_logic;
    > nPCIBUS32_IntC : in std_logic;
    > nPCIBUS32_IntD : in std_logic;
    > nPCIBUS1_Bridge1_Int : in std_logic;
    > nPCIBUS2_Bridge1_Int : in std_logic;
    > nPCIBUS2_Bridge2_Int : in std_logic;
    > nPCIBUS31_Bridge2_Int : in std_logic;
    > nPCIBUS2_Bridge3_Int : in std_logic;
    > nPCIBUS32_Bridge3_Int : in std_logic;
    > nPCIBUS1_Processor_Int : in std_logic;
    > nPCIBUS1_Gigabit_Int : in std_logic;
    > nPCIBUS1_SATA_Int : in std_logic;
    > nPCIBUS1_PMC_Int : in std_logic;
    > nPROC_IRQ_0 : out std_logic;
    > nPROC_IRQ_1 : out std_logic;
    > nPROC_IRQ_2 : out std_logic;
    > nPROC_IRQ_3 : out std_logic;
    > nPROC_IRQ_4 : out std_logic;
    > nPROC_NMI : out std_logic;
    > DONE : in std_logic;
    > RTC_RSTn : in std_logic;
    > PROC_SA11 : in std_logic;
    > LINK_1000n : in std_logic;
    > LINK_100n : in std_logic;
    > LINKn : in std_logic;
    > SDMA12_RESET : in std_logic;
    > SDMA13 : in std_logic;
    > SDMA14_CHKSTOP_INn : in std_logic;
    > PROC_FLASH_PE : in std_logic;
    > RCS0n : inout std_logic;
    > RCS1n : in std_logic;
    > RCS2n : in std_logic;
    > RCS3n : in std_logic;
    > JTAG_TRSTn : in std_logic;
    > JTAG_HRESETn : in std_logic;
    > PCIBUS1_RSTn : out std_logic;
    > PROC_SA0 : out std_logic;
    > PROC_SA1 : out std_logic;
    > PROC_DQ32 : out std_logic;
    > ROM_CEn : out std_logic;
    > ROM_FOEn : out std_logic;
    > LINK_10n : out std_logic;
    > ROM_A21 : out std_logic;
    > ROM_A22 : out std_logic;
    > ROM_A23 : out std_logic;
    > ROM_A24 : out std_logic;
    > PCIBUS1_REQ64n : out std_logic;
    > PCIBUS2_REQ64n : out std_logic;
    > PCIBUS31_REQ64n : out std_logic;
    > PCIBUS32_REQ64n : out std_logic;
    > CPU_RSTn : out std_logic;
    > TRSTn : out std_logic
    > #ifdef debug
    > ; -- not the last statements in entity
    > #endif; -- debug
    > #endif; -- Chip-B
    >
    > #ifdef debug
    > FeedDataToDQ : out std_logic;
    > SDRAMIsReady : out std_logic;
    > DMASDRAMWait : out std_logic;
    > DMASemaphoreWait : out std_logic;
    > DMADescriptorWait : out std_logic;
    > ClockSerialA : in std_logic;
    > SDRAMPtrLoad_O : out std_logic;
    > SDRAMPtr35_3_O : out std_logic_vector(34 downto 3);
    > RTC_SDA_In_Enable : out boolean;
    > RTC_SDA_Latch_Enable : out boolean;
    > SDA_In_Enable : out boolean;
    > SDA_Latch_Enable : out boolean
    > #endif; -- debug
    > );
    > end PCI_CORE;
    >
    > Any comments are welcome.
    >
    > Weng
    >
    > "Symon" <> wrote in message

    news:<>...
    > > Weng,
    > > Do you know how to Google? I guess not or you would've found this:-
    > > http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#cond_compile
    > >
    > > and this
    > >
    > > http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#case
    > >
    > > Could've saved yourself all thet typing. When someone hates with that

    much
    > > energy, it's something inside they're hating.
    > >
    > > cheers, Syms.
    Holger Baxmann, Jun 5, 2004
    #14
  15. > Hi,
    > You are not correct.


    Yes I am


    > Their address widths are not same:


    How should I know?


    > Give you an example: one is 2-bits, second 24-bits, third 12-bits in
    > my case, and in the future, 4th 32-bits.


    You still compare a signal called BusAddress am I right? So its length
    is 32 bits. Whatever you do, the comparisons will be on 32 bits vectors.
    If you want a variable width comparison, you'll have to mask some bits
    (and I'm not talking VHDL here but language-independent hardware).
    Anyway, the 'case' statement is what you need.

    If what you want is something like
    if BusAddress1 = 2-bits-constant-address1 then
    ....
    elsif BusAddress2 = 12-bits-constant-address2 then
    ....
    elsif BusAddress3 = 32-bits-constant-address3 then
    ....
    end if;
    you should have said.
    I'm no wizard (seems I already wrote this not so long ago), I can't
    understand what you *think* you wrote.

    > Weng
    >
    > Nicolas Matringe <> wrote in message news:<>...
    >
    >>Weng Tianxiang a écrit:
    >>
    >>
    >>>if(BusAddress = 32-bit-Address1) then
    >>> NextState <= stateX1;
    >>>elsif(BusAddress = 32-bit-Address2) then
    >>> NextState <= stateX2;
    >>>elsif(BusAddress = 32-bit-Address3) then
    >>> NextState <= stateX3;
    >>>end if;
    >>>
    >>>Did you notice that in goto stateX3 statement it contains two other
    >>>unnecessary comparisons:
    >>>BusAddress = 32-bit-Address1
    >>>BusAddress = 32-bit-Address2
    >>>
    >>>It just wastes resources!!!

    >>
    >>Well known fact. This is not a language problem, only a hardware
    >>description problem. If you hated VHDL a bit less and decided to learn
    >>it a bit more you would discover the fantastic 'case' statement:
    >>
    >>case BusAddress is
    >> when Address1_32_bit => NextState <= stateX1;
    >> when Address2_32_bit => NextState <= stateX2;
    >> when Address3_32_bit => NextState <= stateX3;
    >> when others => null;
    >>end case;

    >




    --
    ____ _ __ ___
    | _ \_)/ _|/ _ \ I didn't even have a real coffee this morning.
    | | | | | (_| |_| | Didn't I say I shouldn't read this newsgroup
    |_| |_|_|\__|\___/ before having my 2nd mug of coffee?
    Nicolas Matringe, Jun 7, 2004
    #15
  16. On 4 Jun 2004 08:52:09 -0700, (Weng Tianxiang) wrote:

    >Thank you very much. What you described is what I really and
    >desperately want.
    >
    >One question:
    >Why cannot VHDL specs include the definition of #if, #ifdef... and let
    >all users share the greatness, easiness and beautifulness of part of C


    Oh, please.

    Yes, there are some things that are more intuitive when done
    with a preprocessor. But preprocessor options are global,
    and take effect at compile time. The VHDL alternative,
    which IMHO is much, much prettier, is to use "generate";
    this can be controlled PER-INSTANCE, a concept that seems
    to have escaped the C preprocessor enthusiasts. Oh, I
    suppose that's because VHDL has the concept of "elaboration",
    yet another concept that's foreign to C.

    If you want VHDL to be C, then kindly use C instead,
    and go ahead and write your own stuff to do all the things
    that VHDL does with silky smoothness - sensitivity of
    processes to events, unconstrained arrays, named association
    lists... SystemC has solved these problems:

    www.systemc.org

    but only by appealing to the considerable power of C++.
    System-level design and verification problems are simply
    too hard to be solved comfortably with the C compiler
    and preprocessor that you seem to favour.
    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

    Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
    Tel: +44 (0)1425 471223 mail:
    Fax: +44 (0)1425 471573 Web: http://www.doulos.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
    Jonathan Bromley, Jun 7, 2004
    #16
  17. This is a Achilles heel for VHDL or Verilog.

    You don't have any feasible means to avoid the situations I mentioned
    in any state machine unless you waste resources as you wrote.

    NextState <= stateX1 when BusAddress = 32-bit-Address1 else
    stateX2 when BusAddress = 32-bit-Address2 else
    ...

    NextState will involve all first comparisons made for the last
    statements, but actually they are mutually exclusive.

    The best way to do it is:
    if(BusAddress = 32-bit-Address1) then
    NextState <= stateX1;
    orif(BusAddress = 32-bit-Address2) then <-- a new suggested keyword
    "orif"
    NextState <= stateX2;
    orif(BusAddress = 32-bit-Address3) then
    NextState <= stateX3;

    NextState <= stateX1 when BusAddress = 32-bit-Address1 elsor <-- a new
    suggested keyword "elsor"
    stateX2 when BusAddress = 32-bit-Address2 elsor
    ...
    It means if one of comparison is true, jump to the state without
    referring to others. Because they are mutually exclusive.

    Otherwise, if you are performance sensitive, you must put least width
    comparison equations at the first places to minimize any unnecessary
    penalty due to many mutually exclusive choices that you, programmers,
    know well, but compiler doesn't know due to lack of expression means.

    > "Synthesis optimizations will clean it right up."


    No ways! Compiler doesn't know they are mutually exclusive unless VHDL
    or Verilog provides a mean programmer can use.

    If you like to know more, send me an email and I had a paper dealing
    with the situations.

    Weng

    > As another poster pointed out, there are cleaner ways to express this.
    > Here's another option:
    >
    > NextState <= stateX1 when BusAddress = 32-bit-Address1 else
    > stateX2 when BusAddress = 32-bit-Address2 else
    > ...
    >
    > Whether you choose if, case, or when, the results are more or less the
    > same.
    >
    > It may appear so, but put a little trust in the compiler. Conditional
    > tree structures are extremely common. Synthesis optimizations will
    > clean it right up.
    >
    > -Tom
    Weng Tianxiang, Jun 7, 2004
    #17
  18. Nicolas,
    Sorry for not clearly describing the situations.

    I am a PCI/PCI-X core designer. While partial or a full 32-bit address
    are used to select one of target space, additional signal IDSEL is
    used to determine the choice. But the address comparisons are still
    mutually exclusive. It means in any cases, only one choice will be
    selected. So any means in VHDL or Verilog fail to write a mutually
    exclusive statements in a state machine.

    Weng

    Nicolas Matringe <> wrote in message news:<>...
    > > Hi,
    > > You are not correct.

    >
    > Yes I am
    >
    >
    > > Their address widths are not same:

    >
    > How should I know?
    >
    Weng Tianxiang, Jun 7, 2004
    #18
  19. Weng Tianxiang a écrit:
    > Nicolas,
    > Sorry for not clearly describing the situations.
    >
    > I am a PCI/PCI-X core designer. While partial or a full 32-bit address
    > are used to select one of target space, additional signal IDSEL is
    > used to determine the choice. But the address comparisons are still
    > mutually exclusive. It means in any cases, only one choice will be
    > selected. So any means in VHDL or Verilog fail to write a mutually
    > exclusive statements in a state machine.


    The real question behind is "How would you do it in hardware?". Then
    describe the hardware the way you like.
    You still need one comparator per address to be decoded. Then their
    outputs are used to determine the next state. This piece of logic
    behaves in a certain way when two (or more) of its inputs are true, even
    if this should not happen.
    What I would do is separate the comparisons and the next state
    determination.

    Anyway, the subject is wrong, this is not a VHDL-only problem ;o)


    --
    ____ _ __ ___
    | _ \_)/ _|/ _ \
    | | | | | (_| |_| |
    |_| |_|_|\__|\___/
    Nicolas Matringe, Jun 8, 2004
    #19
  20. Hi Weng,

    Weng Tianxiang wrote:

    >This is a Achilles heel for VHDL or Verilog.
    >
    >You don't have any feasible means to avoid the situations I mentioned
    >in any state machine unless you waste resources as you wrote.
    >
    >NextState <= stateX1 when BusAddress = 32-bit-Address1 else
    > stateX2 when BusAddress = 32-bit-Address2 else
    > ...
    >
    >NextState will involve all first comparisons made for the last
    >statements, but actually they are mutually exclusive.
    >
    >The best way to do it is:
    > if(BusAddress = 32-bit-Address1) then
    > NextState <= stateX1;
    > orif(BusAddress = 32-bit-Address2) then <-- a new suggested keyword
    >"orif"
    > NextState <= stateX2;
    > orif(BusAddress = 32-bit-Address3) then
    > NextState <= stateX3;
    >
    >NextState <= stateX1 when BusAddress = 32-bit-Address1 elsor <-- a new
    >suggested keyword "elsor"
    > stateX2 when BusAddress = 32-bit-Address2 elsor
    > ...
    >It means if one of comparison is true, jump to the state without
    >referring to others. Because they are mutually exclusive.
    >

    A stupid question: do you have read the VHDL LRM ? or do you base your
    conclusion with your knowledge of C programming, and interpretation ?
    Because the case structure implicate "mutually" exclusive conditions. In
    case of "if..then..else", you have a priority structure.

    Don't confuse HDL (VHDL/Verilog) interpretation, with C code
    interpretation. It seems equivalent on paper, but not in fact.

    Remember that VHDL target some physical implementation as transistors.
    The hw can be generate at run time (no one has seen spontaneous
    transistor generation ;-)). You must decide before which ressources do
    you need.

    Perhaps do you need try to imagine how hw "physically" handle your
    address analyze. In that case, you can see that your remarks have none sens.


    >
    >Otherwise, if you are performance sensitive, you must put least width
    >comparison equations at the first places to minimize any unnecessary
    >penalty due to many mutually exclusive choices that you, programmers,
    >know well, but compiler doesn't know due to lack of expression means.
    >

    That is a tool's implementation issue, not a VHDL problem.

    >
    >
    >
    >>"Synthesis optimizations will clean it right up."
    >>
    >>

    >
    >No ways! Compiler doesn't know they are mutually exclusive unless VHDL
    >or Verilog provides a mean programmer can use.
    >

    In VHDL, the compilation is not enough. To make simulation or synthesis,
    you need instantiate your design, and during this phase you made cleaning.

    That not exactly the same, but to give you an idea. Compare the
    Synthesis with a sw executable generation.
    In both case you have a compilation, but that give you only a data
    structure in memory. To be able to do something with it, you must
    instantiate/synthesize (for hw), or link (for sw).
    This is the resulting code that you truly use.

    Rgrds,
    JaI
    Just an Illusion, Jun 8, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Lewis

    Re: I hate VHDL!!!

    Jim Lewis, Jun 25, 2004, in forum: VHDL
    Replies:
    14
    Views:
    1,127
    Just an Illusion
    Jul 5, 2004
  2. Just an Illusion

    Re: I hate VHDL!!!

    Just an Illusion, Jun 25, 2004, in forum: VHDL
    Replies:
    7
    Views:
    693
    Jim Lewis
    Jul 17, 2004
  3. Tom  Verbeure

    Re: I hate VHDL!!!

    Tom Verbeure, Jul 19, 2004, in forum: VHDL
    Replies:
    11
    Views:
    1,052
    Jim Lewis
    Jul 31, 2004
  4. Tom  Verbeure

    Re: I hate VHDL!!!

    Tom Verbeure, Jul 28, 2004, in forum: VHDL
    Replies:
    3
    Views:
    551
    Wallclimber
    Jul 29, 2004
  5. afd
    Replies:
    1
    Views:
    8,319
    Colin Paul Gloster
    Mar 23, 2007
Loading...

Share This Page