Hello community!
This is my first time posting here on Intel forums. So I will introduce shortly my affiliation with the Quartus software:
I've started to use Quartus when it was still Altera, back in 2008 when I bought my first Altera starter kit through Terasic. It was the Altera Cyclone III starter kit. Before that time I've worked with Xilinx before and used Xilinx way back in my school project. After my purchase I began to notice that there were some problems with getting the USB blaster to work. Initially it worked on my system just fine in 2008, I had been able to download my circuits into the starter kit. A while after, the USB blaster was not recognized and ended up thinking that the start kit USB circuitry might have been damanged. I didn't throw it away, I just stored it somewhere. Back then the quartus version numbering was around 7. Every once a few months I would take a look for a newer version, download it when a new version was available to find out whether in this version the driver signature issue with the USB blaster had been fixed or not. Note that I am a hobby user, I work in software development, though my education has been largely digital hardware, including programmable logic.
With the driver issue back then I noted something during the times between 2008 and somewhere 2013 I think of trying to get to work the starter kit. The conclusion after browsing tons of user comments and issues on the Altera forums was that the USB driver issue ultimately did not have an exact, reproducable cause towards failure. Discussions were always about "which OS, which version" etc. Same deal with the different Quartus versions. And the users going back and forth versions to then see the driver magically work again in the Quartus version that it didn't work with before. As a software engineer I would conclude that the failure is erratic, intermitent and not reproducable despite of so many user comments surrounding the problem. And thus, impossible to narrow down and home in to the exact causal path of failure. I finally gave up trying to use my starter kit, though I would occasionally run the Quartus software to satisfy my digital design pet projects and ideas and simulate them - without bothering to live test it with the starter kit.
Here comes 2019. Due to events in my life I had gained a need to validate sonic reality. (the world of sound). And I had another requirement: No pc. No OS. No software-stack. No CPU. This requirement for my plan was very conscious decision which shows later on in this post. So, what was the design plan? A simple audio recorder that would at the same time display the audio wave over time (slow scrolling) and show what audio typically looks like (what sound samples look like in wave editors, music programs etc.). Beyond this design plan I had another thought. If I am going to buy an FPGA starter kit that would facilitate both audio and video IO, have some memory and other useful periphery, I wanted to make sure I would get a board that would allow me to have fun with it byeond this for now momentary need to validate sonic reality. I like retro computing and getting a retro computer to work on a starter kit capable of running such, would be the fun requirement. And so, I legitimized buying myself a Cyclone V GX Starter Kit both for the short term and long term purpose. The Quartus version at that time available was version 18.
Wel, the starter kit arrived and it didn't take long to get things to run. Upon first installing Quartus 18 I noted something wonderful when it got to the USB Blaster driver installation. Given the previous experiences this was a pretty long fingers crossed moment up until this point. What I saw was the WIndows question about whether I wanted to install the USB Blaster driver. Yes, I use UAC at default settings consciously. I was full of glee when seeing this, realizing the purchase didn't turn our sour and instead let me end up with a working starter kit. I was happy and thought stuff like "Intel finally got the driver signed and registered with Microsoft or something, about bleeping time!"
One guess as to what was the next train of thought: Right! Let's try that Cyclone III starter kit and see whether Quartus sees and discovers it. 5 Minutes later I was holding the Cyclone III kit all the while mulling for a while. All I sad to myself was, good thing I didn't throw it away and listen to my gut feeling that said that the Cyclone III starter kit was not damaged. And then I turned somewhat angry and I began to suspect something that would match up perfectly to my conclusive sentiment from all the user comments and postings gathered in the past.
Now we get on. I finished my audio recording without the aforementioned components. It is a schematic that incorporates hard statemachines and no more than that. It has a record, play, replay and feed-through button. The 10 switches were used to set stuff like audio quality, sample size, DB peak meter scale, audio input source etc. A connected monitor would reveal anything recorded audio pass by. The onboard SRAM was used as the storage device and thus allowed up to 5 seconds of recording at 48KHz. And thus, the design was downloaded in the serial flash rom configuration device and have it as the starter kit startup schematic.
The complementary part to this project was an electret microphone preamplifier of own design again with its own design requirements: Tolerant to any sort of 12V supply; exclusively DC couped from electret mic to output; gain of 60dB. This would allow me to amplify analogously low volume ambient sound that hugs the noise floor of the mic. And thus, eliminate digital amplification within the audio analysis software (Audacity for PC) which could be used to record the 10 second sound bite from the audio recorder. The project for its purpose succeeded perfectly. I was able to record live the last 10 seconds of sound in my home after stopping the recorder and further analyze the sound on PC.
It is now 2021. And Quartus now sits on version 20+. I am now using 20.1.1.720. The last version that includes ModelSim I think.
While the audiographer (as I call it) works as intended, 10 seconds of recording is very modest. So over the course of 2021 and 2022 I had diligently worked on trying to get this HIPHY DDR2 memory interface to work so I could use the integrated 512MB LPDDR2 device. This is where I ran in a multitude of problems which relate to the Altera Megafunctions that implement this DDR2 interface. Basically it came down to this: My goal was to develop a bare-bone LPDDR2 interface and do the memory controlling myself. It was going to be a simple custom controller that would provide a streaming interface towards the host (the audiographer). It was difficult for me to figure out which megafunctions to use for a complete barebone interface geards towards memory devices as opposed to just the data transfer channel. I then got the idea to just implement the HIPHY interface myself. And so, I took the Arria DDR interface design example off your website and examine the cyclone 5 atoms used and go from there.
Well. I succeeded in creating a project that by circuit comparrision correctly implemented all the required HIPHY atoms and then got stuck again. Or rather, the fitter would get stuck. Every time. No joke. The design barely uses any logic fabric registers, it is truly just the DDR channel atoms wrapped into a module that provides a host interface to which a custom controller should be connected. I have been unable to get it to work because I could not get past the fitting process on this mundane project. I may link the project as a separate post for you to examine. So, I was a littlebit disappointed as I could not ultimately improve storage of the audio grapher and provide me with an allround DDR2 memory interface for the future retro computing memory needs. Oh and turn the audiographer into a realtime audio spectrographer for the 1Hz to 1KHz frequency range. For now the project idles.
Now, now for the next part. Yet andther smalltime pet project that I can use for a multitude of other small projects: a very basic 8-bit CPU setup to make configuration of I2C based chips just that bit easier as well as creating some simple UI logic through simple processing. Ok, so I got a basic version to work in Quartus. The CPU test was dead-simple: Upon a button press, read the switches and output them to the leds above them. 4 op-codes were used: OUT (io),A ; IN A, (io), TB a, <n> (test-bit) and JP <c>,<a>. The CPU can not add or subtract yet haha.
Mind that I had no need to actually configure the starter kit since I configured it with the working audiographer. And so, I went by Quartus version 19, 20 and earlier subversions to finally end up with 20.1.1.720. And since I now wanted to live-test the CPU circuit and see whether it works for real I had a reason to get the kit and configure it. After hooking it up I made an annoying discovery. The programmer did not see the USB Blaster. Well shoot. Well, I engaged in the same procedure; go online and see what users say and what solutions there are to problems. But my conclusion quickly became the same as back then in 2008 and on. The blaster driver broke again so it appears. Some say it's the OS, some say it's the Quartus version and nobody has a real solution.
How ever, *I* now across all these years *and* with the experiences in my life I ran into I have enough data to tell and say that Altera, and now Intel, where never the ones that would have to fix something. Because I can now say, there's nothing broke to begin with. My Cyclone III kit will argue with anyone telling me otherwise. It's not the OS. It is not the Quartus version. It is not the USB Blaster driver itself.
Well, then what is it one may ask? Well. I can tell under which guise they operate from a civilian social perspective. And it's the "Intelligence community". Before you start to through aluminum at me and tell me to fold hats, I will tell you: I have first hand, not so pleasant experience with elements witihin that community that mainly operate from behind a digital smokescreen.
And what I have discovered primarily is that in some cases this community is hell-bent on falsifying reality perception of members of society and state. Yes, I've also conducted court cases over this in my country.
On the technical front I have discovered the following: At some layer in the full PC stack (hardware + software stack) it is possible for them to apply a "difference stream" anything file, memory or stream. Whether it about audio media files or video media files. Or Word documents; or configuration files that store fitter settings. On source files no matter the language or development environment. About on everything digital.
"Difference stream technology" enables them to not to have to modify original files and media and thus let hascode algorythms produce legitimate results and not having to need things like hashcode replacement tables for identified files to have modified files reproduce the same SHA256 key. It is a far-going technology through which the can have a serious impact on society and get people and companies out of business when the intelligence community doesn't like their schools of thought or in case of developers, their product intents. To avoid so many legal issues and actual prosecuting, these guys are maximally about relegating their targets into psychological healthcare. It takes away any legality from these targets and they are no longer a threat in court. I think it is safe to say that there may be Quartus community members that recognize themselves in this whole thing when it comes to all these Quartus, USB blaster and starterkit woes that are being experienced.
Applying a difference stream to the driver installation and remove/modify the digital signature to make the driver install fail would be a covert way to avoid driver install. Mind you, the files on disk are just the original legitimate USB Blaster driver files and these are not modified. It happens somewhere where data is transfered between layers.
I can state that I am one of those people that is not liked by the intelligence community and especially the audiographer project with 512MB capacity and a realtime spectrographer output without a software stack and CPU is something I can tell they hate with a passion. Exposing nature and all, when one had run into these folks over a plane that had been claimed to have been shot down through the help of Russians.
Soo..... this is a big heads-up that might help you check out and identify whether you and your endavours are in conflict with any sort of established school of thought and begin to look at failing FPGA IDEs as something that's being activelt fudged with by an external party through difference-stream technology. As a finisher on this I say: Vault 7, Spectre and Prism.
As for the USB driver itself? I may go back to earlier versions of 20, or all the way back to 18 and see whether the USB driver installs properly or not. It may be hit and miss, or I may be with yet another starterkit that I can no longer approach. Maybe Intel can work on something throughwhich they can guarantee the USB blaster should work on any capable OS. It's obvious that the driver itself is not linked to Quartus versions. It's just the same thing packaged with every new version.
Maybe Intel can provide a stand-alone download of the Altera USB Blaster for all supported OS'es? Anways. I think that in the end that I didn't come here so much for a solution as much as letting you know in one solid post about a long-running issue that's been going since 2008 when it comes to the Altera/Intel FPGA products.
Thanks for listening and thanks for your time.
Arno van Harskamp (The Netherlands)
