ZZZ-Consulting

Making some PCBs - part 2 (HyperRAM)

2022-01-05T00:00:00+01:00

Stage 1 - HyperRAM

2-layer board.

First out is a HyperRAM expansion board for the ULX3S. It makes sense to see early if I will be able to pull off BGA assembly with the equipment I have. Also I happen to have 10 of these S27KL0641DABHI020 laying around.

5x5 BGA means that the two outermost rings can be routed in the same layer (only one ball remaining in the middle but that can also escape in the same layer as one corner is missing a ball).

I finally had a go at this and put together quick and dirty PCB in KiCAD and had https://aisler.net/ manufacture it for me. By quick and dirty I mean that the layout is ugly and the traces are not length matched so I would not expect to get any performance out of it. The board should be functionally correct though. I did not bother to put the KiCad files on GitHub.

Two different soldering methods were evaluated and I tried capturing the chip profile with a cheap cell-phone camera through a binocular microscope.

On the left only tacky flux was applied and then using hot air from above (station set to 300C at 50l/min) the chip was soldered in place. After a while the chip noticeably sunk into place and I tried to nudge it several times with a pair of tweezers after which it immediately bounced back. This was a quick method but the end result is that the chip sits flush with the board and visual inspection is not really possible.

On the right no flux was used but instead solder paste was applied through a stencil. The board was placed on a hot-plate that slowly rose to a temperature set to 220C after which hot air was applied from above (with station set to 300C at 40l/min). It was not as noticeable when the chip sunk into place and I did not dare to nudge it (as it was still on the hot-plate). The end result looks much nicer though with the solder balls clearly visible and one can clearly see that there is no bridging.

Eventually I will try to verify the boards with one of the controllers from the list below and report the results.

https://github.com/blackmesalabs/hyperram - slow but portable controller
https://github.com/gregdavill/litex-hyperram - full performance controller for ECP5 in Migen
https://1bitsquared.com/products/pmod-hyperram
https://www.youtube.com/watch?v=dThZDl-QG5s

I did a second try run using the stencil after having acquired https://www.oshstencils.com/ excellent PCB fixture jig. To me having the board properly held in place by jig helped a lot when applying the paste. Of course one can get a similar effect using a few scrap PCBs but I don’t really have many of those lying around that are the right size and besides these brackets just cost a few dollars.

As far as I can tell the stencil alignment and paste coverage turned out well and the end result looks good. So with this I feel reasonably confident that I will also be able to handle the larger FPGA BGA with its 0.8mm pitch (the HyperRAM BGA has a 1.0mm pitch). Again I still have not gotten around to actually verify that these modules work so maybe I should not say too much.

Verification

Now a few monhts later I felt sufficiently energized to have a go at testing the HyperRAM boards. I set up a test bench using the portable HyperRAM controller from blackmesalabs and the PicoRV32 RISC-V CPU core.

The DRAM is mapped into the CPU’s address space presenting its 8MB as 2M 32-bit dwords.

The test consists of having the CPU write the Fibonacci sequence, as 32-bit integers, to memory and then verifying that it reads back correctly. Test result is presented by lighting the appropriate LEDs.

All three boards have been fully assembled and the test passes on all three.

It should be noted that this is a basic test running the memory at a low frequency (6.25MHz) so it does not stress test the board in any way. It does however provide some confidence in that the part survived the assembly process, the solder joints are reasonably sound and that there is no bridging.

Future

It could be interesting to improve the controller, setting a shorter latency, or simply switch to using a different one.

[DRAFT] Making some PCBs - part 3 (MAX9850)

2022-01-05T00:00:00+01:00

Stage 2 - MAX9850

2-layer board.

I also got started designing an audio extension board featuring the MAX9850 stereo audio DAC with builtin headphone amplifier.

Now the MAX9850 part comes in TQFN-28 which is an absolutely tiny package with 0.5mm pitch (the KiCad footprint is “TQFN-28-1EP_5x5mm_P0.5mm_EP3.25x3.25mm”). See comparison below to get an idea how tiny this really is.

MAX9850 next to a standard 3.5mm audio plug.

PCB design

Using the best of my currently rather amateurish PCB design skills I ended up with the following layout with KiCad project files on GitHub.

While it initially looked pretty good to me I realize that is has a number of layout flaws that I will need to remedy before I attempt the combined ECP5 board. To this end I have signed up for the Mixed-Signal Hardware Design with KiCad course from well known YouTube creator Phil’s Lab. Having browsed through the 5 hour video material that focuses heavily on PCB layout I can only say that this appears to be a goldmine. So after finishing this board I will probably take a detour to study the course material and follow along with its board project.

Assembly

Again soldering the top side using stencil and paste. The board is placed on a hot-plate that slowly rises to 220C after which hot air is applied from above for about 20-30s with station set to 300C at 30l/min.

Stencil alignment, stencil with paste, paste alignment, component placement and post solder result.

Bring up

After skimming through the MAX9850 datasheet it does seem that setting up a working audio flow will require writing a fair amount of I2C configuration registers. Ideally you would want some simple kind of test that can be used immediately after assembly to verify that the part has not been totally destroyed in the process. Needless to say you want this test to be dead simple so that you are not led to believe that the part is broken after assembly just because you made a mistake in the test code.

The MAX9850 does have a (single) GPIO pin that is controllable by a I2C register. The pin has also been routed back to the FPGA so the dead simple first test we are looking for could be to write the appropriate I2C control register to toggle this GPIO and then have the FPGA forward the signal to a LED.

Using the simple test bench I have been able to verify that both of the boards assembled so far accept I2C access and can toggle their GPIO pins.

Next up is to configure all required control registers and start streaming digital audio. Using the slightly more advanced test bench the device is configured to use a sample rate of 48.8kHz and sawtooth waveforms at two different frequencies are generated in the FPGA (one for each channel). Pressing a button swaps the sawtooth frequencies. Both assembled boards pass this test.

And finally just for fun, here is a quick integration with the MyC64 project playing the classic Bubble Bobble tune. Using branches myc64/max9850 and usbdev/max9850.

./myc64-keyb ../../../c64-psid/MUSICIANS/C/Clarke_Peter/Bubble_Bobble.prg

This does not sound quite right though, frequency (of the MyC64 design) is expected to be off but I suspect there is more to it than that. Need to examine closer at some point but for now this is good enough.

[DRAFT] Making some PCBs - part 4 (ECP5)

2022-01-05T00:00:00+01:00

Stage 3 - ECP5

4-layer board (signal, power, gnd, signal).

Study these designs:

https://github.com/mattvenn/basic-ecp5-pcb - most basic ECP5 design, highly interesting.
https://github.com/emard/ulx3s - ULX3S design

The LFE5U-12F-6BG256C does indeed seem like the most suitable model and package.

