To fix this, I'll need to resynthesise the whole thing, which will take ~30 minutes. However, it would be great to be able to test things faster than that. A very simple FPGA program can synthesise in about 3 minutes, which is much better. Since we will likely be testing a pile of stuff over the coming days, it is worth making such a program, so that we can quickly iterate things.
Ok, so I have done that, and then realised that until we program the little FPGA that handles IO routing, we can't actually even use the UART monitor. To make life more fun, that FPGA is an Altera/Intel MAX10 -- this means a completely different tool set compared with the Xilinx main FPGA. So time to download 6GB of software, install it using 15GB of disk, and then learn how to use quartus for the first time.
After considerable fighting, I think I am on the way. Instead of an .XCF file for constraints, it uses a .QSF file, which has syntax that is not totally different to that of the XCF files. For example to assign the four pins for the monitor UART (2 to the Xilinx FPGA and 2 to the JTAG connector), the following does the trick:
set_location_assignment PIN_A5 -to te_uart_rx
set_location_assignment PIN_B4 -to te_uart_tx
set_location_assignment PIN_J10 -to dbg_uart_rx
set_location_assignment PIN_K10 -to dbg_uart_tx
So in theory that should be enough to be able to connect logic to the pins. We should in theory just need to connect te_uart_rx to dbg_uart_rx and similarly for the *_tx lines.
I have also put it under source control, although I am sure for now that I have included all manner of build artefacts, rather than just the source files. Perhaps a willing volunteer with some experience with quartus can provide a pull-request to sift them out and create an appropriate .gitignore file. The repository is at https://github.com/MEGA65/mega65-r2-max10
Now the only problem is we are out at a studio to get photos of the MEGA65 pre-series units, and didn't bring the programmer or power adapters with us, that would let me test it.
But in the meantime I can try to solve another problem: The Quartus/Arrow USB drivers to use the programmer for the MAX10 have the annoying side effect of taking control of all FTDI devices with the same USB ID. This is annoying because the adapter for the Xilinx FPGA gets picked up by it, which prevents it from being available to connect to. The problem is that the udev rules file seems to ignore the serial number and vendor fields, so I can't just make it handle the two differently that way.
Digging around on the internet, I found this nice summary of things: http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/. The nice bit here is the info on how to create symlinks to devices. In theory, I should be able to use that to modify my rules file to see when it picks up one or the other.
But I fear that the problem is that the same driver gets used by Linux for ALL devices with a given USB vendor:product tuple, so I might need to change the tuple for the Arrow programmer board.
Digging further, this looks like it might be a problem of how the detection works, in that all variables have to be considered at a single level of the USB device specification (https://askubuntu.com/questions/978485/udev-rule-with-serial-for-ttyusb-not-working). That article suggests doing the tying based on which physical port things are connected to, which could work for me, and also suggests that it should be possible to do it on the basis of serial numbers. I might need to simplify the rule to just look at the serial number and nothing else. Again, I'll have to wait until we get back to where we have the adaptors.
Ah, reading further in the rules file, it seems that part of the problem is that the rule unbinds the FTDI SIO driver when the rule is triggered, which would cause it to unbind any existingly connected device as soon as an Arrow programmer is plugged in. The question arises in my mind, that I am not actually sure that it is a problem that the serial driver remains connected. Again, something else to test later today.
What I can do in the meantime, is to get the rest of the pins for the MAX10 labelled in the QSF file, so that I can begin implementing the rest of the connections, such as to the keyboard.
So, having gone through that, there are a few interesting things that Antti and the folks at Trenz have included:
1. The microSD card slot also doubles as a JTAG programming/debugging interface for the MAX10 FPGA, if you hold the reset button on the side of the computer in. This means with a funky adapter it will be possible to program the MAX10 without even opening the machine.
2. The MAX10 is able to control the JTAG debug interface to the Xilinx FPGA and keyboard, so the same interface can be used to program the Xilinx FPGA from outside as well.
3. Four dip switches for setting things about the machine, e.g., defaulting to PAL/NTSC or keyboard nationality.
4. 256-byte serial flash with globally unique ID, e.g., for seeding the mac address or serial number identification of the machine.
5. 16KB serial flash for storing other things, if we have need. It might be possible to increase this to 128KB, so that a complete ROM could be stored there.
6. A real-time clock and battery, which we can do a bit of magic with, so that the CIA RTC registers get initialised with the values from the actual RTC. It would even be possible for us to make writing to the CIA RTC registers cause the actual RTC to update.
7. The power to the PMOD expansion connectors can be turned on and off for hot-swap.
8. 12-pin debug/expansion header connected directly to the MAX10 FPGA.
But, back to the point at hand, we need to work out which pin connections we need to setup in the MAX10 FPGA. I think the list is:
1. Tri-state Xilinx FPGA reset and related configuration lines
2. Enable 5V power output to joysticks and expansion port.
3. Connect Monitor UART interface between Xilinx FPGA and TE0790 connector.
4. Connect Keyboard connector to Xilinx FPGA.
5. Connect Xilinx FPGA JTAG debug interface to TE0790 connector.
6. Connect microSD card to Xilinx FPGA.
7. Connect reset button to Xilinx FPGA.
8. Disable power save for VGA VDAC.
Most of these are simply straight-through routing of signals. However, the microSD card interface is a bit annoying, because there is no matching set of pins between the Xilinx FPGA and the MAX10. This means we will need to implement an SD card controller in the MAX10 and relay the data at the sector level -- or get the R3 PCB to have the lines to connect it directly to the Xilinx FPGA.
Anyway, that's all we can attack for now, until we get back to base in a couple of hours.
 |
| MEGA65 R2 PCB in pre-series case. |
No comments:
Post a Comment