The TransistoriZed logo should be here! But... curses! Your browser does not support SVG!

homelist of postsdocs about & FAQ

6 great articles on the field of engineering science

I always feel heartfelt while reading great and sensuous short texts about the field of engineering. I am offering you a few beautiful, 1 to 3 minute reads on topics related to engineering science.

Where are today's engineering heroes?By failing to celebrate its finest contributors, the profession risks far more than mere obscurity. This enriching article puts on the spotlight those engineering heroes who are often forgotten but have by far contributed equally much to our field.

Illustration by Tavis Coburn, IEEE Spectrum

Naturally, you might then ask, What makes an engineering hero?, Stephen Harris has tried to shed some more light with a follow-up article, revealing some of our views on engineering achievements.

What would engineering be without its daily battles with complexity and trade-offs? Robert Lucky rubs salt into the wound with the headaches of Unsystematic engineering. But there should be a better handle to the control problem, how's that even happening?

Perhaps the problem lies in The ever-evolving field of electrical engineering. How exactly is electrical engineering defined nowadays? Is circuit design the only E-related early stage subject which all EEs take during their first year at university? Do you have any idea of what EEs actually do?

You think you do? But then, how about Engineers starting to think like field biologists?, Samuel Arbesman has some radical ideas for coping with complexity.

Finally, we all know that solving complexities is always accompanied by the birth of Great Thoughts, here Robert Lucky is stressing that great ideas accompany us in unusual times and places. So, always keep that pen and paper ready, you never know when would that bird land on your shoulder.

Hope these writings reach more people. Happy reading!

Date:Sat Jan 26 22:33:05 GMT 2017


The chips are here!

Awhile ago I wrote about the time I've been investing on designing an image sensor and its column-parallel ADCs in particular. If we know each other well chances are I've been moaning your years about that chip for a long time. Well, they ARE here! Alive! With practically no functional bugs such as inverted signals or wrong connections whatsoever! I might say that this device actually turned out pretty successful, especially considering that every single circuit inside was built all from scracth in a sharp tapeout deadline!

Of course there are a few glitches here and there, but thank goodness it's nothing critical. Besides I haven't seen a first time right image sensor yet, requiring no mask tweaking.

Let's not wait any longer. Here's a very quick and preliminary summary of my measurement adventures so far. And... sorry folks, the striptease will be next time, when I plan to reveal some of the circuits inside. Unfortunately due to some harsh journal pre-publication and disclosure rules I don't really want to get into trouble just yet.

To start with, here's a picture of the chip and the board itself:

ADC Board: 1024 column-parallel hybrid single-slope ADCs

It took quite awhile getting the board back with some iteraitons from the bonding vendor, despite the nice bonding diagrams sketched. Nevertheless, turns out bonding and ESD finally turned out to be successful. Hehe, well, I have some infant mortality in a few boards where the bonding operator has forgotten to weld a group of wires. Perhaps he thought the chips may miraculously work without a signal or two?

You may wonder what's with all these bond wires? Why so many (170)? Actually most of them are redundant power supply pads. The bottom side of the chip contains 16 LVDS output data pairs i.e. 32 pins, one pair LVDS clock in used for the serialization and SRAM readout. In-between the LVDS pairs there are power pads supplying the columns. Indivitual Analog (3.3V), Digital(1.5V), and IO (LVDS, 1.5V). The right side of the chip has another LVDS clock input used for the fast count clock 266 MHz, split power supply for the voltage references bias and control. The control signals for the sensor are on the right and top side, a few pins for the SPI and bias trim. Everything else is used for supplying the matrix with isolated from the ADC power and ground. To recap, here's a coarse high-level diagram:

Chip high-level diagram

The digital test system is based on a Xilix Spartan 6 LX150 FPGA, controlling a Cypress FX3 USB 3.0 chip for the high-speed ADC data transmission to the ADC. Even so, the bottleneck to reading out the chip at its highest rate is the USB 3.0 link and not the chip itself. Perhaps a PCI-Express protocol would have suited the applicaiton better.

