Coding style

Discussion in 'VHDL' started by Guest, Jan 3, 2006.

  1. Guest

    Guest Guest

    Hi,

    Does anyone happen to know what will the following (software) code will look
    like after going through a synthesis tool? I was told, back in the school,
    that never use *HDL as a software language and should have a block diagram or
    data path before coding. But it seams that more and more people trust the
    synthesis tool rather.

    // Verilog version
    reg [5:0] offset; // input
    reg [15:0] we; // input
    reg [15:0] data_in[127:0]; // input

    reg [7:0] data_out [63:0]; // output

    wire [5:0] offset0; // internal logic
    wire [5:0] offset1; // internal logic
    ....
    wire [5:0] offset15; // internal logic

    assign offset0 = offset;
    assign offset1 = offset + 1;
    ....
    assign offset15 = offset + 15;

    always @ (posedge clk) begin
    if (reset) begin
    // initial code here
    ...
    end begin
    if (we[0]) data[offset0] <= data_in[7:0];
    if (we[1]) data[offset1] <= data_in[15:8];
    ...
    if (we[15]) data[offset15] <= data_in[127:120];
    end
    end

    -- VHDL version
    type data_type is array (63 downto 0) of std_logic_vector(7 downto 0);

    signal offset : std_logic_vector(5 downto 0); -- input
    signal we : std_logic_vector (15 downto 0); -- input
    signal data_in : std_logic_vector (127 downto 0); -- input

    signal data_out : data_type; -- output

    signal offset0 : std_logic_vector(5 downto 0); -- internal logic
    signal offset1 : std_logic_vector(5 downto 0); -- internal logic
    ....
    signal offset15 : std_logic_vector(5 downto 0); -- internal logic

    offset0 <= offset;
    offset1 <= offset + 1;
    ....
    offset15 <= offset + 15;

    process (clk, reset)
    if rising_edge(clk) then
    if (reset = '1') then
    -- initial code here
    ...
    else
    if (we(0)='1') then data(offset0) <= data_in(7 downto 0); end if;
    if (we(1)='1') then data(offset0) <= data_in(15 downto 8); end if;
    ...
    if (we(15)='1') then data(offset0) <= data_in(127 downto 120); end if;
    end if;
    end if;
    end process;

    If I was to implement the above circuit, I will not write the above codes. I
    will first draw a data path diagram which show me that I can have have a
    barrel shifter to map the 16-bit 'we' to 64-bit 'data_we' based on the
    'offset' input. Than I will use another shifter to "expand" the data and
    assign each of the 64 slots based on the 'data_we'. I may even write a simple
    Perl script to generate this 64 statement.

    Does anyone know any better implementation scheme or any synthesis tools that
    will generate a better result base on the above code? I tried Xilinx XST and
    the above code failed (out of memory ?!) I know some other synthesis tool can
    generated a valid circuit with terrible performance.

    The most important question is, "Should I worry about this?" Someone told me
    that the code failed to compile just because XST is not good enough. But I
    wonder. My teammates and me have a different point of view in CAD tools. They
    believe the logic optimization (e.g. from behavioral description to netlist)
    and don't trust the physical optimization (e.g. they do hand placement and
    timing on every net). I believe the opposite.

    There are too many *information* available when running the placement and
    routing process which is NOT suitable for a human brain. But the tools can
    handle this well. There some *knowledge* in the design which is hard to be
    captured in the tools. And we engineerings are trained to use this knowledge
    to optimize our design. So I believe that we should code more careful rather
    than pumping constraints to the tools.

    But the current trend is (at least observed by myself), to encourages users
    code more like in a software environment. Is this the design flow for tomorrow
    or I misunderstand something?

    --
    Regards,
    Tsoi Kuen Hung (Brittle)
    CSE CUHK
     
    Guest, Jan 3, 2006
    #1
    1. Advertising

  2. wrote:

    > Does anyone happen to know what will the following (software) code will look
    > like after going through a synthesis tool?


    Unless you have run a simulation testbench,
    the output will likely be a syntax or logical error.
    If the code doesn't sim like you expect,
    why would you care what the synthesis output looks like?

    > I was told, back in the school,
    > that never use *HDL as a software language and should have a block diagram or
    > data path before coding.


    If you don't mind variables and large processes,
    algorithmic logic descriptions are possible.
    If you prefer netlists use a process per block.

    > But it seams that more and more people trust the
    > synthesis tool rather.


    Trust but verify.
    View the rtl schematic output from synthesis.
    Develop your own design rules.

    > The most important question is, "Should I worry about this?" Someone told me
    > that the code failed to compile just because XST is not good enough.


    I expect that it failed for lack
    of simulation and debug.

    > But the current trend is (at least observed by myself), to encourages users
    > code more like in a software environment. Is this the design flow for tomorrow
    > or I misunderstand something?


    That is up to you.
    Here are some single process examples to consider:
    http://home.comcast.net/~mike_treseler/
    Try it and see.


    -- Mike Treseler
     
    Mike Treseler, Jan 3, 2006
    #2
    1. Advertising

  3. Guest

    Andy Guest

    In your vhdl code, I assume you meant not to always store the data at
    offset0.

    Also, data is an array, and must be indexed by integers, not slv. That
    is a certain error in synthesis or simulation.

    Try:

    for i in we'range loop
    if we(i) = '1' then
    data(i+offset) <= data_in(i*8+7 downto i*8);
    end if;
    end loop;

    If we is mutually exclusive, then a good synthesis tool will infer ram
    for data if you code it as such (priority encode, or better, pick up
    the address before you decode the write strobes if possible, since the
    binary address is ME by definition)

    Assuming we is ME, you could add an exit statement after the assignment
    inside the loop to speed up sim and not change the behavior.

    Hope this helps,

    Andy


    wrote:
    > Hi,
    >
    > Does anyone happen to know what will the following (software) code will look
    > like after going through a synthesis tool? I was told, back in the school,
    > that never use *HDL as a software language and should have a block diagram or
    > data path before coding. But it seams that more and more people trust the
    > synthesis tool rather.
    >
    > // Verilog version
    > reg [5:0] offset; // input
    > reg [15:0] we; // input
    > reg [15:0] data_in[127:0]; // input
    >
    > reg [7:0] data_out [63:0]; // output
    >
    > wire [5:0] offset0; // internal logic
    > wire [5:0] offset1; // internal logic
    > ...
    > wire [5:0] offset15; // internal logic
    >
    > assign offset0 = offset;
    > assign offset1 = offset + 1;
    > ...
    > assign offset15 = offset + 15;
    >
    > always @ (posedge clk) begin
    > if (reset) begin
    > // initial code here
    > ...
    > end begin
    > if (we[0]) data[offset0] <= data_in[7:0];
    > if (we[1]) data[offset1] <= data_in[15:8];
    > ...
    > if (we[15]) data[offset15] <= data_in[127:120];
    > end
    > end
    >
    > -- VHDL version
    > type data_type is array (63 downto 0) of std_logic_vector(7 downto 0);
    >
    > signal offset : std_logic_vector(5 downto 0); -- input
    > signal we : std_logic_vector (15 downto 0); -- input
    > signal data_in : std_logic_vector (127 downto 0); -- input
    >
    > signal data_out : data_type; -- output
    >
    > signal offset0 : std_logic_vector(5 downto 0); -- internal logic
    > signal offset1 : std_logic_vector(5 downto 0); -- internal logic
    > ...
    > signal offset15 : std_logic_vector(5 downto 0); -- internal logic
    >
    > offset0 <= offset;
    > offset1 <= offset + 1;
    > ...
    > offset15 <= offset + 15;
    >
    > process (clk, reset)
    > if rising_edge(clk) then
    > if (reset = '1') then
    > -- initial code here
    > ...
    > else
    > if (we(0)='1') then data(offset0) <= data_in(7 downto 0); end if;
    > if (we(1)='1') then data(offset0) <= data_in(15 downto 8); end if;
    > ...
    > if (we(15)='1') then data(offset0) <= data_in(127 downto 120); end if;
    > end if;
    > end if;
    > end process;
    >
    > If I was to implement the above circuit, I will not write the above codes. I
    > will first draw a data path diagram which show me that I can have have a
    > barrel shifter to map the 16-bit 'we' to 64-bit 'data_we' based on the
    > 'offset' input. Than I will use another shifter to "expand" the data and
    > assign each of the 64 slots based on the 'data_we'. I may even write a simple
    > Perl script to generate this 64 statement.
    >
    > Does anyone know any better implementation scheme or any synthesis tools that
    > will generate a better result base on the above code? I tried Xilinx XST and
    > the above code failed (out of memory ?!) I know some other synthesis tool can
    > generated a valid circuit with terrible performance.
    >
    > The most important question is, "Should I worry about this?" Someone told me
    > that the code failed to compile just because XST is not good enough. But I
    > wonder. My teammates and me have a different point of view in CAD tools. They
    > believe the logic optimization (e.g. from behavioral description to netlist)
    > and don't trust the physical optimization (e.g. they do hand placement and
    > timing on every net). I believe the opposite.
    >
    > There are too many *information* available when running the placement and
    > routing process which is NOT suitable for a human brain. But the tools can
    > handle this well. There some *knowledge* in the design which is hard to be
    > captured in the tools. And we engineerings are trained to use this knowledge
    > to optimize our design. So I believe that we should code more careful rather
    > than pumping constraints to the tools.
    >
    > But the current trend is (at least observed by myself), to encourages users
    > code more like in a software environment. Is this the design flow for tomorrow
    > or I misunderstand something?
    >
    > --
    > Regards,
    > Tsoi Kuen Hung (Brittle)
    > CSE CUHK
     
    Andy, Jan 3, 2006
    #3
  4. Guest

    Guest Guest

    Hi - Thanks for the info. There are many typo in the my post since the
    original Verilog code is not allowed to be published. So I must hand
    type a different code in the post. This lead to the logical error you
    refered to. The original code can be simulate and is functional correct.
    It can even be synthesized using tools rather than XST. My main point is
    the coding style. Thanks anyway.

    Mike Treseler <> wrote:
    > wrote:
    >
    >> Does anyone happen to know what will the following (software) code will look
    >> like after going through a synthesis tool?

    >
    > Unless you have run a simulation testbench,
    > the output will likely be a syntax or logical error.
    > If the code doesn't sim like you expect,
    > why would you care what the synthesis output looks like?
    >
    >> I was told, back in the school,
    >> that never use *HDL as a software language and should have a block diagram or
    >> data path before coding.

    >
    > If you don't mind variables and large processes,
    > algorithmic logic descriptions are possible.
    > If you prefer netlists use a process per block.
    >
    >> But it seams that more and more people trust the
    >> synthesis tool rather.

    >
    > Trust but verify.
    > View the rtl schematic output from synthesis.
    > Develop your own design rules.
    >
    >> The most important question is, "Should I worry about this?" Someone told me
    >> that the code failed to compile just because XST is not good enough.

    >
    > I expect that it failed for lack
    > of simulation and debug.
    >
    >> But the current trend is (at least observed by myself), to encourages users
    >> code more like in a software environment. Is this the design flow for tomorrow
    >> or I misunderstand something?

    >
    > That is up to you.
    > Here are some single process examples to consider:
    > http://home.comcast.net/~mike_treseler/
    > Try it and see.
    >
    >
    > -- Mike Treseler


    --
    Regards,
    Tsoi Kuen Hung (Brittle)
    CSE CUHK
     
    Guest, Jan 4, 2006
    #4
  5. Guest

    Guest Guest

    Andy <> wrote:
    > In your vhdl code, I assume you meant not to always store the data at
    > offset0.

    yes, that's a typo
    >
    > Also, data is an array, and must be indexed by integers, not slv. That
    > is a certain error in synthesis or simulation.
    >
    > Try:
    >
    > for i in we'range loop
    > if we(i) = '1' then
    > data(i+offset) <= data_in(i*8+7 downto i*8);
    > end if;
    > end loop;

    Thanks. I just learnt how to do this in Verilog using a "+:" operator. I
    did not try the VHDL code yet.
    >
    > If we is mutually exclusive, then a good synthesis tool will infer ram
    > for data if you code it as such (priority encode, or better, pick up
    > the address before you decode the write strobes if possible, since the
    > binary address is ME by definition)
    >
    > Assuming we is ME, you could add an exit statement after the assignment
    > inside the loop to speed up sim and not change the behavior.

    not, 'we' can be any value
    >
    > Hope this helps,
    >
    > Andy
    >
    >
    > wrote:
    >> Hi,
    >>
    >> Does anyone happen to know what will the following (software) code will look
    >> like after going through a synthesis tool? I was told, back in the school,
    >> that never use *HDL as a software language and should have a block diagram or
    >> data path before coding. But it seams that more and more people trust the
    >> synthesis tool rather.
    >>
    >> // Verilog version
    >> reg [5:0] offset; // input
    >> reg [15:0] we; // input
    >> reg [15:0] data_in[127:0]; // input
    >>
    >> reg [7:0] data_out [63:0]; // output
    >>
    >> wire [5:0] offset0; // internal logic
    >> wire [5:0] offset1; // internal logic
    >> ...
    >> wire [5:0] offset15; // internal logic
    >>
    >> assign offset0 = offset;
    >> assign offset1 = offset + 1;
    >> ...
    >> assign offset15 = offset + 15;
    >>
    >> always @ (posedge clk) begin
    >> if (reset) begin
    >> // initial code here
    >> ...
    >> end begin
    >> if (we[0]) data[offset0] <= data_in[7:0];
    >> if (we[1]) data[offset1] <= data_in[15:8];
    >> ...
    >> if (we[15]) data[offset15] <= data_in[127:120];
    >> end
    >> end
    >>
    >> -- VHDL version
    >> type data_type is array (63 downto 0) of std_logic_vector(7 downto 0);
    >>
    >> signal offset : std_logic_vector(5 downto 0); -- input
    >> signal we : std_logic_vector (15 downto 0); -- input
    >> signal data_in : std_logic_vector (127 downto 0); -- input
    >>
    >> signal data_out : data_type; -- output
    >>
    >> signal offset0 : std_logic_vector(5 downto 0); -- internal logic
    >> signal offset1 : std_logic_vector(5 downto 0); -- internal logic
    >> ...
    >> signal offset15 : std_logic_vector(5 downto 0); -- internal logic
    >>
    >> offset0 <= offset;
    >> offset1 <= offset + 1;
    >> ...
    >> offset15 <= offset + 15;
    >>
    >> process (clk, reset)
    >> if rising_edge(clk) then
    >> if (reset = '1') then
    >> -- initial code here
    >> ...
    >> else
    >> if (we(0)='1') then data(offset0) <= data_in(7 downto 0); end if;
    >> if (we(1)='1') then data(offset0) <= data_in(15 downto 8); end if;
    >> ...
    >> if (we(15)='1') then data(offset0) <= data_in(127 downto 120); end if;
    >> end if;
    >> end if;
    >> end process;
    >>
    >> If I was to implement the above circuit, I will not write the above codes. I
    >> will first draw a data path diagram which show me that I can have have a
    >> barrel shifter to map the 16-bit 'we' to 64-bit 'data_we' based on the
    >> 'offset' input. Than I will use another shifter to "expand" the data and
    >> assign each of the 64 slots based on the 'data_we'. I may even write a simple
    >> Perl script to generate this 64 statement.
    >>
    >> Does anyone know any better implementation scheme or any synthesis tools that
    >> will generate a better result base on the above code? I tried Xilinx XST and
    >> the above code failed (out of memory ?!) I know some other synthesis tool can
    >> generated a valid circuit with terrible performance.
    >>
    >> The most important question is, "Should I worry about this?" Someone told me
    >> that the code failed to compile just because XST is not good enough. But I
    >> wonder. My teammates and me have a different point of view in CAD tools. They
    >> believe the logic optimization (e.g. from behavioral description to netlist)
    >> and don't trust the physical optimization (e.g. they do hand placement and
    >> timing on every net). I believe the opposite.
    >>
    >> There are too many *information* available when running the placement and
    >> routing process which is NOT suitable for a human brain. But the tools can
    >> handle this well. There some *knowledge* in the design which is hard to be
    >> captured in the tools. And we engineerings are trained to use this knowledge
    >> to optimize our design. So I believe that we should code more careful rather
    >> than pumping constraints to the tools.
    >>
    >> But the current trend is (at least observed by myself), to encourages users
    >> code more like in a software environment. Is this the design flow for tomorrow
    >> or I misunderstand something?
    >>
    >> --
    >> Regards,
    >> Tsoi Kuen Hung (Brittle)
    >> CSE CUHK

    >


    --
    Regards,
    Tsoi Kuen Hung (Brittle)
    CSE CUHK
     
    Guest, Jan 4, 2006
    #5
  6. wrote:
    > Hi - Thanks for the info. There are many typo in the my post since the
    > original Verilog code is not allowed to be published. So I must hand
    > type a different code in the post. This lead to the logical error you
    > refered to. The original code can be simulate and is functional correct.
    > It can even be synthesized using tools rather than XST. My main point is
    > the coding style. Thanks anyway.


    You're welcome anyway.
    Sorry if I missed your point.
    Since everyone has different tools I think
    "try it and see" is good advice.
    I run small benchmark entities through synthesis
    all the time to trade off fmax and utilization,
    and to test my own design rules.
    Good luck.

    -- Mike Treseler
     
    Mike Treseler, Jan 4, 2006
    #6
  7. Guest

    Rob Dekker Guest

    Hi
    Not a full solution, but some tips :

    The way your model is writte, a lot of data can be pushed around simultaniously.
    That means that in hardware, there is a lot of logic needed.
    What you want to check is which data can move simultaniously.

    For example, can multiple bits from 'we' be high at the same time ?
    If not (if only one bit is high simultaniously), then you can change the
    16 variable assignments into a single one. That saves a lot of logic.
    With that, data_in no longer needs simultanious access to all its (2048) bits.
    So, you might be able to get it into a single RAMs.

    Also, consider if you really need random access to all bits of 'data_out' ('data' in your target assignments).
    If not, 'data_out' could also be implemented as a RAM, or as 16 small RAMs
    (depending on which parts of 'data' need random access).

    Write HDL with the target hardware in mind, and then follow the 'coding rules'
    (for your synthesis tool) to write generic HDL that will get you that hardware.

    Rob


    <> wrote in message news:...
    > Hi,
    >
    > Does anyone happen to know what will the following (software) code will look
    > like after going through a synthesis tool? I was told, back in the school,
    > that never use *HDL as a software language and should have a block diagram or
    > data path before coding. But it seams that more and more people trust the
    > synthesis tool rather.
    >
    > // Verilog version
    > reg [5:0] offset; // input
    > reg [15:0] we; // input
    > reg [15:0] data_in[127:0]; // input
    >
    > reg [7:0] data_out [63:0]; // output
    >
    > wire [5:0] offset0; // internal logic
    > wire [5:0] offset1; // internal logic
    > ...
    > wire [5:0] offset15; // internal logic
    >
    > assign offset0 = offset;
    > assign offset1 = offset + 1;
    > ...
    > assign offset15 = offset + 15;
    >
    > always @ (posedge clk) begin
    > if (reset) begin
    > // initial code here
    > ...
    > end begin
    > if (we[0]) data[offset0] <= data_in[7:0];
    > if (we[1]) data[offset1] <= data_in[15:8];
    > ...
    > if (we[15]) data[offset15] <= data_in[127:120];
    > end
    > end
    >
    > -- VHDL version
    > type data_type is array (63 downto 0) of std_logic_vector(7 downto 0);
    >
    > signal offset : std_logic_vector(5 downto 0); -- input
    > signal we : std_logic_vector (15 downto 0); -- input
    > signal data_in : std_logic_vector (127 downto 0); -- input
    >
    > signal data_out : data_type; -- output
    >
    > signal offset0 : std_logic_vector(5 downto 0); -- internal logic
    > signal offset1 : std_logic_vector(5 downto 0); -- internal logic
    > ...
    > signal offset15 : std_logic_vector(5 downto 0); -- internal logic
    >
    > offset0 <= offset;
    > offset1 <= offset + 1;
    > ...
    > offset15 <= offset + 15;
    >
    > process (clk, reset)
    > if rising_edge(clk) then
    > if (reset = '1') then
    > -- initial code here
    > ...
    > else
    > if (we(0)='1') then data(offset0) <= data_in(7 downto 0); end if;
    > if (we(1)='1') then data(offset0) <= data_in(15 downto 8); end if;
    > ...
    > if (we(15)='1') then data(offset0) <= data_in(127 downto 120); end if;
    > end if;
    > end if;
    > end process;
    >
    > If I was to implement the above circuit, I will not write the above codes. I
    > will first draw a data path diagram which show me that I can have have a
    > barrel shifter to map the 16-bit 'we' to 64-bit 'data_we' based on the
    > 'offset' input. Than I will use another shifter to "expand" the data and
    > assign each of the 64 slots based on the 'data_we'. I may even write a simple
    > Perl script to generate this 64 statement.
    >
    > Does anyone know any better implementation scheme or any synthesis tools that
    > will generate a better result base on the above code? I tried Xilinx XST and
    > the above code failed (out of memory ?!) I know some other synthesis tool can
    > generated a valid circuit with terrible performance.
    >
    > The most important question is, "Should I worry about this?" Someone told me
    > that the code failed to compile just because XST is not good enough. But I
    > wonder. My teammates and me have a different point of view in CAD tools. They
    > believe the logic optimization (e.g. from behavioral description to netlist)
    > and don't trust the physical optimization (e.g. they do hand placement and
    > timing on every net). I believe the opposite.
    >
    > There are too many *information* available when running the placement and
    > routing process which is NOT suitable for a human brain. But the tools can
    > handle this well. There some *knowledge* in the design which is hard to be
    > captured in the tools. And we engineerings are trained to use this knowledge
    > to optimize our design. So I believe that we should code more careful rather
    > than pumping constraints to the tools.
    >
    > But the current trend is (at least observed by myself), to encourages users
    > code more like in a software environment. Is this the design flow for tomorrow
    > or I misunderstand something?
    >
    > --
    > Regards,
    > Tsoi Kuen Hung (Brittle)
    > CSE CUHK
     
    Rob Dekker, Jan 12, 2006
    #7
    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. Paul Baxter

    style for coding latches

    Paul Baxter, Aug 10, 2003, in forum: VHDL
    Replies:
    7
    Views:
    1,146
    Mike Treseler
    Aug 15, 2003
  2. Willem Oosthuizen

    Coding style to prioritize certain inputs

    Willem Oosthuizen, Sep 2, 2003, in forum: VHDL
    Replies:
    5
    Views:
    501
    Mike Treseler
    Sep 4, 2003
  3. Analog Guy

    Coding style for CPLD vs FPGA

    Analog Guy, Mar 11, 2005, in forum: VHDL
    Replies:
    3
    Views:
    5,460
    Klaus Falser
    Mar 14, 2005
  4. calmar
    Replies:
    11
    Views:
    902
    calmar
    Feb 21, 2006
  5. Ken Varn
    Replies:
    0
    Views:
    477
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page