Problem: JTAG_CLIENT.DLL missing, DE0_Nano_ControlPanel on Windows 8.1, Quartus II 14

[Altera_Forum]

All: 

 I have Quartus II (14) Web Edition installed and working on a Windows 8.1 laptop. Per the DE0-Nano user manual:  the control panel software utility is located in the directory “tools/de0_nano_controlpanel” in the de0-nano system cd. it's free of installation, just copy the whole folder to your host computer and launch the control panel by executing the “de0_nano_controlpanel.exe”.  I therefore copied the control panel files from it's directory to a new folder on my desktop.  The issue is that when I launch DE0_Nano_ControlPanel (either by double clicking, or by navigating directory to its folder in a CMD window and manually launching the EXE file), a dialog appears indicating that JTAG_CLIENT.DLL is missing (see jtag_client_missing.jpg). Dismissing this dialog brings up another error dialog indicating that TERASIC_JTAG_DRIVE.DLL failed (see terasic_jtag_drive.jpg); dismissing that dialog brings up the final error dialog telling me that Quartus needs to be installed (see quartus_installed.jpg). Again, Quartus II (14) is installed and running perfectly.  Searching this forum and the 'net, the only suggestions I could find was to download the latest files from Terasic, which I did; this did not resolve the issue. There was also mention of installing the USB_Blaster(II) driver directly from the Altera installation directory (c:\altera\14.0\quartus\drivers in my case). (I tried both the USB_Blaster and USB_Blaster ii drivers; only the first would actually install. This did not solve the issue.)  Finally, here is a listing of the files in my control panel directory (see files.jpg).  Running out of options, I tried copying the jtag_client.dll file in the Altera installation directory to the control panel directory; this did not solve the problem. I also tried copying the three TERASIC_*.DLL files into the Altera directory (various places that seemed to make sense, like bin64), but this also did not solve the issue.  Any help/direction/suggestions would be greatly appreciated!  Dave  ------------ EDIT: Sep 1, 2014  This has really been bugging me since I encountered it, so I decided to use the sysinternals procmon utility to find out exactly what was going on with de0_nano_controlpanel. After some tracing/debugging, I confirmed that jtag_client.dll was not being read - or at least that's what it looked like (in spite of the copy I placed in the same directory).  A little more debugging (with the dependency walker utility) revealed the real problem: all the dlls supplied from terasic are 32-bit. While these will "run" on my 64-bit Windows 8.1 laptop, they were implicitly looking for the 32-bit version of jtag_client.dll. At that point, I thought I had it solved: simply copy the 32-bit version of jtag_client.dll from Quartus instead of the 64-bit version (which I what I did initially).  However, copying the 32-bit version of jtag_client.dll from the C:\Altera\14.0\quartus\bin32 Quartus install did not solve the issue. While there are no longer any missing DLL messages, DE0_Nano_ControlPanel still thinks that Quartus is not installed!  My theory is that there is a fundamental incompatibility between Terasic and Quartus in the way that the former checks for the latter. Since Quartus no longer supports 32-bit operation on Windows, this seems a likely scenario: DE0_Nano_ControlPanel is still looking for the 32-bit version of Quartus which, of course, it won't find.  terasic: I've done the initial debug/QA for you regarding Win 8.1, 64-bit installs: when will you get around to fixing this? So far I'm definitely not impressed with your QA or the paucity (absence, really) of information regarding this defect on your site.  Dave   ------------ EDIT: Sep 2, 2014  I thought last night about trying one last "fix", namely trying to determine how it is that DE0_Nano_ControlPanel attempts to determine whether/where Quartus is installed. If I could get that, maybe DE0_Nano_ControlPanel could be convinced that Quartus is actually installed.  Using ProcMon once again, I found that DE0_Nano_ControlPanel checks the Windows registry for two values: HKLM\Software\Wow6432Node\Altera Corporation\Quartus  Quartus Install Directory REG_SZ C:\Altera\14.0\quartus  Quartus Version REG_SZ 14.0   (my install is at c:\altera\14.0\quartus, as shown.)  Since these registry values don't exist, I manually added them, supplying the values to match my installation (as shown). ProcMon showed that these satisfied the control panel app, relative to the question as to where Quartus was installed; unfortunatly, there is still a problem.  Once the DE0_Nano_ControlPanel has determined the Quartus install location, it attempts to launch:  C:\Altera\14.0\bin\quartus_pgm.exe  For a normal install of Qaurtus II 14.0, there are only the bin32 and bin64 subdirs under the quartus folder; there is no bin subdir.  It is evident that DE0_Nano_ControlPanel insists on finding a "native" 32-bit app on a 32-bit Windows system. I was fairly sure that it wouldn't work (and it didn't), but I thought I'd try one more test:  I created a bin subdir under quartus, then found (the only) copy of quartus_pgm.exe available (a 64-bit), and copied it to the new bin subdir that I just created. In fact DE0_Nano_ControlPanel found and launched it, but it is not compatible.  So, as the old saying goes: "You can't get there from here." It is evident that the registry trace shows conclusively that DE0_Nano_ControlPanel is "stuck" in the 32-bit world and can't be fooled or forced to work in the Win 8.1 64-bit world until Terasic decides to fix it and bring their small app into the 21st century.  As "CalTech" Dave correctly points out (below), the Nano can still be used to test new HDL designs (by direct download), so the Nano isn't by any means a waste.  It is, however, a disappointment that Terasic hasn't spent the extra 2 or 3 days of SW dev effort to get the app built for 64-bit compatibility, especially for the sake of the newbs (as I am) attempting to use their product to enter the world of FPGA development. There is nothing more frustrating to purchase a product that purports to work, only to find (after a lot of effort and time) that a SW component of it can't work on my Win 8.1 64-bit laptop - and that with absolutely no warning or assistance from the manufacturer!  terasic: are you listening??  Dave

