log.txt

2023-01-06:

- Should you use a 1K or 4K?  The 4K is only available from Mouser, but the 1K is at Digikey or Mouser
  It turns out Mouser has them on order, but not available, so they must be subject to shortages, so the 1K is a safer bet

- should you multiplex the address and data buses onboard?  So you'd have 4 x 16-bit bidirectional transceivers, 2 for
  each bus, and the low voltage side would be wired together and go to one set of 32 FPGA I/Os, and the EN and DIR pins
  for each bus would be wired to the FPGA so it can enable one or the other but not both?
- no I think if you want to do that, you need a latch for the address bus or else it can't actually make a transaction
  on the bus to program the flash chips onboard computie
- but for reading, you'd still need the address pins to be an input, meaning you'd need an extra set of transceivers...
- so it sounds like, either use 64 pins (out of 96 I/O pins), or 6 x 16bit chips, or just don't use it to program flash,
  or act as a bus sender, but instead just be a device and sniffer/analyzer
- just do a passive device for now, not a bus sender, so only 4 multiplexing chips

2023-01-08:

- I need to select some LDO regulators.  I definitely need a 1.2V and 3.3V, but I might need a 2.5V as well, or at least a zener
  diode like the Olimex board uses.  The 2.5V doesn't need to use a lot of current, and since digikey has a lot of the one that the
  TinyFPGA uses, the MIC5365, I think I'll just go with that.  The only concern is that it's in a very small package, SOT-323/SC-70
  but I think I might have soldered something like that before.  They don't have the same model in the SOT-23 package
- for the 3.3V regulator, I think I'll try something bigger, like 500mA.  I will also add a mosfet to either power from USB or from
  a separate source, but that will require an additional opamp I think...  at least the Arudino schematics use that
- I selected the AP2112K-3.3TRG1 from Diodes Inc as the 3.3V supply.  It has 600mA output and the specs seem pretty good, and price
  is low
- I decided to go with another MIC5365 for the 2.5V supply just because it's easy and should work, even though it's probably
  overkill for what the FPGA actually needs on that pin.  Better to be safe than sorry when I need to buy a new specific part
  anyways.

2023-01-10:

- I'm sort of thinking of adding the latches to allow the device to program flash in-circuit on the boards, or be a bus
  sender/requester.  I already need 6 transceivers for the bus signals =/  But it would make it a bit more versatile, and
  I don't have to add them
- I'm going to stick with what tinyfpga did with the SPI flash size and not using the cold boot option to store multiple configs
  because I want to make sure it's as compatible out of the box.  I can change things later once I have something working

2023-01-14:

- I added the oscillators, but I had to swap out the one that TinyFPGA uses because it wasn't available from digikey or mouser.
  I replaced it with a Kyocera KC2520Z16.0000C15XXK which was just the first digikey result that looked like I could hand solder
  it.  It seems to function exactly the same as the other one
- I kept the 16MHz oscillator because it's probably used by the usb bootloader, and I don't want to have to modify that to make
  this work
- I added a 3.6864MHz oscillator because that's what the serial chips on computie use, and I need an odd frequency tty-compatible
  oscillator for any kind of usart.  These two should be enough

2023-01-15:

- I had to switch out the 2.5V regulator for a MIC5317-2.5YM5 because the MIC5365 wasn't available.  It seems to be an identical
  part in every way except it can take up to 6V input instead of 5.5V as the limit.  The datasheet is also a Microchip one, instead
  of Micrel which I assume was bought out, so maybe this series is a newer one that will replace the older series.

- there is no suitable level shifting latch, but we already have level shifting on the address bus, so if the latch is connected to
  the shifted output of the transceiver, it should be ok.  The only problem might be the inputs to OE and LE for the latch, which
  would have to be level shifted from the FPGA I/O =/.  It's also a bit sketchy in that the latch is outputting onto the same bus
  it's getting data from, so the control of the latch has to *make sure* that the OE isn't active until LE is inactive or else they
  will conflict and possible damage the chip

2023-01-23:

- Now the MIC5365s are back in stock... I might switch back

