With that said, there’s nothing to  show for this week besides minor progress on a few fronts; so here’s a picture of my desk as it stands pretty recently:

Happy new year, all.

First, I’ve started a Flickr page! Pictures I take (typically of stuff I’m working on or taking apart) will be auto-uploaded to http://www.flickr.com/photos/sgstair/

I don’t always update the descriptions but any questions posted in the comments will be answered :)

Second, there has been some progress on bitbox; After some early failures, I now have the bitbox_test board working! I misread the datasheet for the LPC134x chips initially – The USB bootloader requires an external crystal; I’m not quite sure why I thought otherwise. For the bitbox I am attempting to do USB without a crystal even though the internal RC OSC might be slightly out of spec. Maybe I’ll need to revise it.

Next I’ll be writing some initial firmware for this board and then all things bitbox should start to move along.

I also ordered some laser cut acrylic for the test fixture, and should get that back in a bit over a week – this test fixture has been interesting to design – it’s a little overengineered in hindsight, I’ve since designed another fixture (for another project) that’s far simpler. Below is my laser cutting pattern with a few designs:

I’m using Ponoko to have this produced – will have to talk more about it next time.

Several of my projects are still making progress, though incremental at best; I may just need to rethink the set of things I’m working on in order to move more quickly again. Or just somehow become less lazy ;)

Well, I’ll say more later.

• Limited progress on the PCI Express firmware… Should get back to that. Have learned a lot about high speed serial, and a lot of related fields.
• I have obtained some cheap wired 3d shutter glasses and a 120Hz projector… this may be interesting.
• Also been reading books, this one has been really interesting.
• And, dealing with some failing hardware :\ one of my RAID cards died recently.
• Been dabbling in high speed video, but nothing interesting here yet…
• Have a few PCB projects staring at me waiting for me to complete them :)
• …And a growing collection of other projects doing the same.

Well, maybe next time I’ll have more to say, wish me luck.

Come to think of it, I have completed the firmware for my little PCI card, which is now actually a useful port 80h monitor, but that’s just an incremental update to its previous firmware.

This weekend I’m working on trying to build PCI Express firmware for a FPGA card; This is a lot of new stuff to me and I’m not sure I’ll make it this weekend, but it should be fun!

Below is a picture of the system I’ve set up to test with:

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.

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.

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.