Introduction

Dramite aims to build a small PC-compatible SBC based on an Intel 80386DX processor and an FPGA to emulate a custom chipset. There are several reasons why I am building a 386 PC in 2021:

1. To learn Chisel
2. I happen to have lots of 386DX chips lying around
3. Just because

I expect this to be a long term project, and this is the first project log. I am trying not to explain too many details in these notes. This should not be a tutorial, but just some facts.

Overall Architecture

An FPGA is used as the bridge. It would handle everything from memory controller, floating point co-processor, to legacy IO bus, USB keyboard and mouse IO port emulation.

On a high level, the design would be simply connect the 386DX to the FPGA, done. However, it is still unclear how to approach everything in the FPGA. We could try to replicate things that exists on real 386 motherboards, such as direct connect between 386 and 387, SRAM caches, ISA buses, multiple devices attached to the ISA buses, etc. But this might not be the optimal solution, and sometimes may not even apply. For example, we would not have FPM/EDO RAMs on our board. Instead I would like to start from a performance perspective, looking at what we have, and see what would be the optimal architecture design.

Local Bus

The processor is the 386DX, I obviously couldn't modify the internals of the processor to enhance the performance. But I want to ensure I get the most out of it. The best I can do is to allow the bus access to finish as quick as possible (0 wait state).

The 386 also allows the bus to be pipelined, so it would sends the address one cycle eariler, to give the memory more time to access. Unfortunately this function also comes with a cost:

Table comes from Intel 80386DX Microprocessor Hardware Reference Manual. As you may see, by enabling the pipelining, we lose 9% of performance. This is still better than 1 wait state, which we loose 19% of performance. We shall see how these means in terms of the time for the FPGA to respond.

In the non-pipelined case, looking at CYCLE 1, the 386DX outputs the valid address and control signals on the falling edge of CLK in T1. Means the FPGA could latch the data in on the rising edge of CLK in T1. The 386DX expects the data to be ready on the falling edge of CLK in T2, means the FPGA should put out the data on the rising edge of CLK in T2. The FPGA has exactly one cycle time in CLK to prepare the data. CLK runs at 33MHz, translates to a cycle time of 30ns. The whole bus cycle lasts for 60ns, and FPGA has 30ns to prepare the data.

If one wait state is added, such as in CYCLE 3, the whole cycle is now 90ns. And the FPGA has 60ns to prepare the data in this case.

What about pipelined?

The bus cycle time is still 60ns, but the FPGA now gets 60ns to prepare the data. Remember this is with 9% of performance penalty.

In conclusion, to achieve the absolutely best performance, we use non-pipelined mode and supply the data in single cycle. It is currently unknown if it would provide any performance improvement if I mix both modes.

Cache

Obviously, some form of cache is needed to provide the data in 30ns. But what kind of?

The on-chip memory of FPGA would certainly be fast enough to provide data in 30ns.

Off-chip high speed SRAMs would also be able to provide data in 30ns. We could use the normal SRAM chips to build the cache if we want, at the cost of layout complexity and IO pin usage.

FPGA on-chip memory size, just for reference.

DRAM

How slow is the DRAM?

Using the DDR3 MIG on Aritx-7, with AXI interface, we could see the typical read latency:

The time difference is 63799.5ns - 63607.5ns = 192ns.

But if we think the DRAM controller is probably not very optimized, what's is the time it takes the DDR3 memory itself to read the data?

Much faster. 63746ns - 63714ns = 32ns, just a little above the cycle time that 386 would take.

But the cache is still needed. It is just the cache miss penalty wouldn't be too bad.

Hardware IO Planning

• 80386DX: 79 5V IOs (with address pipeline mode disabled, 32 bit only, no bus take-over)
• RGMII: 16 1.5V/1.8V/2.5V/3.3V IOs
• Audio: 3 1.8V/3.3V IOs
• USB: 11 1.8V/3.3V IOs + 1 RESET (could be open-drain)
• SDIO: 6 3.3V IOs
• HDMI: 4 TMDS pairs (GTP + voltage translator, or 1.8V IO)
• DDR3 SODIMM: 118 1.5V IOs

The 80386DX needs voltage translator, and best 3.3V-5V for minimal propagation delay. Plus 1 direction control pin for databus, so that's 80 3.3V IOs. Basically means 2 of the IO banks needs to be 3.3V.

The DDR3 uses 3 IO banks, so 3 of the IO banks needs to be 1.5V.

And some common I2C control channels for audio, SPD, HDMI, etc. Count as 4, any voltage.

XC7A35T has 6 available IO banks:

• IO Bank 14: 50 IOs, 1.5V
• IO Bank 15: 50 IOs, 1.5V
• IO Bank 16: 50 IOs, 1.5V
• IO Bank 34: 50 IOs, 3.3V
• IO Bank 35: 50 IOs, 3.3V
• IO Bank 216: 4 TX pairs and 4 RX pairs

In total it has 150 1.5V IOs, 100 3.3V IOs, 4 TX pairs, and 4 RX pairs.

In total 134+5 1.5 IOs, 100 3.3 IOs, 4 TX pairs needed. It still has 11 1.5V IOs and 4 RX pairs left.

I promised that there would be an update about the USB, here it is. This update would only talk about the USB 2.0 Host on the Pano Logic G1 devices with ISP1760 USB host controller, so it is probably not applicapable to other platforms. The goal here is to write a set of RTL and software stack, so it is possible to use USB HID joystick/ gamepad and USB mass storage devices on the Pano G1. Speed would not be the concern here.

