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.

As one of the conclusion of the last log, in order to use the LPDDR memory in 32-bit mode on the Pano Logic G1, a cache is almost a must. Sure I can just use 16-bit mode, half the capacity (16 MB) isn't really an issue for me... But I still decided to just implement a cache, it shouldn't be that hard.

So, as a result, I have got cache working on Pano Logic G1. It is a 8-KBytes 2-way set-associative cache. Replacement policy is LRU and write policy is write back. (The whole point of having a cache is because write through is almost impossible given the data mask cannot be used.) It is connected between the PicoRV32 CPU and the MIG memory controller, so all read and writes to the LPDDR is cached. I won't go into details about the cache since I feel like there is nothing special worth talking about except being slow and inefficient. I will add an bus master arbiter between the PicoRV32 and the cache in the future, so the GameBoy CPU could access the LPDDR as well. Though one need to keep in mind this is only a 2-way set-associative cache, having multiple masters would lead to very questionable performance.

So, what about the performance? Currently:

• Read hit: 2 cycles
• Write hit: 2 cycles
• Read miss: 4 cycles + memory read latency
• Write miss: 5 cycles + memory read latency
• Read miss + flush: 12 cycles + memory write latency + memory read latency
• Write miss + flush: 13 cycles + memory write latency + memory read latency

So you can see.. The cost of missing is high, and the cost of flush is very high.

Also, due to my bad coding and the limitation of Spartan-3E's block RAM (it does not support byte enable, which is important for a cache that allows byte enable), compared to 16-bit non-cached version, the whole design uses 1500 more LUTs. I assume mostly comes from the cache, and some from the 32-bit memory controller.

But anyway... It Works™.

Remember that WIP #LetsDriveLCD? I am still having some trouble with the MIPI-DSI, and that's part of the VerilogBoy project. Currently I do not have access to any soldering tools, so the plan of making a new revision of prototype need to be postponed. In the meanwhile, I thought it might be a good idea to continue working on the RTL – I started refactoring the code but haven't finished yet. But, I need a hardware platform to test. Well, I forgot to bring my FPGA development board (Xilinx ML505, I really loved that board) with me when I came back from Christmas holiday… But no problem, I got myself two Pano Logic thin clients (G1 and G2) last year. Though I have to admit, I didn't do much with these units after I got them. Now the time has come, let's take a look.

We have something to hack

In case you are not familiar with them, let me introduce them first. They were originally thin clients, used to connect to remote desktop servers. What is special about Pano boxes are, they are powered by FPGAs, rather than ARM or x86 CPUs commonly found on a thin client. They advertise it being a “Zero Client”, means there is no (zero) software running on the client. Well, unfortunate for them, they went bankruptcy in 2013. What is fortunate for us is that, these units now become useless for companies originally bought them, being sold for very low price on places like eBay. It is our turn to repurpose these devices! Of course, hackaday has already featured it for several times:

• Ask Hackaday: We might have some FPGAs to hack
• Racing the Beam on a Thin Client, in FPGAs
• Pac-Man Fever Comes to the Pano Logic FPGA
• Two Joysticks Talk To FPGA Arcade Game Over A VGA Cable

As far as I know, there are 3 generations of Pano Logic clients, the first two looks very similar, and the third is slimmer. Unfortunately I have never seen a slim model on the eBay. If you know anything about the slim model, please tell me, I am interested. The first generation (G1) model is powered by a Xilinx Spartan-3E XC3S1600E FPGA (1600K system gates, translate to around 30K LUT4s.), with 32MB of on-board LPDDR RAM. The second generation model, depending on the revision, is either powered by a Xilinx Spartan-6 XC6SLX150 (Rev. B) or Xilinx Spartan-6 XC6SLX100 (Rev. C), both with 128MB of DDR3 memory. The one I own is a Rev. C one. Both generations has already been reversed engineered by the community, notably cyrozap, twj42, and Tom Verbeure. You may find more information about details of the Pano boxes here: https://github.com/tomverbeure/panologic, and https://github.com/tomverbeure/panologic-g2.

本期，我们将继续讲解之前没有讲完的Verilog代码。上一期的教程已经介绍了Verilog最核心的一些操作，本期则将介绍一些有用的其它操作，他们最终也可以用核心的操作代码表示出来，但是通常而言编写起来更为简便。本期同样会介绍仿真工具的使用，在开发过程中非常有用。不过在开始新的内容之前，先来讲讲上一次留的作业。

上期练习

上期留了一个作业，就是实现第五期里面讲过的状态机。这里首先复述一下第五期的状态机：假设一个贩卖机，只卖矿泉水，价格定为2元，只接受1元硬币或者5角硬币，多不找零，设计一个状态机来描述它的行为。这个机器的话，它有两个输入，投入5角或者投入1元；以及一个输出，是否已经付了足够多的钱。

如同之前一样，假设表示投入5角硬币的信号叫a，表示投入1元硬币的信号叫b，输出是否已经付够钱的信号叫c。同时定义这个系统有S0-S4一共5个状态，分别表示当时已经投入了0、0.5、1、1.5和2元。

要用Verilog来实现这个状态，第一步肯定是先写一个整体的模块框架，再往里面加入东西。于是参考上期的声明module的方法，先写下如下的代码：

module vending(
    input clk,
    input rst,
    input a,
    input b,
    output c);

endmodule

上面的代码定义了一个叫vending的模块，有四个输入，clk、rst、a和b，一个输出c，主体没有内容。clk提供时钟，rst提供复位。首先来考虑输出吧。状态机的输出是由当前状态决定的，所以需要有一个变量（触发器）来保存当前的状态，比如叫做state：

reg [2:0] state;

有了state之后就可以描述输出的逻辑了。一种方法是直接用第五期的逻辑表达式：

assign c = state[2] && !state[1] && !state[0];