Although routing a 256 pin BGA does seem intimidating one has to keep in mind that a large number of these balls will be no-connect. Since this is a custom board for a given application we only need to route what we use. This situation is substantially different compared to doing a generic development board where you really want to expose as many pins and interfaces as possible.

Another simplifying matter is that this is a FPGA so it has very few fixed function pins and interfaces (expect the fixed function ones like JTAG and flash SPI) can generally be brought out in way that will cause no trace crossing on the PCB.

So besides power and ground how many signal do we need expose from the FPGA?

Interface	Pins
HyperRAM	12
HDMI	10
JTAG	5
Flash	5
MAX9850	5
USB	4

Okay so it is quite a few but still much less than the 197 I/Os that are available in the given package.

Configuration

When first looking into how the device is to be configured while on the PCB the options and tools involved seem quite a bit overwhelming. However after doing some googling and reading up a bit I think the following answers most of my worries (mostly by confirming that this process does indeed depend on well established and standardized techniques and not so much proprietary magic).

Use JTAG (TCK,TMS,TDI and TDO) as main means of configuration. Either driving it with external JTAG-cable, an integrated FTDI chip or onboard MCU. Timing is not critical, bit-banging is fine, the TCK may stop etc.
For non-volatile bitstream storage use SPI connected flash. ECP5 acts as SPI master. The FPGAs JTAG interface allows direct programming of the SPI connected flash memory.
The Symbiflow tools support generating both .bit files and .svf files. The former contains the configuration bitstream only while the latter contains JTAG commands to setup programming and the entire contents of the bitstream. This allows for programming with a JTAG tool that does not know anything about the actual device (i.e. all instructions are in the .svf file).
There are several tools for programming the ECP5. ujprog, fleajtag, OpenOCD and even one in python https://github.com/emard/esp32ecp5. The last one does bit-banging from a MCU while the first three relay on a USB connected FTDI chip for JTAG. OpenOCD only support programming with .svf files while ujprog and fleajtag can do .bit directly. That is they contain code to write the appropriate JTAG registers to initiate the programming. Actually IEEE 1532 defines a standardized JTAG based interface for programming that the ECP5 follows. So ujprog has code to interface the FTDI chip as well as code to issue the relevant IEEE 1532 commands over the JTAG interface.
Probably don’t need to care much about the PROGN, INIT and DONE signals.
The interface between the ECP5 and FTDI need only be the 4 wire JTAG signals. Often the FTDI also provides usb-serial port services but this is not strictly needed. Actually the FTDI chips are really expensive (same cost as the ECP5 12F) so while it may be useful for the development version of the board it will not go on any production variant.

In fact since FTDI appears to be a generally unlikable company it would be a good thing to try to not use their products at all. So instead of putting an overpriced FTDI chip on each board let us use an external JTAG cable for programming and only put a JTAG pin-header on the PCB (with pull-down on TCK but nothing else). Once the board has been “factory” programmed via JTAG subsequent updates could be handled via the USB interface. During FPGA power up the configuration bitstream is read from the SPI flash but after that the SPI interface pins are controllable by the FPGA fabric (according to documentation). So in theory once our FPGA core is up and running we can receive a new configuration bitstream via our USB interface and then write that to the SPI flash so that it will be used during the following FPGA power up sequence.

PCB manufacturing

The chosen ECP5 BGA package is 0.8mm pitch so in order to escape route the inner rings (mostly power and gnd) rather small vias need to be placed (via diameter needs to be less than 0.55mm). Unfortunately it turns out that making such small vias exceeds the capabilities of Aisler so a different PCB service needs to be used. These vias are just within the capabilites of the Oshpark so we have to turn to them instead.

When it comes to PCB services the order of preference for me would be Aisler (Europe), Oshpark (US), JLCPCB and PCBWAY (China).

PCB layout

Thinking that we can mount the switch mode voltage regulators and support circuitry on the back side of the board. Also if possible decoupling capacitors for the BGA can go on the back side as well.

[DRAFT] Making some PCBs - part 1

2021-06-08T00:00:00+02:00

NOTE: This post is not finished yet but instead of keeping it as a hidden draft I have decided to publish it anyway - mostly to serve as a notebook to myself while I work on the project.

Introduction

For a while now I have had a desire to make a custom PCB for the MyC64 project, a board with suitable display interface and perhaps some tiny keyboard. Something that could be used in a handheld. A handheld FPGA based C64 emulator now that would be pretty cool.

Back in 2019 I did play a bit with KiCad making a very simple (through hole) PCB for PMOD like VGA interface but wrt complexity that is light years away from what I need to do now.

A board for the MyC64 will need to include the ECP5 FPGA with its, at least, 256 ball BGA packaging as well as HyperRAM 24 ball BGA and multiple other fine pitch surface mount components.

While I certainly need to learn a lot about board design and KiCad that bit does not scare me half as much as doing the actual assembly for those parts.

As a side not I spent some time during summer vacation to build a workbench for my lab corner where I can put all my equipment. This is how it turned out.

The Plan

So to get started I thought I could begin with making a few rather simple PMOD boards for some of the components that I intend to use on the final board. This time actually following the Pmod specification. This way I get a chance to improve my limited KiCad and assembly skills along the way as well as trying out interfacing the components with the FPGA on the trusted ULX3S board. That seems like a sound plan.

[DRAFT] A most basic GPU - part 1

2021-03-26T00:00:00+01:00

NOTE: This post is not finished yet but instead of keeping it as a hidden draft I have decided to publish it anyway. Right now I am not working on this project but if/when I return I will try to update the post with the progress.

Introduction

Putting the MyC64 project on hold for a while.

Recently I have seen updates on the new PS1 FPGA core by @Laxer3A, which I of course can’t help to find interesting. I have never owned a PS1 and honestly never cared much about it until now. It turns out that graphics wise it had have some rather interesting design choices. More preciecely the graphics pipeline is based around fixed point integer representation so there are no floating point numbers involved at all. Further more there is no z-buffer. In fact Modern Vintage Gamer has put together a short video describing these limitations that is well worth a watch Why PlayStation 1 Graphics Warped and Wobbled so much | MVG.

So apparently it was possible to reach commercial success with a system like this some 25 years ago. Nowadays probably not so much but it is still interesting to see that one can get away with these limitations and still get reasonable results.

For me this suggests a very basic GPU may actually be within reach as a fun FPGA project.

The rasterization algorithm is very well described in Rasterization: a Practical Implementation over at Scratch Pixel. What follows below will be some thoughts that I had while reading that and thinking about a simple design that could be put inside a FPGA.

Project scope

Fixed pipeline (duh, not likely to implement programmable shaders any time soon)
Fixed point integers only (no floating point)
Flat shading only (triangles filled with solid color)
No z-buffer (geometry has to be sorted before sent down the pipeline)

