What is the fastest way of accessing on-chip register contents?

Thanks ted very much. Actually, we have Ethernet port with the boad. As the current implementation has the JTAG-to-Avalon MM master, so I am trying with this option first. Do you think it is possible to have the read operation every several milliseconds (say 20 ms) using this communication? Actually, I just found out the Monitor Commands in System Console that helps determine the read frequency of some specified memory space. I do not know if this can solve my issue or not, just trying now. If you have any experience regarding this, please advice me. Again, thank you.

PLMT

I don't have first hand experience making system-console work "fast" or reliably over long periods of time, like what I think you might be hoping to do. I haven't used the monitor API's, but I can say that master_read_32 is slower than master_read_memory for some tasks.

I was asking about possibly a control port Ethernet being available, because in the past what I have done is to craft a HDL module which pulls together the statistics and encapsulates them in a UDP Ethernet packet, which gets collected on a PC by a simple application.

I have also used a NIOS and a JTAG UART to do "while(1){ printf() }" at fixed period, but this has similar throughput issues as the system-console.

The master_read/write_memory commands are the fastest way to use the JTAG interface. There's SignalTap II traces in here that explain why:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_analysis.pdf

Cheers,

Dave

--- Quote Start ---

The master_read/write_memory commands are the fastest way to use the JTAG interface. There's SignalTap II traces in here that explain why:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_analysis.pdf

Cheers,

Dave

--- Quote End ---

Hello Dave,

Thank you very much for the information you provided. Actually SignalTap II is what I have been using for debugging my design so far. But I think Signal Tap can display the content of signals for some interval, rather than whole test time. So, for the purpose of collecting the statistics stored inside registers, I am using JTAG-Avalon interface, TCL script with master service to read the registers.

To provide some more explanation about my application requirement, I have a 10 Gb/s Ethernet subsystem including two nodes corresponding to two designs running on two different boards. So, this is basically a 10 Gb/s board-to-board communication via SMA cable. During a test, one of the two node (A) changes the data rate and by some way, and by extracting the received data, the other node (B) can detect this change and updates the data rate in a register. The change is happening in several tens milliseconds. Node B then wants to inform some other external controller about the change in A's data rate in runtime that help the controller make some decision. Hence, the external control needs to be able to read the register inside the node B design in a very fast way, in tens milliseconds.

As you just mentioned, master_read is the fastest way to use JTAG interface, what else should I use if I want a faster access method? Do you have any idea about monitor_read_data of monitor service? How about the TCP/IP communication, or through Ethernet interface, in general, which should be the method that is suitable for my purpose?

Again, thank you and look forward to your further advice.

Thanks ted.

I have not used the NIOS II and JTAG UART, but it is good to know that these have same issue with JTAG avalon.

I am really interested in communication between the host PC and the FPGA design using the Ethernet port. Because I want to use the traffic of real application running on a server for the board-to board Ethernet subsystem (more details can be found in my previous post). So, could you please provide some more details about your project, or briefly the procedure for establishing such communication?

Thank you.

--- Quote Start ---

I don't have first hand experience making system-console work "fast" or reliably over long periods of time, like what I think you might be hoping to do. I haven't used the monitor API's, but I can say that master_read_32 is slower than master_read_memory for some tasks.

I was asking about possibly a control port Ethernet being available, because in the past what I have done is to craft a HDL module which pulls together the statistics and encapsulates them in a UDP Ethernet packet, which gets collected on a PC by a simple application.

I have also used a NIOS and a JTAG UART to do "while(1){ printf() }" at fixed period, but this has similar throughput issues as the system-console.

--- Quote End ---

--- Quote Start ---

Actually SignalTap II is what I have been using for debugging my design so far. But I think Signal Tap can display the content of signals for some interval, rather than whole test time. So, for the purpose of collecting the statistics stored inside registers, I am using JTAG-Avalon interface, TCL script with master service to read the registers.

--- Quote End ---

The reference to SignalTap II was not so that you would use it, but that the document *showed* why the master_read/write_memory procedures were faster.

--- Quote Start ---

To provide some more explanation about my application requirement, I have a 10 Gb/s Ethernet subsystem including two nodes corresponding to two designs running on two different boards. So, this is basically a 10 Gb/s board-to-board communication via SMA cable. During a test, one of the two node (A) changes the data rate and by some way, and by extracting the received data, the other node (B) can detect this change and updates the data rate in a register. The change is happening in several tens milliseconds. Node B then wants to inform some other external controller about the change in A's data rate in runtime that help the controller make some decision. Hence, the external control needs to be able to read the register inside the node B design in a very fast way, in tens milliseconds.

--- Quote End ---

Why do you want to change the link lane rate? If the links operate correctly at 10Gbps, then why not just run them at 10Gbps all the time? I wonder whether you are making this more complicated than necessary. For example, if you are sending data over the 10Gbps link, and the data volume changes, then that is ok, there no reason to change the link rate, just send more idle packets.

