That Was Tricky: The logic analyzer versus a DVM

This story starts back in 1995 during our undergraduate years. On the last semester we had to take one “hands-on” class which was about constructing a real electronic device.

As my colleague and I were both busy with our final thesis, we were very keen to take a “nice and easy” project (our final thesis was complex enough… speech recognition with DSP). When the list of available projects was posted up on the lab announcement board, I was very excited for a particular project that would fit our description of “nice and easy”. I called my friend and we were within the first students to register for the lab, in order to apply for that “nice” project. The project’s name was “Printer Multiplexer”.

Back in 1996, network printer servers were expensive and scarce. Thus, in our department we had many computer rooms containing four to eight computers for the students to use, but only one of these computers would be connected to a printer.

So it made a good sense to have a sharing device that would allow printing from all or at least some of the PCs to this single printer. The requirements of the project were to design such a printer sharing device, build it, and document it properly so that it could be duplicated.

The lab assistant supervising the project said that if we agreed to undertake this project, we would take on more risk to fail the lab even if the write-up was excellent. Minor hardware defects could sometimes be forgiven, the class being part of the learning process. But this time the device had to perform perfectly as it was to be put to service immediately. The department’s good name was on our shoulders, and this good name would be at stake if the device would not be delivered.

Calmly we both accepted the challenge without the slightest hesitation, filling the eyes of the assistant with surprise confronted with such confidence from our side.

It was common for the students to do some literature research and modify a similar circuit to fit the lab’s requirements. But as we were pretty well experienced (or so we thought at the time), we opted to create our own design from scratch. Why bother anyway? It was (seemingly) an easy problem, right?
 
Parallel printing uses a handshake mechanism. (Maybe we should say “used” because nowadays there are no such things as “parallel ports”.) There is a strobe signal, an acknowledge signal, and various other signals that control the data transfer. In our case, the important signals were strobe, acknowledge, and busy.

Our device would monitor these signals. The idea was that if one of the PCs started printing by asserting the strobe, we would connect all the port signals to that PC and signal “busy” to the all other PCs. Thus, the first PC attempting to print was granted access to the printer and all other PCs were prevented from printing – hoaxed to believe that the printer was connected but not available.

The good part was that this approach required no programming on the PC and it was transparent for the users. We were very proud to think as far as implementing a timeout of 30 seconds from the last strobe before releasing the busy signals and allow other PCs to print so as to accommodate the printer data buffering.

As information was not plentiful at that time, we had to confirm our concept, so we made some interface PCBs and connected them to a PC. The lab had a wonderful HP16550 logic analyzer, which we desperately wanted to use. The analyzer was not easily handed over for use so as to prevent damage to it by students less attentive than ourselves (which meant all of the others according to our mindset at that time). The problem was that we lacked – yet – to provide sufficient reason before we could be granted access to it.

I remember that instead of a touch screen this beast had an X-ray finger detector! It was brilliant, but certainly not beneficial to work for many hours in front of it. A suitable warning label (that we did not care to fully read) explained something regarding x-ray exposure.


Anyway, by presenting our “complex” project difficulties to those in power, we were eventually granted access to the instrument in order to document and debug our prototype design.

Happy to finally be working with this high-end technology, we connected the logic analyzer to our circuit. Initially, we had problems starting a print from the PC. After two hours of debugging on the HP we discovered that a few signals were floating and pull-up resistors were missing from our circuit. After adding these resistors, the PC-side interfaces were working. We could prevent or allow a PC to print by manipulating the port’s control lines. Of course we had performed any actual timing measurements on the analyzer at this stage – we had used this beast only to identify some missing pull-ups…


The next day we were in our home lab to finish the main controller logic. Our logic was implemented as a priority encoder, which allowed the first strobe signal to reach it to block the rest of the inputs. We used discrete components. A latch was used to store the current state. In our home lab, the logic analyzer was nothing more than a cut-out from an EDN advertisement taped on the wall (don’t forget that we’re talking about 1996 when these instruments were incredibly expensive). The only tools at our disposal were a DVM (Digital Volt Meter) and an analog oscilloscope, and for some reason that I no longer remember we did not use the oscilloscope.

