PC <-> S530Dev. Bd. Reg R/W interface?

--- Quote Start ---

Dave - let me ask you something. All I'm really interested in is adding the JTAG-To-avalon-master to my designs. Now that I've been through Qsys, and, as you say, Qsys is just a way to generate RTL, do I really need all the overhead? Why can't I just create my own RTL with a call to the JTAG-To-avalon-master, + my code, and use a QIP file so Quartus can find the avalon component. It seems much easier...

--- Quote End ---

It all seems easy when you have a simple bus architecture with say a single master, and multiple slaves. However, once you get to multiple masters accessing multiple slaves in parallel, the interconnect becomes more complex. For example, when a master accesses a device for a long burst, and another master requests the same device after the first has started its burst, when will the second master get access? What if the second master is supposed to have higher priority than the first?

The advantage then of Qsys and SOPC builder, is that it allows you to specify the master-to-slave relationships and the arbitration (via arbitration shares), and then all the 'glue' logic (bus plus arbitration) is automatically generated.

Another issue with trying to connect Qsys and SOPC Components directly to each other, is that some components to not fully implement their interface in the HDL component. Some of the timing is embedded in the _hw.tcl description file, and that logic gets embedded in the fabric., hence the fabric is an integral part of the master-to-slave design.

The alternative to using the Altera components and Qsys is to build your own JTAG interface using the SLD Virtual JTAG component, and then wire up your masters and slaves yourself. This was what I had been doing until I took a longer look at SOPC Builder. Now I build my own Avalon-MM components such that they can be connected directly, or using SOPC Builder and Qsys.

Cheers,

Dave

Hi Dave - well, I got everything working 8-}. It's been an interesting experience - thanks for your help. So right now I have a somewhat "generic" QSYS output that I can simply modify as my design changes without using QSYS, since the changes will all be in the slave logic. I think it was worthwhile to go through the experience, but unless I'm building the types if things you describe (typically not - we do primarily signal processing), might not crack Qsys again for a while. Thanks for the thoughts.

BTW: I spent a few hours with the system console dashboard widgets today. They're not all that pretty (or well documented), and also seem somewhat buggy (i filed a ticket because the "timechart" sometimes doesn't update until long after the script completes"). We NEED something like this to do pretty demos for our customers. Is there a step up from this interface without going all the way to LabView?

Again - thanks for all your kind help. The Jumpstart was appreciated 8-}

/j

--- Quote Start ---

So right now I have a somewhat "generic" QSYS output that I can simply modify as my design changes without using QSYS, since the changes will all be in the slave logic. I think it was worthwhile to go through the experience, but unless I'm building the types if things you describe (typically not - we do primarily signal processing), might not crack Qsys again for a while. Thanks for the thoughts.

--- Quote End ---

I also work on signal processing systems. I ignored all Avalon-based systems up until the point that I could not avoid them. The IP for using the transceivers on the Stratix IV and V devices have Avalon interfaces inherently built into them for their control and debug, eg. eye-pattern sweep, output voltage swing etc. So, if you start working with ADCs/DACs that use the high-speed transceivers to interface to the FPGA, then you'll have to 'suck it up' and work with Qsys :)

--- Quote Start ---

BTW: I spent a few hours with the system console dashboard widgets today. They're not all that pretty (or well documented), and also seem somewhat buggy (i filed a ticket because the "timechart" sometimes doesn't update until long after the script completes").

--- Quote End ---

I haven't seen these widgets. I guess I did not look for them. They sound like something new in v11.0.

These widgets sound like they are similar to Tcl/Tk widgets.

--- Quote Start ---

We NEED something like this to do pretty demos for our customers. Is there a step up from this interface without going all the way to LabView?

--- Quote End ---

My recommendation would be to separate functional interfaces from user interfaces. The separation can be via DLLs or sockets. For example, make your hardware accessible via read/write over JTAG, and then wrap that with a simple read/write server. The GUI then talks to the read/write server. The advantage of this separation is that the guy programming the GUI just has to prove that he can generate the right read/write sequences to the client. This makes debug a lot easier, and saves tying up your hardware for GUI development.

If you later replace the JTAG interface with a NIOS network interface, then the GUI code does not change, it simply contacts a different server IP; that of the NIOS processor.

--- Quote Start ---

Again - thanks for all your kind help. The Jumpstart was appreciated 8-}

--- Quote End ---

You're welcome!

Cheers,

Dave

Hi Dave - thanks, and yes, I suspect I'll be back in Qsys when we start hooking up the HSMC daughter cards. Your next-to-last paragraph "My recommendation..." rings very true to me about the separation, but I can't quite picture the interface you describe (probably because I'm a HW guy and when you say "DLL or sockets" you're a little past me). Can you give me a little more, albeit still qualitative, idea of how this works? I mean, are we replacing system console with this "R/w server", or is the serrver talking to system console, and (either way), how?

