标签: ieee

IEEE之严肃版:     IEEE会员有四级：student member，member，senior member，fellow。学生的时候可以入IEEE，当student member，硕士或者 博士毕业后就可以当member了，有一定的学术成就后可以当senior member，最高级的就是FELLOW了。要当fellow要满足两个条 件，一个是要起码有5年的会龄，另外一个条件是要有5个FELLOW的推荐，一年大概有250个FELLOW产生，相当于会员总数的0.1% ，所以相当值钱.      另外还有一个特别的life fellow，life是独立于那四等级的，需要年龄+会龄=100，这样就可以当life fellow了.    IEEE之搞笑版：     电子类工科学生大都知道IEEE, 这个IEEE就像一个大的BBS论坛，而这个协会下面有很多杂志，比如图像处理，信号处理，微波技术等。这些杂志就是论坛下的分版面。每个版面有版主（主编），版副（副主编）等职务。      大学里的教授负责组织人力在IEEE灌水。教授灌的水被别的论坛或版面转载或引用。这就叫坑。大牛教授挖大坑，小牛教授挖小坑。同学们就在这些大坑，小坑中灌水。      水越多的坑，坑就越牛，从而挖坑的教授（坑主）名气也越大。根据挖坑的大小，和水量，IEEE会评选出IEEE senior member (高级坑主)，IEEE fellow (坑王)，IEEE life fellow (终生坑王)。一般同学只要交了注册费就可以成为student member (灌水学员), 毕业后可成为member（灌水员）。      IEEE每个版面一般会举行一年一度的版聚(IEEE symposium)。大家从四面八方聚在一起交流灌水心得。一些坑王会在版聚时介绍挖坑经验(IEEE workshop)。为了鼓励灌水学员灌好水，为成为坑主作准备，版聚设了本年度最佳灌水员奖(best student paper)。      一般灌水在IEEE的发贴区(IEEE sponsored conferences)。有价值的坑或者连环坑经编辑后会保留到精华区(IEEE Transaction).

The beauty of the nameless sequence is that whenever the number of wires double we only have to add one new test pattern. That is, 8 wires require 4 test patterns, 16 wires require 5 test patterns, 32 wires require 6 test patterns, and so on. Thus, as the number of wires increase, so does the efficiency of the "nameless" sequence in comparison to the walking ones sequence. Note that if you're using the "nameless" sequence and the number of wires is not equal to a power of two (2, 4, 8, 16, 32, 64, ...), then you can add some imaginary wires to create the sequence and discard them at the end. For example, if you have 5, 6, or 7 wires, you would add enough pseudo-wires to bring the total number of wires up to 8, write the test sequence based on 8 wires, and then drop the pseudo wires. The "nameless" sequence unmasked! After I had first mentioned my "nameless" sequence in an article in EDN magazine many years ago, I received a jolly pleasant letter from Mr. Norman Megill, Vice President of Engineering at Production Services Corporation, Belmont, MA. Mr. Megill pointed out that my "nameless" sequence should more properly be referred to as the Modified Counting Sequence Algorithm as per a 1989 IEEE paper: N. Jarwala and C.W. Yau, "A New Framework for Analyzing Test Generation and Diagnosis Algorithms for Wiring Interconnects," Proceedings, IEEE International Test Conference, 1989, pp. 63-70 Mr. Megill went on to note that, to the best of his knowledge, this algorithm was first documented by himself in a 1979 paper: N.D. Megill, "Techniques for Reducing Pattern Counts for Functional Testing," Digest of Papers, IEEE Test Conference 1979, pp. 90-94 In fact my discussions on the nameless sequence prompted a slew of emails from readers who had independently come up with the same thing. Furthermore, several readers noted a trick they used to generate a variation on the nameless sequence, which simply involves writing down a standard binary count sequence, commencing at 1, proceeding up to the number of wires you wish to test, and then "rotating" the results. For example, assuming that we wish to test 10 wires called a through j for stuck-ats, bridges, and open faults, we would commence by writing the binary values for 1 to 10 as illustrated in Figure 3(a).   Figure 3: Generating a variation of the nameless sequence.   Once we've generated the binary count, we conceptually "rotate" the table 90 degrees clockwise (or anti-clockwise if you are so-inclined) to create the final test sequence as illustrated in Figure 3(b). This scheme has an advantage over my nameless sequence in that it results in one less test for any number of wires except 2 n (I tell you, I learn something new every day). Actually testing the device Using the "nameless" sequence (or similar) to generate addresses, we would first write corresponding "nameless-sequence-based" data values into each "nameless" location and then read these values back again. This would ensure that we had access to the device and that there were no short, open, or bridging faults on the address or data busses. The next step would be to write functional tests that verify the internals of each memory device, but these techniques are a tad more complex and will therefore be left as topics for future columns. And the answer is... And so, returning to my original tale of woe, how could it be that my tests passed when there wasn't even any memory in the cabinet? Arrggghhh! It was all due to parasitic capacitances on the data and address busses. Whatever 010101... (or similar) value that I wrote to the bus persisted long enough for me to read it back again. I cannot tell you how silly I felt when I discovered my mistake, but that's how we learn... the real trick is to not make the same mistake more than once (grin).

