So the thing I spent the most spare time on this last week has been designing a FPGA-based PCI card. This is something I’ve wanted to do for some time now (and have an earlier unfinished attempt that was far more complex), but I have recently encountered some inspiration for a board that will be somewhat useful, or at least interesting.

This board isn’t really much of anything special, but it will fill a specific niche, and will be sufficient to try out a lot of interesting things I’ve been thinking of in the PCI space.

So, This isn’t going to be an exceptionally impressive post, but I did collect screenshots from various stages of the board’s development, and  I’ll also discuss the design decisions behind this board.

On with the screenshots!

(Just getting started, have finished the core of the schematic, have all the power and parts set up)

(After working out the pin mappings from FPGA to PCI card, adding some PCI-related capacitors)

(Fixed the PCI – fpga mappings slightly and started routing. This is a few hours of progress, but it takes a lot of effort…)

(Continuing to route PCI-FPGA traces)

(Ah. Done with that. A few things move around to pack better)

(A lot of other stuff gets routed! It’s not as hard as the PCI stuff :)

And the final part done: Routing the power pins on the FPGA. (And a few pesky remaining traces due to an error)

The signals on the board are now 100% routed, but the board is still not complete, I have a number of cosmetic things to do still, moving component text around and adding some descriptive text. Also planning to add ground fills to unused board space.

So, some of you may have guessed my inspiration for this board, it’s pretty similar to those “BIOS POST code display” boards – Yup, and that is one of the intended uses of this board, but by no means all it can do. This board has been designed so it can also easily work as a standalone development board for general purpose FPGA experimentation, and it is also my intention to build a full PCI Device using this board as well. Of course it’s not going to do much with this board alone, but the I/O header should allow for some interesting external devices if I want to try anything specific.

Some more specific details of the design:

• The PCB is routed with 8 mil traces (and 8 mil spacing) – this makes it pretty challenging to route, but it was fun.
• If operating only as a PCI card, it would be possible to remove several components (the power supply stuff and clock  on the right side of the board), without affecting anything
• The FPGA in this case is a Spartan-3AN (XC3S50AN – not incredibly big but will work here) – the 3AN series, as opposed to most other Spartan-3 FPGAs, have onboard flash memory to store configuration data (otherwise an external chip would be needed to configure from, eating up more I/O pins)
• There are 4 I/O pushbutton switches, and an 8-switch dipswitch
• The PRSNT1# and PRSNT2# lines on the PCI connector are used to indicate to the system board whether or not a PCI card is present in a given slot. This board has solder-bridge jumpers potentially connecting those to ground (to indicate presence); In the case of a BIOS POST card we don’t actually want to indicate to the system that there is a board present, as we can get what we want without being a “full” pci device. But bridging those jumpers will also allow a full PCI device to be designed.
• The PCI connector has been routed by flipping back-side signals to the top side, and trying to align the PCI signals to the FPGA pins before even starting that; On the back side, I have a thick 3.3V trace running along the length of the connector, and a GND trace above that, which makes it relatively easy to keep all the power lines connected properly. This is the fourth or so revision of my process for doing this, and it’s pretty effective – but I noticed yet another optimization… If I also were to match up the FPGA 3.3V pins with the front-side PCI 3.3V pins, it would further reduce the complexity of routing the connector, and I’d get better connected power pins as well – Something to consider for next time, the time that goes into planning and routing the PCI connector to a FPGA is pretty significant.

I am planning to finish up the design work and get some of these boards produced in the next few days – and when I get them back and get some stuff working on them, I’ll post again on how it went, how PCI works, and other sorts of interesting things :)

Update: After a little bit more effort, I have deemed the board “complete”. Now working on getting it fabricated…

As promised, this week’s project entry is much less entertaining;

I did attempt to get this project a bit further today but distractions have taken their toll. Expect this one to come up again in the future :)

So, not too long ago I had the bright idea to build a little USB stick; My motives at the time were apparently highly questionable, so I am here about a month later with a fairly limited use USB stick

One of my major goals behind this project was to have an excuse to work out the details of USB, and try some stuff out, which I’m still doing now. Once I get that done with, I will attempt to explain just how all that works; USB is a bit elaborate, but it’s increasingly interesting and important these days, as serial and parallel ports are becoming more rare. I have another project along these lines too, but it’s quite a bit more low-level.