Hardware Connections

On the Pano G1, an USB 2.0 high-speed host controller (Phillips ISP1760) is connected to the FPGA via 16-bit parallel memory bus. To mitigate one of the controller’s errata, an USB high speed hub (SMSC USB2513) is connected to one of the downstream port of the controller, and all user accessible ports are connected to the USB hub.

Overall Architecture

Though it might be possible to write a FSM to implement some basics of the USB host protocol stack, it is just not very practical. (Device side might be more practical, though). The solution I have here is to continue use the PicoRV32 soft-core processor on the FPGA. The host controller would be mapped to PicoRV32’s memory space as MMIO, then software driver and protocol stack can run on the PicoRV32. When needed, certain outputs can be achieved by using MMIO GPIO (for example, output the currently pressed keys). Hopefully, debugging software would be much easier than debugging hardware.

Generally, there would be several layers. The bottom part is called as the HCD (Host Controller Driver), which is specific to particular hardware, like the controller chip being used. Then it comes the HD (Host Driver), this is the part handles device enumeration and USB Hub communication, this layer is no longer specific to the platform. Higher than that is the class driver, as name suggests this is specific to a device class, for example, HID class or audio class. The driver might be generic to the whole class, or it might just support one of few specific USB devices. Higher than that, usually it is operating system, or in our case, user application.

In conclusion, there are 5 things I need to do:

1. Write the RTL to interface ISP1760 with PicoRV32
2. Port or write the HCD for ISP1760
3. Port some appropriate host driver over
4. Port or write the class driver for HID gamepad and mass storage devices
5. Write some application code to use the driver

Let’s discuss all these parts.

嗯……受邀去做了一下演讲，懒得翻译了，就发生肉了，中式英语大家都听得懂吧（笑） 大致介绍了一下我设计GameBoy掌机项目的一些经历。完整的项目相关的东西可以见这里：VerilogBoy项目页。

• https://www.bilibili.com/video/av51601240/

It has been a while since my last update. I have been working on the USB stuff for Pano Logic G1, mainly for connecting to joysticks and flash drives. I was concerned that my LPDDR and cache would cause me some trouble when the code is being executed in RAM, but so far they are holding up well. I will talk more about them in the next log. In this log I would like to talk a little about some debugging utilites, namely, the UART and the hard fault.

UART

UART is very handy when you want to see logs from the device. At first I thought I can get away just by using VGA text terminal, but it soon turns out that 80x30 text is simply not enough. Unfortunately the Pano Logic doesn't have any serial ports. From the schematics, it seems that they originally have one, but was removed after some revisions. But anyway, I have to repurpose the IOs to create myself a serial port to use.

This is not new to Pano Logic, Skip Hansen from PanoMan project has already done this: he soldered a wire to the LED pin and get the serial output from there. For me, as mentioned in one previous log, I do not have soldering iron with me currently, so I need to find some other way.

As an alternate, I used the wire clip come with my logic analyzer. They can be attached to through-hole components easily, such as this VGA connector.

I am using VGA SCL pin for the serial port. I wrote an extremely simple UART transmitter to transfer the data: https://github.com/zephray/VerilogBoy/blob/refactor/target/panog1/fpga/simple_uart.v. Why I don't just use Skip's UART transmitter core for Pano Logic G1? Or why I don't just work on top of Tom and Skip's project? Well, the (stupid) answer is the same regarding why I picked PicoRV32 rather than VexRiscv: I have decided (long ago) to call this project VerilogBoy, so all the source code should be written in Verilog, not SpinalHDL. Yes I am also aware there are tons of better open-source UART controller written in Verilog available online. I am probably just too lazy to find one considering I don't need other fancy functions anyway.

Introduction

Back in the last century, when the CRT was still the most common technology for computer monitors. It was quite common to see such an argument: the LCD will probably evolve and produce better images, but it is never going to replace the CRTs. CRTs are just objectively way superior in terms of image quality, and LCDs are only suitable for applications requires absolute low profile and low power consumption[1]. Several decades later, we all know what happened in the end. I think it was be fun to take a look at the LCDs at that time, are they really that bad? What it would be like to use that kind of screen in 2019?

LCDs in the last century

There were several different types of display being used on portable PCs last century. The very first portable PC in the last century usually comes with CRT displays, like Compaq Portable (1983) or IBM 5155 (1984). Of course, it is clear that CRTs just too heavy to be used on these portable devices. Later they switch to TN LCDs, like on IBM 5140 (1986) and Toshiba T1000 (1987). These TN displays has very low contrast and very poor viewing angles.

Later some companies experimented other technologies like Gas Plasma screens on Toshiba T3200 (1987) or IBM PS/2 P70 (1991). Gas Plasma screens provides perfect contrast, but the color was limited to different shades of orange, and was very expensive to produce.

Finally, in the early 90s, the industry switched to the STN LCD screens. These STN screens provided not too bad contrast (typically 1:5 to 1:50), and few shades of gray. Given these laptops are mainly for business uses, STN screens was good enough. But what if one want color display? There were two choices, CSTN and Color TFT. The first laptop with a color TFT screen was the NEC PC9801NC, came out in 1990. The TFT screen provided much higher contrast ratio and much lower response time, with one drawback: it was expensive to manufacture. CSTN, on the other hand, was basically a STN screen plus a color filter. Cheap to manufacture but the performance was limited. As a result, STN and CSTN continues to dominate the market, and being used widely on low-end laptops. Today we can still see CSTN screens being used on New York subway trains.