FPGA Readout Board

The ADC board has AD8620 14-bit DACs which are used for providing test sweep voltages to the ADC. An ADC used for measuring the power drawn by the separate supplies, which are driven by a few fixed-voltage LDOs. There are also voltage translators to 1.5 V as the FPGA's banks operate on 1.8 V minimum.

It took me over three months to setup the FPGA and readout to the PC. The FPGA contains a few elemental blocks:

1. An UART Rx/Tx module which I use for preloading various settings and data to the FPGA. The module is bit-banged and re-used from a lab assignment during my MSc university days.

2. A bit-banged SPI module specifically tailored to the SPI register inside the testchip.

3. A bit-banged SPI module for the AD8620 DACs

4. A 4 kB block RAM with asynchronous write/read capability. The RAM contains the sequencer data and is preloaded via the UART module.

5. 16 hardware 1:6 deserializers (ISERDES), with automatic phase alignment of the strobation pulse and automatic bitslip module based on the received training pattern from the chip.

6. Two 12288 kbit frame line FIFO buffers which allow for fully pipelined ADC SRAM readout.

7. A transmission header combinarion module.

8. Control state machine for the FX3 GPIIF interface.

The FPGA without any readout software is useless. I use the in-house viewer at the company I was hosted for capturing images over the USB, while the register programming and sequener I had to design myself. To ease life with configuring the chip registers I created a tiny Java GUI calculator? which allows me to enable or disable the various on-chip registers. I also use it for controlling the DAC voltages and well as some of the FPGA internals. Its backend is written in bash and practically controls the corresponding UART device via the /dev folder.

Register control tool

Being able to easily change the chip's timing is one of the most important things in chip testing. My initial solution for a sequencer was to use hard-coded state machines on the FPGA. Such scheme however, is extremely hard to tune or tweak, making it impractical. To improve flexibility, I designed a tiny assembler, decoding my custom instructions controlling each individual (or combined) signals. Nothing extraordinary but a perl script parsing my assembler files, translating them to a binary stream, which is then fed via the same UART backend to the FPGA and ultimately the block RAM.

An example configuration of the current sequencer system

Here is a sample of the instruction set

;| Instruction List and Function                                    |
;| ROW 0x00 1/0 - set row_rs                                        |
;| ROW 0x01 1/0 - set row_rst                                       |
;| ROW 0x02 1/0 - set row_tx                                        |
;| ROW 0x03 1/0 - set col_bias_sh                                   |
;| ROW 0x04 1/0 - set row_next                                      |
;| SHX 0x00 1/0 - set shr                                           |
;| SHX 0x01 1/0 - set shs                                           |
;| ADX 0x00 1/0 - set adr                                           |
;| ADX 0x01 1/0 - set ads                                           |
;| COM 0x00 1/0 - set comp_bias_sh                                  |
;| COM 0x01 1/0 - set comp_dyn_pon                                  |
;| CNT 0x00 1/0 - set count_en                                      |
;| CNT 0x01 1/0 - set count_rst                                     |
;| CNT 0x02 1/0 - set count_inv_clk                                 |
;| CNT 0x03 1/0 - set count_hold                                    |
;| CNT 0x04 1/0 - set count_updn                                    |
;| CNT 0x05 1/0 - set count_inc_one                                 |
;| CNT 0x06 1/0 - set count_jc_shift_en                             |
;| CNT 0x07 1/0 - set count_lsb_en                                  |
;| CNT 0x08 1/0 - set count_lsb_clk                                 |
;| MEM 0x00 1/0 - set count_mem_wr                                  |
;| REF 0x00 1/0 - set ref_vref_ramp_rst                             |
;| REF 0x01 1/0 - set ref_vref_sh                                   |
;| REF 0x02 1/0 - set ref_vref_clamp                                |
;| REF 0x03 1/0 - set ref_vref_ramp_ota_dyn_pon                     |
;| SER 0x00 1/0 - set digif_seraial_rst                             |
;| LOAD PAR - load follow-up instructions to buf register           |
;| SET PAR  - set the loaded in buf register to output              |
;| START    - initialize output register to 0x0000                  |
;| NOP      - NOP operation (stall) one cycle                       |
;| NOP n    - NOP operation (stall) n cycles                        |
;| FVAL 0x00 1/0 - frame valid                                      |
;| LVAL 0x00 1/0 - line valid                                       |

