Dual Nios cores - but a catch - one's behind the "black box" wall

[Altera_Forum]

Background: I'm very new to Altera (lifetime Xilinx user), and am learning the Nios flow through some tutorials and playing with a development board. 

 The project: We are a subcontractor and are doing a collaboration with our customer in which we will be producing a "black box" design with protected IP inside and a defined interface for them to access it from their "side" of the design. Each of us wants a Nios in our code. They do not have to access any shared memory, so I imagine that simplifies things. However, are there any difficulties of this design approach?  1) How does the IDE know which one to connect to when debugging software? 2) Can the one in the black box side be somehow protected so that the party who is not privvy to the IP can not   (I think the answer to this is simply: "Don't provide the IDE project, and the worst they could do is to reverse-engineer the assembly code (which is probably an acceptable risk)") 3) If we *don't* provide them our IDE project, is it still possible for them to have a project that access only their own Nios, even though ours will be hanging out on the JTAG bus, possibly confusing the tool? 4) And vice-versa, can we access our Nios core with the IDE without always having to have a copy of their up-to-date project to tell the tool how to put the JTAG interface on their Nios into pass-through mode so we can ignore it? 5) Is there any difficulty to compiling a netlist with a Nios for inclusion in a top-level design in the first place?  Thanks! I know I could answer a lot of these questions with some trial-and-error, but I'm hoping that some wise souls will be able to keep me from going down a lot of dead-end alleys. -- Kevin

[Altera_Forum]

You can certainly compile and link nios code outside of the IDE and without all the headers generated by the sopc builder (etc). 

I'd much rather have a memory map (etc) specified, and the C headers and fpga image both built to match the specification.  JTAG download and debug are a different issue. I presume you want to download the fpga itself from on-board memory - or, at least, not over JTAG from quartus. Which makes a lot of sense anywhere where the hardware and software are written by different people (even if they are only a few desks apart).  We download nios code (and do any debugging) using the PCIe slave interface. Not having breakpoints or source level debug isn't that much of a hardship - you can't really breakpoint real-time (or comms protocol) code since the rest of teh world doesn't stop.