Crosslink NX support

[gregdavill]

There will soon be LiteX support for the Crosslink/Certus NX. enjoy-digital/litex#618

It would be nice to extend ecpprog to support these chips. This shouldn't bee too difficult as the JTAG engine on these parts is quite similar. Additionally the Crosslink-NX Eval board already features an FTDI connection.

Two issues have been identified:

• IDCODEs not present for NX parts
• FLASH verify fails after first sector (4096 bytes)

[tcal-x]

@gregdavill Should I send a PR adding the codes that David listed at enjoy-digital/litex#618 (comment)?

The output that I pasted in enjoy-digital/litex#618 (comment) shows my incorrect code -- I added the code for LICCL-40-ES, but describe it in text as "LICCL-40". I would fix that and add the other codes.

If you'd rather fix everything in this issue in one go, that makes sense too.

[gregdavill]

I have branch where I'm pushing changes to: https://github.com/gregdavill/ecpprog/tree/nx_support

It has some changes but I'm still yet to test with a LiteX bitstream, waiting on a licence file for Radiant.

[tcal-x]

Let me know if I can assist in any way -- I have the NX eval board with LICCL-40-ES, and Radiant 2.0. (I installed Radiant 2.1 first before realizing that it won't generate a bitstream for NX parts.)

I think I just had to make an account with Lattice to get a license -- no fee.

[alanvgreen]

I found the slowing the JTAG/SPI clock allowed ecpprog to verify flash content. It also solve several other weird problems.

[gregdavill]

Interesting, thanks for poking around with that.
I wonder if this is a general issue with the NX parts, or if it's a problem with the Eval board.

[alanvgreen]

It could well be a limitation of the JTAG/SPI bridge on the NX. Maybe on non-ES parts it will be better?

I am now curious about why programming takes ~1 minute per MB.

[daveshah1]

I printed the flash and file data to see what is going on with the verification failure. It seems like there is an off-by-one-bit error; this starts from the first byte and the printing is misleading as to which sector is defective - in the output read data is left and file data is right (this is just random data for test purposes, not a real bitstream):

at 0x000000 d7 != af
at 0x000001 f4 != e9
at 0x000002 2e != 5d
at 0x000003 e5 != ca
at 0x000004 dc != b8
at 0x000005 0c != 19
at 0x000006 0f != 1f
at 0x000007 06 != 0c
at 0x000008 04 != 08
at 0x000009 0e != 1c
at 0x00000a fd != fb
at 0x00000b ed != db
at 0x00000c 0f != 1e
at 0x00000d 1a != 34
at 0x00000e dd != bb
at 0x00000f 17 != 2f
at 0x000010 fe != fc
at 0x000011 0d != 1a
at 0x000012 21 != 43
at 0x000013 f6 != ed
at 0x000014 fc != f9
at 0x000015 e7 != cf
at 0x000016 da != b5
at 0x000017 cb != 97
at 0x000018 21 != 42
at 0x000019 07 != 0e
at 0x00001a fc != f8
at 0x00001b d5 != ab
at 0x00001c 09 != 12
at 0x00001d d2 != a5
at 0x00001e 09 != 12
at 0x00001f 2d != 5b

The logic analyser output (0=tck, 3=tdo) matches the file if you sample on the falling edge:

[daveshah1]

With the following patch to sample using the negedge, programming and verification seems reliable for me:

diff --git a/ecpprog/jtag_tap.c b/ecpprog/jtag_tap.c
index 9aa1608..400c228 100644
--- a/ecpprog/jtag_tap.c
+++ b/ecpprog/jtag_tap.c
@@ -203,7 +203,7 @@ static void jtag_shift_bytes(
 
 
 
-       data[0] = MC_DATA_OUT | MC_DATA_IN | MC_DATA_LSB | MC_DATA_OCN;
+       data[0] = MC_DATA_OUT | MC_DATA_IN | MC_DATA_LSB | MC_DATA_OCN | MC_DATA_ICN;
        data[1] = (byte_count - 1); 
        data[2] = (byte_count - 1) >> 8;        
        memcpy(data + 3, input_data, byte_count);

[gregdavill]

Thanks for looking into this @daveshah1!

This is useful info.

[gregdavill]

I've tried the patch you've suggested It seems to work in conjunction with -k 2 Which I think is a 3MHz SCLK rate.
With no -k value I get the same verification errors.

[gregdavill]

Has anyone been able to get "LSC_REFRESH" working?

With a board powered up on my bench, I can press PROGRAMN, and see it re-configure itself from FLASH. My understanding is that "LSC_REFRESH" is supposed to also do this, but I can't seem to get it work.

I'd like to boot into the bitstream that we just loaded into FLASH, without the requirement of power cycling.

[alanvgreen]

Not sure if this is related: with the LIFCL-40-EVN board, I was not able to get LSC_REFRESH to work. There was another weirdnesses too - the PROGRAMN button put the device into a state where it was waiting (presumably for JTAG) and I had to power cycle the board to get it to read Flash at all.I reported to Lattice and they told me it was a problem with this particular product (though I was unclear whether it was the board or the early silicon).

I have been working around it by programming to flash, and then reprogramming the bitstream in SRAM, at which point the configuration phase completes and the bitstream starts running.

[gregdavill]

Thanks! That sounds similar to what I'm seeing. (I'm also using the LIFCL-40-EVN for these tests).
Usually the PROGRAMN button works for me, but I have been able to put the device into a zombie state before.

It's probably worth implementing the FLASH->SRAM sequence you've mentioned if we detect an NX-ES part.

[alanvgreen]

@tcal-x scripted this for us, but a command line switch to "double program" might be useful for others, especially people new to the board.

fwiw, in my use cases, I have been using ecpprog to program other content to the flash too (mostly risc-v programs). Automatically uploading the same content into SRAM would be unhelpful (!)

[gregdavill]

I've merged the basic NX support that was in the nx_support branch into main, since it appears to mostly be working.

Feel free to open up issues if there are features that aren't working exactly right with NX support.