Forum Discussion

michalis_patelis's avatar
michalis_patelis
Icon for New Contributor rankNew Contributor
3 years ago

adding information regarding expected timing in the LPM_ADD_SUB section of the user guide

To help an engineer make an informed decision about using any of the integer arithmetic IP cores, it would help immensely if some timing information was provides in the user's manual.

taking as an example the LPM_ADD_SUB IP core (page 22 in the manual)

some indication for the expected timing:

- when no pipelining is deifned, what is the expected input-to-output propagation delay for such an IP core? Dependencies on core parameters, target FPGA family, speed grade, etc exist, of course, but some examples for specific families and speed grades would be helpful: for example 8-bit/16-bit/32-bit adder-only in a Cyclone V, speed grade x, etc.

- when pipelining is defined, what is the expected clock frequency that the IP core could operate at? (for dependencies, same as above).

It is understood that such timing information, if available, could only serve as a rough guide to the designer, but they would still be very useful in making a choice between pipelining/non-pipelining and, if pipelined, how many pipe-stages.

14 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    3 years ago

    As you state, there are just too many possibilities of device and options to put something in a user guide. That's the whole point of the timing analyzer in Quartus. You can add something to a design and then quickly get this information for the device you are targeting with the options you select.

    If something like this was in a user guide, how are you seeing its use for a designer?

    And as for pipelining, well, in theory, you can never have too many pipeline stages if your goal is a fast running design if you are ok in the rest of your design with the extra cycles of latency. This is the whole idea behind hyperflex in Stratix 10 and Agilex. And fast forward compile with those devices will tell you how many pipeline stages would be most optimal.

    • michalis_patelis's avatar
      michalis_patelis
      Icon for New Contributor rankNew Contributor
      3 years ago

      Hi Nurina,

      No, the above comment does not help as it is missing the point. The information that I am suggesting should be included in the documentation is to help an engineer make a decision about the suitability of an IP core for their design. This means that they have NOT yet made a design, using this core, so that they can analyse it using the timing analyser! At the design/concept stage, when one is looking for options, that's when this information could help make a decision. What if there were 2 (or more) alternatives that could be used? Should the engineer have to make 2 (or more) designs using the candidate cores and perform a timing analysis on each one? And should all the engineers, in the whole world, that are considering using this core have to do this for themselves? What a waste of time!

      This work should be done ONCE, by Intel, and should be included in the documentation (giving some examples of all the possible combinations, as I have already mentioned). In this way, ALL the engineers, in the whole world, over the entire lifetime of the IP core, will be able to make easier decisions, in less time.

      So my request still stands, as in my original entry, above, and I am advised (by the support team) to ask you to be assigned to the case owner of 15012890347.

      Thank you for your help.

  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    Hello,


    We do not receive any response from you on the previous question/reply/answer provided. Please login to https://supporttickets.intel.com , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


    p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 4/5 survey


    Regards,

    Nurina


    • michalis_patelis's avatar
      michalis_patelis
      Icon for New Contributor rankNew Contributor
      3 years ago

      Hi,

      I have updated the supporttickets and have also replied to your previous question.

      Best regards

  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    Hello,


    Thank you for your feedback. I have checked case 15012890347 and will check with our engineering team whether we can publish this information on user guide.



    Regards,

    Nurina


  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    Hello,


    We have checked with engineering team. Expected timing performances is not available for publication because there are too many parameter combinations.


    Regards,

    Nurina


  • michalis_patelis's avatar
    michalis_patelis
    Icon for New Contributor rankNew Contributor
    3 years ago

    As I said in my original question, I am aware that there are many possible combinations and that it would be unrealistic to provide timing information relating to every single one of them. That is why, I suggested, that there should be timing information for only a select few combinations. This would still be helpful.

    For example:

    1. take only 2 of the most popular FPGA families
    2. take only a single speed grade, neither the fastest, nor the slowest,
    3. take the following implementation cases:
      • non-pipelined
      • pipelined, one-stage

    The above, makes a total of 4 combinations, which is perfectly manageable.

    For other IP cores, there is information, provided in the IP core's documentation, about the number of logic cells that would be required when instantiating the IP core in different FPGA families, together with a typical clock frequency that could be achieved.

    I don't see any reason why the same analysis could not be done for the arithmetic cores and the results included in the documentation.

  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    Hello,


    Thank you for your suggestion.

    I am relaying your response to engineering team so see if this information can be published.


    Regards,

    Nurina


  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    Hello,


    I am currently waiting for response from internal team.

    I'll let you know of any updates.


    Regards,

    Nurina


  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    Hello,


    I am currently waiting for response from internal team.

    I'll let you know of any updates.


    Regards,

    Nurina


  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    Hello,


    Thank you for your patience. Internal team responded that they plan to add this information in a future release of the user guide.

    May I know if you have any concerns?


    Regards,

    Nurina


    • michalis_patelis's avatar
      michalis_patelis
      Icon for New Contributor rankNew Contributor
      3 years ago

      Hi,

      I will then have to wait to see if this information has been included in future versions of the user guide so that I can comment if an improvement has been made.

      Regards