Rasterization stage

Rasterization is the process of finding pixel coverage for a given triangle

This stage is about finding out, for a given triangle, what screen pixels are covered by that triangle. Since well behaved triangles contain significantly more pixels than vertices (three) this step is likely to be the main bottle neck of the system.

Determining if a pixel is inside a triangle is done by checking if it falls on the right side of all three edges.

Intuitively it seems that the cross product could be used to determine if a point is on the left-side or right-side of an edge. Now screen space is 2d and the cross product is a 3d only concept but one can of course limit the vectors to be contained in the plane $z=0$ . In that case the well known cross product

$a \times b = (a_2b_3-a_3b_2, a_3b_1-a_1b_3, a_1b_2-a_2b_1)$

simply becomes

$a_1b_2-a_2b_1$

which in rasterization is known as an edge function. It is worth noting that the edge function is in fact the magnitude of the cross product of the two vectors in the $z=0$ plane (so it has something to do with area).

So the edge function for edge $u \to v$ and arbitrary point $p$ is

$E_{u \to v}(p) = (v_x - u_x)(p_y - u_y) - (v_y - u_y)(p_x - u_x)$

now condsider what happens if an offset $o$ is applied

$\begin{eqnarray} E_{u \to v}(p+o) &=& (v_x - u_x)(p_y + o_y - u_y) - (v_y - u_y)(p_x + o_x - u_x) \\ &=& E_{u \to v}(p) + (v_x - u_x)o_y - (v_y - u_y)o_x \end{eqnarray}$

in other words once we have computed $E_{u \to v}(p)$ we can explore neighbouring pixels by simply adding and subtracting $(v_x - u_x)$ and $(v_y - u_y)$ both of which we have already computed for $E_{u \to v}(p)$ .

This is a significant improvement as it allows us to replace two multiplications and five additions with a single addition.

Naively every pixel of the screen need to be checked against each triangle for coverage but obviously one often do much better by simply checking the bounding box of the triangle. Either way the amount of pixels is significant so this last result is really important as it will allow us to check multiple pixels each cycle at a reasonable cost in hardware.

The idea is to consider quads of 2x2 pixels. Begin by computing the $E_{u \to v}(p)$ for the pixel in the upper left corner of the bounding box. After that add/subtract as described above to get the remaining three pixels of the quad. This should preferably be done in sequence not to wast too much resources. Once the first quad is done the neighbouring quad in $x$ direction is obtained by simple addition of the precomputed $2(v_y - u_y)$ (keeping in mind that we get the shift by one for free in hardware by simply hard-wiring in a zero at the lsb). So we begin with sequential computations for the first quad but after that we reach a steady state where we evaluate an entire quad each cycle.

Still though every triangle has three edges so evaluating a quad every cycle means that 12 adders need to be instantiated. If that results in too high resource utilization we may need to cut down a bit.

First milestone

Rasterize fixed triangle over DVI/HDMI. Use block RAMs for frame buffer. Suitable resolution 320x240. Try quad rastierizer and check resource utilization in FPGA. If it works then great otherwise scale down.

Geometry processing

Eventually we could try floating point format for the geometry processing. Since geometry processing is not expected to be a bottleneck compared to pixel rasterization one can probably afford a completely sequential implementation and hence floating point is within reach. Also the dynamic range of floating point makes more sense when it comes to vertices compared to pixel coordinates in raster space (which are inherently integer).

Computer aritmetic appendix from Computer Architecture: A Quantitative Approach

Commodore 64 experiments part-3 (FPGA)

2020-09-26T00:00:00+02:00

I figured the natural next step of our MyC64 journey would be to get the emulator running on a FPGA, or more specifically the ULX3S board. Doing so requires a few support systems such as keyboard input and visual output to be in place so let us use this post to look at how that can be accomplished.

Keyboard input and control

As we already know the real C64 keyboard is a 8x8 matrix connected directly to the CIA1 and scanned by the KERNAL code. Any modern keyboard we might find is based on scan-codes so some conversion layer (much like what we already do in myc64-sim) will be necessary.

In addition to keyboard input .prg injection also needs to be handled.

A straight forward way to deal with these requirements is to treat the emulator as a USB device and develop some kind of software on the host workstation that performs the keyboard forwarding and program injection. Additional control signaling such as reset/reboot could also be handled this way.

Following this approach would put good use to my USB device implementation detailed in previous posts as well as serving as motivation for thoroughly finalizing it and working out remaining bugs.

So let’s do that! We simply grab the entire USB device subsystem from github including controlling RISC-V CPU with ROM and RAM.

On the workstation software side we need to develop a program that communicates with the USB device while maintaining a workable GUI. For the USB communication we use libusb and for GUI we relay on GTK. Combining these two essentially boils down to using the asynchronous API of libusb and plugging it in to the single event loop handled by GTK.

To be more precise libusb is queried for its (Unix) event file descriptors and the GTK event loop is setup to watch these (presumably using the select system call internally). Details are found in sw/myc64-keyb.cpp.

Video output

Displaying C64 video output in a reasonable way is rather tricky as we need to comply with both the internal timing of the VIC-II (to avoid compatibility issues with existing software) as well as the timing of the chosen video format for a modern display.

Apparently this is not impossible as the Ultimate 64 manages to tweak the video timing of 576p50 to match its VIC-II output (described here). Details on the 576p50 video mode can be found here.

For this project we choose to go a different route and store intermediate VIC-II video frames in external SDRAM and display them in 640x480@60Hz over DVI/HDMI.

Audio output

Not much to say about this. The ULX3S features a 4-bit resistor ladder for DAC and we simply connect the SID’s mono output to it. Actually depending on the content 4-bit resolution does not sounds as bad as one would think. Just listen to this comparison video.

The MyC64 SoC

Combining these systems in a SoC turns out as follows

As can be seen this involves interaction between several clock domains. Especially the visual path, which is rather intense in terms of pixel shoveling, uses asynchronous FIFOs when crossing in and out of the SDRAM’s 125MHz clock domain.

The ECP5-12F only has two PLLs so we are limited in the number of clock frequencies that we can synthesize. Two blocks have strict requirements on the clock frequency. The USB block needs a clock that is a multiple of 1.5MHz and the DVI/HDMI controller needs a 125MHz clock (and a derived 25MHz pixel clock). The MyC64 block needs a clock in the neighborhood of 8MHz but it does not have to be exact (especially now that it is decoupled from the display).

So given these constraints we end up with the three clock domains 15MHz, 25MHz and 125MHz seen in the diagram. The MyC64 block uses an internal clock enable to “divide” the 15MHz clock by two.