For this post though, I’m just talking about the hardware design of this project.

The board was really quickly designed; I thought (for some reason) that it would be neat to have a little USB stick that had an RGB LED, and a speaker to output audio. So, that’s what I made :)

This stick is based around a Atmel ATMega32U2 microcontroller, which has  built-in USB device support. It requires a pretty stable clock source in order to use USB, so I picked an 8MHz crystal for it. I found a reasonably cheap RGB LED on digikey, and added some passives, an op amp, and a tiny speaker I had around for sound.

PCB design for the board (It looks confusing because I’ve included a lot of layers, but you don’t usually work with all of those layers on, you can just look at the front/back individually)

And, actual implementation of the board!

I’m sure you can see the mistakes in this one, but probably not quite all of them. Things to check for next time I make a really rushed design:

• Make sure TFQFP package reflects reality. Not sure how but my pads start at the very tip of the pins :) I must have been looking at the wrong package type for spacing info.
• Enhance font size on 0402 components (see the 2 tiny capacitors by the crystal? They’re C1 and C2 in the PCB design image.)
• Make sure crystal doesn’t overlap other components (fortunately the crystal body isn’t connected to anything, so it can be near / short against USB V+ without issue.)
• Pay closer attention to drill sizes. USB header shield doesn’t actually fit through the holes I designed it for. I have a caliper so these sorts of mistakes are just silly :)

Some other miscellaneous design notes

• This AVR has a 3 PWM channels based on one 16bit timer – this is being used for the RGB LED
• The audio output is a PWM channel on another 8bit timer – it’s feeding through a resistor into a cap, which produces a pretty stable voltage level based on the PWM duty cycle. Then the opamp is buffering that voltage level and outputting it to the speaker. It should be able to do 8bit audio with good quality, though it’s certainly not a perfect DAC.

So, not bad for a few hours of looking for parts and hacking some weekend, I’m not actually sure if the utter lack of any serious purpose makes this a good or bad project :)

Anyway, I’m off now, as I have some other project ideas calling me now…  Perhaps this motivation drought has ended.

I went and found a few chips I had around, and got some sandpaper; For this test I just used 220, 600, 1500, and 2500 grit sandpaper; I had a few others around but these worked pretty well. The microscope is pretty nice, and has essentially two zoom settings, at around 20x and around 400x (or so is claimed). As such, a lot of the “chip-size” images are taken at the 20x level, and then I have zoomed in to the 400x level, taken sets of images, and stitched them together for full die images. Die images were stitched together using Microsoft ICE, a free tool that does stuff like that, it has worked pretty well for me here.

The first of the chips was some chip I had desoldered from a board I had around a very long time ago; I had no idea what it was, but it appears to be a MC34072 dual op-amp

On with the sandpaper; It takes a bit of time to sand down to the die layer, so patience is important here.

I didn’t see any of the bond wires in this chip, possibly because I wasn’t sure what to be looking for. They aren’t obvious in these pictures either, I’m not sure why. After much sanding  though I could see the die

I took a full set of images at the higher magnification level at this point, though it’s pretty clear the chip packaging material is still covering a lot of the die. (this is a big image! click to zoom in!). The die is upside-down in the chip orientation I chose, so I’ve rotated the die images.

That’s pretty neat, though I’ve taken a little bit of the corner of the die off already. I spent a bit more time sanding with high grit (1500) to try to clean up the rest of the die- and while I lost some of the corners I’ve made the rest of the die a lot more visible.

That one is pretty easy to follow, it’s a very big process as it was designed apparently a long time ago (I wonder if the “72″ is the year the design was created). Unfortunately none of the other chips in this set are quite so nice :)

Also, even though you can very clearly see the metal traces in this die, what you don’t really see are the doped regions of the silicon underneath, so it’s difficult at best to infer the transistors being used. In some regions it’s possible to tell that something is different underneath (see some areas where the blue changes to dark gray), but I’m not sure what to infer from that (possibly that is material being used for resistors).

The next chip I set out to decap is one of my favorites, the Xilinx XC9572XL CPLD:

Bond wires! They actually serve as a reasonably good guide to know how well you are aligned with the die, and what areas you need to sand further so the die is more parallel to your sanded surface.

You can see that my alignment has improved but isn’t perfect yet; Also at this point I took a closer look at the bond wires (at 400x)

Can’t see the die at all yet, just the bond wires and packaging material. Continuing to sand…