The beauty of the nameless sequence is that whenever the number of wires double we only have to add one new test pattern. That is, 8 wires require 4 test patterns, 16 wires require 5 test patterns, 32 wires require 6 test patterns, and so on. Thus, as the number of wires increase, so does the efficiency of the "nameless" sequence in comparison to the walking ones sequence. Note that if you're using the "nameless" sequence and the number of wires is not equal to a power of two (2, 4, 8, 16, 32, 64, ...), then you can add some imaginary wires to create the sequence and discard them at the end. For example, if you have 5, 6, or 7 wires, you would add enough pseudo-wires to bring the total number of wires up to 8, write the test sequence based on 8 wires, and then drop the pseudo wires. The "nameless" sequence unmasked! After I had first mentioned my "nameless" sequence in an article in EDN magazine many years ago, I received a jolly pleasant letter from Mr. Norman Megill, Vice President of Engineering at Production Services Corporation, Belmont, MA. Mr. Megill pointed out that my "nameless" sequence should more properly be referred to as the Modified Counting Sequence Algorithm as per a 1989 IEEE paper: N. Jarwala and C.W. Yau, "A New Framework for Analyzing Test Generation and Diagnosis Algorithms for Wiring Interconnects," Proceedings, IEEE International Test Conference, 1989, pp. 63-70 Mr. Megill went on to note that, to the best of his knowledge, this algorithm was first documented by himself in a 1979 paper: N.D. Megill, "Techniques for Reducing Pattern Counts for Functional Testing," Digest of Papers, IEEE Test Conference 1979, pp. 90-94 In fact my discussions on the nameless sequence prompted a slew of emails from readers who had independently come up with the same thing. Furthermore, several readers noted a trick they used to generate a variation on the nameless sequence, which simply involves writing down a standard binary count sequence, commencing at 1, proceeding up to the number of wires you wish to test, and then "rotating" the results. For example, assuming that we wish to test 10 wires called a through j for stuck-ats, bridges, and open faults, we would commence by writing the binary values for 1 to 10 as illustrated in Figure 3(a).   Figure 3: Generating a variation of the nameless sequence.   Once we've generated the binary count, we conceptually "rotate" the table 90 degrees clockwise (or anti-clockwise if you are so-inclined) to create the final test sequence as illustrated in Figure 3(b). This scheme has an advantage over my nameless sequence in that it results in one less test for any number of wires except 2 n (I tell you, I learn something new every day). Actually testing the device Using the "nameless" sequence (or similar) to generate addresses, we would first write corresponding "nameless-sequence-based" data values into each "nameless" location and then read these values back again. This would ensure that we had access to the device and that there were no short, open, or bridging faults on the address or data busses. The next step would be to write functional tests that verify the internals of each memory device, but these techniques are a tad more complex and will therefore be left as topics for future columns. And the answer is... And so, returning to my original tale of woe, how could it be that my tests passed when there wasn't even any memory in the cabinet? Arrggghhh! It was all due to parasitic capacitances on the data and address busses. Whatever 010101... (or similar) value that I wrote to the bus persisted long enough for me to read it back again. I cannot tell you how silly I felt when I discovered my mistake, but that's how we learn... the real trick is to not make the same mistake more than once (grin).  