We soon discovered that we had intermittent problems in the circuit, which did not work as expected. We were very puzzled. It was a simple circuit. After the first shock we reverted to our “Sherlock Holmes” mode. We managed to make the circuit fail and I took the DVM’s probe. I measured the voltage on the input. I did the same on the output. Under normal operation these values should be matched because the latch output would reflect the input, but in our fault case the output had not followed the input.


Immediately I looked at the datasheet. The setup time of the latch was about 25nS. I turned to my colleague and said to him bluntly: “We are missing 25ns…”

After a few minutes of thinking about the theory the problem was obvious. The asynchronous operation of our circuit violated the setup time of the latch. Ha! And we found this out without the glamorous HP16550 in less than an hour.

After rethinking over the design, we decided to replace the latch and the discrete logic with a PLD. That would allow us flexibility by reprogramming the logic and would require the least possible alterations to our prototype PCB.

The difficulty was that our department was not really famous about its digital logic classes, so we lost another full day on the drawing board designing, simulating, and testing failing designs in the PLD. Simulations were always OK, but real life was hard on us. Nobody had taught us about fully asynchronous logic with the exception of internal flip-flop structures.

We seemed doomed to failure until my colleague became fed up and told me: “Stop it! We are going to design it asynchronously. No flip-flops. Just gates!”

At first I disagreed and said it would not work. But eventually we agreed to give it a try, and ... Voila! It worked! It wasn’t until a number of years later that I read a book with a whole chapter on this type of circuit and the methodology to design them safely.

By the project’s deadline, we had prepared everything. The report, the prototype in a nice shiny enclosure, the associated documentation… everything was ready for submission.

The assistant professor’s first question after seeing the report and the hardware was: “Did you modify this circuit from an electronics magazine?” Our negative answer surprised him once again. Actually, it had not even crossed our minds that we could do that.

In fear that “Mr. Murphy” was still lurking around, during the project presentation we connected just a single PC and one printer to our device. Well, there was a problem when only one PC was connected and we were not aware of it. The assistant said that it was okay and that we had passed the lab, but we would have to take back the hardware and fix it.

Furious about this unexpected development (remember, we were young…) we went into another lab and connected two PCs, only to see that it worked perfectly. We almost flew back to the assistant – it was just before the summer vacation and we didn’t want to leave any pending problems behind us – where he accepted this small issue.

Phew. It was a “nice and easy” project that revealed one thing: It *is* possible to find missing nanoseconds with a DVM (and missing pull-ups with a logic analyzer!). All you need to have is a good test strategy with a binary outcome: Either it should be high or it should be low for it to work. So never underestimate the small DVM hidden in your drawer ever again!

About the authors
Argiris Diamandis: Argiris’s early toys included small cars and a soldering iron that he pulled down from his father’s bench while still crawling around on the floor. When radios and TV sets with tubes were opened up for repair, Argiris could not resist playing with the wires. By the age of six he could solder kits together, and by the age of ten he could make some easy repairs on TVs, helping to win the “day’s bread”.

Several years later, education helped Argiris to understand what was really happening in all these electronic devices, and the urge to design some of his own was satisfied – only partially – by working on embedded systems. Since then, the urge is still going strong, and Argiris has explored fields such as hardware, software, signal processing, and many more.

Ilias Alexopoulos: Fascinated by computers seen in advertisements in the start of 80’s Ilias knew just what he wanted to do. He started playing with early computers for fun and both the hardware and software was his everyday joy.

Later, at the university, Ilias entered the world of embedded computing, DSP, and FPGAs. His passion for high-end systems has lead him to solve many challenges from production testing equipment to high-tech startups.

Commitment to engineering excellence and enjoying the engineering journey is always his aim. Recently, Ilias has started to contribute to the open source community with articles, code, etc. You can find more information at www.ilialex.gr


Click Here to see other articles in this "That Was Tricky..." series...


Editor's Note: It would be great if you took the time to write down some stories of your own. I can help in the copy editing department, so you don’t need to worry about being “word perfect”. All you have to do is to email your offering to me at max@CliveMaxfield.com with “That Was Tricky” in the subject line.

I can post your article as “anonymous” if you wish. On the other hand, what would be really cool would be if you wanted to add a few words about yourself – and maybe even provide a couple of “Then and Now” pictures showing yourself as a young engineer ("Then") and as the hero you've grown into ("Now").

---

If you found this article to be of interest, visit EDA Designline where – in addition to blogs on all sorts of "stuff" – you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).

Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).