Getting closer and starting to see the die…

And finally breaking through the filler material to exposing the actual die surface! I then sanded a bit further with really high grit and took a few sets of images for the full die image. Ultimately I wound up using a slightly rotated orientation for taking pictures of this die, as I noticed the LED illumination at that angle made it easier to see many of the details. This method is far from perfect though – there’s still a lot of filler on the die which is only partly transparent, but I didn’t want to sand the edges away (also, too lazy now.).

Partly due to the microscope’s cheap optics and camera, and also due to the material remaining on the die, it’s very hard to discern details at this level, but you can see the larger elements in use and how they are generally connected together.

And now a very cheap AVR Chip I had around, this is an ATTiny48:

I got down to the die level without too much trouble, though I exposed one corner a lot earlier than the rest of it. After looking at that one corner closer, I decided it was important to take more of the filler material off

After taking more material off I do have a much clearer view of the die but  managed to badly mess up the one corner. I did get a (mostly) complete die image – there’s a black area I somehow managed to miss :)

It’s a pretty small process, but you can generally identify the regions and their purposes. I’m not an expert on this stuff yet, but my current assumption is the shiny stuff in the bottom center is flash, the nice structured grid in the upper middle of the chip is sram, and most of the stuff above/around it is the uC logic (But I may be completely incorrect, I can see other possible interpretations.)

That leaves one more chip… This chip was ill fated in many ways; first it’s a bit too big for me to be able to move the microscope around above it well – but I was a bit less than patient with decapping it, and managed to seriously scratch up the die. The die showed up earlier than I thought it would, but I’ll let the images tell the story:

Oops. I cleaned up the remaining die a bit and tried to get some decent pictures, but this chip is on a much smaller process than the others and I couldn’t see much of anything that was big enough to see the structure of.

Overall this has been a pretty entertaining project for me. I think I will definitely have to try this using an acid rather than sandpaper some time in the future, and I’m already looking at better microscopes for when I get more serious with this.

In the meantime though, I hope you’ve found this as interesting as I have – thanks for reading!

Tune in next week for… Something obviously less awesome :)

This week’s project is a little bit more complex than the last one, but it’s still pretty small. It’s a small board that drives an 8×8 LED matrix. It’s actually a pretty silly project because I only have a dozen or so of these LED Matrices around (I’m not sure I can even buy these specific matrices anymore) – I actually bought them back in 2005 – they’re 8×8 arrays of red/green LEDs. They’re organized with a common anode per row, and then red/green cathodes per column. (Davr also got some, and has a number of entries on his blog about his efforts)

Just for fun, I set out to design a board that would sit on the back of the LED matrix and make it easy to drive from a small microcontroller. My design goals were to have current drivers on the common anodes, and provide a shift register to easily configure the other LEDs. I also wanted to be able to easily chain multiple boards together to make a much longer array. (Read on for more details about the design…)

So, after measuring the part and setting up a part in eagle for the LED matrix, I set to work on a circuit board.

This part I actually generated a timelapse video of – you can see it here:  PCB design: An LED Matrix Controller board

The video may be a little boring (perhaps I should add music or something), but my process went as follows:

First I had to design an interface, a set of pins that would let me control the board, specifying what to display and how. I settled on a pretty simple design: There is a power and ground pin, 3 pins for selecting one of the 8 rows, and finally a serial interface into a shift register for providing the graphical data. The serial interface consists of SCLK, SDATA, and LATCH – Upon a rising edge of SCLK, the internal shift register will be advanced as the value of SDATA is pushed in. LATCH serves dual duty; a rising edge of LATCH causes the shift register’s value to be latched to the display output, and also LATCH serves as an output enable, LEDs only light up when LATCH is high.

Additionally, since I wanted this module to be chainable, I also need a second interface on the other side of the board to attach to a second board – Most of the signals are the same, but the data signal on the other side has to be an output from the shift register – just another thing to consider. I used a CPLD (the XC9572XL again!)  to actually do all the intelligent work, and for switching the power to the common anodes, I used some P-FETs which are switched by the CPLD.

