FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6355 Discussions

Different simulation results depending on device type set in Device Block

Altera_Forum
Honored Contributor II
1,223 Views

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.
0 Kudos
10 Replies
Altera_Forum
Honored Contributor II
402 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

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)
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

OK, it's in my previous post

0 Kudos
Altera_Forum
Honored Contributor II
402 Views

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

Not sure why.
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

Nice.  

Frankly, I was hoping that I just overlooked something..
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

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:-)
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
402 Views

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 ...

0 Kudos
Reply