system console, external memory, multiple masters

Hi Dave

I implemented the jtag mm master, and i do believe that it encompasses all memory, but my original triggering problem still exists: when i use the master_write_from_file in system console, that seems to jam up the following nios code:

printf("waiting for trigger...\n");

while(IORD_32DIRECT(TRIGGERBUFFER,0) != triggerCaptureVal )

{

delay = 0;

while(delay < 100000000)

{

delay++;

}

printf("\nTriggerReg is %08x\n",TRIGGERBUFFER);

verifyTriggerSet = (IORD_32DIRECT(TRIGGERBUFFER,0));

printf("\nTriggerVal is %08x\n",verifyTriggerSet);

}

I can watch each loop output text, but the second that i run the

master_write_from_file $myMaster "c:/mydir/bitStream34.bin" 0x20000004

the loop stops printing. no errors, just hang up.

Any ideas? I just need to be able to load up a bunch of commands to memory before this trigger occurs. i was hoping that the master_write_from_file would be the answer. Any other ideas on how to do this? or possibly pause the nios from checking that memory (in case there is an access contention)?

attached is an updated qsys just incase you see something there

thanks!

If you open your Qsys system, the default page with your component connections will also have your memory map. If the addresses on the right-side of the GUI are all visible, eg., registers at 0000_0000h, ram at 1000_0000h, then the address map of both masters is identical. It is possible to make the masters have different address maps, but then the addresses on the default page get replaced with something like <multiple>.

What devices do you have in your Qsys memory map, eg., a NIOS II processor and the default JTAG master that comes as part of the memory controller, or did you explicitly include a JTAG-to-Avalon-MM master bridge?

Cheers,

Dave

Also, here is part of my top level code: just the mem pins and the instantiation

//generated from terasic system builder ....

//////////// LPDDR2 //////////

output [9:0] DDR2LP_CA;

output DDR2LP_CK_n;

output DDR2LP_CK_p;

output [1:0] DDR2LP_CKE;

output [1:0] DDR2LP_CS_n;

output [3:0] DDR2LP_DM;

inout [31:0] DDR2LP_DQ;

inout [3:0] DDR2LP_DQS_n;

inout [3:0] DDR2LP_DQS_p;

input DDR2LP_OCT_RZQ;

.....heres my instantiation