After getting the circuit straight, it was a bit of a challenge to actually decide what CPLD pins to use, and how exactly to lay out the board. This is always an interesting problem, and sometimes difficult, but when you keep your priorities straight it is reasonably easy to get past. In my case, power/GND and the Jtag pins dictated how certain parts of my board needed to work, and as with most cpld and fpga designs,  most of the signals could have been connected to any of the pins on the CPLD. I took care to connect the serial clock pin to one of the global clock pins on the CPLD, but the majority of the pins were just connected to nearby CPLD pins for convenience. Ultimately I ended up using a 45-degree  orientation for my CPLD, which I think simplified a lot of the routing.

Once the pin mappings were decided, routing was pretty simple, and didn’t take too much time; I was able to quickly route the majority of the traces, only having to move some things around for the last few traces – And that’s where the timelapse video ends. Afterwards I did wind up increasing the trace width just a bit, adding a bypass cap for the CPLD (which is important enough normally, but really important when switching power), and just cleaning some things up.

PCB Design for the LED Matrix board

So, I submitted some PCBs to be produced via BatchPCB, and  waited a few weeks for them to show up.

A few weeks pass, and they do finally show up!

It did not take long to solder one together, so the second phase of this project began: designing the CPLD code. While I designed the interface with the possibility of implementing PWM in mind (to vary the brightness of the LEDs), I opted to start with the simplest usable design first. My VHDL code which controls the CPLD performs essentially the following operations:

• Decodes the ROW0..2 to enable one of the 8 common row FETs (sets one line to low, all others to high)
• Has an internal 16bit array for the row data (8 red, 8 green LEDs). If LATCH is high, the inverse of these values will be exposed to the LEDs (as low = on), otherwise the LEDs will be off (pulled high)
• Has an internal 16bit shift register which is shifted on the rising edge of SCK (new bit is shifted in from SDATA, and the last bit is always exposed as SDATA on the other side of the board)
• When Latch transitions from low->high, the shift register is latched into the internal LED data array.

And, that’s the complete system! It is ntended to be controlled with 6 I/O pins, but you can, if you don’t mind a little bit of light bleeding, even connect SCK and Latch together and drive it with only 5 pins, which I did for testing (using an ATTiny85 chip). My ideas for improvement are a bit limited because there isn’t really much space available on this CPLD for elaborate designs… I could abandon the idea of having a separate shift register and internal display register, and use a few bits per pixel to hold a several-bit-per-pixel value, and use the LATCH signal both as a display enable and also to advance a PWM clock. The problem with this though is then setup time becomes pretty high per row (as you can no longer shift new data in the background – shifted data would be immediately visible), so you have to update at a lower frequency.

The JTAG connector on the bottom edge works pretty well, though it took a few attempts before I held the connector against it firmly and consistently enough to program the CPLD.

(Some pictures above… The soldered board, and also a test pattern – I could make a happy face, but davr already did so what’s the point? ;) The red LEDs are only on due to bleeding as the line is visible as the data is being shifted. This would be avoided if I were using 6 I/O pins and using LATCH as intended, but using the attiny85, I only have 5 practical I/O pins)

Overall, it was a pretty entertaining project, though I probably won’t do much further with it. It was very much a spur of the moment project, so I didn’t really have any deep plans. While I could chain many of these together I would start to have serious problems supplying the power easily, as the estimated maximum of 400mA per board is actually a significant amount of power – my present lab equipment doesn’t include a proper power supply, so maybe a future project will be to build some higher power 3.3V power supplies :)

Some Theory – A closer look at the details

(For those of you who aren’t deeply familiar with this stuff, which might be most of you.)

This matrix is an 8×8 array of bicolor Red/Green LEDs; to make it easier to deal with, instead of just giving you pins for each LED, they give you buses; In this case they connect the Anodes (positive terminals) of each row and give you one pin per row-anode-bus. Then they also  connect the red and green Cathodes (independently) to column buses, and expose those buses. You can’t tell this sort of system to “hold” a specific image, it’s designed for you to only draw one row at a time – however, due to Persistence of Vision effects, you can quickly alternate between driving each row with a different pattern, and it will appear that the entire matrix is on at once. The points behind this are signal management and cost… This module gives you 8 pins for common row anodes, 8 pins for common red cathodes, and 8 pins for common green cathodes – a total of 24 pins. Actually wiring each LED independently would give you 64 LEDs * 3 pins per LED = 192 pins… Not nearly as easy to connect; and most sane designers would just connect the rows and columns together in a logical fashion on the PCB. Driving each LED independently is arguably just a bit less than 8 times as expensive as driving 8 sets of 8 LEDs and switching between them (even before you consider the PCB routing logistics to drive each LED independently!) In some systems (like giant full color LED display signs, and such) it does make sense to use per-LED driver circuitry in order to be as bright as possible, and they are rather expensive due to this and other factors :)

