I’ve been working out the concepts in software using the modified USB stick (as I mentioned previously) but just haven’t had enough time to allocate to it yet. Soon, though.

This design is pretty simple; I have the microcontroller (ATMega32U2), a RGB LED, switch, and crystal – Then around that I am building a set of voltage level translation circuits for the jtag signals, and for additional inputs, outputs, and “pump” signals (which can strongly connect to a target’s V+ level, and drive a significant amount of current)

I’m including the JTAG interfaces I use commonly  on the board, and I have another additional “expansion” slot which I’ll be building new boards for to connect to yet other interfaces

Schematic done, decided on a rough layout and started placing parts.

I got the core signals routed, and routed the level shifted jtag signals around the board, connecting to the side connectors as they go.

Added most of the other level shifting signals

And now the design is essentially complete!

Added ground planes, and vias to keep them well connected / allow plenty of return paths.

At this point I thought I was done…. Only, oops, I connected the top 3 headers backwards;  I had gone off of the pinout of the socket they plug into. Fortunately I noticed this before trying to produce the board :)

Ahh, now they’re correct.

So I’m having this board produced pretty soon and will write up more on JTAG once I have done some stuff with this.

In other news I’m taking a vacation in about 2 weeks! No, I’m not going anywhere interesting, just visiting family, but perhaps I’ll have something fun to write about by then :) I certainly have plenty of things I want to do!

I’ve been using JTAG for many years now, which started with FPGAs, and has mostly been for CPLDs and FPGAs since- but it’s also a pretty widely used protocol for programming and debugging mid range microcontrollers all the way up to high end CPUs. I’ve always wanted to look into how JTAG worked in more depth, but never really had the time.

Now, I do have some time (and some projects which depend on JTAG hacking) – so this post will go into the world of JTAG.

Many of you have probably seen the following diagram, usually in some CPU or FPGA datasheet where it talks about the JTAG port. And it probably clicks to a degree, you see there’s a state model you can move around in, and the TMS signal causes that – but what doesn’t really get said is really a lot simpler than all that.

There are really only a few core truths and fundamental operations to know about when working with JTAG:

• There are 4 data lines important to JTAG: TDI, TDO, TMS, TCK – All of them are expected to be pulled up with resistors (either in the chip or externally). Some devices provide a “TRST” signal, which just does essentially the same as navigating to “Reset” through the state machine (only possibly without the side effect of committing a register change)
• Pins are named in a Chip-Centric way. TDI goes into the chip, TDO is data out of the chip. TMS and TCK are controlled by the programmer
• The device samples on the rising edge of TCK, and you should listen for its response on the falling edge.
• A JTAG Reset should reset the test circuitry. Enter the reset state by cycling with TMS = 1 for 6 cycles (or more) – and then usually move to the “run/test/idle” state.
• Idle in the  ”run/test/idle” state by cycling the clock when TMS=0. Some devices depend on having idle clocks like this in order to perform their programming functions.
• Write to the Instruction register – you do this by entering the Shift-IR state, Stay in this and shift bits (set TDI to your value, and listen on TDO). You need to set TMS = 1 for the last bit you shift.
• Write to the Data register – Exactly the same way, just by entering Shift-DR
• Another rule which it helps to know, is bitstreams are usually sent bottom-bit first – and are almost always represented with first sent bit on the right side. Important strings in documentation have been always specified in this form, in my experience (though it’s anybody’s guess what order the manufacturer will use to push their data into the port.
• JTAG is inherently a multi-chip protocol. You can chain multiple chips by connecting TMS and TCK to all chips in the chain, Connect TDI to the first device, and connect the first device’s TDO to the second device’s TDI – And so on, finally connecting the last chip’s TDO to the header.

Most of the other logic in the state machine is for devices that are tied to a fixed clock, and need to be wedged for a while if the host can’t keep up with shifting data.

At this point though, you can think of the JTAG system as memory mapped I/O, except for that the read/write widths are variable. Each transaction (Traveling through Capture-DR, shifting data, and then returning through Update-DR) has an impact on the system, which could be very small or very big. Everything is hardware specified, and every bit -could- have a meaning. That being said though, there are a few rules that make this manageable!

First, the Instruction register is typically very small. It exists so you can tell the device what mode to work in – And usually the size (Bit width) of the data register is fixed and based on the mode you are in.

There are a few mandated modes – The boundary scan modes were the original intent of the JTAG system – they exist so you can control and listen on the I/O pins of the device. JTAG was primarily designed as a way to test electrical connections on circuit boards between chips – This is implemented as the EXTEST and SAMPLE modes, for which the specific instruction register values are not rigidly specified (it varies per device)

There is a mandated “Bypass” mode, which is defined as an instruction word filled with ones – so you can technically use it even with chips that you don’t know anything about in the JTAG chain. When a chip is in BYPASS mode, it’s data register is a single bit. (Which will always clear itself to 0 when you start a new data transaction by entering Capture-DR)

When you enter JTAG Reset, the chip will automatically enter either IDCODE or BYPASS. IDCODE is an optional mode which is usually implemented; Its data register is a fixed 32bit value uniquely identifying the chip type, which MUST start with a ’1′ bit. The (slightly inobvious) advantage to this, is after resetting a JTAG chain, you can easily identify the number of devices in the chain and their types, if they entered the IDCODE state, just by shifting some bits through the data register! Based on whether the bit you receive is 0 or 1, either you know there is a bypassed device, or you will have 31 additional IDCODE bits to identify the current device with. Provided that you’re shifting in ’1′ bits into TDI, you can also identify the end of the chain when you encounter an IDCODE of all ones.

Another thing defined for your convenience, is the instruction register doubles as a status register.  The (variable size) instruction word is required to shift out as “xxxx01″; where one is sent *first* (rightmost first), and the “x” bits could be status from the device. This also gives you some clue as to how big the instruction registers are, if you didn’t know about all the devices in your chain. Though, even with this it may not be possible to concretely identify the sizes of the instruction registers in your chain. Well, there may be another trick/requirement but I don’t know it – I have been working entirely off of public documentation :)

It’s definitely easiest to work with chains that only have one device, but it is not too hard to set all the uninteresting devices to BYPASS if you can identify their instruction register sizes.

As for actually doing stuff with JTAG? Well, I think I’ll have to go over that some other time. The idea is to set some instruction, and then you get to send a data word, which is some data, some control bits, and some very strange logic sometimes. The device also trades you back a value in the exchange, and frequently you receive the results of the previous command you entered.

I have been starting to reverse engineer the JTAG protocols used by some Xilinx FPGAs and CPLDs (just in order to build my own programmer for them) – it’s been an interesting project that has repeatedly broken many of my assumptions about how JTAG is used. I’ll post more about this when I have worked it all out. Some things are very simple, others seem to be highly complex and mysterious, littered with commands that don’t make much sense and (apparently) unused data. (Seems I’m mostly interested in the complex ones – oh well.)

On the bright side, I have found a new use for my AVR USB Stick, it currently has a bundle of wires attached to it for JTAG purposes :) I’ve written a simple protocol on the virtual serial port that lets me do JTAG stuff easily, and am probably going to set up a new PCB for dedicated USB programming, just because it’s so much faster than my existing serial port based programmer.

Not too long after that, I did send out an order to manufacture some boards – and this last week they finally arrived! I’ve assembled a few, tested them, run into a few problems, solved them, and finally got a pretty basic PCI Port-80h debug card working.

In this post I’ll walk through these things, and talk some more about the PCI interface.

So; Early this week I received a package from MyroPCB – A cheap outsourced PCB manufacturer; I’m rather happy with the quality of these boards – it’s a reasonably simple design to produce these days I suppose, but it is still pretty neat.

(A Scan of some of the boards I received)