[Altera_Forum]

In my experience the close-source example GUIs provided with the kits only work with specific installations of Quartus under specific versions of windows. They're nice to use to confirm that the hardware works out-of-the-box, but since they do not supply the source code, they're not much use in the long run. 

 What did you want to do with your DE0-nano? I've posted a couple of example designs in some other threads, eg.,  A basic design: http://www.alteraforum.com/forum/showthread.php?t=45748&page=2  An SDRAM design: http://www.alteraforum.com/forum/showthread.php?t=45927  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  What did you want to do with your DE0-nano?  --- Quote End ---    Dave:  The idea in purchasing the nano was to prove a design for a new product that I'm developing now (probably for the Cyclone IV). (My VHDL model is looking very good.) Everything in the manual (and generally on the web related to the nano) supposedly supports that assumption. :(  From my experience in writing lots of code for the Windows API, this seems to be a PATH issue, but I haven't been able to figure out what PATH values are needed where. I really expected more from what looks to be a very professional implementation from Terasic, but maybe this is typical?  It could also be a USB driver issue, but that also I've not be able to confirm.  Thanks. Dave

[Altera_Forum]

Dave: (I just replied, but it seems to have disappeared...) 

 Thanks for your quick reply. I purchased the nano to prove a new design (probably for the Cyclone iV). The simulation and timing both look good; I'm really ready to test it.  I hope that someone from Terasic looks at this post as well, because I really was expecting something better from a company that at least looks like it did a good job implementing the nano. So far, the reality is disappointing. I can continue work on my model, but not being able to test on hardware is going to become critical soon.  Dave

[Altera_Forum]

--- Quote Start ---   but not being able to test on hardware is going to become critical soon.   --- Quote End ---   Why do you think you cannot test your hardware? The control panel only lets you run the closed-source GUI. The hardware has a JTAG interface, and you are free to do whatever tests you like.  Cheers, Dave

[Altera_Forum]

Dave: 

 Ahhh... Being a newb with the nano, I think I now understand what you're saying: I should be able to talk directly from Quartus II to the nano via the Altera USB_Blaster driver (I think that's the correct one) to download my design, and simply not bother with the controlpanel app. That is, the driver will supply the JTAG interface to program the Cyclone IV, correct?  I'm completing the VHDL edits for a new feature right now, so it will be a short time before I can test this.  Dave

[Altera_Forum]

--- Quote Start ---   Ahhh... Being a newb with the nano, I think I now understand what you're saying: I should be able to talk directly from Quartus II to the nano via the Altera USB_Blaster driver (I think that's the correct one) to download my design, and simply not bother with the controlpanel app. That is, the driver will supply the JTAG interface to program the Cyclone IV, correct?   --- Quote End ---   Yes, exactly.    --- Quote Start ---   I'm completing the VHDL edits for a new feature right now, so it will be a short time before I can test this.   --- Quote End ---   Great!  Since you're new to FPGAs, I'll provide a warning; do not download to your board until you confirm that your pin assignments are correct. If you screw it up, and create driver conflicts, then you risk damaging your board. You can also damage the board by connecting it to incompatible voltages, eg., 5V logic.  The example designs I linked to above have a top-level design entity that includes every single defined pin on the DE0-nano schematic. Look at the two designs and compare what I did to the unused pins, eg., in the basic design the SDRAM pins are statically driven to valid values, whereas in the SDRAM design, the pins are connected to an SDRAM controller.  The DE0-nano has a built-in USB-Blaster. If you want to test your VHDL, then you'll want some way to "look" inside the FPGA. You can do that using the USB-Blaster (I can give you links for that too).  Ask questions here on the forum and you'll get plenty of help.  Cheers, Dave