- I've mostly been working on the RTL to make a simple usart device that I can get working on the TinyFPGA, which tests the bus
  interface.  It still needs a lot of work, but I think the basic idea has been proven
- I need to work on a debugger RTL that uses the USB device from the bootloader

- I have that working now.  I had the data directions wrong, so I was trying to use data_in to load the usart, but data_in is for
  data to go into the bus, and data_out is for the data coming from the bus that was written by the CPU.  Now it loads 0x30 into the
  usart when the address strobe signal is pulled low.  It's not great, but it at least proves the bus works and all that logic of
  the state machine for the bus is actually synthesized into the design instead of removed for being unused.  It's using 83 LCs out
  of what will be 1280 for the 1K.  That seems a bit tight, but until I can solder BGA, it's my only option

- welp, the bootloader takes 1440 LCs, so it probably won't fit in the 1K =(

2023-01-26:

- I searched around a bit and found that Newark had 44 of the HX4Ks in stock, one of the few trustworthy places with them available,
  so I ordered 5 of them which arrived today.  I can redesign things for the new chip, which will have enough room for the
  bootloader.  It also has 10 extra I/Os, no idea what I'll use them for

2023-01-30:

- haven't updated in a while.  I've been slow at this project lately, but I started the PCB layout and have mostly dragged my feet
  at writing the bus debugger rtl

2023-02-10:

- I've been kind of putting things off and mulling things over this past week, about reassigning the I/Os and orienting the FPGA.
  I was thinking that maybe I should use the differential I/O inputs on bank 3 for the various I/O things, which would have required
  orienting the chip upside down, but after thinking about it more, I'm probably not going to use them for anything anyways, and if
  I was going to, it might be through the logic analyzer type idea, so having the databus pins on that bank kind of makes sense,
  since those pins are most likely to be used for logic analyzer pins.
- so I've reassigned the pins such that the databus is entirely on bank 3, and the signals are on bank 0, and the chip will be -45
  degrees from level because why not, it looks cool, and maybe gives some more room for connecting the address and data pins
  together.
- now I'm kind of unblocked on the PCB design, and I've started hooking things up to the FPGA.  I'll finalize the locations of
  everything else after that's done and I know how much space I need

2023-02-24:

- getting close to the end of the board design.  Will order parts soonish

2023-03-04:

- sent the boards off to JLC, had to pay twice the price to get yellow ones, which sucks that it cost more.  It's one of the best
  colours

2023-03-20:

- yesterday I started building a board.  I tried to film soldering the chips on, but I managed to mess up every single one of the 8
  48-TSSOP chips, mostly putting too much solder on and having to use solder wick to fix it.  I also got 3 chips kind of crooked
  so I think I'll take them off with hot air and resolder them.  A bunch need a couple pins resoldered as well.  I won't bother
  posting the videos

- I still don't know how I'll boot this thing.  I think I'll put the flash chip and header on before the FPGA and program it first,
  but I'll need a way to program it.  I figured I'd just write an arduino program to do it, but I just haven't bothered to write it
  yet, nor to get a bootloader compiled with the right pin assignments

2023-04-02:

