I am getting closer to being able to communicate with the QSPI flash, so that we can have the MEGA65 update its own bitstreams in the field. To recap the current situation:
1. Most of the signals
to the flash are easy to connect to with the QSPI flash, except the
clock, which is normally driven by the FPGA's configuration logic.
2. The FPGA has a facility, the STARTUPE2 component, that allows the running bitstream to take control of this signal.
3. I have managed to achieve (2) in a test bitstream, as confirmed by my new JTAG boundary scan setup.
4. But I haven't got it working for a real bitstream.
To get to this point, from the last blog post, I discovered that the STARTUPE2 component *must* be in the top level of a design.
The question is now why in the real bitstream, it still isn't working, even though I have moved it to the top level.
it works in the pixeltext test target, that lacks a M65 computer, but
not in the nexys4ddr-widget target. More weird, when I removed the M65
computer component out of this second target, it still isn't working.
makes me suspect that there might be some kind of target setup in the
Vivado project that is to blame. There is a "persist" flag that can be
used, which causes the configuration clock to remain active on the QSPI
clock pin. That could be the problem -- but then I would still be
expecting to see the line waggle, which it doesn't seem to.
digging further, I did managed to control the line with the M65
computer component taken out of the real bitstream. Now trying to put
it back in, but with a dedicated 1Hz clock on the pin, so that I can
eliminate internal problems in the plumbing of the line to the register I
had it hooked up to. Basically I can keep pushing the connection
deeper down into the design, until it is in the component where I was
Ok, so with the full machine core, and
the 1Hz clock in the outer layer, I can control the clock line. Next
step is from in the sdcardio.vhdl file where it gets connected to, to
see if I can toggle it there under automatic control. If that works,
then I must have some subtle bug in the register plumbing. If not, then
the plumbing problem must be between sdcardio.vhdl and the outer layer
of the design. Either way, I will be able to considerably narrow down
where the problem can be hiding.
So, the clock toggles, meaning the problem is probably in sdcardio.vhdl somewhere...
So, this is one of those funny bug fixes that I really hate. It could
well be that I have done something really stupid, but if so, I am
ignorant to what it is. But the solution was to create a 2nd register
to control the QSPI clock at $D6CD. With that implemented, magically
$D6CC works to control the clock. I've had this kind of problem before
with VHDL, where possibly something is incorrectly optimising out the
ability to write to some signal. Anyway, it is solved for now.
I started trying to investigate things, and came to the rapid
conclusion that my life would be so much nicer, if I could make my new
JTAG boundary scanner produce industry-standard VCD files that I could
view in gtkwave, to get a more effective understanding of what is going
on. So I did. It wasn't too hard, and now I can produce pretty pictures
Digging through this, I
fixed the initial problem, but also found I had the SO and SI lines
switched around from the way they should be, so that will need a
resynthesis... Well, then I wasn't so sure, so I made it so that the
four data lines are open-collector with internal pull-ups in the FPGA.
This means that the lines can be either driven low, or float high. This
means I can fiddle with which line is which etc, without having to
resynthesise each time.
However, I am seeing some quite weird things with the data lines when I look at the JTAG traces:
look first at FPGA control of the pins as a potential cause. As the
other pins don't exhibit this strange behaviour, and the four DB pins
are all controlled in an identical manner, I find it hard to believe
that the problem is there. That leaves the QSPI flash as the current
First stop: Check the schematics.
Nothing sinister here on the Nexys4DDR boards: the QSPI flash is
directly connected to the FPGA, with only some external pull-up
resistors, which can't cause this funny problem I am seeing.
So that suggests it is most likely just the way that I am communicating with the QSPI flash.
around, it seems that DB0 only changes (or is only changeable) when CS
is high. This makes sense, as when CS is high, the QSPI flash is not
active, and so shouldn't be trying to drive any lines. When it is low,
then DB1 stays tied low. This makes me 99% sure that DB1 is the line
from the QSPI to the FPGA, and DB0 is the command line from the FPGA to
This means, in theory at least, that I should be
able to talk to the QSPI flash, if I drive the correct waveform.
However, so far at least, there are no signs of active response from the
QSPI flash. And looking at the trace, here we see this weird problem
again: The DB0 signal stays low for one clock tick longer than it is
being pulled low:
delay occurs whether the QSPI flash is selected via the CS line, or
not. This would seem to suggest that it is not the QSPI flash to blame
-- unless it is in some strange mode following the FPGA configuration
Ok, looking again that the schematic, there
are indeed 1.8K pull-ups on the DB2 and DB3 lines, but not on DB0 or
DB1. This means that it is possible that running these lines
open-collector might not be practicable. So I resynthesised with the
ability to push those lines actively high, as well as pull them low, or
tri-state them, as before. Now by actively pushing them, they respond
immediately, as expected. So now I can send a byte via the SPI
interface, and it all looks right:
course, it still isn't working. But that could be because I just
realised I am sending the bits least-significant-bit first, instead of
most-significant-bit first. And indeed, that suddenly gets it responding
course I could have just figured out how to do it from in Vivado, but
its so much nicer to have a little light-weight and open-source tool.
Also, by having it integrated in monitor_load, I can do multiple things
all in one quick action. Here is now I run the test program, and then
ask monitor_load to sample those pins -- all in one single command:
src/tests/qspitest.prg && src/tools/monitor_load -F -4 -r
src/tests/qspitest.prg -V log.vcd -J
so its a bit of a long command, but that's what pressing the up arrow
in a shell is all about, so you can just use it again and again, without
having to re-type it.
When that command has logged
the pins for long enough, I just hit control-C, and then launch gtkwave
on the resulting log.vcd file, with a little tiny script that tells it
to automatically show all signals:
gtkwave -S allsigs.tcl log.vcd
So the whole work-flow is now super easy and efficient.
anyway, back to figuring out why the test program doesn't read the data
from the SPI response correctly... It's currently reading all ones,
i.e., not noticing when the DB1 line goes low. Adding a short delay
fixes this. Not entirely sure why. But with that, I can finally read
some useful things out of the chip, and display them:
QSPI FLASH MANUFACTURER = $01
QSPI DEVICE ID = $2018
RDID BYTE COUNT = 77
SECTOR ARCHITECTURE IS 4KB PARAMETER SEC
TORS WITH 64KB SECTORS.
PART FAMILY IS 8000
256/512 BYTE PROGRAM TYPICAL TIME IS 2^8
ERASE TYPICAL TIME IS 2^8 MILLISECONDS.
01 80 30 30 80 FF FF FF
FF FF FF FF 51 52 59 02
00 40 00 53 46 51 00 27
36 00 00 06 08 08 0F 02
02 03 03 18 02 01 08 00
02 1F 00 10 00 FD 00 00
01 FF FF FF FF FF FF FF
FF FF FF FF 50 52 49 31
confirmed with the data sheet that these data are broadly sensible. So
the next step will be to extract all the relevant data out, e.g., the
information I need to programme the device, and after that, to implement
simple block read, erase and write functions... Which turned out to be
remarkably painless, if rather boring internally. The more exciting
part will be in the next post, where I (hopefully) actually implement
writing of bitstreams to the QSPI flash.