It takes some time to assemble this PCB, due to all the parts; The most annoying parts have been ones with pads strongly attached to the ground fill; Those pads have thermals seperating them from the fill, so they are not completely embedded in copper, but they’re still too well connected, and very troublesome to solder as all the heat is sucked away by the large mass of copper. Also the capacitors take some time to solder just by virtue of there being a large number of them. (And also that a large number of them have one pad attached too well to the ground fill)

(After some soldering)

At this point I didn’t do much else with this project until today;

Unfortunately, I had made a serious miscalculation – Note that the PCI edge connector on this card is 3.3V only… Now, I had built this card not long after seeing a PCI 3.3V only slot in a server system; so I made the assumption this would work great for me. In fact the PCI 3.0 specification (released in 1994!) no longer even includes the 5V PCI card slot

So that means it’s gone, right?

Well, No.

And, in fact my assumption proved to be wrong in the most incredible sense; There are literally no desktop-class motherboards on the market with 3.3V PCI slots! I spent an hour or two looking through motherboards on Newegg, and the cheapest motherboard I could find with 3.3V PCI slots was $200. (And, only had 3.3V PCI slots by virtue of them being part of 3.3V PCI-X slots)

All was not lost though, first, this board was also built to be general purpose  - so it will have other uses. Also, as it turns out, it isn’t impossible to use it in modern 5V PCI slots.

Apparently,  system board manufacturers don’t want to sacrifice compatibility – so while modern PCI busses are all driven with 3.3V signals, they are still using the 5V connectors and maintaining 5V compatibility – This is really annoying for my project, because my FPGA isn’t 5V tolerant like their bus controllers are, but I can work on a 3.3V bus just fine. So, to actually be able to test, I have cut out the second key slot in the PCI connector and broken the VCCIO traces that would otherwise connect 5V to my 3.3V rail in the 5V slot. The PCI connector has a bundle of different voltage rails – but in a 3.3V-only card, like I made, the I/O voltage levels are intended to be connected to the 3.3V rail – so I did connect them – Unfortunately, being compatible with a 5V slot means those I/O voltage levels are 5V. It’s not ideal to just disconnect them, as they are supposed to have bypass capacitors in order to reduce noise, but I didn’t have many options with this, so I have just disconnected my card from the I/O voltages completely.

(Chopped traces and a new slot)

With this modification, my card is quite happy to work in the motherboards I have around – The caveat is, since my FPGA isn’t 5V tolerant, if I put it in with a 5V device (which does typically drive the bus up to 5V), it will likely damage my device. However, for what I’d like to do, I can live with this, and I can redesign the board if I ever actually need 5V tolerance.

After resolving how to test my board as a PCI device, I set out to write a first simple test firmware, to verify that the core functionality worked- This just drives the display and sets the LED values based on the switches present on the system.

(Test program)

It was at this point that I noticed the green “programming done” LED had accidentally been populated with a red LED on this board – oops. I will have to go back and fix that later.

A few short steps further, and I converted the test program to firmware for watching the port 80h I/O Writes on the PCI bus – I had an old motherboard around from a system upgrade some time ago, connected it up, and it does appear to be working! After powering up the system, the display cycled through a number of values exactly the way it should; In the image below you can see the last 2 values it observed written to port 80h.

(Victory!)

So,A few short notes about PCI devices – First, this isn’t actually a full PCI device; It does not interfere with the bus any more than is necessary to make electrical contact- it is only listening to the bus in order to see this information (as such it’s out of spec). It is actually possible to make a full PCI device with this card, and that’s on my list of  things to do eventually as well.

The PCI bus though, is essentially a collection of signals – there are 32 address/data lines, and a number of control signals; At its core though are the PCI Clock signal, a FRAME signal (each transaction on the bus is a frame), the 32 address/data lines, 4 lines which are used as both a control word, and as 4 individual byte enables (to enable byte granularity in the 32bit value) – Beyond these are some handshaking signals (IRDY/TRDY), sanity checking (Parity), error reporting (PERR/SERR), transaction abort (STOP), System reset (RST), and location-based device identification (IDSEL/DEVSEL)

