FPGA, SoC, And CPLD Boards And Kits
FPGA Evaluation and Development Kits
5892 Discussions

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

Altera_Forum
Honored Contributor II
3,674 Views

Hi - so I just got my first Altera Development kit (S-IV GX S530). My "hello world" project starts with a tiny user-designed design (i.e. RTL code) that I download to the board that consists of some registers. I want to have a simple PC interface that allows me to read/write these registers on the FPGA on the development board from the PC. It can be a command-line interface (I can later put a GUI on top of it). I'm guessing/hoping that the building blocks for this structure exist and I just have to paste them together. (PC-based USB driver -> USB interface on FPGA, or maybe Rj45 Ethernet?)  

 

Can anyone point me in the right direction? 

 

Much Thanks!  

/j
0 Kudos
33 Replies
Altera_Forum
Honored Contributor II
224 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

 

--- 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
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

ok thanks 8-}

0 Kudos
Altera_Forum
Honored Contributor II
224 Views

Dave, 

 

Jeff and I appreciate your suggestions for interfacing LabVIEW to the System Console. Per your suggestion, I've started down the path of implementing a Tcl server application within the System Console using Tcl's standard networking functions. I've noticed that the "fileevent" Tcl command, which is commonly used for receiving socket data on an event-driven basis, doesn't seem to be recognized by the System Console's interpreter. In your experience, does System Console only support a subset of the standard Tcl commands? We were looking for documentation on which standard commands were supported, but had no luck. Thanks.
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

Hi, 

 

 

--- Quote Start ---  

 

Jeff and I appreciate your suggestions for interfacing LabVIEW to the System Console. Per your suggestion, I've started down the path of implementing a Tcl server application within the System Console using Tcl's standard networking functions. I've noticed that the "fileevent" Tcl command, which is commonly used for receiving socket data on an event-driven basis, doesn't seem to be recognized by the System Console's interpreter. In your experience, does System Console only support a subset of the standard Tcl commands? We were looking for documentation on which standard commands were supported, but had no luck. Thanks. 

--- Quote End ---  

I've noticed that Altera has managed to screw up the System Console Tcl interpreter in other ways too ... 

 

Here's a snippet of code I use to detect the Tcl shell type 

 

# Tool (wish shell) detection set toolname ] if { == 0} { # Toolname starts with 'wish' set tool wish } elseif { == 0} { # Modelsim starts vish.exe # (alternatively argv0 ends in vsim) set tool modelsim } elseif { == 0} { # Quartus also has a global called quartus # that can be detected using . set tool quartus # Quartus shells need to initialize Tk init_tk } else { error "Tcl/tk tool detection failed!" } Start 'quartus_stp -s' and 

 

tcl> info nameofexecutable C:/software/altera/10.1/quartus/bin/quartus_stp.exe tcl> The above code snippet allows the display of Tk GUI elements when using quartus_stp, or the main Quartus GUI. 

 

However, I tried this in SystemConsole (Quartus v10.1) and the result of 'info nameofexecutable' is an empty string! On top of that, the TK widgets don't work (try typing tk_init, or help misc)! 

 

I get the impression that at Altera there are two different software development groups, and neither has bothered to talk to the other to ensure compatibility between tools. 

 

So, my recommendation is to use SystemConsole with caution (I know, I recommended looking at it ... sorry, I was too optimistic). The quartus_stp tool is reliable, but I'm not sure that the SystemConsole commands work there. They can be made to work, its just that I'm not sure that Altera provides a package with the Tcl commands. The majority of USB interfaces I have built up until now have used the Virtual JTAG interface, and I control that via quartus_stp. 

 

All is not lost. I've figured out how to communicate with the USB-Blaster directly from C/C++ code. In the next week or so, I'll finish documenting how to do this, and then I was going to put together a DLL that could be accessed from LabView code. This documentation would include HDL code for USB-to-Avalon-MM masters, so you can replace the components and Tcl interfaces provided by SystemConsole, with something you are free to change. 

 

You're welcome to be a guinea pig for that code :) 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
224 Views

Thanks Dave - we look forward to it! 

/j
0 Kudos
Reply