Here comes the interesting part. The ADCs can be run at 1us ramp time, which is as designed, and achieve a noise variance of about 1.6 LSB at 1x gain. According to the preliminary histogram tests with a sinewave from the soundcard from my laptop and buffered via a, perhaps not so linear opamp, provides a monotonic response and DNL of less than 1 LSB. It would be desirable to be less than 0.5 LSB, however, I see tiny glitches popping up beyond 0.5 LSB. The root cause for this may likely be a poor duty cycle ratio of the count clock, as my architecture relies on a sharp clock with 50 % duty cycle. But for that I shall investigate further. The ADCs consume 35ish mW from the digital supply (1.5V) and about 100mW from the analog (3.3).

Here are some preliminary fancy pictures, starting with a noise histogram:

Noise histogram over 32K samples

3D plot, noise histogram over 32K samples, 128 columns

3D plot, noise histogram over 32K samples, 1024 columns

The noise may perhaps be dampened further, as the PCB itself can not boast with being the best low-noise design. The external DACs used for feeding in the input voltage use the power supply as a voltage reference (via a low-pass filter of course), which is horrendous circuit design practice.

Here is a posh 3D code distribution histogram for the columns in the first ADC group of 128. Shown is a bathtub distribution produced by feeding in an input sinewave to the columns.

First bathtub histogram test, note that the sinewave used here is not full range, neither it clips the ADC

Another angle of the bathtub, first 128 columns only

You can see some stairs here:

Staircase at 1 us ramp time. A tiny glitch which can be fixed. Also note the input signal samples in this case are not sufficient.

To prove that the digital correlated double sampling works, here is the mean value of all columns under a uniform voltage input:

Mean value of all columns over 8k samples

Nice and uniform gray "image" with just ever so little (unnoticeable?) column fixed pattern noise. Do your eyes see it?

The pixel array also works and I can successfully acquire blank images. The pixel sequencer needs tuning so as to eliminate some strange column FPN artefacts. I also plan on attaching better lens, as the current ones are probably the worst possible choice for a sensor with a small size as the current.

Finally, just wanted to mention that this is work in progress, so stay tuned for more updates in the nearby months. But please lower your expectations for design details. I need to make sure this work is accepted in some of the major journals before publishing anything here. Sorry folks, it will come eventually.

Date:Sat Jan 25 20:43:40 GMT 2017


Powered by ICs

I recently participated in a T-shirt design contest organized by the solid-state circuits society. I just got an e-mail rejecting my entry as apparently another participant has won the contest. His design, compared to mine looks neat and clean. Congrats!

Nevertheless, now that the contest is over, let me introduce you to my design, and perhaps make SSCS angry about not following their strict copyright ownership rules. Apparently, by submitting your design you are automatically giving out all of your copyright to SSCS. Yeah, sure! :)

From the satellites information comes down!

Perhaps one of the most fascinating technologies empowered by solid-state devices is data communication and processing. I tried to express the peak of humanity, hehe "peak" (as well as IC design) with space technologies. My design entry contains an outline graphic of the Soyuz capsule, which is used for bringing in and out astronauts to the international space station (ISS) every 200 days. Keeping continents connected wouldn't have been possible without geostationary satellites. Similarly the ISS also relies on communication satellites, which is why my design also includes small satellite symbols surrounding the Soyuz capsule. All of that would not be possible without microchips, hence, the big chip with the SSCS logo at the center, linking the Earth and space.