- I was finally able to get the flash chip programmed using an AdaFruit QT Py (because I needed a 3.3V arduino and that was the
  closer thing I had with spi-flash-programmer on github, although I had to change the frequency in the arduino program because the
  default was CPU frequency divided by 2 which was clearly too fast for the duport wires I was using to hook it up to the header.
  It would fail to write because it would read back data that didn't match what was sent, even though it didn't specifically say
  that in the error messages with verbose debug on.  Changing to 8Mhz worked fine.

- the footprint for the 3.6468MHz oscillator was too big but it actually really helped with soldering.  The 16MHz osc footprint just
  fit but it was really hard to solder because it was so small to begin with.  Bigger is easier to solder, and using a larger
  footprint really helps so long as it can still fit.

- well, I got the rest of the board built now.  I tested it after each major addition to isolate what the issue might be.
- when I put the 16MHz clock chip on, it seemed to require an amp or two of power to start, and was uing hundreds of milliamps when
  running steady, so something was wrong.  I pulled out the hot air rework station and took the chip off, and the problem went away,
  so it was something with the clock chip.  I put the 3.6864MHz clock on because it was easier to solder and that worked but drew a
  fair amount of current a few times (150+ mA when normally it was 30mA) and I heard a bit of boiling so it might have been the flux
  that was conducting a bit
- I put the same 16MHz chip back on and boiled some of the flux off and it worked enough that I figured once it was cleaned it would
  be fine, but the chip took a lot of heat and rework and has some solder on the metal can.  It doesn't test out the best, with the
  clock single not being entirely stable, but if I really dig the probe in, it seems to work, but I'm still a bit suspicious of it

- I got the FPGA on and it went much easier than the transceivers.  The extra caps don't seem to increase the inrush by much either,
  which is nice.  I had already installed the LEDs and the programmed the flash, so when I turned it on with the FPGA, the first LED
  started slow blinking!  I didn't expect it to do anything, but that absolutely can't happen without an FPGA configuration at least
  partially working, so that's a really good sign

- I assembled the rest of the board, including all the headers.  I forgot the jumpers for the USB and bus, so when I went to plug it
  into the computer after checking it on the bench supply, it didn't work because the jumper to connect power was missing
- It shows up as /dev/ttyACM2, and is clearly enumerating with the OS, but it doesn't seem to work.  Nothing works connecting to it,
  which is odd.  I'm using the tinyfpgab python program to connect to it, and it doesn't detect the bootloader running

- The first time I tested the TinyFPGA's osc, I got 32MHz, but after going down that path a bit, the schematics do indeed say 16MHz
  as does the tinyfpga website, and checking it again, it is indeed 16MHz.  I used a shorted ground lead, for the probe, and
  rechecked Fidget again, and it's pretty stable at 15.9999MHz, which isn't perfect, but I'm hoping that's not significant, so maybe
  it's something else going on...

- I checked tinyfpga by plugging it into the computer, looking at dmesg, and connecting to the serial device it creates.  Apart from
  the vendor:device id being different (which I set on the command line when using the python programmer), it looks the same in
  dmesg, and when you connect, it does nothing and doesn't respond.  The readme describes the protocol and the binary opcodes used.
  The \0 opcode makes the fpga boot into the other configuration in flash, so I sent that with `echo \0 > /dev/ttyACM2` and it
  disconnected from serial in the other terminal window, and the LED stopped flashing, so it boot!
- I tried that same thing with fidget and it does exactly the same thing, so the bootloader is there, it's running (even though the
  LED seems to be blinking 1/2 or 1/3 as often as the BX board), and it responds to serial commands correctly, so the serial is
  working, at least for small commands.  I have no idea why the python programmer isn't recognizing it

- after playing around a bunch more and writing a python program to dump serial, it seems like the bootloader is working fine, but
  the meta data hasn't been written to the device.  I wrote the two bootloader .bin files that the makefile produced, but there was
  actually another one fw.bin that has some bytes at the beginning, and possibly some more data elsewhere in the image.  The other
  boards have a very different Makefile which creates a json file as metadata.  Either way I need to reflash the memory, or somehow
  hack the tinyprog program to work
- when trying to write to the onboard spi flash, it won't work.  I get 0s for everything.  I know it worked before I put the FPGA
  chip on, so I suspect that's doing it, and holding down reset is not working either.  Perhaps the power requirements are more than
  the onboard regulator on the QT Py can supply, and that's causing problem.  I just don't know...

- checking the TinyFPGA again and printing out the meta data when it gets to the point where it returns None when fidget is
  connected, and it returns a json string, and it's the read_security_page that returns data.  The 3 pages it reads are different
  data too, so I'm not sure if that's supposed to be multiple images.  Either way, the security page is a specific feature of the
  SPI flash chip, and has custom commands to program it.  So the normal flash writer might not help


2023-04-04:

- I haven't been able to get the security page programmed to store the meta data.  It says it programs it all fine, it gets good
  response, but when it's read back at the start of the program, it reads all \xFFs and then can't find metadata and dies.
