Archive - March 2016

J68 is now booting from User Flash Memory on the BEMICRO MAX10 FPGA board
Still debugging the attachment of User Flash Memory to the J68….
LCD Test image and pixel-level detail

J68 is now booting from User Flash Memory on the BEMICRO MAX10 FPGA board

I’ve been struggling for quite a few nights and weekends over the last month or so.

I’ve now successfully attached the J68 to the built-in User Flash Memory. This means that the 16KB (actually about ~13KB) of the ROM monitor VUBUG is now out of the pre-initialized m9k’s configured as a ROM, and now into FLASH. Which is non-volatile, and will survive a reboot. The most important part of this is that it frees up our valuable high-speed on-chip m9k’s.

The solution involved waiting for rd_ena (read enable) to go high, and combining that with the address that makes it a ROM READ, and then passing that to the Altera IP Flash avalon-mm bus interface. Since the latency is a fixed-cycle delay, then I just shift that read-enable pulse to become the “data is ready pulse”, aka data_ack and feed that back to the J68.

I had some more complicated solutions including a state machine, but this way is clearly superior. I had created some bolt-on hardware to help troubleshoot the problem. While it helped initially, when I had the problem fixed, some symptoms in the add-on hardware hid the fact that it was actually working….

The SDRAM controller works in simulation when connected to the J68, and hopefully will be tested on hardware very soon. This puts the ROM code in FLASH, and the RAM on the 8MB memory chip where it belongs. This will give us what we need for future development, including the GPU!

Still debugging the attachment of User Flash Memory to the J68….

So if I take my working UFM avalon-mm Master controller (which if you recall, connects to the Altera Flash Memory IP core), and attempt to attach it to the J68, the J68 no longer boots the ROM monitor code.

Since it’s not booting, I really don’t have many indications as to why. I decided that writing a ROM bus sniffer that records ROM memory requests and responses, including how long it took to satisfy that request, was worth the trouble.

In the image below, you’ll see four 32-bit columns of data on the left. Each row is a separate request.

They are:

  • A 32-bit counter that increments once a master clock cycle. Right now, I’m just running at 33.333mhz, but this J68 works upwards to 100mhz. This is recorded at the time of the request — at the time rd_ena goes high.
  • The ROM memory address being requested (first column on the left in BLUE)
  • The 32-bit counter at the time data_ack goes high, which means the request has been handled
  • The actual 16-bit data value. Ignore the 0xFAFA — that’s just padding. (rightmost column in BLUE)


Note that the requests are being handled the next clock cycle, right now, with the M9k’s serving up the ROM file. So you see 0x3A request, 0x3B response. 0x40 request, 0x41 response, and so on. The flash will not be as quick, and there should be something like (5) cycles between them.

My plan is to attach my newly working debugger to the new J68 solution with the UFM, and compare it. I think the problem will be obvious once I see what is happening…..

LCD Test image and pixel-level detail

So I’ve managed to get a semi-working test pattern image up on the LCD.

Here are a couple shots:


If we zoom in about 10 times, we can see how the LCD really works, on an individual pixel level:


Pretty challenging to get a decent image out of this, but here you can see the individual LEDs that make up the TFT screen that we’re using….. Interesting that the roughly-purple color comes from Blue and Red mixed…. except they aren’t mixed, just very close together.


Here’s an idealized image…..looks pretty similar to mine!


I actually don’t think that the colors above in my test image are right….there seem to be documentation problems for the pinouts on the BEMICROMAX10…….