Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

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

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

13 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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