homelist of postsdocs about & FAQ

with an emphasis on VLSI, but probably applicable to any other eng-sci field

If one hasn't been showered with job offers already, chances are high he has had to send that sacred job application at some point. Here's my list of six questions one should (must?) ask along with the necessary work-related topics when seeking for a new job.

Work and work environment — As an employee you'll most likely spend 9+ hours daily at the job and you must be happy with what you do. Make sure you go check out the working conditions before accepting an offer, even if the office turns out to be on the dark side of the moon – do that! You should never accept blind offers based solely on telephonic interviews, unless you are super desperate and have absolutely no other choice. Not knowing what to expect when on your first day at the job might leave you disappointed. Never judge your workplace by its name and/or reputation.

Meet coworkers — Another important reason why you should visit your prospective employer is to meet your coworkers. Make sure you meet every one aboard the team. Typically, good groups will set you up on private interviews with future colleagues, which is an excellent opportunity for you (and them) to see whether you'll like each other. Are they...eeergh... idiots, slackers? Yes? Run fast!

Design practices — The individual private meetings are an excellent opportunity for you to ask more about the actual job, as well as getting a glimpse of their design practices. Are they trying to save from licensing costs by torturing their engineers do pointless heroisms? Just so the corporate boss can show off and say he's a great manager who just saved the company three bucks on behalf of your nervous system. This is also the time for you to ask counter-questions so you can see whether you should run fast.

The future — The group's future directly impacts you so don't hold your breath. However, be cautious, as there's a chance you'll hear a ton of lies on how pink the situation at the company currently is, expansion, profit, growth... You might also get a counter-question about your future vision (or whatever). Be careful what you're answering as such questions might have nothing to do with your job, but your employer might be just fishing and checking out what's under your hood. Here's a classic (in case you're applying for a jr. position) – "In the future would you like to take the management path or would you rather stick to R&D?" Remember what you're applying for, if you're asked anything similar be sure it's a trap.

Know your value — It really depends on your skills as well as the country and company you are applying at. Pay-related discussions might mostly be a trap for young players, but generally speaking the VLSI industry is pretty uniform and honest. If you are applying in the US or country with capitalistic views there's a high chance you get an offer that barely reaches the industry's mean level of pay. Don't be shy asking for more, but be careful – know your value, you cannot really ask 20x more than what you're offered initially... well, except for some special cases...

Backgrounds — Do your homework. Check the background of the group you're applying to. Ask former employees, be a detective, stalker, or however you want to call it. Glassdoor is one starting point.

Make sure you explore your options thoroughly!

Date:Thu Apr 06 14:02:09 GMT 2017

varning – det inlägg är off-topic – läser du på egen risk

Yesterday I hopped over to one of the regular weekly PhD Tea meetings at the physics department of Sofia university. These are informal meetings run by the some of the nicest PhD students from the physics and (sometimes) chemistry/biology departments, so I typically try to pay a visit on some rare occasions when I'm there. Anyway, the topic of yesterday's talk was about molecular switching devices that could potentially replace CMOS one day. The presentation was executed in a superb fashion – probably one of the best appearances in Bulgarian I've listened to in the recent years. This together with the super exciting topic made me write a bit more about the devices, but an odd experience at the after-talk tea leads to this which I think is more important. I also hope this doesn't turn the blog into a philosophic one. Hardcore electronics on the way, I promise!

Let me give you a brief intro: I was super excited throughout most of the talk, even though I soon realized that the presented devices are way ahead (or behind?) of our time and it is likely that we won't see such replacing CMOS anytime soon. The focus of the presentation was on Tautomer-based switches. These organic compounds act as color filters which change their transmission peak between two different wavelengths (blue - red) when the acidity level (PH) of the environment they're residing is altered. It also turns out that this process is irreversible which is a topic of further investigation by the group.

I see more hope for such devices in color filter or bio-sensor applications rather than anything close to CMOS or electronics as it was presented. When I asked what the input stimulus to this device is and how could it be interfaced with an electric signal I got some bad looks from most of the (otherwise really friendly) people in the room i.e. why is that idiot asking this now?. I also asked how is it that an ogranic molecule could be faster than a few atom (7nm) Si transistor, whose switching effects occur on crystal rather than molecular levels? Ah well, it seems like asking such critical questions can bring you into trouble. I thought we're all seeking the truth in this room, but it turns out not really. Everyone else tried to compensate the discussion by asking nicely irrelevant questions about micromachines and whatnot, except for a few people who had a clue of what's going on but never dared to say anything.

Although, I was trying to be super friendly at this point, stressing that the answer doesn't really matter and most likely there's plenty of other exciting applications, I just felt like the bad work-bashing foreigner there, ah ah nobody can understand my thoughts... All of that reminded me of a quick rant by Derek Muller on the nature of asking uncomfortable questions. Let me finish off with that one:

People, if someone is asking quastions straight to the point, that doesn't really mean that they're being nasty and/or find no merit in your work. Please, shape up!

Date:Thu Apr 08 08:17:39 GMT 2017

Date:Sat Apr 08 12:26:08 CET 2017

To PhD or not to PhD?

Lately, some of my fellow lab rat mates are slowly transitioning out of academia as if someone's spread deadly poison around the corner. As a result, a handful of hot and furious coffee-break chats arose, all on the efficiency of academia and the meaning of doctoral studies. In the end the debate didn't lead to any final conclusions, but I thought I'd put my thoughts into writing.

So, where did it all began? It is no secret that research in engineering (here referring from a semiconductors guy point of view, but I believe the situation in the rest of the engineering and applied physics world is not much different either) is mostly conducted in industrial entities. Nowadays academia has a hard time providing that manpower and financial resource needed to complete a few silicon iterations of a complex VLSI (or whatever) system. That immediately brought the assertions from some colleagues that academia is a "waste of time" and "super inefficient", while joining industry would bring you that quest for innovation and knowledge much faster. My answer, mostly as a spectator to this debate is: "it depends".

It depends on what you really want to do. If you are starting a PhD just because you think that someone (your supervisor) will be holding your hand, and expect that you will be coached on a daily basis (joining because of these extra courses) you are probably doing it wrong. If you prefer this model it may be easier to join an industrial group where you will be (as a fresh graduate) typically given specific orders, lots of teaching, lowered expectations as well as minimal freedom (here it also depends on the industrial group too). It is also wrong thinking that after completion that doctor's degree will immediately embark you on a senior position – nope, not necessarily. Please don't misunderstand me, there is nothing wrong with wanting to follow the taught model which will eventually lead you to being a professional, whatever that means. It's just that you risk running into a doctorate which will turn nightmare for you.

Anyhow, doing a PhD, as opposed to joining industry, brings young players the possibility to gain knowledge and shine very quickly just because there's virtually no obstacles (bar some academic idiotizms) to what you are allowed to do. In contrast, blue sky R&D in the corporate world is extremely rare and is typically reserved to seniors. A lot of the innovation occurring in companies is monetarily driven and follows certain goals which can sometimes squeeze the joy out of work. And again: it depends, it depends, depends! Surely access to fun technology is limited in academia, but unless you end up in a very shallow place I'm sure you'll find a way through to some good enough semiconductor process, or whatever it is that you need.

I think the most important bit to consider when starting a PhD is that to be successful you should be self-driven and self-motivated. When doing a doctorate one typically devotes its time almost entirely on his own project. You are your own boss and 3/4 of the success of your project depends entirely on you. On the plus side, the other 1/4 of your project is steered by your supervisor and, in contrast with doing research entirely on your own, you are at least taken care of project funding. That way you don't necessarily have to do the social part of science i.e. spreading the word, writing grant proposals, PR-engineering and taking care of work facilities, etc... Well, this doesn't mean that you shouldn't if there is a chance to do so. A doctorate as opposed to industry allows you to also develop other skills, which may not be entirely linked deeply with your scientific research, but these are perhaps sometimes even more useful than the new transistor sizing technique you've just discovered. Learning to deal with all sorts of characters is one of the most valuable skills I am beginning to acquire here in academia.

Being happy and feeling beneficial is of highest importance and you can only find out if the Third acaremic stage is for you by investigating more on the topic. So if you are hesitant of what you should do ask around, be inquisitive, talk with various current and former employees, alumni and students, compare - contrast. Don't be lazy, do your homework before it's even been assigned!

Date:Sun Apr 02 10:31:21 GMT 2017

A mixed-signal testchip sequencer solution

Every mixed-signal system needs some form of a digital sequencing which controls the internal blocks. Typically for test systems it is highly desirable that this sequencer is also flexible. While there are a number of ways of achieveing this, I am sharing a tool and perhaps a solution for generating control signals for testchips based on an external FPGA-based ROM memory block. This approach may not be the most efficient when it comes to silicon real estate or power. However, what I like in this methodology is that it is extremely flexible, and yet is relatively simple to work with. Fiddling with dedicated state machines is perhaps the most efficient methodology but it is a bit more time consuming for inexperienced people in digital design as myself.

An example configuration of a Device-Under-Test sequencer system

An FPGA contains a RAM/ROM block, together with some control circuitry. Pretty simple huh? And it truly is. The UART module clocks-in the memory content to the write and read address generator, which loads the data into the memory. After the memory is initialized, all the address generator does is to loop through the RAM's depth (addresses).