- I hacked around it by setting the metadata in the program and it works, and I can upload a program, but it doesn't seem to run
- the bootloader is definitely working to some extent, so I know the pin assignments and compile environment is right, and I just
  tested the blinking light demo on the tinyfpga so I know the code is working, but I can't get a user configuration to work.  The
  light that the bootloader blinks goes off when it should stay lit all the time, and flipping the assignment in the code doesn't
  change it.  The other 3 leds which are supposed to be used, but are semi-light when in the bootloader because of the internal
  pullups in the FPGA, they remain semi-light

- on the SPI programmer front, I looked at the signals when the FPGA is on and it's always driving the SPI clock, CS and output
  lines, but during reset they have weak pullups and can easily be pulled to ground, so I tried programming it with the QT Py again,
  while holding reset, but the debug messages would say it wasn't getting a response.
- The HELLO issue from before was because the arduino software seems to misbehave if the write fails (continuously sending signals
  and not responding to the python program), and resetting the arduino fixes that
- I'm pretty sure I have the in and out signals correct.  I'm stumped at the moment.  SPI flash should work like it did before, and
  the user program in flash should run correctly.  It's possible that the FPGA thinks it programs the flash correctly, but doesn't.
  It's possible that some wire or other thing is broken in the QT Py setup.  It's possible the bootloader uses the wrong information
  internally (I don't really know what it does).

2023-04-07:

- last night and today I've been trying to trace what's going wrong.  I had the oscilloscope out and was looking at the SPI signals
  to see if I could get a new image loaded, but didn't have much luck, so I broke out my new(ish) clone salae 16 input logic
  analyzer and that clearly showed one serial line had no data and the other had a bunch.
- I was connected to the arduino end of the signals, so I can be pretty sure the device transmitting is the arduino.  I suspected
  that the signals might be backwards and was able to confirm that.  The MISO (POCI) was plugged into the SDO signal, but it should
  have been SDI, so I swapped them around and it still didn't work, but it seemed more right than wrong.
- the orange wire I was using for the CS signal wasn't attaching all the securely to the QT PY pin, so I changed it for another one
  and suddenly it starting writing!  I had to keep the reset held down because I wasn't expecting it to work, and I had changed to
  the SPI speed to 1MHz for debugging, which meant it took a long time, but sure enough, it worked

- ok, now I can write data to the SPI flash, while holding reset, and it's definitely affecting things because sometimes the
  bootloader will be running, with the slow blinking light, and other times it wouldn't work.  Trying all sorts of combinations
  wouldn't make the blinking led program I made work.  I even tried putting it in place of the bootloader with the vector table
  intact and it wouldn't do anything
- I learned more about the boot sequence and warm boot modes, but the documentation isn't very detailed about the vector table at
  the start of memory.  There's a table from 0x00-0xA0 which has 5 x 16 byte vectors that include an address in flash where the
  configuration for that option is stored.  The first one is the default cold boot vector and the next 4 are the warm boot vectors.
  The tinyfpga bootloader only uses the second vector for user programs the others point to the bootloader that starts at 0xA0.
  This info wasn't in the Lattice docs, but in a blog post here: https://umarcor.github.io/warmboot/

- the issue was so simple.  I had the wrong FPGA selected when compiling the config, so it was only ~31 KiB, even though it should
  have been ~131 KiB like the bootloader images.  I should have noticed that one sooner.  It works perfectly now.  I can load the
  image over USB using the bootloader, and then boot into the image.
- The only thing still not working is the metadata and writing it to the security page, but I have a workaround by modifying the
  python to use a hardcoded json string if no other meta data is found

- I added an option to the bootloader to boot into the user config if you press the user 1 button (I think it's 1 and not 2), so I
  can boot it without connecting it to USB.  That might be handy when I'm testing it on VBUS power and don't want to connect the USB

2023-04-14:

- I just realized the 5V/3.3V jumpers for all the I/Os are useless because the FPGA's I/Os aren't 5V tolerant.  They should only
  ever be run at 3.3V.  Well, I still need the jumper to disable power supplied from the serial port usb convertor, and I'm not
  positive if the 3.3V serial port adapters still supply 5V on that pin.  They are kind of more for backfeeding than anything else.
  I probably should have left them off the SPI and I2C headers though

2023-07-05:

- I've finally gotten around to writing some verilog.  I wrote a serial port transmitter and receiver, which I've tested in
  isolation and with an echo/loopback.  I've also written an attempt at a bus snooper
- initially trying out the bus snooper, it seemed fine at first, but I didn't have the bus powered.  When I put the jumper on to
  power it, it drew a whole bunch of current.  Turned out the addr_oe and data_oe outputs were not initialized correctly (not set
  in all modes of the state machine), so adding that prevented the short that was happened
- I tried connecting it to the k30 board, and the computer's serial port kept spitting out the letter `D`.  It took me a while to
  realize it was the computer and not a serial setting or something.  After thinking about it a bit, I realized it's probably
  interferring with the computer's bus requests, and that's probably because I just set up the transceivers as if it was a receiver.
  This turns out to be a design problem...
- It's one thing to set the alt_ctrl_dir to inputs, so that the bus arbitration and interrupt pins are inputs to the FPGA, but I
  made the DSACK and BERR pins always be the opposite of the bus control signals using a single logic gate to invert the
  send/receive signal!  That is quite wrong.  I need to be able to make the DSACK and BERR signals be inputs unless I'm acutally
  going to output them, or else they would interfere with other devices on the same bus.  There isn't only one receiver...
  I had the extra signals too.  I could have wired up that extra transceiver control to its own I/O but I was trying to save an I/O.
  I can maybe cut the trace and wire in place of the invertor gate, but it'll be messy.  I'll definitely need to fix this for the
  next iteration

2023-07-16:

- I'm getting closer.  The transmitter is using a state machine and has 3 fifos for starting and signaling the completion of the
  transfer.  I modified it to sequentially print ascii directly in the state machine loop, and had no glitches, and then modified
  the comm_clock'd process to, instead of controlling valid/ready, increment the data and start a transfer back to back using the
  fifos, and I'm also not getting glitches, so the problem with echoing at speed is either the receiver or the glue in the echo
  module.  But it's affecting the snooper too, which is only using the transmitter, so it could still be an issue with the actual
  interface, or the the glue between the bus output and transmitter...

2023-07-29:

- I made an asynchronous FIFO and finally got it hooked up, and it didn't work.  It was putting out all zeros instead of data, and
  even then it was fewer characters than it should have been transmitting, and transmitting 2 chars for each single char, which is
  what it was doing before I swapped the fifo in, minus the zeros.
- changing to the non-block ram dual_port_memory module fixed the zeros, so it's still doing the other two things, but it is
  actually echoing characters.  There must be something wrong with the block ram, which I haven't otherwise tested before.  I might
  have timings off, which would make a lot of sense given it's untested =P
- but there's also something wrong probably in the handoffs that is still dropping characters, and also duplicating characters

- I made a setup that just fed the input side of the fifo with incrementing characters to verify that the fifo was working, and it
  wasn't.  It was producing a lot of missing charaters
- I had a bug or two in the character generation code such that when it was blocking, it was incrementing to the next character and
  skipping over a bunch, which could be seen on the testbench, but it still wasn't working
- I tried limiting the chars printed to the buffer size to test if it was an issue with it looping around, because the test showed
  it only counting about half as many as expected, and there was also some red xx data at some points
- after hunting around a bunch, I found that the dual port ram was using the log of the depth instead of the depth to initialize the
  buffer, so there wasn't memory there...
- It seems to work now

- There's still one more issue, where it will print a double character on the first character, instead of just one

2023-07-30:

- the dual port ram tile wasn't working because the output was reg and initialized to 0, when it should have been a wire.  There was
  also an issues where read/write mode 1 wouldn't work (characters, but the incorrect ones).  It was as if it was only 4-bits wide,
  but mode 1 should correspond to 8-bits wide and 2 should be 4 bits.  Either way, changing it to 0 worked.
- the glitching that happens also corresponds to the buffer size.  With a 128 byte buffer, it can replay a long string.  With a 16
  byte buffer it glitches at or around the 16th byte.  The only way to prevent that would be to apply backpressure to the serial
  port ala RTS/CTS signals, so I guess that would be the next thing to get working