spiFromQsys8Bits u0 (

.clk_clk (CLOCK_125_p), // clk.clk

.reset_reset_n (1'b1), // reset.reset_n

.spi_0_external_MISO (GPIOSPIGPIO[3]), // spi_0_external.MISO

.spi_0_external_MOSI (GPIOSPIGPIO[2]), // .MOSI

.spi_0_external_SCLK (GPIOSPIGPIO[1]), // .SCLK

.spi_0_external_SS_n (GPIOSPIGPIO[0]), // .SS_n

.memory_mem_ca (DDR2LP_CA), // memory.mem_ca

.memory_mem_ck (DDR2LP_CK_p), // .mem_ck

.memory_mem_ck_n (DDR2LP_CK_n), // .mem_ck_n

.memory_mem_cke (DDR2LP_CKE), // .mem_cke

.memory_mem_cs_n (DDR2LP_CS_n), // .mem_cs_n

.memory_mem_dm (DDR2LP_DM), // .mem_dm

.memory_mem_dq (DDR2LP_DQ), // .mem_dq

.memory_mem_dqs (DDR2LP_DQS_p), // .mem_dqs

.memory_mem_dqs_n (DDR2LP_DQS_n), // .mem_dqs_n

.oct_rzqin (DDR2LP_OCT_RZQ) // oct.rzqin

);

--- Quote Start ---

I see all the memory addresses. So i think thats good.

--- Quote End ---

Yes. Your memory map has only one set of addresses.

--- Quote Start ---

Ive attached a screen shot of my qsys and mem settings. I believe im using the built-in avalon controller within the memory.

--- Quote End ---

Because that "master" is hidden within the memory controller, it can only see the memory addresses (most likely starting with an address of 0). I suspect that if you write with the JTAG memory master to address 0, then read with the NIOS processor from address 2000_0000h (the base address of the memory as viewed by the NIOS II processor) you will see the same data.

There is another component called the JTAG-to-Avalon-MM bridge. You can add that to the top-level design, and connect it just as you have done with the NIOS II processor. You can then use SystemConsole to access the memory map via that master.

I believe the NIOS II processor debug interface can also be used via SystemConsole, however, I have not used it. Its possible you can use that to read/write the memory map.

Personally, I think its "easier" to understand what is going on if you explicitly add the JTAG-to-Avalon-MM master to your design and use it to access the same addresses as the NIOS II master.

Here's some notes on the JTAG-to-Avalon-MM master ...

http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial

Cheers,

Dave

Hi Dave

I tried a quick test on the memory offsets in system console. Was hoping that i could write master 0 at addr x4 and then read the same data back at master 1 addr x20000004, but the memory content doesnt line up:

% set extMem[ lindex [ get_service_paths master ] 0 ]

/devices/5CGTFD5(C5|F5)|5CGXBC5C(6|7)|..@1#USB-1/(link)/JTAG/sldfabric.node_1/phy_0/mem_if_lpddr2_emif_0_dmaster.master

% open_service master $extMem

% master_read_32 $extMem 0x00000004 10

0x818001c0 0x019e0000 0x818021c0 0x019e0000 0x818041c0 0x019e0000 0x818061c0 0x019e0000 0x818003c0 0x019e0000

% close_service master $extMem

% set myNios[ lindex [ get_service_paths master ] 1 ]

/devices/5CGTFD5(C5|F5)|5CGXBC5C(6|7)|..@1#USB-1/(link)/JTAG/sldfabric.node_2/nios2_qsys_0.data_master

% open_service master $myNios

% master_read_32 $myNios0x20000004 10

0xdfc00015 0xd8400215 0xd8800315 0xd8c00415 0xd9000515 0xd9400615 0xd9800715 0xd9c00815 0x000b307a 0xda000915

% close_service master $myNios

Ill try adding the jtag to avalon mm master in there and report back

thanks for all your help!

I haven't tried either of the methods you're using, so cannot comment on what I'd expect to see. The only time I use the JTAG master embedded in the DDR controller is to run the DDR memory interface toolkit for sweeping the memory interfacing timing margin.

--- Quote Start ---

Ill try adding the jtag to avalon mm master in there and report back

--- Quote End ---

I know for-sure that this will give you the results that you want.

Cheers,

Dave

--- Quote Start ---

but my original triggering problem still exists: when i use the master_write_from_file in system console, that seems to jam up the following nios code:

--- Quote End ---

Sorry, I can't help you with that. I have used SystemConsole and SignalTap II for triggering, and for the longest time they did not work well together, i.e., you had to make sure you opened the JTAG master server before clicking on the trigger in SignalTap II.

Given that you are trying to access NIOS II debug channels over JTAG as well, I think you're just asking too much. Think about what you are trying to do, and try another method.

For example, what board are you testing with? A simple solution for many boards is to use a USB-to-UART cable, eg., the FTDI FT232H cable and use a proper UART over that channel. That way you can see the output from your NIOS processor, yet it will not interfere with SignalTap II or SystemConsole.

Cheers,

Dave

Hi Dave

I dont believe im doing anything that shouldnt be possible. just trying to use the system console in a very basic way. but it does seem like hanging issue appears for others as well

I do appreciate your help! youve taught me a few things today !!

thanks!

--- Quote Start ---

I dont believe im doing anything that shouldnt be possible. just trying to use the system console in a very basic way. but it does seem like hanging issue appears for others as well

--- Quote End ---

You're right, it should all be possible. However, in my experience, the Altera JTAG software has bugs. Or perhaps that the user-space application interface to the driver and the locking between processes is not quite correct, and you are able to lock it up. I've explained one way that I am pretty sure you can still lock it up, and I suspect that you have found another. Unless you spend a lot of time debugging, you're unlikely to find the source of the problem, or to get Altera to fix it, so you'll have to figure out a work-around :)

If you can come up with a small design that can be shown to fail repeatedly on an Altera development board, then file a Service Request with Altera, upload the code, and ask them if they can help. The support people are very receptive to helping and solving problems, but its a waste of their time if you simply complain, its much better to give them an example that demonstrates the issue.

--- Quote Start ---

I do appreciate your help! youve taught me a few things today !!

thanks!

--- Quote End ---

You're welcome!

Cheers,

Dave

Ive actually went ahead and abandoned the write_from_file idea. i put a gigantic for loop in my tcl script that loops over a ton of write_32 mem write that i thought for sure would be just as memory intensive as write_from_file and the nios code didnt lock up and triggered perfectly. so there has got to be a bug in that write from file that hoses mem. but, i dont have time to wait for altera right now, ive got to get this up and running so we can capture data from these DUTs. ill send what i have to altera. if they either correct me or fix a bug, ill post here

thanks