This is the USB Jtag PCB I previously mentioned, and I had it produced in a group PCB order managed by Laen – They turned out nice and came back pretty quickly, I’ll definitely be sending him more PCBs

As I was on vacation though, I just recently ordered the parts to complete these boards, and haven’t got them yet. I’ve also been thinking about priorities and am working more heavily on some projects which I won’t blog about :)

Things are still developing though, keep watching and I should have more to talk about in 2 weeks.

I haven’t actually done anything too interesting though :) just messing around with some stuff while I’m away on vacation; Mostly doing less than usual though – that’s ok every now and then.

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!

So, I’m shifting the format and will write blog posts every other week – I’ll continue next week.

Thanks for reading! I hope some of this material has been useful to you, and please do let me know if you’d like to see something specific, or if anything isn’t clear.

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, nothing too interesting this week; Next week should be good though. (and the week after, and the week after. I have quite a bit lined up now, just not all done yet)

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.