For the SDRAM the 125MHz clock appears to be a bit too tight, both on the PCB as well as inside the FPGA (builds often fail timing constraints). So with additional clocking resources it would be preferable if this clock could be lowered to say 100MHz.

Since the async FIFOs don’t provide almost full and almost empty signaling it seemed difficult to operate the SDRAM in burst mode (i.e. as the burst is pipelined so we need to stop it before the FIFO is full to avoid overrun). Adding almost full and almost empty signaling to the FIFO was deemed out of scope since asynchronous FIFOs are already notoriously complicated in that area.

One option could have been to add a normal synchronous FIFO in series to get the almost full and almost empty signaling from that FIFO. Another option could have been to adjust the SDRAM address pointers when an overrun or underrun occurs (but since timing is already tight in the SDRAM clock domain this kind of additional logic could make things worse).

While those suggestions seem possible in theory we instead chose a simpler approach of operating the SDRAM in single access mode. Since the C64 only generates 16 colors we can store these in SDRAM instead of the full RGB value. Doing so means that we get four pixels per 16-bit memory access which appears to fall well within the time budget when operating the SDRAM at 125MHz.

The components used are gathered from various places

SDRAM controller - Slightly modified version of the one from fpga4fun.com.
DVI/HDMI controller - From Project Trellis DVI.
Asynchronous FIFO - From here. This is a variant of Cliff Cummings design formally verified by Dan Gisselquist. In fact it is the subject of a Crossing clock domains with an Asynchronous FIFO article by Dan.
MyC64-SubSys - That is what we are working on here.
UsbDev-SubSys - That is what I was working on before this project.

Verilator simulation for the SoC

The simulator needed to be extended a bit to handle all the different components with their associated clock domains. Regrettably I dragged my feet on this and as a result wasted valuable time trying to diagnose what turned out to be rather trivial problems while running on the FPGA.

Mostly it is about handling of multiple clock domains in Verilator. Turns out that Dan Gisselquist has an excellent article titled Handling multiple clocks with Verilator so I went ahead and did something similar.

To avoid breaking the video chain we also need to simulate the external SDRAM so I added a very basic SDRAM model to rtl/myc64-soc/myc64-soc-top.v.

With all this additional stuff in place simulation with myc64-soc-sim is a much slower than with our previous myc64-sim. So much slower that interactive input and display does not make sense any more. Instead the SoC simulator stores each video frame directly to the file system in PNG format.

We store video frames directly after the VIC-II output as well as the intermediate VGA frames that are being fed into the DVI controller. That is we store output both before and after the error prone SDRAM part.

The SoC simulator myc64-soc-sim is implemented in sim/myc64-soc-sim.cpp.

Synthesis

Synthesis for my ULX3S’s ECP5-12F FPGA yields the following utilization which I find rather low given the amount of stuff we have put in. Of course we have used up all the PLLs and almost all of the block RAM but in terms of logic slices it is not that high.

Info: Device utilisation:
Info:          TRELLIS_SLICE:  6136/12144    50%
Info:             TRELLIS_IO:   128/  197    64%
Info:                   DCCA:     4/   56     7%
Info:                 DP16KD:    49/   56    87%
Info:             MULT18X18D:     3/   28    10%
Info:                 ALU54B:     0/   14     0%
Info:                EHXPLLL:     2/    2   100%
Info:                EXTREFB:     0/    1     0%
Info:                   DCUA:     0/    1     0%
Info:              PCSCLKDIV:     0/    2     0%
Info:                IOLOGIC:     0/  128     0%
Info:               SIOLOGIC:     8/   69    11%
Info:                    GSR:     0/    1     0%
Info:                  JTAGG:     0/    1     0%
Info:                   OSCG:     0/    1     0%
Info:                  SEDGA:     0/    1     0%
Info:                    DTR:     0/    1     0%
Info:                USRMCLK:     0/    1     0%
Info:                CLKDIVF:     0/    4     0%
Info:              ECLKSYNCB:     0/   10     0%
Info:                DLLDELD:     0/    8     0%
Info:                 DDRDLL:     0/    4     0%
Info:                DQSBUFM:     0/    8     0%
Info:        TRELLIS_ECLKBUF:     0/    8     0%
Info:           ECLKBRIDGECS:     0/    2     0%

As earlier mentioned, the 125MHz clock domain appears to be operating at its limits as we often get timing constraint violations after small (even unrelated) modifications to the design.

Demonstration

After loading the design on the ULX3S board and plugging in the secondary USB connector we should expect to see the following in dmesg