Creating a hero of the IC designer is a rather hard and ambitious task, as solid-state technologies are so much embedded in today's life, that makes it hard for one to decide on the coolest application made possible by ICs.

Huge credit goes to my cousin (Queller 4) for giving a hand with the drawing.

Date:Sat Jan 14 10:54:30 GMT 2017


What is the current state of microelectronics outreach anyway?

a.k.a. the magic smoke got let out, so it doesn't work anymore

Yesterday on a pop-sci talk I heard one of the presenters say "robotics is the main reason for the emergence of self-driving cars and the world we know today," as if that could be a rock solid argument. It reminded me of a big misconception that is etched into the brains of general public, that all those fancy fields; robotics, artificial intelligence or machine learning play a major role in the development of our modern world. Perhaps they are right to a serious extent, except for that they blunder a significant chunk from the puzzle.

That chunk I call microelectronics which goes hand-in-hand with materials science, physics and all the brave engineering behind modern computing systems. Before reaching the pinnacle of our age — alias current affairs in artificial intelligence — a long way has been paved by generations of multi-disciplinary scientists and engineers towards building the computing infrastructures we know today. Unfortunately, nor microelectronics or materials science come out to be as prolific to the bare eye as their neighbouring fields, hence, the public's general bias and black-box awareness of the actual technology drivers. Ask your average Joe whether has heard of material science; chances are he has a vague idea, but yet, much more ambiguous than his image about Tesla's new self-driving car. So what or who brings this dissonant knowledge gap?

That's a surprisingly tough question to answer. For one thing though, we can definitely try pointing out some of the suspects:

1. Microelectronics could be very confusing — it deals with signals and processes that appear to be virtual, if not even magical; they cannot be seen or felt, have no smell and are squeezed within areas just about the size of a grain of sugar. It is so confusing to the public that it has led to popular myths following a post-hoc logic such as the one about the magic smoke: once it gets let out the chip doesn't work anymore, hence, to get it back up and running you just need a refill. That's what all those engineer ninjas do all day and night, right?

2. The field is not run by a single engineer ninja — another misconception is that our sphere is typically composed of "nerds" working alone in dazzling basements having no connection to the outside world. Such ideas prematurely put off all general interest in public towards anything "nerdy" as most of us are "pro people persons". That actually resonates well with superhero fiction movies like October Sky or Iron Man, where a rock-star engineer does it all by himself, being indifferent to anyone getting on his way. In reality I know no engineer working like that. In reverse — microelectronics is a very collaborative field and, in fact, most present day electronics is a product of extensive communication between various "Homo sapiens". We are cool people talking often with each other, and above all, we do not work in basements!

3. Popularizing is hard — when speaking in public, not only can you not show any big physical objects (e.g. vs. the case of a funny walking AI robot) but when presenting, one is typically limited to speaking numbers, or showing colorful polygon-o-fractal pictures at its best. All of that typically tends to induce boredom in the audience. I have so far given a few introductory talks about the field and I've learnt that public, in general, does not even differentiate analog from digital. Then what is one micro Watt anyway?

4. Vetoed speech — most engineers boiling in these industries are strictly prohibited to talk about their work. This automatically shrinks down the outreach producers to those in academia and perhaps some individual hooligans. But it is the chefs from the kitchen corner that keep the most delightful stories to tell.

5. Access to technology — while this is constantly evolving, currently only few of us are blessed to have the keys to silicon foundries as well as the complex custom software needed to create a chip. I'm not even mentioning the knowledge factor here. The reason here resides partly in pt. 1 and the fact this gear is expensive. Not every hobbyist can afford 60 K€ for a chip fabrication run. Also, sometimes even if you have the money you cannot access just any process you like due some political reasons. The good news is that there is a positive change towards process accessibility owing to the Multi Project Wafer (MPW) and Multi Layer Mask (MLM) services, now commonly offered by major foundries and coordinating institutions. It is still expensive though, but the trend is changing to the better.