In order to listen for a specific port write on the bus though, you only really need the CLK, FRAME, data lines, and the 4-bit control word / byte enable – All PCI signals are sampled on a rising clock edge, the controller starts a frame by asserting FRAME on a clock edge. When it does this, it also sets the 4-bit control word to the transaction type, and for some types of transactions also sets the address lines to the related address.

What my card is doing, is waiting for reset to finish; then every frame that starts, it checks if it is an I/O write with address = 0×00000080; If so, it listens on the next cycle, and if byte enable 0 is set, it will accept the data in the bottom 8 bits of the data lines as a new port 80h write – In any case, it waits for the frame to finish, and then continues waiting for another frame to start.

Sounds simple? It really is.

Making a real PCI device though will be a lot more challenging, and I’ll be sure to document that when I get around to it :)

Small update: I should probably also mention the significance of Port 80h – System BIOS manufacturers have standardized on using port 80h as a debug port of sorts, they write a byte to that port to indicate which section of the BIOS code is running; As such, there are a number of cheaply available “PC Diagnostic” boards, which do essentially what I’m doing here, just listen for Port 80h accesses and display the values. The capability to see this code is helpful when diagnosing a difficult motherboard problem, to be sure… but it’s also helpful when writing and debugging low-level code when little else on the system is running, as you can add writes to 80h that give you information about what stage of execution your program is in.

So, this post is a little bit late as well, I almost didn’t manage to make this work :) I’ve been now tinkering with writing a USB device stack for my USB stick for literally the past two weeks now; Being a new space, I’m used to the idea of having issues, but between incredibly stupid bugs, very minimal documentation, and errors in some critical hardware documentation, this has been quite a challenging project.

On the plus side, I now have my USB stick behaving as a virtual com port – so it will be trivial to write extensions and make it start to do really useful stuff (haven’t quite got around to that yet, so expect a part 3)

Additionally, in the process I’ve become pretty familiar with  how USB works, and I’ll try to more simply define it for those who are interested in getting started.

First, some detail about how I managed to make it to this point; I’ve wanted to play around with USB for quite a long time – the first time I tried was many many years ago, around the time I had mastered several much simpler serial protocols… That didn’t particularly go anywhere as I had no idea where to start with the USB specification, and every part of it seemed equally irrelevant and incomprehensible.

As you might imagine, I’ve since become a lot better at reading specifications – and while the USB specification is still by no means trivial, it makes quite a bit of sense now, and have been able to identify the important parts and work through the process of actually building a compatible device.

Since I’m using an AVR with USB support, some level of this is done for me;  the entire electrical communication layer is done, and the vast majority of the protocol work – all that remains is to handle the high level messages and instruct the hardware on how to proceed. This was indeed a pretty easy thing to do, just bugs caused quite a lot of pain.

One thing I’ve found very helpful in this process is USB protocol tracing; There are a number of tools out there that can capture USB traffic, and if you’re using Windows 7, a mechanism to do this exists built into the OS’s USB stack itself (take a look here for more information). In general the bugs I’ve hit were mainly packets that didn’t complete properly (returned an inappropriate response, or didn’t return at all), and those things are pretty easy to find in a protocol trace.

So, let’s start with a broad question: What is USB?

The USB specification defines the behavior and allowed interactions of all parts of the USB ecosystem. It provides a framework for building devices which require data transfer between the device and host, in a number of ways. The specifications for USB are available from usb.org – Most modern devices are USB 2.0, and USB 3.0 is out of the scope of what I’m talking about here :)

It’s actually a very  wide specification, and the USB specification and related specifications seek to define a lot of things, such as:

