Forum Discussion

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

Different simulation results depending on device type set in Device Block

Hello everyone,

Recently I tried to use Decimation FIR from Advanced Blockset. It worked fine during the simulation until I put the Device block in the design to generate a device specific hardware. When I set device type to Cyclone IV FIR always outputs zeroes. Then I changed device to Stratix II and it worked fine again, same thing with Arria.

So, for some devices it generates working design(Stratix II,Arria) and for some not (Cyclone III,Cyclone IV).

I tried different operating frequencies in Control Block, but it didn't alter the simulation results.

I also tried the same experiment with Single Rate FIR, it also outputs different impulse responces depending on device type!

Does anyone know what can be the reason to that behavior?

Thanks in advance.

10 Replies

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

    --- Quote Start ---

    Hello everyone,

    Recently I tried to use Decimation FIR from Advanced Blockset. It worked fine during the simulation until I put the Device block in the design to generate a device specific hardware. When I set device type to Cyclone IV FIR always outputs zeroes. Then I changed device to Stratix II and it worked fine again, same thing with Arria.

    So, for some devices it generates working design(Stratix II,Arria) and for some not (Cyclone III,Cyclone IV).

    I tried different operating frequencies in Control Block, but it didn't alter the simulation results.

    I also tried the same experiment with Single Rate FIR, it also outputs different impulse responces depending on device type!

    Does anyone know what can be the reason to that behavior?

    Thanks in advance.

    --- Quote End ---

    I never seen that problem. your testing must be wrong

    If you are simulating it inside a larger design then check you are giving the right inputs in each case. Still better check the block at simulink level

    before integrating it anywhere else.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Thanks for your reply.

    There is only Decimating FIR and Scale block in the design, so I can't find anything else that can be wrong.

    I just change Stratix II to Cyclone III or IV in the Device block and rerun the simulation. And the output is different! (zeroes in case of Cyclone and non-zero inpulse responce in case of Stratix)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    Thanks for your reply.

    My apologies, it wasn't about the FIR block, but about the Scale block that goes after the FIR.

    But the question still stands only now it concerns Scale block.

    There is only Decimating FIR and Scale block in the design, so I can't find anything else that can be wrong.

    I just change Stratix II to Cyclone III or IV in the Device block and rerun the simulation. And the output is different! (zeroes in case of Cyclone and non-zero inpulse responce in case of Stratix)

    --- Quote End ---

    can you attach your simulink file.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    If you set coeff resolution to 16,15 instead of 24,23 then it works.

    Not sure why.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    Nice.

    Frankly, I was hoping that I overlooked something..

    --- Quote End ---

    problem occurs in filter blocks and step response goes wrong, not the scale block.

    Usually coeff resolution of 16,15 is common. Why should 24,23 fail? looks like a bug, related to multiplier width support across devices.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Thank you for information

    Funny thing, I used that kind of 24,23 single rate FIRs in another design. At that time I didn't even bother to check that it generates different results with and without Device block. But despite that it worked fine on the hardware. I've just pulled that old filles and found that this bug is there too! So may be it's the bug in simulation..

    Anyway, I guess it's the last time I use DSP Builder:-)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    Thank you for information

    Funny thing, I used that kind of 24,23 single rate FIRs in another design. At that time I didn't even bother to check that it generates different results with and without Device block. But despite that it worked fine on the hardware. I've just pulled that old filles and found that this bug is there too! So may be it's the bug in simulation..

    Anyway, I guess it's the last time I use DSP Builder:-)

    --- Quote End ---

    I ran modelsim on generated code and it shows the failure issue as well. So I doubt it will be working in hardware.

    In both cases, the failure produces a comb like filter instead of low pass
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    What's happening here is that the FIR needs 25x24 multiplications. On classic Cyclone devices, the widest native multiplier is 18x18 so DSP Builder needs to split the multiplication into multiple parts. This isn't the case for other families, which have 27x27 and/or 36x36 multipliers available. DSP builder splits the multiplication into 17-bit chunks and recombines the result. Effectively, it implements a 34x34 multiplier. The output of the 34x34 multiplier is 68 bits wide. Unfortunately, this is too wide for the simulation model used by the FIR compiler, which is restricted to 64-bit data paths. (This restriction does NOT apply to user-built systems, which use a different simulation model.) The result of this is that the Simulink simulation results for the FIR are incorrect. The generated hardware actually works properly, which means that the Modelsim simulation results will be correct but mismatch against the expected output (which is generated from the incorrect Modelsim results). We're working on it ...