Perhaps there are even more obstacles hindering the outreach of this cocktail of sciences which drive the electronics industry today. It is likely though, that public awareness will grow with time, but so far, to help make this happen, we should try to ring the bell a bit more often.

Date:Fri Dec 30 11:40:29 CET 2016


Trust NOT fake chips!

I'd like to share some recent experiences in using fake chips and perhaps point out the obvious:


Especially in combination with other, not-so-cheap hardware. In my case, having no backup boards meant a sure stalling of my work for a few days until the newly ordered boards arrive, plus two fists of cash poured down the bin.

Spartan survived the battle with China with only two pin casualties

You might be wondering: what's his problem with using non-genuine clone chips, as long as they in fact do work? Well, I like them too, and I've used plenty of these in the past. However, as we shall see further, my problem is reliability and undocumented "features". Especially the nasty ones.

Background of the story:

I had to interface UART to a Spartan 6 LX150 chip, which I use for setting up some of the internals of my FPGA design, which then also sets the SPI module of my testchips. While constructing the digital system, I decided to use some of the USB-UART adapter boards out there on ebay, typically employing the notorious FT232 chip. So I bought a bunch of these (the price of $1 shipping included is very appealing), and because I know that there are some supereal fake FT232 chips out there being blackedout in software by the original FTDI driver, I bought a handful of different types from various vendors.

Cheap USB - UART dongles

After the parcels arrived, I discovered the CH340G chip, which is manufactured by the Big semiconductor player "Nanjing QinHeng Electronics Co.,Ltd.", offering a cheap alternative to the FT232. So I decided to pick and use that chip instead. The rest of the boards definitely used fake FT232s, which made me take the decision to use at least a genuine part from a Chinese vendor: it works, right?

And it did! I had been developing my system with this IC for about a month. Well, not for long: in a few cases, I would end up discovering that at certain conditions, the CH340G enters in some kind of latch-up state, and heats up to an unbearable temperature of over 80 deg C. It turns out that while doing this, its on-board 5 V to 3.3 V LDO fails as well (?), feeding out the deadly 5V out to my costly Spartan FPGA. Crabs! Crabs! Crabs! So I ended up popping two pins (PMOS of the LVCMOS33 driver popped, stuck to weak high, NMOS pulling down just about a few tens of milivolts) out of BANK 2. Here:

NFET pulling dowm, but the PFET has popped...

Very little is known about what's there inside the chip that manages the output voltages, although I wouldn't be extremely surprised if these guys have put just a huge resistive divider, ensuring a warm winter for all the Swedish, Norwegian and Finnish population. I really hope Zeptobars or JohnDMcMaster at siliconpr0n open the lid of that sucker one day. Reversing the board yields a wiring scheme which suggests that there is some kind of regulation.

Regulation in CH340G

Note the jumper bridging the 3V3 LDO output (low bandwidth LDO with external cap) with the 5V supply. For those who can read Chinese, here's its rich datasheet.

Oddly enough, if you turn off the power of the CH340G, let it cool down and turn it on again, the chip preserves its normal operation... until next time. I figured out it goes into latchup even when its power supply spikes and/or is unclean. Also perhaps a simple ground bounce glitch might have triggered it while connecting up the Tx/Rx lines to my board while being powered. And this is definitely not just an odd defective chip, I can reproduce the problem in all of the CH340G dongles I have here. Perhaps a design problem? Or in the best case a defective wafer lot which slipped in?

Finally, although it's normal that sh@t happens sometimes, next time please double check the vendors and quality of the parts you use... also, when buying an adapter, try finding one with opto-isolation.

And here's my final word - Crabs!

Crabs! Crabs! Crabs!

Date:Sun Nov 25 16:01:39 CET 2016