Re: I hate VHDL!!!

Discussion in 'VHDL' started by Just an Illusion, Jun 25, 2004.

  1. As Jim said,

    I haven't said that I am agree with you.

    I don't think that your proposal can help synthesizer.


    Weng Tianxiang wrote:

    >OK, at last Jim and JaI admit my equation is right.
    ><snip>
    >
    >>process (DIMMNumberClear, nC_BE_R0, n, bad_pci_type)
    >>begin
    >> if (DIMMNumberClear) then
    >> DIMMNumber(4 downto 0) <= (others=>'0');
    >> elsif (bad_pci_type = '0') then
    >> if (AD_R0(28+n*32) = '1') then
    >> DIMMNumber (4 downto 0) <= "10000";
    >> else
    >> DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
    >> endif;
    >> endif;
    >>end process;
    >>
    >>

    >
    >Above equations are wrong. n must be a constant to let compiler to
    >work. It is an compiler error. If n is a dynamic signal like in my
    >case, you must use n as in a condition for 'if' statement. If you
    >don't believe, try to compile it using any VHDL compiler.
    >
    >

    I have demand you if pci type (32-b and 64-b) can be dynamically change,
    you haven't answer.
    So I give you an example where n is constant.

    Reread my question.

    Don't keep only some out of context part.

    >Second segment of equations is right. Thank you, JaI!!! It clearly
    >demonstrates how hard from current VHDL structure to get both right
    >and efficient code.
    >

    Sorry I don't understand which second segment.

    >You must rewrite total code to get efficient
    >code!!!
    >

    If the coder have badly write his first code version, don't blam the
    language.
    You have the same problem with any programming language.

    Before write any vhdl code line, you *must* think before about what you
    want to do.
    Put some comment, and perhaps that can help you to find an other way to
    write the same equation.

    >It is a big problem when you have a big project. It is real,
    >not virtual. That is why 'I hate VHDL': it is like you bought a set of
    >sockets to start your business and found that 3/8" socket wasn't there
    >and the manufacturers say it is your problem, you can deal with it
    >using 1/2", why do we need to manufacture a 3/8" socket especially for
    >your purpose?!
    >

    Sorry, I don't understand your joke about socket.
    Propose to your manufacturer to multiply your buying price by ten, and
    see it's answer.

    >
    >That is why 'orif' is so useful in the situation: first you write
    >correct code, then change 'elsif' to 'orif', you get your most
    >efficient code without any other code and structure change.
    >
    >

    I am not convinced.
    Lot of exclusive section are implementation dependant; if you want
    design a reusable module, then you can do these types of assertions.
    Otherwise you have a _critical_ risk in your design.

    Logical equation optimizations are in synthesizer perimeter, not vhdl.
    If you write clear logic equation, you can help the synthesizer; but
    look the resulting netlist, the equations are not exactly the same that
    you have write.

    For you, what is the difference between both following notations ?

    c <=a and b;

    and
    InstAnd : And2 (A=>a, B=>b, Y=>c); -- where And2() is a
    component of which behavioral fucntion is the logical and.

    For behavioral functionality, or logic simulation (with zero delay),
    none. But after synthesis, you can have two different circuit.
    Why ? because with And2 case, you said to synthesizer that you want
    explicitely use the gate And2 model.

    Take following pseudo-examples:

    ExampleA:
    c <= a and b;

    d <= e and f;

    g <= c and d;


    and:

    ExampleB:
    InstAndC: And2(a,b,c);
    InstAndD: And2(e,f,d);
    InstAndG: And2(c,d,g);

    After synthesis, in case ExampleA you can use 1 and gate, with 4 inputs,
    to generate 'g' (and 1 and-gate delay); but for ExampleB you have 3 and
    gates, with 2 inputs, to generate the same 'g' (and 2 and-gate delay).
    You have the same functionnality, but not the same implementation.


    JaI
     
    Just an Illusion, Jun 25, 2004
    #1
    1. Advertising

  2. JaI,
    > Sorry but example of read vs. write is not a good example, remember case
    > of double access ram, where you can have a read and a write access
    > simultaneously.


    If you don't know something, it is better to keep quite and stand
    aside to learn.

    Tell me what kind of double access ram working in a way a read and a
    write access happen simultaneously.

    Weng
     
    Weng Tianxiang, Jul 6, 2004
    #2
    1. Advertising

  3. Hi Weng,

    Weng Tianxiang wrote:

    >JaI,
    >
    >
    >>Sorry but example of read vs. write is not a good example, remember case
    >>of double access ram, where you can have a read and a write access
    >>simultaneously.
    >>
    >>

    >
    >If you don't know something, it is better to keep quite and stand
    >aside to learn.
    >
    >

    You are not the only people which made design, so be quiet.

    >Tell me what kind of double access ram working in a way a read and a
    >write access happen simultaneously.
    >
    >

    Fifo between two different clock domains is the most classical case.
    Read and write are fully independant, and can be done simultaneously.

    It is not because you don't do it that nobody does.

    >Weng
    >
    >

    JaI
     
    Just an Illusion, Jul 7, 2004
    #3
  4. Jim,
    > For: exclusive (A1, A2);
    > The key to the issue is when does exclusive check
    > for mutual exclusion:
    > 1) On changes of A1 and A2
    > 2) When either A1 or A2 is read?
    > 3) At a specified condition


    My algorithm may not be the best, but it clears things up.
    1. Find where (A1, A2) signals appear on conditions of
    'if..elsif..end', record their lines like the following:
    (A1, A2): line 1001, 1330, ...
    2. At the last delta time, every signals are stable, test if A1, A2
    are both true, if so, output error information:
    (A1, A2): violates mutually exclusive conditions at line 1001, 1330,
    ....

    exclusive (A1, A2);
    1. exclusive name is seldom used;
    2. it has not effects on all old design done before 'exclusive' is
    introduced. It affects only later new design. New design cannot use
    'exclusive' as a signal name. It doesn't violate VHDL spirit.
    3. If you must include old part of design that contains 'exclusive'
    name, change it. Because old version has to be changed to include any
    new VHDL benefits.

    Weng
     
    Weng Tianxiang, Jul 7, 2004
    #4
  5. Just an Illusion

    Jim Lewis Guest

    Weng,
    How about an example of orif?

    I have already spoken my peace on exclusive.

    Regards,
    Jim

    > Jim,
    >
    >>For: exclusive (A1, A2);
    >>The key to the issue is when does exclusive check
    >>for mutual exclusion:
    >> 1) On changes of A1 and A2
    >> 2) When either A1 or A2 is read?
    >> 3) At a specified condition

    >
    >
    > My algorithm may not be the best, but it clears things up.
    > 1. Find where (A1, A2) signals appear on conditions of
    > 'if..elsif..end', record their lines like the following:
    > (A1, A2): line 1001, 1330, ...
    > 2. At the last delta time, every signals are stable, test if A1, A2
    > are both true, if so, output error information:
    > (A1, A2): violates mutually exclusive conditions at line 1001, 1330,
    > ...
    >
    > exclusive (A1, A2);
    > 1. exclusive name is seldom used;
    > 2. it has not effects on all old design done before 'exclusive' is
    > introduced. It affects only later new design. New design cannot use
    > 'exclusive' as a signal name. It doesn't violate VHDL spirit.
    > 3. If you must include old part of design that contains 'exclusive'
    > name, change it. Because old version has to be changed to include any
    > new VHDL benefits.
    >
    > Weng
     
    Jim Lewis, Jul 8, 2004
    #5
  6. Jim,
    Here you are. The longest 'if..elsif..end' statement.

    Following the process(), there are two versions of compilation
    information for Xilinx chip xc2v1000-4, 1 million gate chip: one for
    non-optimized version as follows, another for manually optimized
    version that I have been using. Other parts are entirely same.

    Their stark differences are:
    Minimum period: 14.904ns - 14.687ns = 0.217ns
    Number of occupied Slices: 3,432 - 3,369 = 63
    Total Number 4 input LUTs: 5,688 - 5,581 = 107

    From above observation, we conclude: 'if..elsif..end' is very code
    inefficient!!! This is only one counter. If more, you cannot expect to
    get what you want for a complex design.

    This is the basic reason I want to introduce new keyword 'orif'.

    Weng

    The process is a counter, it has 7 loading conditions which are
    mutually exclusive.

    RowChipPtrA : process(nRESETGlobal, CLK66M)
    begin
    if(nRESETGlobal = '0') then
    RowChipPtr <= (others=>'0');

    elsif(CLK66M'event and CLK66M = '1') then
    if(WriteFIFO_SDRAMPtr) then -- 1
    if(MEMORY_2G = '0') then
    RowChipPtr(14 downto 0) <= WriteFIFODataOut(29 downto 15);
    else
    RowChipPtr(14 downto 0) <= WriteFIFODataOut(30 downto 16);
    end if;

    elsif(AD_R0_SDRAMPtr) then -- 2
    if(MEMORY_2G = '0' and WINDOW_16M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 24) &
    AD_R0(23 downto 15);
    elsif(MEMORY_2G = '0' and WINDOW_256M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 28) &
    AD_R0(27 downto 15);
    elsif(MEMORY_2G = '1' and WINDOW_16M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 24) &
    AD_R0(23 downto 16);
    elsif(MEMORY_2G = '1' and WINDOW_256M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 28) &
    AD_R0(27 downto 16);
    elsif(MEMORY_2G = '1' and WINDOW_NO = '1') then
    RowChipPtr(14 downto 0) <= AD_R0(30 downto 16);
    elsif(MEMORY_1G = '1' and WINDOW_NO = '1') then
    RowChipPtr(14 downto 0) <= AD_R0(29 downto 15);
    elsif(MEMORY_512M = '1' and WINDOW_NO = '1') then
    RowChipPtr(14 downto 0) <= '0' & AD_R0(28 downto 15);
    else -- when MEMORY_256M = '1' and WINDOW_NO = '1'
    RowChipPtr(14 downto 0) <= "00" & AD_R0(27 downto 15);
    end if;

    elsif(AD_R1_SDRAMPtr) then -- 3
    if(MEMORY_2G = '0' and WINDOW_16M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 24) & AD_R1(23
    downto 15);
    elsif(MEMORY_2G = '0' and WINDOW_256M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(29 downto 28) & AD_R1(27
    downto 15);
    elsif(MEMORY_2G = '1' and WINDOW_16M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 24) & AD_R1(23
    downto 16);
    elsif(MEMORY_2G = '1' and WINDOW_256M = '1') then
    RowChipPtr(14 downto 0) <= TWindowAddress(30 downto 28) & AD_R1(27
    downto 16);
    elsif(MEMORY_2G = '1' and WINDOW_NO = '1') then
    RowChipPtr(14 downto 0) <= AD_R1(30 downto 16);
    elsif(MEMORY_1G = '1' and WINDOW_NO = '1') then
    RowChipPtr(14 downto 0) <= AD_R1(29 downto 15);
    elsif(MEMORY_512M = '1' and WINDOW_NO = '1') then
    RowChipPtr(14 downto 0) <= '0' & AD_R1(28 downto 15);
    else -- when MEMORY_256M = '1' and WINDOW_NO = '1'
    RowChipPtr(14 downto 0) <= "00" & AD_R1(27 downto 15);
    end if;

    elsif(ReadFIFOTailPtr_SDRAMPtr) then -- 4
    if(MEMORY_2G = '0') then
    RowChipPtr(14 downto 0) <= ReadFIFOTailPtr(29 downto 15);
    else
    RowChipPtr(14 downto 0) <= ReadFIFOTailPtr(30 downto 16);
    end if;

    elsif(MSDRAMPtr_SDRAMPtr) then -- 5
    if(MEMORY_2G = '0') then
    RowChipPtr(14 downto 0) <= MSDRAMPtr(29 downto 15);
    else
    RowChipPtr(14 downto 0) <= MSDRAMPtr(30 downto 16);
    end if;

    elsif(ModeValue_RowChipPtr) then -- 6
    if(MEMORY_256M = '1') then
    RowChipPtr(14 downto 0) <= "000" & X"027";
    elsif(MEMORY_512M = '1') then
    RowChipPtr(14 downto 0) <= "00" & X"027" & '0';
    else -- MEMORY_1G_2G
    RowChipPtr(14 downto 0) <= '0' & X"027" & "00";
    end if;

    elsif(RowChipPtrEnable) then -- 7
    RowChipPtr <= RowChipPtr + '1';
    end if;
    end if;
    end process;


    For version of 'if..elsif..end' statement
    Minimum period is 14.904ns.
    Design Summary:
    Number of errors: 0
    Number of warnings: 77
    Logic Utilization:
    Number of Slice Flip Flops: 2,424 out of 10,240 23%
    Number of 4 input LUTs: 5,346 out of 10,240 52%
    Logic Distribution:
    Number of occupied Slices: 3,432 out of 5,120 67%
    Number of Slices containing only related logic: 3,432 out of
    3,432 100%
    Number of Slices containing unrelated logic: 0 out of
    3,432 0%
    *See NOTES below for an explanation of the effects of
    unrelated logic
    Total Number 4 input LUTs: 5,688 out of 10,240 55%
    Number used as logic: 5,346
    Number used as a route-thru: 108
    Number used as 16x1 RAMs: 1
    Number used as Shift registers: 233

    Number of bonded IOBs: 272 out of 324 83%
    IOB Flip Flops: 286
    Number of Tbufs: 352 out of 2,560 13%
    Number of GCLKs: 3 out of 16 18%

    For manuaaly optimized version
    Minimum period is 14.687ns.
    Design Summary:
    Number of errors: 0
    Number of warnings: 77
    Logic Utilization:
    Number of Slice Flip Flops: 2,425 out of 10,240 23%
    Number of 4 input LUTs: 5,252 out of 10,240 51%
    Logic Distribution:
    Number of occupied Slices: 3,369 out of 5,120 65%
    Number of Slices containing only related logic: 3,369 out of
    3,369 100%
    Number of Slices containing unrelated logic: 0 out of
    3,369 0%
    *See NOTES below for an explanation of the effects of
    unrelated logic
    Total Number 4 input LUTs: 5,581 out of 10,240 54%
    Number used as logic: 5,252
    Number used as a route-thru: 95
    Number used as 16x1 RAMs: 1
    Number used as Shift registers: 233

    Number of bonded IOBs: 272 out of 324 83%
    IOB Flip Flops: 286
    Number of Tbufs: 352 out of 2,560 13%
    Number of GCLKs: 3 out of 16 18%
     
    Weng Tianxiang, Jul 10, 2004
    #6
  7. Jim,
    I have posed my long 'if..elsif..endif' statement on the google with
    clear compilation results to prove that 'if..elsif..endif' statement
    is not only code inefficient in theory, but also in practice.

    I haven't known what your positions are now.

    Are you still interested in assert() or turning to back my opinion
    about 'orif'?

    Another question is why VHDL committee is so adamant not to introduce
    conditional statements widely used in C, C++.

    Weng
     
    Weng Tianxiang, Jul 17, 2004
    #7
  8. Just an Illusion

    Jim Lewis Guest

    Weng,
    > I have posed my long 'if..elsif..endif' statement on the google with
    > clear compilation results to prove that 'if..elsif..endif' statement
    > is not only code inefficient in theory, but also in practice.
    >
    > I haven't known what your positions are now.
    >
    > Are you still interested in assert() or turning to back my opinion
    > about 'orif'?


    Full consideration of "orif" will need to wait for phase 2
    of the VHDL-200X effort. Currently the review of FT items
    (for which I am co-team leader) is taking much of my time.

    I guess the good news is that I did not dismiss it immediately.
    I will have to put some time thinking about your example.
    I will follow up with you later.

    > Another question is why VHDL committee is so adamant not to introduce
    > conditional statements widely used in C, C++.

    Perhaps we might need something more powerful.
    No time right now. I will follow up on this later.

    For now, why not use use CPP? Previously when I fixed
    your conditinal compilation statements they seemed
    to work fine with CPP. Did you persever and
    get it to work? I never posted my solution as
    you never appologized for the not so nice comments
    you made about the standards group.

    Regards,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis mailto:
    SynthWorks VHDL Training http://www.SynthWorks.com
    Director of Training

    Get hand-on VHDL experience with our FPGA based lab boards.
    See: http://www.synthworks.com/

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Jul 17, 2004
    #8
    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. Weng Tianxiang

    I hate VHDL!!!

    Weng Tianxiang, Jun 3, 2004, in forum: VHDL
    Replies:
    51
    Views:
    5,140
    roller
    Jun 19, 2004
  2. Jim Lewis

    Re: I hate VHDL!!!

    Jim Lewis, Jun 25, 2004, in forum: VHDL
    Replies:
    14
    Views:
    1,147
    Just an Illusion
    Jul 5, 2004
  3. Tom  Verbeure

    Re: I hate VHDL!!!

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

    Re: I hate VHDL!!!

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

Share This Page