Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

The best way to test an IP core

Hello all,

I think I have to ask the forum gurus this question before I start testing any IP core. I will be implementing an application specific IP core and what will be the best

way to test it after connecting the IP core to the NIOS II and adding other components in the qsys builder ? I have seen the way of creating a testbench qsys system and a testbench simulation model (from the 'generate option' in qsys builder) and finally doing the simulations in Modelsim (the modelsim being launched from a NIOS II SBT which has an application code).

Will this be a right approach to test my system as well ? Since I am a beginner in this area, I need some help and would really appreciate any response.

(Please let me know if there are any online tutorials regarding testing an IP core)

Thank You,

Akhil

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Typically what I recommend is testing the IP core using bus functional models first so that you'll be testing the IP in isolation. Then once those check out then switch to a software based testing using the Nios II core to perform more exhaustive testing. Normally when I'm using Nios II to do testing I only simulate the system if the test fails which often occurs early when you have a new IP core. The step of doing the BFM testing first helps reduce the number of cycles you have to do while doing software driven testing.

    I'm don't really believe there is a single "right" approach as long as you get the coverage that you require. If that coverage happens to only require software based testing then you could stick to it. Some users can get all their coverage using BFMs without the need to use software based testing. For the type of stuff I design I like using a software driven methodology since I can write C code faster than test programs for BFMs but that's just me so often preference also plays a role.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hello BadOmen,

    Thank you for the reply! I think what you are saying is to create the testbench Qsys system and the simulation model. And instead of adding a C code to test from NIOS II, test the IP by adding testcases in the testbench file (Verilog). Did I understand this correctly? I have seen an altera wiki link http://www.alterawiki.com/wiki/simulating_designs_with_lower-level_qsys_systems

    which shows an example to test (but not testing an IP core, it has a simple counter design) from an application code. Is there any other example which shows the testing of IP in isolation (using the bus functional models) ?

    Thank You,

    Akhil
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    BFMs abstract the simulation so that instead of worries about wiggling ports you can for example perform an Avalon read transaction and let the BFM do the wiggling for you. There are some examples with the BFM documentation for Quartus.

    Does your counter have Avalon interfaces for you to be able to do things like write an initial value, read it back, start/stop, etc.... If it's just a plain counter then a testbench should be sufficient since there is no way to extract a generic interface like that (Qsys uses conduit BFMs for that but you are wiggling wires at that point).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hello,

    Really appreciate the response. Yeah I see online examples from Altera regarding the BFM s and the way those can be used to test the IP cores.

    Hope those will be useful to me. The counter design is a simple one taken from the webpage http://www.alterawiki.com/wiki/simulating_designs_with_lower-level_qsys_systems

    It is just a plain counter with out any Avalon interfaces (so that a testbench is sufficient). Infact the counter is not an IP, just a verilog module.

    Thank You,

    Akhil