• How a USB device physically attaches to a host system (Mechanical, chapter 6)
• How a USB device electrically communicates to a host system (Electrical, chapter 7)
• What specific sorts of message types should be sent between the host and device, and the bit patterns they map to (Protocol layer, Chapter 8)
• How the device uses those messages to interact with the host and expose data about itself (USB Device Framework, Chapter 9)
• How the host should behave in general
• How hubs should work, to allow a single USB port to drive multiple devices
• And additionally the USB Device Class specifications specify in more detail how certain types of devices should behave, in a standardized way.

For what I have been doing with the USB stick and general microcontroller USB development (when hardware support is available), only the parts about the Device Framework and device class specifications are really important – it’s good to know about the protocol layer but that is for the most part taken care of for you.

Still, it is pretty complex – but only because there are a number of details to attend to. I’m omitting a few of the details, but I’ll go over the major points individually:

First, a device is a logical object composed of endpoints – There are 16 endpoint numbers and 0 is always a special number for sending control messages to the device. Everything about USB is host-centric, the host initiates all transactions, the device must only respond. So the majority of what happens in USB, is the host sends a packet of a certain type, to a specific endpoint, and then the device responds to that request with data, acknowledgement, or some error condition.

An endpoint is really just a buffer to send or receive data – the endpoints in USB microcontrollers typically only operate in one direction, though the USB standard allows an endpoint to both send and receive data. Typically you will have to configure your endpoint with a specific size (which will be communicated to the host via descriptors, see further below)  - Then either you will make an IN endpoint write data to the buffer, and hardware will happily send it to the host the next time the host asks about that endpoint – or you will create an OUT endpoint, wait for it to be filled by the host, and the process the incoming data. Endpoint 0 must operate in both directions, and that balance is a little elaborate to maintain.

The big three request packets the host uses to control the flow of data are: SETUP, IN, and OUT. IN commands are the host asking for data, OUT commands are the host sending data, and SETUP packets are slightly more complicated – a SETUP packet must only be sent to endpoint 0, and it is always followed by an 8-byte data packet, which is a data structure specifying a request. As part of the setup transaction, the host may send additional data (with an OUT), or may ask for data (with an IN); and a third stage with the opposite direction will give the device a chance to acknowledge or reject the transaction.

Here’s another representation…

Host sending data to device:  OUT – <host sends data> – [device ACK, handled by hardware]

Host requesting data from device: IN – <device sends data> – [host ACK, or retry logic handled by hardware]

Host sending a SETUP request with no extra data: SETUP – <host sends 8 bytes> – [Device ACK in hardware] – IN – <Device sends zero-length data packet to acknowledge> – [host ACK]

Host sending a SETUP request and requesting extra data: SETUP – <host sends 8 bytes> – [Device ACK] – IN – <Device sends extra data> – [host ACK] – OUT – <Host sends zero length packet> – [Device ACK to acknowledge]

Host sending a SETUP request and sending extra data: SETUP – <host sends 8 bytes> – [Device ACK] – OUT – <Host sends additional data> – [Device ACK]  - IN – <Devices sends zero-length packet to acknowledge> – [Host ACK]

Alternately, the device may send a STALL response instead of data / ack if it does not support a SETUP operation (or if the endpoint has an error); (to add another detail,  USB hardware will also send NAK packets to delay requests until the device is ready to respond- which I haven’t included for the sake of simplicity)

Another small complexity in the SETUP phase is that if your data payload exceeds the maximum endpoint length, multiple packets will be sent/requested, finally terminating with a packet less than the maximum endpoint size.

So, did I say this was simple? I’m sorry :)

That’s the very outer shell – the information you need to know to interface with the hardware; Next comes the requests themselves.

The requests are completely documented in the USB specification, in  sections 9.3 and 9.4; The specification leaves a little bit to be desired in the clarity of what exactly needs to be handled, but most importantly you need to focus on the “type” field in the bmRequestType and also the request code itself. If the type is a standard request, the table of standard device request IDs is in that area, If the type is a class, or vendor request, a different table of request codes applies. It is necessary to handle several of the standard requests in order for a device to work. Most importantly though, are set_address, get_descriptor, and set_configuration. Several of the others are required, but not all of them (I’m not elaborating further because the descriptions in section 9.4 are actually not bad)