[Altera_Forum]

Dave: 

 Yes, I remember reading something about ensuring the pin assignments are correct.  I didn't realize the designs you posted were explicitly for the nano - thanks much for the consideration and foresight! Having known-good samples is really useful; I'll be reviewing them in the morning. While it's been a very productive day, my mind now is mostly mush, so I'm calling it a day.  Thanks so much for your attention and help! Dave

[Altera_Forum]

--- Quote Start ---   Yes, I remember reading something about ensuring the pin assignments are correct.   --- Quote End ---   Its better to remember now, rather than after your I/O pins stop working, or you smell burning electronics ...    --- Quote Start ---   I didn't realize the designs you posted were explicitly for the nano - thanks much for the consideration and foresight! Having known-good samples is really useful; I'll be reviewing them in the morning. While it's been a very productive day, my mind now is mostly mush, so I'm calling it a day.   --- Quote End ---   You can synthesize the examples and download them to your board and they'll work fine. You can then start looking at them to figure out how they work. The SDRAM design includes a JTAG-to-Avalon-MM bridge so that you can read and write to the memory from your PC via JTAG. That same interface can be used to access/test your custom VHDL component.  Cheers, Dave

[Altera_Forum]

Dave: 

 Wow - that TCL script is pretty handy and worked first time! Really impressive!  Ok, I've sucessfully downloaded your basic program into my nano, and it works well. There was a single curious item: my first attempt (Start...) failed. I tried the other modes, of which only passive serial was available, and it failed as well. I then tried JTAG again, and it programmed immediately; the LED counter ran as expected.  I've reviewed the code, and as you mentioned, it is pretty rudimentary but very easy to comprehend. What I'll continue to review this morning is your SDC file and how to define the pins assignment/layout (something that I'm not yet familiar with). (It is obvious that I need to add TCL to my programming languages. I've noticed that it is the programming language in Quartus, so it makes sense to learn it as well.)  Oh, one other short note: I'm not really new to FPGA devices and programming. My first design (a pair of Xilinx FPGAs) was done in the late '80s and a second design (can't remember if it was one or two Xilinx devices) was done in the early '90s. Of course, the tools have improved dramatically since then! I'm simply trying to catch up on the new stuff ala Altera.  Thanks so much for the work that you put into these samples/templates! They both are very useful to me now. If you are ever in Plano, TX, I owe you lunch!  Dave

[Altera_Forum]

--- Quote Start ---   Wow - that TCL script is pretty handy and worked first time! Really impressive!   --- Quote End ---   I'm glad it made your learning easier :)  If you ever need to figure out what Tcl command to use relative to a Quartus GUI setting, you can create a Tcl file from the current project settings via Project->Generate Tcl file for Project.  In fact, I recommend doing that with the 'basic' project you just synthesized, then compare that single Tcl script to the constraints.tcl and synth.tcl scripts, and you'll be able to see how the Tcl is separated into common code in constraints.tcl and project-specific code in synth.tcl. The format of the pin constraints in constraints.tcl is made more compact using Tcl lists for the assignments that belong to one pin. This format was inspired by the Xilinx UCF format, since its less verbose than the Altera format.    --- Quote Start ---   Ok, I've sucessfully downloaded your basic program into my nano, and it works well. There was a single curious item: my first attempt (Start...) failed.   --- Quote End ---   I've noticed this under Windows 7. My guess is that the Altera JTAG server and driver interface is screwy.    --- Quote Start ---   I tried the other modes, of which only passive serial was available, and it failed as well. I then tried JTAG again, and it programmed immediately; the LED counter ran as expected.   --- Quote End ---   The USB-Blaster is essentially a USB to digital I/O controller. It can communicate to the JTAG header on an FPGA board, or the Active Serial header on an FPGA board. The USB-Blaster hard-wired on your DE0-nano can only speak JTAG-mode, so that is the only appropriate mode to use.    --- Quote Start ---   I've reviewed the code, and as you mentioned, it is pretty rudimentary but very easy to comprehend. What I'll continue to review this morning is your SDC file and how to define the pins assignment/layout (something that I'm not yet familiar with). (It is obvious that I need to add TCL to my programming languages. I've noticed that it is the programming language in Quartus, so it makes sense to learn it as well.)   --- Quote End ---   Ask questions, and I'll answer them.  Altera, Xilinx, Lattice, and Mentor's tools can all be scripted with Tcl, so its worth learning.    --- Quote Start ---   Oh, one other short note: I'm not really new to FPGA devices and programming. My first design (a pair of Xilinx FPGAs) was done in the late '80s and a second design (can't remember if it was one or two Xilinx devices) was done in the early '90s. Of course, the tools have improved dramatically since then! I'm simply trying to catch up on the new stuff ala Altera.   --- Quote End ---   They've added lots more features to FPGAs since then; DSP blocks, PLLs, memory, ARM cores, etc. The data sheets have got a lot longer!!!    --- Quote Start ---   Thanks so much for the work that you put into these samples/templates! They both are very useful to me now. If you are ever in Plano, TX, I owe you lunch!   --- Quote End ---   Mmmm, Texas barbeque ... sounds tasty :)  Cheers, Dave

