Forum Discussion

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

A question about retargeting MegaWizard created items in device migration

Hi,

I have done a FPGA design on EP2C70(Cyclone II) , and now I want to migrate this design to EP3C120(Cyclone III).

I have changed the device to EP3C120 in Quartus setting and done the Analysis & Synthesis. But when I opened MegaWizard created items, I found the device family is still Cyclone II in the Megawizard pages.

There are about 30 MegaWizard created items(pll, adders, dividers, shift registers....) in my design. Do I have to manually retarget the device family one by one in the MegaWizard? Can quartus automatically fulfill this boring work?:confused:

Thanks!

6 Replies

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

    There isn't a script to regenerate it all, but it should all occur in the back-end, i.e. just compile for CIII and it will all work. More complicated IP that significantly changes architecture, like changing a transceiver from Stratix IV to Cyclone IV, or changing a memory interface, often does have to be regenerated since options change. If this is the case, it should error out anyway. But the stuff you mentioned is pretty generic and Altera works on keeping it portable.

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

    Thank you very much!

    I did use several complicated IPs such as FFT and FIR. Anyway it is easy to regerate them in the new device.

    But, can I understand your suggestions like this: If there is no error reported in a full re-compilation after device migration, it is needless to regenerate these Megawizard created items, no matter these items are generic or complicated?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    There shouldn't be. I can't think of a time where someone didn't re-generate a core and it caused soft problems(i.e. it fit but didn't work).

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

    I was thinking about it a bit more, if this was the best strategy. I think having a script that retargeted all the IP would be more painful, since it wouldn't allow users to use IP across multiple families at the same time(e.g. a device in Stratix IV that is in production, but the same files may be used for a Stratix V design that will be the new product). If users updated all the megawizard files for SV, they would now have two sets of files to maintain. Plus, if there were incompatibilities, a script wouldn't be able to handle it, and the user would have to make the modifications by hand. So then I thought, why have a target family at all in the megawizard. I imagine the reason is to make sure it is known what family it was generated for. Though it may be compatible with all families (say the altpll), there might some day be a new piece of IP that is different(like fractional PLLs in Stratix V, although the designs I've run still accept the old PLL). So I think Altera's approach is pretty good, unless anyone can think of something I'm missing?

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

    I think Quartus should give error hints or critical warnings at least in Analysis & Synthesis process if some IPs can not be used(it may be IP version or license problem) in the new device or they are incompatible with the new device. Thus, we are clear which Megawizard items have to be regenerated manually in device migration.