For set_address, some interesting logic is usually required, After receiving the set_address packet, you must complete the ACK phase before actually setting the address (or else your address will change before the host commits to your new address, and it will not be possible to complete the ACK ) – the Atmel datasheet went into some detail on how it should be done. The entire transaction is done without extra data (the address is passed in one of the fields of that 8-byte SETUP data packet), so it is the software’s responsibility only to receive that, process it, and then instruct the hardware to send a zero-length data packet in response to the host’s IN (and set the address AFTER that packet completes)

Get_Descriptor is the most important command to get right, and you only absolutely have to handle two types of requests here. First: for descriptor type 1 and descriptor index 0 (the Device descriptor), and second: descriptor type 2 and descriptor index 0 (The first Configuration descriptor) – The descriptors I will cover in a moment, but they are relatively large data structures that describe the structure of your device, among other important details. This is probably the only setup request that is likely to need multiple packets in response (My setup endpoint is 32 bytes, and my configuration descriptor is 67 bytes – so 3 packets for me). In this case the idea is to process the SETUP data structure, reject it with STALL if it’s not one of the supported types, but otherwise send packets of max length followed by waiting for those packets to complete until  you get to the end (you either send a zero length packet or non-max-length packet as the last one). Note as well that the get_descriptor request includes a maximum length, so you may have to stop early sometimes.

By default, your device is in an unconfigured state, essentially all of the endpoints are supposed to be turned off (Except endpoint 0), the device should not be doing anything notable. – set_configuration allows the host to turn on a device to one of potentially several operating modes (each one of these modes gets a configuration descriptor)

If you can implement those three, the others will follow pretty naturally, and Class requests when implementing class devices follow the same pattern.

One last subject for this blog post: Descriptors!

The USB descriptor definitions in Section 9.6  are pretty well documented structures. The device descriptor is simple enough – when you are asked to provide a device descriptor, they mean you should send a string of bytes that correspond to the USB device descriptor (9.6.1) – Note that some of the numeric fields are a bit… distant – descriptor type numbers are in table 9-5 back in section 9.4.

The configuration descriptor is the tricky one. If you read about the get_descriptor device request (9.4.3) you’ll find that the configuration descriptor should actually be a configuration descriptor, followed by one or more interface descriptors, and each interface descriptor may be followed by one or more endpoint descriptors (think of a tree). In the USB world, A configuration is thought of as a mode of operation, and an interface is thought of as a logical unit  that serves a specific function. That specific function is associated with the Zero endpoint for control (typically as Vendor type requests, which you can define yourself if you want to write a driver), and possibly one or more endpoints, which serve as data pipes for interfacing with the device.

How should you define a configuration? Well, any way you want if you are writing your own driver… But USB-IF noticed that this wasn’t ideal, and so the notion of Class devices was brought into the world.

I’m not going to cover this here (this post is already so very long!), but  in addition to the USB core specification there are a large number of official class specifications, which define how specific types of devices should operate – To be more specific, they define what things you should have in your configuration, and they provide a list of class requests, notifications, and custom descriptors related to describing various types of devices. The upshoot of all this is you simply have to implement a class device, and likely the driver to make your device work on whatever computer you plug it into has already been written for you.

In re-reading this, I doubt I will have answered everyone’s questions, I’m happy to answer further questions if you post them; USB does seem pretty simple after wading through it for a week or two, but it is still a large array of moving parts, regardless of how simple as they may be individually.

I’m planning to continue this, another time, and I have been working on a USB cribsheet for my own reference that I’ll also link here sometime.

(And now, I am off, to implement a USB bootloader, and USB jtag programming and… )

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 :)