usb 1-5: new low-speed USB device number 6 using xhci_hcd
usb 1-5: New USB device found, idVendor=abc0, idProduct=0064, bcdDevice= 1.00
usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-5: Product: MyC64 - FPGA based Commodore 64 emulator as a USB device
usb 1-5: Manufacturer: Markus Lavin (https://www.zzzconsulting.se/)
usb 1-5: SerialNumber: 0123456789abcdef

At this point the device should be generating DVI/HDMI output and it is advisable to connect a screen to verify. If all looks good we can go ahead and connect with myc64-keyb and start typing in some BASIC commands. Any key press (and release) that goes into the application window will be forwarded to the USB connected MyC64 emulator.

The myc64-keyb program takes an optional argument that specifies a .prg file to inject into emulator memory.

An interesting program to try out is the machine language monitor SuperMon by Jim Butterfield. SuperMon is the monitor used in Jim’s classic book Machine Language for the Commodore. To get hold of SuperMon itself in modern times simply go to Supermon+64 V1.2. There one can also find a video demonstrating its capabilities.

Known issues / Bugs

USB device loses sync (and host aborts after tree packets with no response) so longer transfers often fail. Works with retry though.
“Static noise” moves past the screen occasionally (seems to be dependent on when reset is released). Believed to be limitations of SDRAM (traces on PCB) operating at 125MHz.
Sometimes the .prg appears to get corrupted when loaded over USB.

Commodore 64 experiments part-2 (SID)

2020-08-22T00:00:00+02:00

NOTE: I wrote the majority of this post (and the implementation) about a month ago but never got around to publish it until now.

After the last post’s progress of getting the system to boot and being able to run small test programs I felt motivated to carry on. While perhaps it would have been wiser focus on the core system I instead turned my attention to the SID chip.

Again, since I did not really do much with my C64 back in the day, and have had no reason to study it afterwards, my pre-existing knowledge about the SID was pretty limited. I basically only knew “it was the chip that made the sounds”.

To get an idea what the SID sounds like the most convenient solution is proably to head over to the online player at DeepSID where there is a huge collection of C64 music from games and demos that will play right in your browser.

So the SID player plays SID files, but what exactly is a .sid file? Well unlike modern audio formats it does not contain PCM samples (e.g. WAV or compressed formats like MP3) nor does it contain the tones/or notes like a MIDI file does. Instead it actually contains 6502 machine code that writes values into SID registers to produce the desired sound. As such a SID player is essentially a scaled down C64 emulator. For a complete description of the SID file format see this link but for our purposes it suffices to say that it contain two entry points. One entry point for an initialization routine that will prepare to play a given song (SID files contain many) and a second entry point for the play routine that is to be called repeatedly (usually at 60Hz).

Now while this format plays directly in a SID player it requires some scaffolding and relocation to play on actual C64 hardware. This is where PSID64 utility comes in, it will provide this scaffolding and relocation and basically converts a .sid file to a .prg that can be loaded and run on a C64.

A huge collection of SID files can be found at the High Voltage SID Collection (HVSC) and convinently their downloads page also provide an archive of the HVSC collection converted to PSID64 format.

Getting the PSID64 .prg to run on MyC64 required some work but it mostly boiled down to finally implementing bank switching.

Let’s try and fire up the good old Bubble Bobble tune

./myc64-sim --cmd-load-prg=130:./MUSICIANS/C/Clarke_Peter/Bubble_Bobble.prg --cmd-inject-keys=135:"LIST<RETURN>RUN<RETURN>"

So now that we have something to test the SID with we can move our focus to try and emulate the actual chip.

For those like me who don’t know anything about music synthesis the following videos (< 10min in total) proved helpful to intorduce the basic concepts

After that I suggest the following souces for details about the SID

A very basic implementation based on that was started in rtl/myc64/sid.v. As usual it is far from complete but it is able to produce some basic tunes. Modifying myc64-sim to store the generated audio signal into a .wav file allowed us to capture Bubble Bobble - MyC64 SID. This admittedly sounds quite a bit off (especially in frequency) compared to Bubble Bobble - VICE 8580 ReSID generated by the well known VICE emulator. Still it is good enough as a first approximation and allows us to move on an focus on other areas. That concludes this post. As always if you have questions or feedback - leave a comment below!

Commodore 64 experiments part-1

2020-07-12T00:00:00+02:00

When I was a kid back in the 80s my parents bought our family’s first computer, a Commodore 64 with a datasette station. I still have fond memories of that marvelous little machine. At the time though I was only ten years old so my mental capacity (and likely also patience) was quite limited. I never managed to do much with it besides playing games and typing in the occasional BASIC listing from the Sunday newspaper. But that almost never worked anyway.

Now in recent times I often find myself watching retro computing episodes from the big YouTubers in the field such as The 8-Bit Guy and Retro Recipes. Needless to say they often feature the C64 and it is refreshing to be reminded of a simpler time. A time when things were not complicated to absurdity, sometimes seemingly, just for the sake of it.

While I know that there are numerous C64 emulators available (mostly in software but also a few FPGA based) I always thought that would be a neat project to try on.

Some weeks ago I ran across the C64 on an FPGA blog series by Johan Steenkamp, a blog series dating from 2017 to present detailing his journey in implementing an FPGA based C64 emulator. While I don’t agree with every design decision taken there the work put in to implementing and the effort spent documenting it is really impressive.

So inspired by this I thought I would try doing something similar or at least see how much work would be required to get a system that boots into BASIC.

Preparations

Before we get started it is useful to gather some preliminary materials.

Documentation

CPU

A Verilog model of a 6502/6510 CPU by Arlet Ottens can be downloaded from here.

ROMs

Kernal, basic and character ROMs can be picked up from here.

Considerations

By today’s standards the C64 is a simply system. However when trying to reimplement it with modern technology (and methodology) inside a single FPGA there are a few things that need to be kept in mind.

The design is based around asynchronous RAM so for reading you expect the data to become available in the same cycle as the address is presented. This is different from the synchronous RAM blocks found inside FPGAs where an additional clock cycle must pass before the data is available.

There are no stall cycles or handshake signals in the bus protocol so every transaction is expected to complete immediately. Also if a chip is not connected to the bus the writes to that will simply be ignored and reads return a default value. When trying to bring up the system this is both good and bad. Good because you feel you make progress fast but bad since you will probably miss implementing functionality that turned out to be really important to avoid those hard to find bugs later on.

The CPU and VIC-II share the same bus by allowing the CPU to access during the first phase of the clock and the VIC-II during the second phase of the clock. This does not map really well to the single edge methodology used in most modern designs.

Also as the design is made up of discrete ICs they are connected with a classic tri-state bus. Tri-state buses inside the fabric is not supported by modern FPGAs so multiplexers need to be used instead. In a way though, it would be nice to be able to closely recreate the PCB interconnect inside the FPGA and have each IC correspond to a Verilog module with the exact same interface signals.

The VIC-II has a 8Mhz pixel clock but the remaining design is based around a 1Mhz system clock where both phases (or edges) are used. This also complicates matters and it is always wise to avoid multiple clock domains unless absolutely necessary.

Design

So given the considerations in the previous section I have chosen to use a single clock domain of 8Mhz with enable signals corresponding to the positive and negative phase of a 1Mhz clock.

The single ported synchronous RAM modules are wrapped so that they act as asynchronous RAM that can be independently accessed with the two 1Mhz phases enable signals. See rtl/spram.v and rtl/sprom.v.

A implementation of a very basic VIC-II is started in rtl/vic-ii.v and likewise for the CIA in rtl/cia.v.

Everything is wired up and connected to a fake keyboard matrix in rtl/myc64-top.v.

Results (so far)

First of all the code for the MyC64 project can be found here on github where the README contains a short intruction sequence to get started with the simulator for those interested.

Simulation is Verilator based and the driver program myc64-sim is similar to the one used for my previous RetroCon project but with the addition of some nifty features to execute delayed commands at a certain frame (e.g. no point injecting a key press sequence until the system has finished booting).

markus@workstation:~/work/repos/myc64/sim$ ./myc64-sim -h
Usage: ./myc64-sim [OPTIONS]

  --scale=N             -- set pixel scaling
  --frame-rate=N        -- try to produce a new frame every N ms
  --save-frame-from=N   -- dump frames to .png starting from frame #N
  --save-frame-to=N=N   -- dump frames to .png ending with frame #N
  --save-frame-prefix=S -- prefix dump frame files with S
  --exit-after-frame=N  -- exit after frame #N
  --trace               -- create dump.vcd
  --cmd-load-prg=<FRAME>:<PRG>           -- wait until <FRAME> then load <PRG>
  --cmd-inject-keys=<FRAME>:<KEYS>       -- wait until <FRAME> then inject <KEYS>
  --cmd-dump-ram=<FRAME>:<ADDR>:<LENGTH> -- wait until <FRAME> then dump <LENGTH> bytes of RAM starting at <ADDR>

As an example consider the following command line that starts simulation and then waits until video frame #135 before injecting the key sequence for the classic one-line BASIC maze generator.

./myc64-sim --cmd-inject-keys=135:"10<SPACE>PRINT<SPACE>CHR<LSHIFT>4<LSHIFT>8205.5+RND<LSHIFT>81<LSHIFT>9<LSHIFT>9;:GOTO<SPACE>10<RETURN>RUN<RETURN>"

It is also possible to inject an arbitrary .prg file into memory and run that. E.g. here we take a trivial program that cycles the background color and assemble it into a .prg file.

Start:
loop:  inc $d021
       jmp loop

cl65 -o test_001.prg -t c64 -C c64-asm.cfg -u __EXEHDR__ testasm/test_001.s

It is interesting to note that the cl65 tool will also insert a small BASIC header containing the necessary SYS <addr> command so that the assembled program can be started with a simple BASIC RUN command.

./myc64-sim --cmd-load-prg=130:test_001.prg --cmd-inject-keys=135:"LIST<RETURN>RUN<RETURN>"

Next steps

I am reasonably happy with the result so far given the limited effort put in, but of course it does not have to end here, this could evolve in any number of different directions. Here are some ideas that come to mind

Continue making the implementation more complete and exact, e.g. take a game such as Bubble Bobble and try to make it play.
Get it running on the ULX3S. This would require putting the video frame in SDRAM so that HDMI/DVI can read it at the correct refresh rate for 640x480@60Hz. Also here we could find real use for the usbdev project to allow key and .prg injection from a host PC.
Start looking at a SID implementation.
Rewrite in nMigen. For quite some time now I have been wanting to try out nMigen on a project and this might be a good opportunity.

That is it for this post. If you have questions or feedback - leave a comment below!

Building a USB device part-2

2020-05-16T00:00:00+02:00

In this post we pick up where we left of last time and start looking at the design and implementation of the USB device that I have been working on. First things first though, the code for the entire project can be found in this github repository. The reader is advised to have that readily available.

The first major goal of this series will be to have the device play along during the USB enumeration process so that the host can set address and read relevant descriptors. This can be verified by making sure that the device shows up properly when issuing a lsusb on my Linux workstation.

Design of usbdev (and SoC)

Clock recovery

The signaling in USB consists of the differential pair D+ and D-. For a full speed (FS) device the bit rate is 12Mbit/s so if we were able to sample at exactly the right spot a 12Mhz clock should suffice, in reality though this is the tricky bit. To aid in clock recovery USB employs both NRZI encoding and bit-stuffing to ensure that the differential pair will contain a level transition at least every seven bit times.

With this in mind it would seem a reasonable approach to run the design at 48Mhz and oversample the differential pair with a factor of four. More precisely by obtaining four equally spaced samples for each bit time we should be able to adjust the actual sampling position (in terms of 1/4 bit times) to be as far away for any level transition as possible (i.e. in the middle of the eye diagram).

So running at a 48Mhz clock we have a 2-bit counter (reg [1:0] cntr) incrementing each cycle (except for when adjusting). When the counter equals zero we perform the real sample. For every 48Mhz cycle we also sample and shift the value into a four bit shift register (reg [3:0] past). Since we want any possible level transition to occur in the middle of this shift register we either advance or delay the counter with one increment depending on if a transition occurred early or late in the shift register.

  // A bit transition should ideally occur between past[2] and past[1]. If it
  // occurs elsewhere we are either sampling too early or too late.
  assign advance = past[3] ^ past[2];
  assign delay   = past[1] ^ past[0];

If advance is active the counter increments by two and if delay is active there is no increment (for the given 48Mhz cycle).

After seeing some transitions this should be able to adjust the sampling point to where the signal lines are stable.

This is not the only option for clock recovery though but it is the simplest one to implement. However if the bit rate was significantly higher compared to the frequency our design is clocked at (e.g. USB high-speed at 480Mbit/s) other methods would have to be used. In such cases I would suspect that sampling at the exact bit rate and then phase adjusting the clock (with help of a PLL) until the synchronization pattern is reliably detected would be the method of choice. Of course simply phase adjusting until the synchronization pattern is detected would not be enough, you probably want a FSM to find the midpoint of highest and lowest phase adjustment that makes the pattern detectable.

A variant of the previous approach would be to use adjustable delay lines on the inputs instead of phase adjusting the clock.

The HW/SW interface

To control the USB block some kind of hardware/software interface needs to be created. I have chosen the simplest possible design that came to mind.

Each endpoint has a 8 byte buffer in RAM, starting at RAM address zero comes the 16 OUT endpoints immediately followed by the 16 IN endpoints. In total 256 bytes of RAM are used for endpoint buffers.

In addition the following registers are exposed to the CPU.

Register	Access	Address
R_USB_ADDR	R/W	0x20000000
R_USB_ENDP_OWNER	R/W	0x20000004
R_USB_CTRL	W	0x20000008
R_USB_IN_SIZE_0_7	R/W	0x2000000C
R_USB_IN_SIZE_8_15	R/W	0x20000010
R_USB_DATA_TOGGLE	R/W	0x20000014
R_USB_OUT_SIZE_0_7	R	0x20000018
R_USB_OUT_SIZE_8_15	R	0x2000001C

I have not bothered documenting them in detail yet but essentially it is as follows.

R_USB_ADDR - is the 7-bit device address.
R_USB_ENDP_OWNER - The 16 low bits correspond to the 16 OUT endpoints and the 16 high bits correspond to the 16 IN endpoints. A set bit indicates that the corresponding endpoint buffer is handed over to the USB block. This means that the corresponding endpoint will accept one IN/OUT packet (with data) and ACK, after which the bit will be cleared and the buffer is handed over to the CPU. When the CPU owns a buffer the USB block will respond with NAK to all IN/OUT+DATA packets.
R_USB_CTRL - Control pull-ups for attach.
R_USB_IN_SIZE_0_7 - 4-bits per endpoint indicate the number of bytes in the corresponding buffer.
R_USB_IN_SIZE_8_15 - 4-bits per endpoint indicate the number of bytes in the corresponding buffer.
R_USB_DATA_TOGGLE - The 16 low bits select the data toggle (DATA0/DATA1) to be expected for the 16 OUT endpoints and the 16 high bits select the data toggle to be sent for the 16 IN endpoints.
R_USB_OUT_SIZE_0_7 - 4-bits per endpoint indicate the number of bytes in the corresponding buffer.
R_USB_OUT_SIZE_8_15 - 4-bits per endpoint indicate the number of bytes in the corresponding buffer.

Of course a primitive interface like this requires a fair amount of CPU intervention and if one wants to offload the CPU and achieve higher performance a lot of this handling could be automated by the USB block itself.

SoC

The resulting SoC consists of the USB device block, a PicoRV32 RISCV CPU, RAM and ROM. From the CPU’s side the memory map is as follows.

Base	Size	Memory
0x00000000	16KB	ROM
0x10000000	4KB	RAM
0x20000000	32B	USB control & status registers

The USB device block’s endpoint buffers reside in RAM and the block has priority over the CPU when accessing. RAM is constructed of four 8-bit banks. The CPU is connected by a 32-bit bus while the USB block has a 8-bit bus. As mentioned USB has priority when accessing RAM but in practice this should result in minimal stall cycles for the CPU as its clock is significantly higher than the rate of which USB will read/write bytes.

Simulation

The simulation environment is based around Verilator and a set of C++ classes to build, manipulate and dissect USB packets.

usb-pack-gen

The USB packet generation and manipulation code is found in sim/usb-pack-gen.h and sim/usb-pack-gen.cpp. It allows both encoding and decoding of USB packets. In essence it consists of three layers

UsbPacket - Base class for the various USB packet types (SETUP,IN,OUT,DATA0,DATA1,ACK,NAK) that allow easy high level manipulation. UsbPacket is derived into the various packet types.
USbBitVector - A sequence of USB bits.
UsbSymbolVector - A sequence of USB symbols (J,K,SE0,SE1).

There are methods for translating in both directions performing the necessary steps such as CRC calculation, bit-stuffing and NRZI encoding.

Test-suite

The test-suite is invoked by the sim/runner.pl script that will execute all tests found in sim/tests (or the ones given as argument). Each sim/tests/test_XXX.c consists of both firmware code to be compiled for the RISCV CPU as well as usb-pack-gen code compiled into the Verilator based simulation environment.

To get a feel for what a test looks like I suggest studying sim/tests/test_003.c. It is probably a good idea to start with running the test and looking at the decoded USB traffic.

./runner.pl tests/test_003.c
sigrok-cli -i test_003.sim.sr -P usb_signalling:dp=0:dm=1,usb_packet | awk '/usb_packet-1: [^:]+$/{ print $0 }'

Should give us something like this (but without the host/device annotations I added manually).

host   : OUT ADDR 0 EP 0
host   : DATA0 [ 23 64 54 AF CA FE ]
device : ACK
host   : IN ADDR 0 EP 1
device : NAK
host   : IN ADDR 0 EP 1
device : DATA0 [ 24 65 55 B0 CB FF ]
host   : ACK
host   : IN ADDR 0 EP 1
device : NAK

So the host sends six bytes of data to endpoint zero and the device acknowledges it. The host tries to read from endpoint one but the device is busy (the dummy loop reading the address register) so responds with a not acknowledge. The host tries to read again and this time the device responds with the byte array with each element incremented by one. The host acknowledges the received data. The host tries to read yet again but now the endpoint buffer has been handed back to the CPU so the USB block responds with not acknowledge.

Now with this in mind it should be rather clear what is going on in the test case.

Test-suite artifacts

When run the test-suite outputs several useful artifacts. These are

test_XXX.comp.log - Any messages (errors and warnings) from the firmware compile.
test_XXX.sim.log - Log and debug printouts from the simulation.
test_XXX.sim.vcd - RTL simulation waveform in VCD format.
test_XXX.sim.sr - Captured USB signaling in sigrok’s format.
test_XXX.elf - Firmware code for the RISCV CPU.
test_XXX.so - Shared object with test-case code to be loaded into the simulator.

A real world example

I thought we finish this post by using some work-in-progress driver code (sw/usb-dev-driver.c) to perform the first steps of the USB enumeration process with the ULX3S connected to my Linux workstation. The logic analyzer captured the following trace (5M samples at 5Mhz but only 68KB file size with sigrok’s native format). The reader is urged to decode it by at least using

sigrok-cli -i ulx3s-usbdev-1.sr -P usb_signalling:dp=1:dm=0,usb_packet | awk '/usb_packet-1: [^:]+$/{ print $0 }'

but preferably also in PulseView to better see reset signaling etc.

In summary the following happens in the trace. The host resets the bus, the device descriptor is read, the host resets the bus, the host sets the device’s address to 23, the host reads the device descriptor once again, the host reads the configuration descriptor (first nine bytes only to figure out total size), the host reads the total size of the configuration descriptor (which includes interface and endpoint descriptors but in our case there are none so the size is still 9 bytes). Finally the host tries to set the configuration of the device but this is not yet implemented in the firmware and the device responds with NAK indefinitely.

On my Linux workstation the dmesg log contained the following lines

[ 2980.864737] usb 1-5: new low-speed USB device number 16 using xhci_hcd
[ 2981.014361] usb 1-5: config 0 has no interfaces?
[ 2981.014369] usb 1-5: New USB device found, idVendor=1234, idProduct=5678
[ 2981.014372] usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2981.014647] usb 1-5: config 0 descriptor??
[ 2986.192817] usb 1-5: can't set config #0, error -110

