Forum Discussion

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

Multi NIOS2 system Custom instruction opcode reuse problem in QSys

I'm currently using Qsys version 11.0, Build 157.

Currently I have a system that consists of two NIOS2 processors and they are both connected to their own custom instruction component. As far as I can understand, the two NIOS2 processors should not be able to see the other's Custom Instruction component. If I set the OpCode Base to 0 for both custom instructions, I get these error when trying to generate the system in QSys:

Info: cpu:

Info: cpu: ERROR:

Info: cpu: msb of '2' is less than lsb of '3' for custom instruction 'crc_0' (addr_base='0', addr_width='3', master_n_field_decode_sz='3'

Error: cpu: Failed to generate module niosii_3c25_system_cpu

"cpu" is the name of one of the NIOS with the other called "cpu_0". "cpu" is hooked up to custom instruction "CRC_0" and "cpu_0" is hooked to "CRC_1".

The system also contains a DDR SDRAM Controller, JTAG UART, Interval Timer and Clock Source. There are two copies of each, one for each half of the system. None of the connections I made in QSys cross between the two halves and the two sides are connected in exactly the same way. This is sort of a test system based off the CRC Custom Instruction tutorial from the Nios 2 Custom Instruction User Guide. I essentially duplicated every component in the system.

Currently the system has the opcode range for both custom instructions set to 0-7. If I change one custom instruction range to 8-15 the system will generate without problems. However, this workaround will not work if I have a larger number of custom instructions since I'll eventually go past the limit of 255 for opcodes.

Is there any way to have two custom instructions in one system that use the same opcode range? I'm currently having a problem understanding why QSys currently has a problem with what I'm doing even though the components don't seem to connect to each other. Are they connected in a way I don't currently realize?

6 Replies

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

    This should be possible and I just tried it using the two custom instructions that show up in Qsys. Make sure that the custom instruction master from one CPU doesn't connect to the custom instructions of the second CPU.

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

    Just to make sure I've got this right, if they aren't connected in the "Connections" column in QSys, they aren't connected, right?

    The custom instruction master of each CPU is only connected to the custom instruction associated with the CPU. "cpu"'s custom instruction master is only connected to "CRC_0"'s custom instruction slave. "cpu_0"'s custom instruction master is only connected to "CRC_1"'s custom instruction slave.

    Here's step by step everything I did in QSys to get the error:

    Started from a new system that only has a Clock Source.

    Add a NIOSII/f (named nios2_qsys_0)

    Set Reset vector memory to jtag_debug_module

    Set Exception vector memory to jtag_debug_module

    Instruction cache is set to 512 Bytes

    Data Cache is set to None

    clk and reset_n are hooked up to the Clock Source.

    Add a CRC (named CRC_0)

    Hook custom instruction master to custom instruction slave.

    Add a second NIOSII/f (named nios2_qsys_1)

    Set Reset vector memory to jtag_debug_module

    Set Exception vector memory to jtag_debug_module

    Instruction cache is set to 512 Bytes

    Data Cache is set to None

    clk and reset_n are hooked up to the Clock Source.

    Add a CRC (named CRC_1)

    Hook custom instruction master of the second NIOSII/F to custom instruction slave of the second CRC.

    I confirm that both custom instruction use the OpCode range 0-7.

    I did NOT make any connection between the first CPU master and the second custom instruction slave or a connection between the second cpu master and the first custom instruction slave.

    Save System and Generate.

    The same error appears:

    Info: nios2_qsys_0: ERROR:

    Info: nios2_qsys_0: msb of '2' is less than lsb of '3' for custom instruction 'crc_0' (addr_base='0', addr_width='3', master_n_field_decode_sz='3'

    Error: nios2_qsys_0: Failed to generate module niosii_3c25_system_3_nios2_qsys_0

    If it matters, the CRC Custom Instruction comes from the "Nios II Custom Instruction Design Example" on the Altera website.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I was able to reproduce this. If others run into this try placing the CPU and custom instructions into separate subsystems to avoid this issue with the overlapping opcodes.

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

    It is also shame you can't select the number for each custom instruction.

    If I have several custom instructions, I'd much rather use the a fixed number for each as it makes the compiler setup somewhat easier.

    I suspect you get a duplicate symbol problem if you have 2 (or more) nios that contain the same custom instruction (name & vhdl) with different numbers.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    @BadOmen

    I run into the same problem.

    What do actually mean by separate subsystems? Two different instances of QSys system?

    I think this would be no good solution for me because I need the two NIOS to be sharing the same Avalon bus and with two separate instances this would be not possible, am I right ?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Either way should work assuming this is still an issue with the latest tools (not sure haven't checked myself).

    If you want a shared address space then I would put a CPU into it's own subsystem with it's own set of custom instructions to avoid this issue. For shared peripherals/memories just put a pipeline bridge into each CPU subsystem and export the master of the bridge. Then at the top level (or whatever heirarchy level the shared components live) connect those exported bridge masters to all the slaves you want both CPUs to see. Just make sure you expose enough address bits for each of those pipeline bridges to span all the slave ports you want each CPU to have access to.