--- Quote Start ---

As you just mentioned, master_read is the fastest way to use JTAG interface, what else should I use if I want a faster access method? Do you have any idea about monitor_read_data of monitor service? How about the TCP/IP communication, or through Ethernet interface, in general, which should be the method that is suitable for my purpose?

--- Quote End ---

If the 10Gbps links always operate at 10Gbps, then the data plus any meta-data related to the data can go across the same link. Think of TCP/IP, it can support multiple socket connections over the same link. You can do the same thing over a 10Gbps link. You may just have to go to a slightly higher protocol over that link. However, that may be the most appropriate solution.

Now that you have something working, take a step back and think about "what you really want". You may find that you should decouple the transport rate (10Gbps) from the data rate (which is as fast as 10Gbps).

Cheers,

Dave

--- Quote Start ---

Why do you want to change the link lane rate? If the links operate correctly at 10Gbps, then why not just run them at 10Gbps all the time?

--- Quote End ---

By data rate, I meant the real data volume/time unit instead of link rate/link capacity (10 Gb/s). While the link rate is fixed at 10 Gb/s, the system is expected to work with a varying data rate.

For example, if you are sending data over the 10Gbps link, and the data volume changes, then that is ok, there no reason to change the link rate, just send more idle packets.

Exactly this is what I meant.

If the 10Gbps links always operate at 10Gbps, then the data plus any meta-data related to the data can go across the same link. Think of TCP/IP, it can support multiple socket connections over the same link. You can do the same thing over a 10Gbps link. You may just have to go to a slightly higher protocol over that link. However, that may be the most appropriate solution.

Thanks for this hint.

You may find that you should decouple the transport rate (10Gbps) from the data rate (which is as fast as 10Gbps).

Can you clarify this point?

--- Quote Start ---

By data rate, I meant the real data volume/time unit instead of link rate/link capacity (10 Gb/s). While the link rate is fixed at 10 Gb/s, the system is expected to work with a varying data rate.

--- Quote End ---

Ok, that makes more sense.

--- Quote Start ---

--- Quote Start ---

You may find that you should decouple the transport rate (10Gbps) from the data rate (which is as fast as 10Gbps).

--- Quote End ---

Can you clarify this point?

--- Quote End ---

The data you send across the link is not synchronous to the 10Gbps clock, so you must decouple it somehow right? One way of decoupling the data would be to packetize it. Each packet of data samples can be preceded by a header that contains; a timestamp (or packet ID code or incrementing count), a data rate (the thing you are trying to figure out now), and the number of samples to follow in the data payload.

For example, lets say I have an Avalon-ST stream generating 16-bit samples at 100MHz clock rate, i.e., 200MB/s. I could capture a block of this data (using a FIFO or dual-port memory), prepend the header, send it over the link, and then generate a 16-bit 100MHz clock rate data stream on the other side of the link. So long as the Avalon-ST valid signal is used to indicate when samples are valid, the DSP logic on either side of the link should work correctly.

Cheers,

Dave

--- Quote Start ---

I am really interested in communication between the host PC and the FPGA design using the Ethernet port. Because I want to use the traffic of real application running on a server for the board-to board Ethernet subsystem (more details can be found in my previous post). So, could you please provide some more details about your project, or briefly the procedure for establishing such communication?

--- Quote End ---

Here is a link to the frequently cited UDP Offload Example:

http://www.alterawiki.com/wiki/nios_ii_udp_offload_example

You can use it (and it's components) to get your bearings.

Basically, what you want to do is to create a new Qsys component with an Avalon-MM Master port and a state machine to execute the (various) reads to gather and/or compute the statistics you want to communicate to the host.

Then, take that data and encode it into the payload of a UDP packet.

Your new "statistics generator" module is roughly the equivalent of the "PRBS Generator" component shown in the lower left corner of the diagram at the bottom of that page. In the final configuration, you will likely discard most of that block diagram, such that you basically are left with your statistics generator connected to the Ethernet MAC Avalon-ST sink. It all depends on how much/little work you want to do. If you want to explore this approach, I would suggest starting with the UDP Offload Example, and then clone the PRBS Generator block to start crafting your own "Statistics Generator".

On the PC, you just need to write a simple socket utility to receive the UDP packets.

From your previous post:

--- Quote Start ---

Hence, the external control needs to be able to read the register inside the node B design in a very fast way, in tens milliseconds.

--- Quote End ---

Since your timing requirement is not aggressive, if your hardware would support it, you can achieve similar result to the above but with a NIOS and software. I believe 10ms should be ample time for the NIOS to receive an interrupt from your change-of-state notification, then formulate a TCP or UDP message to send to the host PC.

Which route to go basically depends on whether you are a software person or a hardware/HDL person, and whether or not your hardware can support you.