One can generate the RAM block using the IPcore generator in Xilinx's Vivado. If you use other vendors I am sure they would be offering similar tools. What you need to take care of is the memory's width, which is driven by the number of sequener signals you need, as well as its depth — depends on the sequencer resolution you are targeting, as well as its length. For most cases, if you use a large FPGA you shouldn't run out of dedicated memory block space. Here's an example screenshot oof Xilinx's IPcore generator:

Screenshot of Xilix's IPcore memory generator tool.

There's plenty of ways to generate memories with various tools. If one has to write the memory content bit-by-bit it'll take him, perhaps not years, but hours. Fiddling with raw "1/0" text files, boxes, csv, or whatever else is a painful task.

To try and automate things a little bit, I created a tiny assembler instruction interpreter, which compiles memory machine code, which I can then directly load into the memory via the UART. This is currently a work in progress, however, I have put a plenty of code comments, and I've tried to keep things clean. Hehe, well, as much as perl code can be made clean.

The instruction list is currently embedded into the code and remains under the parse_line() subroutine, where you can swap bit posisions, instruction syntax and add new functionality. There are two global definitions in the main() subroutine needed to be taken care of. These are the: \$ram_width and \$ram_depth. The latter define the exact size of the memory file and must match with the ones used during the generation of the IP core, as well as the address length of the memory addresser module. Here's how the memory content file looks like:


memory_initialization_vector=
00000100111010011001111010100000,
00000100111010011001111010100000,
00000100111010011001111010100000,
00000000111110011001100011100000,
00000000111110011001100011100000,
00000000111010011111110011100000,
00000000111010011110110011100000,
00000000111010011110110011100000,
00000000111010011110110011100000,
00000000111010011111110011100000,
...


Each instruction, when called, alters a specific bit (also may be multiple bits) in the memory. Right now the tool has a set of 30ish instructions. Here's a complete list:


;|------------------------------------------------------------------|
;| 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                                           |
;| 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                             |
;| 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                                       |
;|------------------------------------------------------------------|



I tried to kind-of preserve the classic assembler language constructs as much as I could, e.g. comments use ";", to load a signal you start with MOV, then issue the command e.g. ROW followed by its specific bit e.g. 0x01 and finally the value to be written. The NOP instructions stall the system (copy the previous memory line for N cycles), LOAD PAR pushes the next instructions into the PAR register, afterwards SET PAR sets the modified instructions after LOAD PAR, in parallel. Here's a sample code:

START

;|----------------------------|
;| Initialize startup signals |
;|----------------------------|

MOV REF 0x03 1		; ota_dyn_pon always @ '1'
MOV CNT 0x04 1		; count_updn '1'
MOV CNT 0x01 1		; count_rst '1'
MOV CNT 0x05 1		; count_inc_one '1'
MOV CNT 0x08 1		; count_lsb_clk '1'
MOV MEM 0x00 1		; count_mem_wr '1'
MOV FVAL 0x00 1 	; FVAL '1'
MOV COM 0x01 1		; comp_dyn_pon always @ '1'

;|-----------------|
;| Sequencer start |
;|-----------------|

; references and shr sampling
MOV SHX 0x00 1		; shr
MOV REF 0x01 1		; ref_vref_sh
MOV REF 0x00 1		; ref_vref_ramp_rst
MOV COM 0x00 1		; comp_bias_sh
SET PAR

NOP 22			; halt 220 ns - phase 1 in vref_ramp

MOV REF 0x01 0		; vref_sh
SET PAR
NOP 8			; halt 80 ns
MOV REF 0x02 0		; cla off
NOP 6

; reset counter
MOV CNT 0x04 0
MOV CNT 0x01 0
MOV CNT 0x05 0
SET PAR
NOP 2
MOV CNT 0x04 1
MOV CNT 0x01 1
MOV CNT 0x05 1
SET PAR
NOP

NOP 52			; halt 520 ns - wait for ramp buffer to settle

MOV SER 0x00 1		; stop data serialization out
NOP 34			; prehalt - wait SHA

MOV SHX 0x00 0		; complete shr sampling
NOP 2

; start count + ramp current
MOV REF 0x00 0
MOV CNT 0x00 1
SET PAR

NOP 102 		; halt 1024 ns (ramp slew time)

MOV CNT 0x00 0		; stop counter
MOV REF 0x00 1		; stop ramp current
...


The execution of the script is rather simple:

asmitp.pl program.asm -o instr.coe

Future to do:

1. Put instruction table setting in an external file

2. Add a vec and vcd file generation switch, to allow integration with spectre/spice

3. Implement JUMP instruction (loop)

4. Implement conditional statements

5. Create pdf documentation

If you find this approach appealing, please feel free to fork my repo or write to me so that I can add you as a contributor and develop these tools further. Cheers ;)

Date:Sun Mar 19 13:23:26 CET 2017