Forum Discussion

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

64bit ddr2 conflit with lan91c11

Hello

in my design, I use a ddr2 high performance controller, DQ is 32bits, so local interface is 64 bit. and I also use a lan91c11. before generation, there is no any base address conflict. but after I click generation, there is a lot of base address conflicts related lan91c11. and I found if I delete lan91c11, then no conflicts. and if I change DQ width to 16 bits, so local interface is 32 bits, also no conflicts. so if I want to use lan91c11, I has to make local interface of DDR2 controller 32 bits?

thanks for any feedback.

6 Replies

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

    Doesn't the issue get solved when you use the auto assign base address menu item? If not you can try and give addresses manually to the ddr controller and the lan chip.

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

    After generation look at the address spans of your components to see if some of them have increased. I've heard of this issue before but I forget what caused it (I think it was caused by native addressing with slaves wider than the masters).

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

    find the cuase : should add a cross clock bridge between DDR2 and avalon bus.

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

    If the master and memory are on different clock domains then SOPC Builder will insert a clock crossing adapter. This adapter doesn't support pipelined transactions so your memory performance will drop a lot. To avoid this you can use the clock crossing bridge which will have a little bit more latency but it'll allow back to back transactions through it.

    If you care about the performance of the Nios II processor I would suggest trying to operate the processor and memory at the same clock speed to avoid any clock crossing. Clock crossing transfers adds a lot of latency so keeping both cores on the same clock domain may give you better performance.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    thanks for your reply, but that will go back to the first problem. my beginning plan is to make NIOS2 and DDR2 controller run in the same clock domain. but if I don't add cross clock bridge, before generation, no any base address confict. while in the half process of generation, a lot of strange base address conflits happen. if I change DDR2 controller local if to 32 bits, then no any conflicts during generation. so I think you are right it's caused by native addressing with slaves wider than the masters. but as I know, SOPC build should adap this automatically. So how to get rid of it if the ddr2 local IF has to be 64bit? and by the way, I also test this conflicts on cycloneIII_3c120_dev_niosII_standard_sopc example in the kits of Quartus91, same with my desgin.

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

    Ok I see. This issue is starting to become more familiar and if I remember correctly there isn't a nice workaround.

    So.... in your situation what I recommend you do is as follows:

    1) Make sure to use the SDRAM in full rate mode

    2) Make sure to use the HP2 implementation of the SDRAM controller

    3) Set the local burst size of the SDRAM controller to 1

    4) For the Nios II master connections to the SDRAM set the arbitration share to 8*

    * if your data cache line size is 4 bytes/line use 1, if your data cache line size is 16 bytes/line use 4.

    This will allow you to avoid clock crossing and burst adaptation. The single word accesses by the CPU will get condensed into off-chip bursts for you by the memory controller.

    Alternatively you could also try Qsys. Qsys doesn't support native addressing and just treats native slave ports as 32 bits wide dynamic ports. So I suspect this issue can't show up in Qsys.