The TESLA 3000 MPB was developed for NxtPhase by Fidus in Ottawa. It went fairly well, until the prototype board would just not recognize the Ethernet NIC, at all. Michael Miller asked Elecsys to investigate.
I insisted that we boot LINUX on the board. Fidus advised that it was not feasible to do so. I persisted, and after about a week’s work (customizing the boot parameters and hacking the kernel a bit), I had it booting to LINUX with a small laptop hard drive. Sure enough, the Ethernet NIC would not come up, even though it was fully supported by the installed LINUX driver.
By instrumenting the driver with printk() and observing the result of loading and unloading the driver in the system log, I determined that it was a short between two lines on the PCI bus to the NIC. When Fidus took a close look at the Gerber files, they discovered that the design rules were too tight on the PCI bus on a deep inside layer of the PCB. The PCB was corrected and remade, and the NIC worked.
Later, there was an issue with the operation speed of the MPB core. Fidus was doing the FPGA development in VHDL on Synopsys, but did not have the resources to continue. I took over the development under Synopsys, having to establish VPN to Fidus to obtain the license for it to run. I suspected that the Synopsys tools, as good as they were, could be responsible for my inability to get appropriate performance from the FPGA. I ported the VHDL out from Synopsys back to Xilinx ISE, a byproduct of which was that we could do full development stand-alone in Winnipeg, which was nice.
With a few tweaks, I was able to get the MPB FPGA to simulate out at better-than-required full speed operation, which was proved out in actual operation. I mapped a path to higher speed operation, anticipated as a requirement for future product development.
After performing the design and full verification of the TESLA 3000 AIB, Elecsys was asked to support the manufacture of the boards at Trilogy-Net in Calgary. There were challenges in getting the boards to work, mostly because of the silly little LM358BP, which is in a tiny 8 microbump package. We had process issues on getting it to solder properly.
In the end, the fault was the layout that I had supervised. Unfortunately, in our desire to pack everything onto one side of the board, I had moved down to the absolute smallest package of the LM358 dual op-amp. Well, in the end the board layout person went to double sided assembly but didn’t tell me until the last minute, meaning that the tiny op-amp stayed. There were larger parts around the op-amp that drew the heat out of the oven, so the op-amp wouldn’t solder consistently. This was a headache until a couple of years ago, when that op-amp was finally replaced by the larger SOIC version. Sigh.
Anyway, we wanted to do a 100% test of the AIBs to ensure proper function before TESLA assembly.
I acquired a number of surplus IEEE-488 / GPIB test equipment and a PC GPIB card, and wrote scripts in PERL to control the test equipment. We were able to drive precise voltages into each channel, to test offset and gain, then certain frequency signals to test filter response. Data was logged, analyzed, then the aggregate data was reviewed continually to calculate statistical process control.
We were promoting the “Manitoba Power Connection” of Manitoba Hydro, Teshmont Consultants, Vansco, Manitoba HVDC Research Centre, and the University of Manitoba. The HVDC Research Centre had a new real-time simulator system called RTDS (Real Time Digital Simulator) and an off-line simulator called EMTDC, both of which used their power-system simulator drafting tool called PSCAD. We wanted to work with these tools, so they counselled us to set up a LINUX machine. I purchased LINUX 5 and installed it on an old X86 machine. It took 3 or 4 tries to get it installed correctly, ha ha.
Then I immediately set out to playing with it… of course.
Because we used QNX, we didn’t have an extensive Ethernet network at Vansco. The APT division had its own local Ethernet, but no connection to the shared printer that we needed in another area of the building.
We did have an extensive ARCnet… which I still believe is far superior to 10Base Ethernet because of its ability to get to near-100% utilization without degredation, but anyways..
We were in the process of decommissioning our QNX desktop network and moving to MS-Windows (hiss, boo, but that’s another story). We had plenty of QNX-proprietary memory-mapped ARCnet cards around. I took a few home and set up computers at home running LINUX, and hacked together the ARCnet and Ethernet drivers to get TCP/IP running over the proprietary ARCnet cards. Then, pulling down the (now unused) ARCnet cables from the ceiling, and dropping a small computer at the other end, I was able to connect to the main network and its print spooler, and give us access to the main printer. A demonstration of the power of LINUX, and what you can do if you have the source code!
Sometime around v0.91 to v0.93, I downloaded LINUX – probably Slackware – and gave it a try. The first time it booted, I said, “yes, yes, that’s the way a real operating system announces itself when it boots!”
However, I didn’t have a practical use for it, so I went back to my QNX hacking.
At the time, we didn’t have a VPN, but we had 33k modems for remote access at Vansco. I was able to log into QNX at work and do my work more-or-less the same as at home. Because everything was terminal-based, it was lightning-fast. Because it was QNX, it was rock-solid stable and could recover from almost any problem.