thanks!

/j

--- Quote Start ---

Your next-to-last paragraph "My recommendation..." rings very true to me about the separation, but I can't quite picture the interface you describe (probably because I'm a HW guy and when you say "DLL or sockets" you're a little past me). Can you give me a little more, albeit still qualitative, idea of how this works? I mean, are we replacing system console with this "R/w server", or is the serrver talking to system console, and (either way), how?

--- Quote End ---

The implementation depends on how your GUI would work, but here's one option. Lets say you have a GUI developer that wants to write LabView, here's what you tell him.

1) LabView application with;

a) Monitor points, eg. LED states, DIP switch states, etc.

The LabView application connects to a monitor point server that sends a network packet every 0.5s. The contents of the network packet are the LED state, DIP switch state, etc. You would need to define a binary data format for this information, eg. all data is represented as 32-bit big endian integers.

The monitor points are displayed via GUI elements that to the user are effectively read-only, i.e., they are status GUI elements.

b) Control interface, with commands like, write to LEDs (and read to LEDs)

The labview application sends a binary data packet to the server, and that packet has the command type (an enumeration), followed by command arguments. The server responds with another binary packet containing eg., a status response, followed by any response data.

The control interface is displayed with GUI elements that are interactive, eg. push buttons, toggle switches, check buttons, etc.

2) System console Tcl server application, or NIOS server application

This is the actual interface to the hardware. You create a couple of server threads; one for the monitor server and another for the control server. The monitor server reads all the board status, packs it into the binary format expected by the clients, and then sends the packet every half second. The control servers waits for a command from a client, performs the action (eg. write to the LEDs register), and then sends a response (eg., status ok).

If this server was implemented using System console, the server parts would use Tcl's standard networking functions, the command implementations would use the Altera-specific commands to access the hardware, and then standard Tcl to respond to the labview application. Actually, I recall in Welch's Tcl book, an example where the client just sends Tcl command strings, and the Tcl server simple interprets those strings, eg., lets say your server implements the function 'led_write <value>' using Altera-specific JTAG commands. The LabView client can send a Tcl command string, eg. 'led_write 0x55', and the server can process that command, and then send back an empty string to the client as an acknowledge. In this case, the client-to-server communications for the control server uses ASCII (Tcl commands), not binary.

A fake version of the server can easily be created. The fake server can have an LED register state, fake monitor points generation, etc. You can have a monitor point indicating whether the simulator or real hardware is being accessed.

----

Why split things up like this?

For a start, it makes the software development, maintenance, and testing a lot easier. There is some complexity, in that you have to figure out networking and come up with a network communications protocol, but that knowledge is re-useable across all projects.

It also makes large system designs tractable. For example, I have a system with ~100 signal processing boards (containing ~1000 FPGAs), producing several thousand monitor points, eg. voltages, currents, temperatures, etc. You would not want to have to interactively ask for each monitor point, due to the communications overhead. Having each board send all monitor information every 0.5s makes for a much cleaner system design.

Some of this stuff is discussed in documents here:

http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html (http://www.ovro.caltech.edu/%7edwh/correlator/cobra_docs.html)

Cheers,

Dave

Hi Dave - thanks. A lot to absorb, but I think I can work through it. Sounds like I need to learn a lot about TCL! Of the 3 or 4 'top' books, do you particularly like one for working in this space?

thanks!

/j

--- Quote Start ---

Sounds like I need to learn a lot about TCL!

--- Quote End ---

Altera Quartus, Xilinx ISE, Lattice Diamond, Modelsim, Precision RTL, etc., all use Tcl, so its worth learning it.

--- Quote Start ---

Of the 3 or 4 'top' books, do you particularly like one for working in this space?

--- Quote End ---

Brent Welch, Practical Programming in Tcl and Tk.

(Looks like 4th edition is the latest)

Cheers,

Dave

Agreed - no problem learning TCL - i get the sense it's sort of a mix of C and Perl, and I speak both (love Perl). As for books, I looked at all the top contenders, excerpts, reviews, etc - and actually it looked like Flynt's Developer's Guide was maybe a better choice for me? Lots of people said not to use Welch as a main/first book?

thanks!

/j

--- Quote Start ---

it looked like Flynt's Developer's Guide was maybe a better choice for me? Lots of people said not to use Welch as a main/first book?

--- Quote End ---

I don't have the Flynt book. I do have 'Effective Tcl/Tk programming', McLennan, and 'Tcl and the Tk Toolkit', Ousterhout. I don't really look at them too much any more; unless I'm looking to jog my memory. I'm sure the Flynt book will be just fine. You can always ask for example scripts here.

Caveat; when automating your build scripts, you might find it easier to have a top-level Makefile, and within that make file use Tcl scripts, eg. quartus_<tool> -s script.tcl. Hence, learning both how to use the Tcl APIs and the command-line versions of tools is recommended.

Cheers,

Dave