Some logistics have to be considered in a design like this – such as, just how much current is it going to draw? Assuming the CPLD is well programmed, at most 16 individual LEDs will be on at once. The LEDs have forward voltages of about 1.7-1.9V, and this board is driving them at 3.3V in series with 50 Ohm current limiting resistors. Walking through the power calculation, I’ll assume the LED has a 2.0V forward voltage drop (which is a worst case estimate), so the resistor will drop 1.3V when the LED circuit is switched on (as 2.0V + 1.3V = 3.3V); and as the voltage across the resistor is 1.3V, the current through the resistor (and as such, through the LED) will be 26mA (V = IR, or I = V/R, where V=1.3V, and R=50Ohm) – the reality is a little bit more complicated because LED voltage drops vary, and the CPLD will only allow so much current.

The CPLD needs to also turn individual rows on and off – but it can’t actually switch very much current on it’s own. As such, this design uses a FET that does the electrical heavy work, and the CPLD tells the FET to turn on and off. So how much current might a row take if it’s turned on? Assuming a worst case current of about 25mA per LED, the system will use 400mA if all 16 LEDs are on at once! (The CPLD by itself can only practically switch 20-30mA) I found a capable FET to handle this load though (Digikey part number DMP2004KDICT-ND) – which is a P-Channel FET capable of switching 600mA. All FETs essentially switch current flow on and off based on the voltage between the Gate and Source pins, but being a P-Channel FET means that the Source pin should be the highest voltage of the three, and it will switch on (“connect” the Source pin to the Drain pin) when the Gate’s voltage is less than the Source pin voltage by a certain amount. This FET has a switching voltage of 1V, so it’s “off” when the Gate voltage is > 2.3V, and “on” when the Gate voltage is < 2.3V – as such a logic low applied to the Gate pin turns the FET on.

Final note: A lot of these technical details are pretty shallow explanations; Things really do work this way, but there be dragons and missed details in all of the numbers I’ve given; here’s a small list of examples: The CPLD driving voltage actually depends on current, so it won’t be quite 3.3V – my example is a worst case estimate. You can see these pin driving traces sometimes in CPLD datasheets (And other times they’re linked: Xilinx FPGA/CPLD I/V Curves, see page 6 for XC9500XL family. Also, see Page 13 of the  CPLD I/O User Guide for more information on I/V curves). The FETs, too, add a resistance to the load passing through them (about 0.9 ohm in this case – this is shown on the Digikey page as “Rds On”, and will also be specified in the part datasheets), so that further reduces the 3.3V that I was assuming. On a completely different tangent, FETs are capable of a lot more than just turning on and off, though they are in fact really good just for switching on/off, which is why they’re used so extensively in modern electronics (CMOS digital logic is typically almost all FETs). If you want a good book that explains all the minute details for discrete circuit design, I highly recommend The Art of Electronics- It’s a little bit older, but presents most of the important concepts in electronics very clearly and in an easily approachable way.

(It’s over! Phew- that was long. Now I’m thinking about what to write about for next week… I have a good idea for next week, but beyond that it’s a bit hazy… I have literally piles of projects around here, the problem is almost none of them are done… Perhaps this will be an incentive to work harder! That can only be a good thing, right?)

So, not terribly long ago I decided it was really time to give microcontrollers another go; My history with microcontrollers in general has been a little sketchy, because not only are they pretty limited systems, but they don’t really allow a lot of creativity in solving your problems. Being mostly self-taught on ARM and x86 CPU architectures, the little 8-bit uCs generally seemed more like a pain than anything else.

However,  I was determined not to let my history deter me, and to try again. I ordered some AVR DIP chips for prototyping and a serial programming cable. Unforuntately, like so many well laid out plans, this didn’t wind up working out – not knowing too much about the AVR landscape, I had inadvertently ordered a serial programmer that requires an actual native serial port to work (it wouldn’t do anything with my USB-serial converter… And seriously, who has a native serial port around these days?)