[Altera_Forum]

Dave: 

 Your constraints.tcl script is a huge time-saver. It must have taken a few hours to put it together.  Ok, after reviewing your script and the Pin Planner tool I can see how your script defined the pins (because everything matches). However, I have a follow-on question: how do you distinguish in your script the difference between input and output pins? Specifically, I'm looking at the script for the accel_csN and accel_int pins (as an example):   set pin(accel_csN) {PIN = G5, IOSTD = "3.3-V LVTTL", DRIVE = "MAXIMUM CURRENT", SLEW = 2}  set pin(accel_int) {PIN = M2, IOSTD = "3.3-V LVTTL", DRIVE = "MAXIMUM CURRENT", SLEW = 2}  The Pin Planner shows accel_csN as an output, while accel_int is an input, yet your script appears to define them identically. (The adc_xxx pins show a similar trait, for example.)  How is the direction (input, output, or bidir) actually specified in the script? What did I miss?  Thanks, Dave

[Altera_Forum]

--- Quote Start ---   Your constraints.tcl script is a huge time-saver. It must have taken a few hours to put it together.   --- Quote End ---   The way I create this script for a new board is;  1. Use the board vendor "golden reference design" and export its project Tcl file.  2. Cut-and-paste the relevant settings into my custom Tcl, and reformat the pin assignments.  3. Manually check the FPGA pins in the schematic and the VCCIO bank assignments (the most time consuming aspect)    --- Quote Start ---   Ok, after reviewing your script and the Pin Planner tool I can see how your script defined the pins (because everything matches). However, I have a follow-on question: how do you distinguish in your script the difference between input and output pins? Specifically, I'm looking at the script for the accel_csN and accel_int pins (as an example):   set pin(accel_csN) {PIN = G5, IOSTD = "3.3-V LVTTL", DRIVE = "MAXIMUM CURRENT", SLEW = 2}  set pin(accel_int) {PIN = M2, IOSTD = "3.3-V LVTTL", DRIVE = "MAXIMUM CURRENT", SLEW = 2}  The Pin Planner shows accel_csN as an output, while accel_int is an input, yet your script appears to define them identically. (The adc_xxx pins show a similar trait, for example.)  How is the direction (input, output, or bidir) actually specified in the script? What did I miss?   --- Quote End ---   You didn't miss anything. This is probably a copy-and-paste issue. The pin direction is defined by the top-level VHDL file, which in turn is defined by the "intention" in the schematic. An input signal does not need the drive and slew settings, so that is the copy-and-paste error.  The constraints.tcl settings ideally result in Quartus synthesizing the design without any "missing" pin constraints. Delete the drive and slew rate settings on an output that is used in the design (eg., the LEDs), re-synthesize the design, and you'll see the missing constraints messages.  Cheers, Dave

[Altera_Forum]

I run into the same issue when trying to run DE0_Nano_ControlPanel. Google search led me here. My issue resolved after consulting Terasic support. The cause as you have already know is trying to run 32-bit application with 64-bit Quartus installation. The solution is to recreate a 32-bit environment for DE0_Nano_ControlPanel. Terasic support sent me the original EXE and supporting dll needed to run the 32-bit ControlPanel. Following is the list of additional files needed. You should be able to find them under older version Quartus/bin directory. 

 

• jtagmaxprog.exe  
• jtag_atlantic.dll  
• jtag_client.dll  
• msvcp100.dll  
• msvcr100.dll  

  Just copy these files to the same directory of DE0_Nano_ControlPanel.exe. Hope that it helps.  Dan