A young engineer sent me an email that made me feel rather sad, but that reminded me how lucky I was when I began my career in engineering. Perhaps we can offer this youngster some advice... Let's start with the original message, which reads as follows (note that I've edited this a little in order to protect her/his identity): Hello Max. My name is ###### ###### and I am fan of you and your writing. I purchased your Design Warriors Guides to FPGAs while I was in school and found it very informative. I am writing to you because I am a young engineer in need of advice. I currently work as an ASIC/FPGA engineer at a large aerospace firm in ######. My problem is that I am lacking the guidance I need from senior engineers to truly learn the discipline well. I find myself frequently getting stuck and staying stuck for much of the day because senior personnel are too busy to help. I ultimately resolve my issues, but I feel like I am not learning the trade very well. I am very interested in knowing what it takes to become good at this. I believe that I am capable and bright, but I lack the coaching. Many of the senior engineers had great mentors that they shadowed and they learned the trade very well, so it's puzzling to me why that sort of system is practically nonexistent these days. I was thinking about enrolling in professional training courses but they are costly. I would appreciate any words of wisdom! Regards, ###### ###### As I say, this made me feel very sad. It's horrible to be dropped in at the deep end, to not know which way to turn, and to not have anyone to ask questions and bounce ideas off. It also reminded me as to how lucky I was when I started my own career. I can't help myself... join me if you will on a brief trip down memory lane... ———Start of trip down memory lane——— After graduating with a B.Sc. in Control Engineering in the summer of 1980, my first position ( "Look Mom, a real job!" ) was with International Computers Limited (ICL) in Manchester, England. At that time, ICL made honking big mainframe computers and I was hired as a member of one of their Central Processing Unit (CPU) design teams. It didn't take me long to discover that little of what I'd studied at college had much bearing on my new job. I also quickly realized that tasks that had appeared easy in the classroom (when the lecturer was doing the bulk of the work) were somewhat trickier when you had to do them in earnest. Fortunately, ICL had a really good policy whereby junior engineers like me were partnered with more experienced team leaders. I was lucky in this regard to be assigned a mentor called Dave Potts, who taught me far more than I'm sure he ever realized. Working under Dave was somewhat frustrating, however, in that he would never answer even the simplest question directly; for example: Max: Hey Dave, what time is it? Dave: Where is the sun in the sky? Which way is the wind blowing? On what side of the tree does the moss grow? How... To cut a long story short, Dave's policy was to lead you through a series of questions, thereby guiding you to discover the answers to life, the universe, and everything for yourself. In many ways this proved to be a superb learning experience (but you quickly learned not to ask Dave what time it was). As one example, my first task at ICL was to design a 128bit barrel shifter and rotator; that is, a unit that could shift or rotate the contents of a 128bit bus by any amount from 1 to 128 bits in a single clock cycle. Dave informed me that the project called for this unit to be implemented using eight Application-Specific Integrated Circuits (ASICs), each of which would handle a 16bit chunk of the data bus. Furthermore, all of the ASICs were to be functionally identical in order to keep the project within budget. Note: As an aside, I should point out that we were designing gate-level schematics using only pencil and paper; also that the ASICs in question each contained only around 2,000 equivalent logic gates (these devices were considered to be pretty much state-of-the-art at the time). Initially, my task didn't appear to be particularly strenuous. The only tricky details involved handling logical versus arithmetic shifts and working out what to data to "stuff" into the "ends" of the shifter / rotator. Part of the solution was to employ a couple of the pins on each ASIC to act as a device ID, thereby instructing each chip as to its position in the chain. When I'd completed this part of the exercise, Dave deigned to inform me that he'd neglected one slight detail, which was that – in addition to processing all 128 bits – the shifter/rotator also had to be capable of working with only the least-significant 64 bits or the least-significant 32 bits. OK, my task had just become a tad trickier, but it still wasn't all that bad and a few days later I returned with my latest offering. "Ah, Ha!" said Dave, "Now we're getting there, but in addition to binary shifts/rotates, this device also has to be able to handle 128, 64, or 32bit Binary-Coded Decimal (BCD) data." Dave then proceeded to explain BCD in general along with what shifting/rotating this form of data entailed (what values do you insert when performing an arithmetic shift right on a BCD representation, for example). The great thing was that Dave was endlessly patient and he was always available to answer questions and to offer suggestions as to different ways to do things and cunning logic tricks one might employ. And so it went. Every time I finished a problem, another feature would be added to my portion of the project. In reality, of course, the main specification already contained all of these details, but if I'd been presented with the full requirements on my first day, my brains would have leaked out of my ears and I would have been reduced to a gibbering wreck. ———End of trip down memory lane——— Looking back with hindsight (the one exact science) I realize just how lucky I was. If I had simply been presented with the full-up specification for the shifter/rotator on the first day, I wouldn't have known where to start. The result could well have been to ruin my self-confidence and to leave me feeling like a failure, which would almost certainly have negatively affected the rest of my career. So my heart really goes out to the young engineer who sent me the original email. The problem is that I really don't know what to suggest. There are various online training resources, but there's nothing as good as having access to someone more experienced with whom you can ask questions and bounce ideas around. One thought might be to see if there's a local chapter of the IEEE or ACM and to join it. Maybe one could find a mentor there. Does anyone else have any suggestions?