Being incredibly stubborn and unwilling to  wait further to order yet another programmer, I decided to take matters into my own hands – After reading the AVR documentation on programming their chips (which is actually quite good), I put together a small CPLD based programmer which has served my needs. Read on for the full details…

The original version of the programmer was a tangled ball of wirewrap wire, tightly coupling the core components, and was fortunately soldered well enough to hold together for several weeks before the first PCB arrived. I built the programmer out of materials I had readily lying around, it consists of: A 3.3V regulator (At the time, I was going to run the AVR chips at 5V – and my CPLD is 3.3V with 5V tolerant IO), a CPLD (XC9572XL), a 50MHz clock generator, and a MAX3232 equivalent serial level shifter (and a few caps for good measure). I wrote some basic VHDL to speak serial and accept some basic commands to control some pins as GPIO, and then a powershell script (yes, a powershell script) that interfaced the serial port and performed the high level programming commands. It didn’t take too terribly long, and it did finally work! I got my AVR to blink an LED, such a worthy task of all this effort :)

Below is the evolution of versions of this project – First the tangled mess; Second was the first PCB revision, it added an LED and had a few minor pcb errors; And third is the second PCB revision – which has 2 LEDs (one red, one green) for status.

(Can you spot the PCB errors in rev 1?)

Another hurdle that had to be overcome was that of programming speed – using the CPLD just as GPIO worked, but manually sending a byte for each clock transition was pretty slow and tedious. So I revisited the CPLD firmware and added another mode for AVR programming, It’s a special command that operates on the following 4 bytes: for each of these bytes it will automatically generate clock transitions in sync with the serial state machine, and also send back the data received from the chip (which is also in sync with the serial state machine). This makes programming the chip approximately 16 times faster than it was – it’s not as fast as it can be but it’s pretty quick and only limited by the serial connection speed at this point.

So, while this project hasn’t precisely been a necessary one, it has actually been pretty interesting and useful. One of the nice things about having a few GPIO pins around is that I’ve actually reused this for other things as well, like dumping a serial eeprom :) (in fact I even wound up using the 4-byte serial mode for the EEProm serial transfer as well, it’s pretty much just a 32bit serial mode) – And I imagine this device may come in handy in the future too for similar things (though, it will probably become obsolete around the time my current big project is done… I’ll leave that one to your imagination for now.)

And finally, this project did indeed serve my original goal, I’ve continued to do some development for the AVR uC platform, and while I still would prefer a much more beefy CPU, I have to admit that these little chips are pretty intelligent choices for small cheap projects that need something “smart” but don’t need much in the way of power. As such, I have a few projects based around them – and while I don’t have too many projects involving uCs at the moment, they are likely to get more attention in the future.

Okay! So that’s the first one; I hope you found this entertaining, and who knows where this will go next week :)

Not all of the framework is in place for this project yet. I have a Subversion server and a bugtracker that are both partly ready, I expect to have both of them running correctly soon – they’ll be responsible for making this teamwork possible.
The code for this project will be closed source during development, until a certain level of completeness is reached (this has yet to be decided) – after which point, all the code will be released under the MIT source code license (this, too, is just the current plan, if the team has other ideas, it can change)
We will release binaries periodically, to allow people to test on their own, and to allow emu authors to get a good look at what problems exist.
If you would like to be involved with this project, please email me at sgstair [at] akkit [dot] org.

So, here’s the plan: I’m dropping the apprentice idea. If you wanted to be involved and wanted to learn something, you’re still welcome to ask me; I’m still interested in answering questions and pointing people in the right direction.
I still have a number of projects going on, and I would still like to allow members of the community to be involved with them, and I will still have high entry standards for joining such projects.

I’ll post on this blog when I have projects going on; I have one now (that I’ll post right after this post). If you want to be involved in a project, email me: sgstair [at] akkit [dot] org.
My criteria for allowing people onto projects is going to be entirely subjective, but things that I expect from people who are interested are: a good knowledge of C/C++, some understanding of the workings of the DS, and some understanding of how to write secure code. Other requirements will be present for more complex projects, of course… and some of those will be starting eventually.

Also, to all of you who participated in the first round of the apprentice exam – thanks! Sorry it didn’t go further in that form, but if you’re still interested.. that’s what this is for! I’m presently hesitating to send out the “results” of the first round, mainly due to the high subjectivity of my ratings; however if someone convinces me otherwise, I might reverse my position. I do hope to get to work with some of you in these coming projects :)