and a lsusb -v contained

Bus 001 Device 016: ID 1234:5678 Brain Actuated Technologies
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0         8
  idVendor           0x1234 Brain Actuated Technologies
  idProduct          0x5678
  bcdDevice            1.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength            9
    bNumInterfaces          0
    bConfigurationValue     0
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA

As can be seen my made up idVendor actually corresponded to a registered vendor as can be confirmed in Linux usb.ids.

Slightly strange though is that lsusb claims that the device address is 16 while the trace clearly contains a SET_ADDRESS and subsequent use of address 23.

Next steps

The logical next steps would be to continue working on the driver code until the enumeration process completes successfully supporting all required requests. Likely some RTL bugs will show up in the process but we will try to deal with them when they do.

That is it for today. As always if you have questions or feedback - leave a comment below!

Sigrok and thoughts on building a USB device

2020-04-25T00:00:00+02:00

Last summer I bought a DSLogic Plus USB-based Logic Analyzer, about 6 months ago I tried it for the first time and today I hope to finish this post describing the experience. The thing comes with its own analyzer software running on the PC called DSView, but I never bothered trying that and instead went with the better known sigrok (of which DSView is a derivative).

Setting up sigrok for the DSLogic Plus

Building from source seemed rather complicated with many dependencies to be met, but luckily they also provide self contained AppImage binaries for download here. So I picked up a PulseView and a sigrok-cli binary.