I got an email from a young engineer that made me feel rather sad, but that reminded me how lucky I was when I started out my career in engineering. Perhaps we can give this youngster some advice... Let's start with the original message, which reads as follows (note that I've edited this a little in order to protect her/his identity): Hello Max. My name is ###### ###### and I am fan of you and your writing. I purchased your Design Warriors Guides to FPGAs while I was in school and found it very informative. I am writing to you because I am a young engineer in need of advice. I currently work as an ASIC/FPGA engineer at a large aerospace firm in ######. My problem is that I am lacking the guidance I need from senior engineers to truly learn the discipline well. I find myself frequently getting stuck and staying stuck for much of the day because senior personnel are too busy to help. I ultimately resolve my issues, but I feel like I am not learning the trade very well. I am very interested in knowing what it takes to become good at this. I believe that I am capable and bright, but I lack the coaching. Many of the senior engineers had great mentors that they shadowed and they learned the trade very well, so it's puzzling to me why that sort of system is practically nonexistent these days. I was thinking about enrolling in professional training courses but they are costly. I would appreciate any words of wisdom! Regards, ###### ###### As I say, this made me feel very sad. It's horrible to be dropped in at the deep end, to not know which way to turn, and to not have anyone to ask questions and bounce ideas off. It also reminded me as to how lucky I was when I started my own career. I can't help myself... join me if you will on a brief trip down memory lane... ———Start of trip down memory lane——— After graduating with a B.Sc. in Control Engineering in the summer of 1980, my first position ( "Look Mom, a real job!" ) was with International Computers Limited (ICL) in Manchester, England. At that time, ICL made honking big mainframe computers and I was hired as a member of one of their Central Processing Unit (CPU) design teams. It didn't take me long to discover that little of what I'd studied at college had much bearing on my new job. I also quickly realized that tasks that had appeared easy in the classroom (when the lecturer was doing the bulk of the work) were somewhat trickier when you had to do them in earnest. Fortunately, ICL had a really good policy whereby junior engineers like me were partnered with more experienced team leaders. I was lucky in this regard to be assigned a mentor called Dave Potts, who taught me far more than I'm sure he ever realized. Working under Dave was somewhat frustrating, however, in that he would never answer even the simplest question directly; for example: Max: Hey Dave, what time is it? Dave: Where is the sun in the sky? Which way is the wind blowing? On what side of the tree does the moss grow? How... To cut a long story short, Dave's policy was to lead you through a series of questions, thereby guiding you to discover the answers to life, the universe, and everything for yourself. In many ways this proved to be a superb learning experience (but you quickly learned not to ask Dave what time it was). As one example, my first task at ICL was to design a 128bit barrel shifter and rotator; that is, a unit that could shift or rotate the contents of a 128bit bus by any amount from 1 to 128 bits in a single clock cycle. Dave informed me that the project called for this unit to be implemented using eight Application-Specific Integrated Circuits (ASICs), each of which would handle a 16bit chunk of the data bus. Furthermore, all of the ASICs were to be functionally identical in order to keep the project within budget. Note: As an aside, I should point out that we were designing gate-level schematics using only pencil and paper; also that the ASICs in question each contained only around 2,000 equivalent logic gates (these devices were considered to be pretty much state-of-the-art at the time). Initially, my task didn't appear to be particularly strenuous. The only tricky details involved handling logical versus arithmetic shifts and working out what to data to "stuff" into the "ends" of the shifter / rotator. Part of the solution was to employ a couple of the pins on each ASIC to act as a device ID, thereby instructing each chip as to its position in the chain. When I'd completed this part of the exercise, Dave deigned to inform me that he'd neglected one slight detail, which was that – in addition to processing all 128 bits – the shifter/rotator also had to be capable of working with only the least-significant 64 bits or the least-significant 32 bits. OK, my task had just become a tad trickier, but it still wasn't all that bad and a few days later I returned with my latest offering. "Ah, Ha!" said Dave, "Now we're getting there, but in addition to binary shifts/rotates, this device also has to be able to handle 128, 64, or 32bit Binary-Coded Decimal (BCD) data." Dave then proceeded to explain BCD in general along with what shifting/rotating this form of data entailed (what values do you insert when performing an arithmetic shift right on a BCD representation, for example). The great thing was that Dave was endlessly patient and he was always available to answer questions and to offer suggestions as to different ways to do things and cunning logic tricks one might employ. And so it went. Every time I finished a problem, another feature would be added to my portion of the project. In reality, of course, the main specification already contained all of these details, but if I'd been presented with the full requirements on my first day, my brains would have leaked out of my ears and I would have been reduced to a gibbering wreck. ———End of trip down memory lane——— Looking back with hindsight (the one exact science) I realize just how lucky I was. If I had simply been presented with the full-up specification for the shifter/rotator on the first day, I wouldn't have known where to start. The result could well have been to ruin my self-confidence and to leave me feeling like a failure, which would almost certainly have negatively affected the rest of my career. So my heart really goes out to the young engineer who sent me the original email. The problem is that I really don't know what to suggest. There are various online training resources, but there's nothing as good as having access to someone more experienced with whom you can ask questions and bounce ideas around. One thought might be to see if there's a local chapter of the IEEE or ACM and to join it. Maybe one could find a mentor there. Does anyone else have any suggestions?