Forum Discussion

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

Design portability on a cyclone

Good morning,

I've got a HDL design which run in RTL simulation.

This design run in gate level simulation with time modelisation on a stratix II or an arria II.

Howerver, it doesn't work on a cyclone (II or III) FPGA.

I don't know what to do ! It's the first time for me that a design work on RTL simulation, on gate level simulation for several device but not on a Cyclone II/III.

For information here is the result of the ressource utilization on stratix II :

Combinational ALUTs    5,491 / 72,768 ( 8 % )
Dedicated logic registers    4,037 / 72,768 ( 6 % )
    
Combinational ALUT usage by number of inputs    
-- 7 input functions    29
-- 6 input functions    1400
-- 5 input functions    625
-- 4 input functions    600
-- <=3 input functions    2837
    
Combinational ALUTs by mode    
-- normal mode    3957
-- extended LUT mode    29
-- arithmetic mode    1388
-- shared arithmetic mode    117
    
Logic utilization    7,961 / 72,768 ( 11 % )
-- Difficulty Clustering Design    Low
-- Combinational ALUT/register pairs used in final Placement    7168
-- Combinational with no register    3131
-- Register only    1677
-- Combinational with a register    2360
-- Estimated pairs recoverable by pairing ALUTs and registers as design grows    -260
-- Estimated Combinational ALUT/register pairs unavailable    1053
-- Unavailable due to unpartnered 7 LUTs    18
-- Unavailable due to unpartnered 6 LUTs    886
-- Unavailable due to unpartnered 5 LUTs    27
-- Unavailable due to LAB-wide signal conflicts    99
-- Unavailable due to LAB input limits    23
    
Total registers*      4,037 / 75,850 ( 5 % )
-- Dedicated logic registers    4,037 / 72,768 ( 6 % )
-- I/O registers    0 / 3,082 ( 0 % )
    
ALMs:  partially or completely used    4,263 / 36,384 ( 12 % )
    
Total LABs:  partially or completely used    585 / 4,548 ( 13 % )
    
User inserted logic elements     0
Virtual pins    0
I/O pins    168 / 535 ( 31 % )
-- Clock pins     12 / 16 ( 75 % )
Global signals     2
M512s    0 / 488 ( 0 % )
M4Ks    16 / 408 ( 4 % )
M-RAMs    1 / 4 ( 25 % )
Total block memory bits    223,096 / 4,520,448 ( 5 % )
Total block memory implementation bits    663,552 / 4,520,448 ( 15 % )
DSP block 9-bit elements    4 / 384 ( 1 % )
PLLs    0 / 6 ( 0 % )
Global clocks    2 / 16 ( 13 % )
Regional clocks    0 / 32 ( 0 % )
SERDES transmitters    0 / 118 ( 0 % )
SERDES receivers    0 / 118 ( 0 % )
JTAGs    0 / 1 ( 0 % )
ASMI blocks    0 / 1 ( 0 % )
CRC blocks    0 / 1 ( 0 % )
Remote update blocks    0 / 1 ( 0 % )
Average interconnect usage (total/H/V)    2% / 2% / 2%
Peak interconnect usage (total/H/V)    27% / 27% / 26%
Maximum fan-out node    CLK~clkctrl
Maximum fan-out    4076

Does anybody got ideas ?

19 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Yes

    data_out ='X'

    But I can't evaluate where the problem come from because I am in gate level simulation. What can I do ?

    --- Quote End ---

    Hi,

    it looks for me as an synthesis issue, because the synthesis engine are different for the FPGA families. Can you try an older or newer Quartus version ?

    Kind regards

    GPK
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    But I can't evaluate where the problem come from because I am in gate level simulation.

    --- Quote End ---

    You should be still able to assign the nets to original design entities and try to determine what's the 'X' source in your design.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi, I already tried with the new quartus version 9.1. However it doesn't work. If you have an idea it would be great.

    In anyway, thank you.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Hi, I already tried with the new quartus version 9.1. However it doesn't work. If you have an idea it would be great.

    In anyway, thank you.

    --- Quote End ---

    Hi actris,

    which versions did you try up to know ? 9.1 and 9.0 ?

    Maybe you should try an older one. I will try to setup your project in my environment,

    but this take some time.

    Kind regards

    GPK
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I found, that there's exactly one dangerous warning in the Cyclone III report:

    --- Quote Start ---

    Warning: Synthesized away the following node(s):

    Warning: Synthesized away the following RAM node(s):

    Warning (14320): Synthesized away node "FDCT:U_FDCT|MDCT:U_MDCT|ROME:\G_ROM_ST1:0:U1_ROME|altsyncram:Mux11_rtl_15|altsyncram_0hv:auto_generated|ram_block1a0"

    --- Quote End ---

    It's originated from an instance of rome.vhd.

    By changing the table definion in rome.vhd from

      constant rom : ROM_TYPE := 
    to

      signal rom : ROM_TYPE :=

    the above warning vanished and the ROM implementation was changed from Mux11_rtl_15 to rom_rtl_15. I didn't set up the ModelSim simulation, but I hope, the problem can be solved this way.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I tried. Thank you. However I don't understand why it work.

    Now I manage to make the gate level simulation with propagation time but : it doesn't work on hardware?

    I never saw that ...

    What can I do ?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    OK !

    It works properly you was right. I have made a mistake on how to modifie a file wich is include in a SOPC.

    Thank you VERY VERY much
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    However I don't understand why it work.

    --- Quote End ---

    Neither do I. Megafunction inference is sometimes mysterious... In this case, the constant type seems to be the problem. It's a kind of Quartus design compiler bug in my opinion.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Neither do I. Megafunction inference is sometimes mysterious... In this case, the constant type seems to be the problem. It's a kind of Quartus design compiler bug in my opinion.

    --- Quote End ---

    Hi FvM,

    I agree with you, because for other device families it seems to work fine.

    Kind regards

    GPK