Re: need help, synthesizable vhdl

Discussion in 'VHDL' started by KJ, Aug 21, 2010.

  1. KJ

    KJ Guest

    On Aug 21, 11:27 am, niyander <> wrote:
    > Hi,
    >
    > I have written some vhdl code which uses internal multiplier present
    > in spartan-3 device. Can someone check if this code is synthesizable,
    > i would appreciate if someone can help me in this.
    > I am getting desired results in simulation, but i am not sure if this
    > code is 100% synthesizable.
    >
    > code:http://anceop.com/vhdl.txt
    >
    > Thanks


    Synthesis tools are downloadable from the supplier's web site,
    consider downloading one. In both the short and long run you'll be
    more productive. Using Quartus, the warnings reported below (*1)
    represent conditions under which the logic that gets generated will
    *not* match simulation results. (*2)

    You should also consider getting rid of the first process and just use
    concurrent signals assignments as you did when you commented out the
    process portions of your second group. As a general rule you should
    try to not use combinatorial (i.e. non-clocked processes) they lead to
    design errors such as the ones being reported below as well as latches
    if you miss an assignment to a signal under some condition in the
    process.

    Sometimes one really likes to use statements such as 'if' and 'case'
    that are not available in concurrent assignment statements (such as in
    your last process). In those cases, if making the process clocked is
    not an option, then peruse the synthesis warnings for statements like
    the ones listed below since they are actually potential design errors
    waiting to trap you. Alternatively, consider implemeting your
    'process' code as a function or a procedure instead. At least then
    any compiler will flag usage of some signal (such as 'lead0') that is
    not formally listed as an input parameter.

    Kevin Jennings

    (*1)
    Warning (10492): VHDL Process Statement warning at Junk.vhd(509):
    signal "lead0" is read inside the Process Statement but isn't in the
    Process Statement's sensitivity list
    Warning (10492): VHDL Process Statement warning at Junk.vhd(511):
    signal "lead0" is read inside the Process Statement but isn't in the
    Process Statement's sensitivity list
    Warning: Design contains 1 input pin(s) that do not drive logic
    Warning (15610): No output dependent on input pin "clk"

    (*2) The synthesized result will behave as if 'lead0' was listed in
    the sensitivity list. Since it is not, then your simulation will
    differ if 'lead0' changes but none of the other signals does not
    happen to simultaneously transition. In your case, 'lead0' will
    change one simulation delta cycle after product_mantissa(47 or 46)
    changes so it won't be simultaneous. Your process for computing
    'final_mantissa' will wake up because of the change in
    'product_mantissa' (with a soon to be out of date value for 'lead0')
    but will not wake up again on the next simulation delta when 'lead0'
    actually gets updated.
    KJ, Aug 21, 2010
    #1
    1. Advertising

  2. On Aug 21, 10:57 pm, KJ <> wrote:
    > On Aug 21, 11:27 am, niyander <> wrote:
    >
    > > Hi,

    >
    > > I have written some vhdl code which uses internal multiplier present
    > > in spartan-3 device. Can someone check if this code is synthesizable,
    > > i would appreciate if someone can help me in this.
    > > I am getting desired results in simulation, but i am not sure if this
    > > code is 100% synthesizable.

    >
    > > code:http://anceop.com/vhdl.txt

    >
    > > Thanks

    >
    > Synthesis tools are downloadable from the supplier's web site,
    > consider downloading one.  In both the short and long run you'll be
    > more productive.  Using Quartus, the warnings reported below (*1)
    > represent conditions under which the logic that gets generated will
    > *not* match simulation results. (*2)
    >
    > You should also consider getting rid of the first process and just use
    > concurrent signals assignments as you did when you commented out the
    > process portions of your second group.  As a general rule you should
    > try to not use combinatorial (i.e. non-clocked processes) they lead to
    > design errors such as the ones being reported below as well as latches
    > if you miss an assignment to a signal under some condition in the
    > process.
    >
    > Sometimes one really likes to use statements such as 'if' and 'case'
    > that are not available in concurrent assignment statements (such as in
    > your last process).  In those cases, if making the process clocked is
    > not an option, then peruse the synthesis warnings for statements like
    > the ones listed below since they are actually potential design errors
    > waiting to trap you.  Alternatively, consider implemeting your
    > 'process' code as a function or a procedure instead.  At least then
    > any compiler will flag usage of some signal (such as 'lead0') that is
    > not formally listed as an input parameter.
    >
    > Kevin Jennings
    >
    > (*1)
    > Warning (10492): VHDL Process Statement warning at Junk.vhd(509):
    > signal "lead0" is read inside the Process Statement but isn't in the
    > Process Statement's sensitivity list
    > Warning (10492): VHDL Process Statement warning at Junk.vhd(511):
    > signal "lead0" is read inside the Process Statement but isn't in the
    > Process Statement's sensitivity list
    > Warning: Design contains 1 input pin(s) that do not drive logic
    >         Warning (15610): No output dependent on input pin "clk"
    >
    > (*2) The synthesized result will behave as if 'lead0' was listed in
    > the sensitivity list.  Since it is not, then your simulation will
    > differ if 'lead0' changes but none of the other signals does not
    > happen to simultaneously transition.  In your case, 'lead0' will
    > change one simulation delta cycle after product_mantissa(47 or 46)
    > changes so it won't be simultaneous.  Your process for computing
    > 'final_mantissa' will wake up because of the change in
    > 'product_mantissa' (with a soon to be out of date value for 'lead0')
    > but will not wake up again on the next simulation delta when 'lead0'
    > actually gets updated.


    Thank you ever one for your valuable comments.
    Pranav Pareek, Aug 22, 2010
    #2
    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. walala
    Replies:
    4
    Views:
    1,184
    Technology Consultant
    Sep 9, 2003
  2. Mike Treseler
    Replies:
    5
    Views:
    745
    Okashii
    Sep 13, 2005
  3. aravind

    Synthesizable VHDL

    aravind, Oct 30, 2006, in forum: VHDL
    Replies:
    2
    Views:
    1,286
  4. Vince
    Replies:
    0
    Views:
    789
    Vince
    Aug 21, 2010
  5. Mike Treseler

    Re: need help, synthesizable vhdl

    Mike Treseler, Aug 21, 2010, in forum: VHDL
    Replies:
    0
    Views:
    783
    Mike Treseler
    Aug 21, 2010
Loading...

Share This Page