Forum Discussion
Altera_Forum
Honored Contributor
11 years agosystem console, external memory, multiple masters
Hi guys
Im fairly new here. Im working with a cyclone V GX board and have used qsys to add a memory controller in my nios code to control some lpddr memory on the eval board. Im using system console to write some values to the memory, but i notice that system console finds 2 masters: the memory and the nios. I can use system console to write to the memory using the valid address values that qsys assigned, but i need to use the master assigned to the memory (not nios). My problem is that i need nios to access what i write to external memory. In my nios code, i try read that same valid address that points to my lpddr memory, but its not the same as what i wrote with system console. I was under the impression that the "avalon memory master" would take care of letting nios see that memory. Am i missing something in my qsys system? Im trying to learn everything at once :) Can you guys help me understand what i need to do? I can post code/screenshots if needed thanks!!!!47 Replies
- Altera_Forum
Honored Contributor
--- Quote Start --- Do you have any experience with bytesteam in system console? --- Quote End --- A bytestream is simply an Avalon-ST interface. The NIOS II does not have one of those. If you are using a NIOS II, why not use an interrupt from your device as the trigger? The NIOS II processor interrupt service routine could then decide to read from some location. Cheers, Dave - Altera_Forum
Honored Contributor
Hi Dave
Ive read for the last couple days on this. I wanted to have "something" before i came back and bugged you. For the sake of discussion here, Im an "Altera idiot." Ive managed to get the qsys spi nios working, and can use system console to load memory contents, but the for rest of the Altera universe, i know very little. So, im open to suggestions... Heres what i need: a host side sw-driven way to trigger the nios/spi to send out data to my DUT. My DUT cant init the interrupt. I would imagine that the only "sw-driven interrupt" that i could init from the host to trigger the spi transmission would be some kind of uart transmission. I implemented something in my nios code: char* msg = "Detected the character 't'.\n"; FILE* fp; char prompt = 0; fp = fopen ("/dev/jtag_uart_0", "r+"); //Open file for reading and writing if (fp) { printf("uart has been opened"); while (prompt != 'v') { // Loop until we receive a 'v'. prompt = getc(fp); // Get a character from the JTAG UART. printf("char received %c\n", prompt); if (prompt == 't') { // Print a message if character is 't'. fwrite (msg, strlen (msg), 1, fp); } // if (ferror(fp)) {// Check if an error occurred with the file // pointer clearerr(fp); // If so, clear it. // } fprintf(fp, "Closing the JTAG UART file handle.\n"); fclose (fp); } } and it sat there waiting for a trigger, but when i used the bytestream example in system console set bytestream_index 0 set bytestream [lindex [get_service_paths bytestream] $bytestream_index] set claimed_bytestream [claim_service bytestream $bytestream mylib] # Send FeedbackTo specify the outgoing data as a list of bytes and send it through the opened service: set payload [list 1 2 3 4 5 6 7 8] bytestream_send $claimed_bytestream $payload it failed to claim the service. I got curious and stopped the nios processor, and i could then claim the service and send the data. But of course, my nios wasnt running. Restarted the nios and it froze up. Then i tried just monitoring the uart status byte while (!(uart_status = IORD(JTAG_UART_0_BASE, 2) & 0x40)); but got similar results when trying to use system-console I tried looking at using the nios2-terminal to send data over the uart, but after i enter "nios2-terminal", and hit enter, it just freezes up. Cant enter characters or do anything. Have to kill it with cntrl-c So heres some questions for you: 1)Seeing as how i need the host to generate the interrupt/trigger, is there something better than the uart to accomplish this? Can you show me an example? At this point, id even settle for having nios monitor some led or something and have host set the led... 2)Is there a way for both the system console and the nios to share the uart? 3)Is there a better tool to use on the host side to generate the interrupt (other than system console)? thanks! - Altera_Forum
Honored Contributor
Lets take a step back first ...
You said you are using a Cyclone V GX board. What development board are you using (provide a link if you can)? What do you *actually* want to do, i.e., describe it in general, rather than the specific implementation you've decided upon. Chances are the development kit has other interfaces you can use, so that you're not trying to do too many things via JTAG ... which as you've discovered is not entirely bug free or as general purpose as "marketing" claims :) Cheers, Dave - Altera_Forum
Honored Contributor
Hi Dave
This is what i have Cyclone V GX Starter Kit http://www.terasic.com.tw/cgi-bin/page/archive.pl?language=english&no=830 I have a DUT that communicates via SPI protocol. We need a host interface to this to send the SPI command words (65K+ 32bit words) and collect the response from the DUT and transfer back to host PC for processing What i have done so far: qsys generated SPI core that works perfectly with our DUT. I can implement a subset of commands and the DUT responds correctly. small nios c program to format the instructions to spi and save response from DUT and store into 32bit words i have used the master_read_to_file over system console to read back these 32bit words back to host, analyze in matlab and it looks correct. i can use the master_write_from_file over system console to write my memory but it does interfere with the current nios mem polling/triggering, same goes for the master_write_memory What i need to do is take this small scale subset and scale up to met full transfer to/from DUT. So i need to move 65K+ (or more) 32bit instructions to memory (every once in a while, the instructions may change. so this process can be slower, but not snail pace) I liked your master_write_memory suggestion vs master_write_32. that sped things up to be around 10 seconds. this is acceptable if worst comes to worse, i can try to cram everything i need into a mem init hex file and load that at power up, but the formatting/checksum algorithm has kept me from trying this yet. besides, id rather be able to dynamically load new instructions as needed. the SPI transfer to DUT must be decently fast. im confident i can get that up to speed. right now, its slow because i was debugging the transfer and never sped it up. This SPI transfer will happen multiple times per test based on changing test conditions. So i envision nios code running in a loop and being triggered by the host after test conditions are set up. instructions in memory need not change every time and probably wont. but the captures need to be fast 1-2 seconds if possible Thats where im getting stuck. I really dont care how the SPI transfer gets initiated as long as its by the host pc and eventually controlled by sw. Everything but this triggering is working. Im open to suggestions. id rather learn to do this stuff correctly the first time than try to replicate bad design after bad design thanks!! - Altera_Forum
Honored Contributor
--- Quote Start --- This is what i have Cyclone V GX Starter Kit http://www.terasic.com.tw/cgi-bin/page/archive.pl?language=english&no=830 --- Quote End --- Ok, thanks. Note that this kit has an FTDI FT232R USB-to-UART device. Unfortunately the device is not an FTDI USB-to-FIFO device which are faster, however, according to the FT232R data sheet, the UART can be operated at 1Mbaud or perhaps 3MBaud. You can use this interface to communicate with your NIOS II processor, rather than using the JTAG port. Leave the JTAG port for use by SignalTap II and SystemConsole (if you even need to use SystemConsole - the NIOS II processor should be sufficient). --- Quote Start --- I have a DUT that communicates via SPI protocol. We need a host interface to this to send the SPI command words (65K+ 32bit words) and collect the response from the DUT and transfer back to host PC for processing --- Quote End --- So why use an FPGA? An FTDI cable or a microcontroller can be used to do this? --- Quote Start --- What i have done so far: qsys generated SPI core that works perfectly with our DUT. I can implement a subset of commands and the DUT responds correctly. small nios c program to format the instructions to spi and save response from DUT and store into 32bit words i have used the master_read_to_file over system console to read back these 32bit words back to host, analyze in matlab and it looks correct. i can use the master_write_from_file over system console to write my memory but it does interfere with the current nios mem polling/triggering, same goes for the master_write_memory What i need to do is take this small scale subset and scale up to met full transfer to/from DUT. --- Quote End --- Ok. I would recommend changing over to using the USB-to-UART to transfer the data directly to the NIOS II processor. I have not used the Qsys UART core, so have no idea of how good the performance is. However, you do have an FPGA, so even if the UART does not meet your requirements, you can easily write an interface that does. --- Quote Start --- So i need to move 65K+ (or more) 32bit instructions to memory (every once in a while, the instructions may change. so this process can be slower, but not snail pace) --- Quote End --- Using the USB-to-UART this will take 65 x 1024 x 32b / 1Mbaud = 2.1 seconds. Is that fast enough? The USB-to-UART devices are much faster, as is the MPSSE mode, so you could always use the GPIO connectors if you needed a faster transfer rate. Given that you are using a development kit, I'd argue that you just "use what you've got", and improve that interface on any final design you implement if you decide you need a faster transfer rate. --- Quote Start --- I liked your master_write_memory suggestion vs master_write_32. that sped things up to be around 10 seconds. this is acceptable --- Quote End --- In that case, 2 seconds would be a further improvement :) --- Quote Start --- the SPI transfer to DUT must be decently fast. --- Quote End --- That is totally dependent on your signal integrity. If you're using the GPIO pins to communicate with your DUT, then you'll need to check the SPI signals for signal integrity using a scope. --- Quote Start --- This SPI transfer will happen multiple times per test based on changing test conditions. So i envision nios code running in a loop and being triggered by the host after test conditions are set up. --- Quote End --- I don't see a need to trigger the NIOS II processor. If you consider the NIOS II processor your "server" and it listens on its serial port, then you send it a command to update the SPI data, followed by the 65K x 32-bit samples. The processor can then initiate a new test, or if you like, you can have another command to start the test. Since the board has memory, you could use the UART to send multiple test vectors to memory, and then have the NIOS II select and use one of the test vectors. --- Quote Start --- I'm open to suggestions. id rather learn to do this stuff correctly the first time than try to replicate bad design after bad design --- Quote End --- Let me know what you think of the above suggestions. Cheers, Dave - Altera_Forum
Honored Contributor
Hi Dave
To answer your questions: We will be adding a few more interfaces to this code and it just made sense to minimize the HW if possible. We do have one of those little usb spi cables and ive used that in the past to talk to another dut. not sure of the maker, but i do remember downloading the FTDI drivers. it worked well, but again, we are just looking to do much more. this is me getting my feet wet with fpga. this should be "easy," but being so new, it adds to the learning curve. Ok, on to the last 24 hours: I realize that what is instantiated in my qsys is the jtag_uart. Ive read that i cant use putty etc to talk to this jtag_uart. I can only use nios2-terminal (which is corrupt on my 14.1 install...14.0 works ok) or Altera Monitor (which doesnt work on 14.1) or i can actually use the "nios2 console" window inside the Eclipse IDE (didnt realize that when i was trying to use system console. so i closed the console and nios2 console tabs in eclipse and went back to sys console and was able to use bytesteam to send some chars, but its not full duplex...cant see the response from nios printfs) So the big questions i have: After further reading, i see the jtag_uart is not the same thing as the usb-uart you use. I see a uart (rs232) in qsys. I see that you configure the baud rate inside qsys to 115k bits. Not exactly the 1MBps speed. How would i create and use the usb-uart interface? What tools do you use to interface with usb-uart? Putty? How do i use this to move massive amounts of data through the usb-uart? one character at a time or is code to take entire files or big chunks and push it through? Again, Dave, thank you for all your help! - Altera_Forum
Honored Contributor
--- Quote Start --- just made sense to minimize the HW if possible. --- Quote End --- Once you've debugged your system, you can decide whether to use just a USB cable to the USB-to-UART interface, or just a cable to the USB-Blaster. Ultimately you'll only need one cable per board. However, while developing, it makes sense (to me) to use the USB-to-UART for NIOS II communications, and the JTAG interface for debug tools. --- Quote Start --- We do have one of those little usb spi cables --- Quote End --- You don't need it just yet. Start with the USB-to-UART that exists on your board. --- Quote Start --- I realize that what is instantiated in my qsys is the jtag_uart. --- Quote End --- Right, so change that for a regular UART, and you should be all set! --- Quote Start --- Ive read that i cant use putty etc to talk to this jtag_uart --- Quote End --- Right, because its not really a UART, its the JTAG interface polled by Altera's software, so its not really an "Asynchronous" interface in any way at all. Its a simple interface that is suitable for simple tests. Since you want to also use SignalTap II and SystemConsole, you're probably asking a little too much of the JTAG port. --- Quote Start --- How would i create and use the usb-uart interface? --- Quote End --- Read the Qsys documentation for the NIOS II UART. The USB-to-UART is *already* part of your board. You just need to connect the Qsys TXD and RXD wires to the top-level pins. --- Quote Start --- What tools do you use to interface with usb-uart? Putty? --- Quote End --- I use Tcl/Tk, exactly what you use now for SystemConsole access. You can use SystemConsole, or since the UART is a separate USB device, you can use ActiveState ActiveTcl. --- Quote Start --- How do i use this to move massive amounts of data through the usb-uart? one character at a time or is code to take entire files or big chunks and push it through? --- Quote End --- Write a large buffer. Here's some code ... I'm writing it directly into the forum, so it might be buggy, but it'll give you something to work with ...
Rather than printing a message, you could read a file into a buffer, and then write the file. The annoying thing about your board is that there is no RTS/CTS handshake on the UART interface, so its quite possible you could lose data. You'll have to test and see. Cheers, Dave# Open the serial port for buffered line access set portname "\\\\.\\COM5" puts "Open serial port" set fd fconfigure $fd -mode 115200,n,8,1 fconfigure $fd -buffering line # Write a line puts $fd "Hello world!" # Read the response set response puts "Response: $response" # All done! close $fd - Altera_Forum
Honored Contributor
Hey Dave
I got pulled off on something else and am getting back to this. I was able to use the eclipse ide niosII console to use the jtag_uart to send data to nios and nios interprets it correctly and performs the operation i specify. But im having issues with the bytestream service in system console and nios terminal (working on that in parallel with altera), so i switched gears to the usb-uart. I have implemented the usb-uart and instantiated it in the top level as you instructed. Im having issues with getting either putty or system console (using a variation of your tcl code above) to communicate with the nios. Im using this code in my nios: fp = fopen ("/dev/uart_0", "rw+"); //Open file for reading and writing while(1) { printf("waiting for trigger...Send 't' for trigger\n"); if (fp) { //char prompt = 0; char *prompt = NULL; printf("uart has been opened\n"); while (strcmp(prompt,"t") != 0) //while (prompt != 't') { //prompt = getc(fp); // Get a character from the UART. //string prompt = gets(fp); //printf("char received %c, but need a 't' to proceed\n", prompt); printf("string received %s, but need a 't' to proceed\n", prompt); } } } Again, it works with the jtag_uart, so i would think transitioning to the usb-uart would be fairly straightforward. Inside the nios ide bsp_editor, ive tried every combination of stdin/out/err, switching between jtag_uart, uart_0 and none. Using putty, the characters that are printed from reading the com port are messed up. special ascii chars and such. Its like the encoding or interpretation is wrong. Ive tried a few solutions on the web, but none helped. Some questions for you: 1)Seems like there are many different ways to access the uart data. ive seen gets, scanf, and several altera specific macros like altera_avalon_uart_rxData. Is one way better than the other? 2)Is the data held in a uart buffer until i read it? using something like altera_avalon_uart_RXData would imply that it is. but maybe without flow control, that is not possible and polling is needed? 3)Do i need to check status register of the uart before trying to read it? 4)Any ideas on the funny characters being printed out to putty? thanks Dave!!! - Altera_Forum
Honored Contributor
--- Quote Start --- 1)Seems like there are many different ways to access the uart data. ive seen gets, scanf, and several altera specific macros like altera_avalon_uart_rxData. Is one way better than the other? --- Quote End --- Try to use stdio function, eg., gets or getline. If Altera have implemented their stdio layer correctly, this should work. --- Quote Start --- 2)Is the data held in a uart buffer until i read it? using something like altera_avalon_uart_RXData would imply that it is. but maybe without flow control, that is not possible and polling is needed? --- Quote End --- The UART has hardware buffering, and the stdio library should also have buffering. --- Quote Start --- 3)Do i need to check status register of the uart before trying to read it? --- Quote End --- You should not be programming the UART at all. This should be taken care of by the stdio layer. --- Quote Start --- 4)Any ideas on the funny characters being printed out to putty? --- Quote End --- No. I'd start by simply printing strings from NIOS II, eg., "Hello World!" and perhaps the alphabet. If you see non-ASCII characters, then I'd suspect your UART baud rate is wrong. Cheers, Dave - Altera_Forum
Honored Contributor
I suspected the baud rate and slowed it down from 115200 to 9600 baud. I changed this in both qsys and putty. I dont think i need to change this anywhere else, correct? the ftdi chip layer would be transparent, right? And, wouldnt need a specific rate.
I have tried printing constant string as you suggested without much luck. Please let me know if you have any ideas. ill keep trying :)