Although being self contained two additional steps were required to get things going.

First setting up udev rules

git clone git://sigrok.org/libsigrok
cp libsigrok/contrib/*.rules /etc/udev/rules.d/

and second, due to legal reasons, the self contained sigrok binaries do not contain the necessary firmware for the DSLogic Plus so we need to grab a script that fetches those separately

git clone git://sigrok.org/sigrok-util
sudo sigrok-util/firmware/dreamsourcelab-dslogic/sigrok-fwextract-dreamsourcelab-dslogic

Test capture

Attaching to the USB D+ and D- of a STM32 based thumb device and capturing the signaling that occurs when the device is connected to the bus.

For background on USB 2.0 the spec summary USB in a NutShell is a highly recommended read, the similar summary USB Made Simple also provides very valuable information. For all the gory details the full specification is available here.

Sigrok provides a very neat protocol decoder for USB (as well as for many other protocols).

It is interesting to observe what happens when a new device is connected

# Newly connected device has address 0.
host   : SETUP ADDR 0 EP 0
host   : DATA0 [ 80 06 00 01 00 00 40 00 ]
device : ACK
host   : IN ADDR 0 EP 0
device : NAK
host   : IN ADDR 0 EP 0
device : DATA1 [ 12 01 00 02 02 02 00 40 83 04 40 57 00 02 01 02 03 01 ]
host   : ACK

host   : OUT ADDR 0 EP 0
host   : DATA1 [ ]
device : NAK
host   : OUT ADDR 0 EP 0
host   : DATA1 [ ]
device : ACK

host: <RESET for 50ms>

# SET_ADDRESS (=0x05) to 10 (=0x0A)
host   : SETUP ADDR 0 EP 0
host   : DATA0 [ 00 05 0A 00 00 00 00 00 ]
device : ACK
host   : IN ADDR 0 EP 0
device : NAK
host   : IN ADDR 0 EP 0
device : DATA1 [ ]
device : ACK

# From this point on the device has address 10.

host   : SETUP ADDR 10 EP 0
host   : DATA0 [ 80 06 00 01 00 00 12 00 ]
device : ACK
...

what appears to be going on here is that the host begins by reading the device descriptor containing, among other things, the highest USB version this device supports, idVendor and idProduct. If these are satisfactory the host goes ahead and drives a long reset followed by assigning the device a new address.

A simple lsusb confirms that idVendor and idProduct appear in the response message retrieved before the reset.

Bus 001 Device 010: ID 0483:5740 STMicroelectronics STM32F407

Thoughts on building a USB device

If you are so inclined you might now wonder what kind of digital circuitry it would take to build a USB device. Common sense says this would be a rather significant undertaking so it seems wise to begin with some preparatory considerations.

ULX3S setup

As usual the platform for my experiment will be the excellent ULX3S. The board has two USB micro female connectors where the second (designated US2) is wired directly to the ECP5 FPGA.

Schematics

Full schematics are found here but for the sake of this discussion I have extracted the relevant parts.

What is interesting to note here is that the USB_FPGA_D+ and USB_FPGA_D- pair is connected to the FPGA twice. One pair is connected to a differential IO cell and the second pair is connected to single ended IO cells. Reason is that USB requires us to both drive and sample differential as well as single ended. Still weird though as ECP5 docs kind of suggest that all of that could be done within one IO cell (pair).

The second interesting part is that the board has FPGA controllable pull-ups. This allows us to attach/detach from the USB without physically touching any cables. As well as choosing if we want to identify as a full-speed or low-speed device.

Clocking

USB full-speed is 12Mbit/s and USB low-speed is 1.5Mbit/s, the ULX3S board has a 25Mhz crystal oscillator.

For full-speed if we were to sample at exactly the right spot a 12Mhz clock should suffice, but in reality this is not possible (without phase adjusting the clock). So instead one typically settles for oversampling with a factor of four (so a 48Mhz clock would be needed).

Now a 25Mhz clock does not directly PLL into a 48Mhz clock (nor any other reasonable multiple of 12Mhz). It does however PLL it into a 15Mhz clock that can be used for low-speed (oversampling with a factor 10).

Eventually though for full-speed we can use two PLLs in cascade configured as follows to reach exactly 48Mhz.

markus@workstation:~$ ecppll -i 25 -o 60
Pll parameters:
Refclk divisor: 5
Feedback divisor: 12
clkout0 divisor: 10
clkout0 frequency: 60 MHz
VCO frequency: 600
markus@workstation:~$ ecppll -i 60 -o 48
Pll parameters:
Refclk divisor: 5
Feedback divisor: 4
clkout0 divisor: 12
clkout0 frequency: 48 MHz
VCO frequency: 576

Connecting the Logic Analyzer

A sturdy attachment point for the analyzer is desirable as it is rather annoying having test hook clips constantly falling off the board as soon as it is moved/touched only the slightest.

Luckily since it is a FPGA we can route the USB_FPGA_D+ and USB_FPGA_D- pair “out on the other side” to make it available on the pin header. This is mechanically stable and has the additional advantage of being isolated from the actual signals so there is no risk of interference from the analyzer probes.

Sigrok support

Having powerful tools such as the Sigrok suite and the Logic Analyzer will prove invaluable for the task ahead. In fact, as we shall soon see, they will be useful in not only the obvious way.

Capture signaling/traffic between the USB host and FPGA would be the obvious application and while this will eventually be its main use we need to get quite a lot of things working to reach that point.

In the meantime we can capture authentic host signaling and feed into RTL simulation. Doing so can be easily accomplished with

sigrok-cli --input-file capture.sr -O csv | awk 'BEGIN{FS=","}{print $2$3}' - > capture.vh

and initializing the Verilog array with $readmemb.

However this presents an issue with mismatch in sampling rate. The closest the analyzer can come to 48Mhz is 50Mhz so this will be an issue for the USB device’s clock recovery.

To avoid the sampling rate mismatch another option is to have sigrok run the low level usb-signalling decoder to reliably extract the J, K, SE0 and SE1 symbols for us. To do this we use the follow python snippet to translate

#!/usr/bin/env python
import sys
import re

pattern_j = re.compile("^usb_signalling-1: J$")
pattern_k = re.compile("^usb_signalling-1: K$")
pattern_se0 = re.compile("^usb_signalling-1: SE0$")
pattern_se1 = re.compile("^usb_signalling-1: SE1$")

for line in sys.stdin:
  if (pattern_j.match(line)):
    print('01')
  elif (pattern_k.match(line)):
    print('10')
  elif (pattern_se0.match(line)):
    print('00')
  elif (pattern_se1.match(line)):
    print('11')

and then run the entire chain

sigrok-cli -i capture.sr -P usb_signalling:dp=1:dm=0 | ./usb_signalling2vh.py > capture.vh

Once our RTL simulation generates USB signaling we can feed that into sigrok for decode and verification. It is just a matter of having simulation produce a CSV file and then

sigrok-cli -i capture.csv -I csv:samplerate=48000000 -o capture.sr

where the file capture.sr can be opened and graphically decoded in PulseView. Pretty awesome!

Wrap up

That concludes this post. Next time we will look closer at the design of our USB device, its simulation environment and traffic generator. Questions or feedback - leave a comment below!