Porting LiteX to the Crosslink-NX eval board

[davidcorrigan714]

I've just started working on getting LiteX working on the Crosslink-NX evaluation board, basically copying the Versa ECP5 target, stripping out the Trellis stuff, adapting it for Radiant, and working on some of the device specific details that need to be figured out (like the PLL block configuration). Figured I'd start a thread here on it in case anyone else has played with this, or has some pointers on the process.

[daveshah1]

Haven't used it much, but I have a CrossLink NX eval board too if you need any help testing stuff

[enjoy-digital]

@davidcorrigan714: same as @daveshah1, i have the board but haven't used it yet, also happy to help.

The first thing will probably be to create a build backend for Radiant and test it on very simple designs: Leds/Buttons/GPIOs (by using https://github.com/enjoy-digital/litex/blob/master/litex/build/lattice/diamond.py as a basis), then use a CPU running with the input clock (to avoid the PLL) and then add support for the specific primitives (PLL, IOs, etc...) and start creating more complex designs.

[davidcorrigan714]

Getting the LEDs blinking is my first objective. I got it working with Radiant just fine, really just needed some tweaks to the scripting commands. Seemed like the commands were generated by two different files but only one took affect when actually building, I'll have to find those again later and then maybe you all know if ones deprecated or used for another method of building.

Good thought skipping the PLL, the documentation on that primitive is severely lacking so it'll be a bit tedious figuring out what the Radiant generator does with various parameters.

On the eval board I had issues with the flash, basically I had to slow down the programming clock in the programmer GUI otherwise the data coming back from the flash to the FTDI seemed to have some timing issues. I didn't narrow down exactly what timing spec it might be violating but slowing it down definitely fixed the issue. Unfortunately by the time I figured that out I had accidentally programmed the eFuses in the feature row to skip booting from flash, guess my board will always have to be loaded manually which is fine for testing and development.

[alanvgreen]

@davidcorrigan714 I'm also planning to start working on this. My eval board just arrived, and I haven't yet had time to plug it in. If you could share a branch, I'd find that helpful - maybe we could collaborate?

Thanks for the tip on flash/FTDI issues

[davidcorrigan714]

@alanvgreen sure thing, I'll get a repo up this evening (ie 6ish hours from now). The other thing is to get the correct version of Radiant. They disabled bitstream generation for the chip in the latest release, so you want 2.0.1 ie 2.0 then install SP1.

[davidcorrigan714]

Uploaded here and here. Everything in there is a WIP but the structure is starting to get there.

[alanvgreen]

@davidcorrigan714 Wow! You've made a huge amount of progress.

I wanted to double check we have the same hardware: I am using the very generically named CrossLink-NX Evaluation Board from Lattice.

[davidcorrigan714]

That's the board, it could really use a proper name. Wasn't quite sure what the target file should be called in this case since it's basically the name of the chip. I also used LIFCL in a few places instead of putting CrossLink NX or some variation, should make that more consistent at some point.

I basically started with the versa_ecp5 target then copied all the diamond & ecp5 code and started combing through it. The structure of the IceBreaker target looked much more minimal so I started rearranging the target file more like it then will try and fill in the more advanced stuff like the PLL and a proper CRG once we get some LEDs blinking. Most things really seem to be close between the ECP5 and Crosslink-NX but they cleaned up the names of primitives and the tcl script commands quite a bit but if something looks wrong it probably is. Seems like Lattice has the big FPGA library reference PDFs with all the primitives for their other platforms, but the only reference I found for Crosslink-NX is in Radiant. There's a tab at the bottom under the file tree, I'm blanking on what it's actually called but it just shows very non-descript templates for all the various primitives.

For my application I'll need ethernet too, so at some point I'll be making a board for the FMC connector with ethernet and some other application specific logic.

[daveshah1]

The Radiant webhelp folder has detailed primitive documentation within it, similar to the old reference guides.

[davidcorrigan714]

Well I got an LED chase pattern going on the board. There's a few manual steps I need to clean up in the code, and I'm using an external oscillator at the moment. Not sure why yet but it's not letting me use the onboard one on pins C11/C12.

[enjoy-digital]

Great!

[alanvgreen]

@davidcorrigan714

I have a SoC building verilog and calling the tooling. The synthesis step is failing due to "Port CLOCK does not exist", which I am guessing is due to needing a .pdc file to constrain pins to ports. Sent a couple of pull requests your way with all the code needed to get to that point.

Unless you have a better idea, I'll work on generating the pdc file next.

Is there an IRC channel or other forum where we can coordinate? Otherwise feel free to use gchat - avg@google.com.

[enjoy-digital]

@alanvgreen: feel free to also discuss this in #litex channel atfreenode.net.

[davidcorrigan714]

@alanvgreen glanced at those commits. I've been developing against the "crosslink-nx" branch in my repos which you may not have seen so it looks like we both did the RAM, but we actually did it using two different primitives so we'll just need to figure out naming since they're probably both useful depending on the application. I'll work on bringing everything into master, think that works out fine for eventually doing a pull request back to the official repos.

I worked on the pdc files last night, looks like I may have forgot to push it though so I'll do that in the next few hours. There's some notes in my work and some # TODO . Should be: -fix ldc/pdc python naming that I mangled -finish adding it to the tcl script, I had a relative path and it needs the full path -bare IOBUF, wasn't quite sure how to translate it and wanted to find an example that actually hit it to test with

I'm currently using a 16 Mhz clock on one of the PMOD connectors to drive it.

IRC or g-chat is fine with me. My g-chat is davidcorrigan714@gmail.com . I'm mostly working on this between 9 - 11 US Central time and can hop on IRC too. Feel like once the bare bones are working it'll be easier to setup issues around things to grab where as right now I'm really just scanning for mistakes and things that need to get done.

[tcal-x]

Hi all, I'm having a hard time finding a link for Radiant 2.0/2.0.1 download. The main page is all 2.1, and the Version History page doesn't seem to have any links. Thanks for any tips! -- TimC

Update: found it! https://www.latticesemi.com/Support/SoftwareArchive

[davidcorrigan714]

Go to this page, scroll down and click "Downloadable Software" then find Radiant 2.0 and 2.0.1

[davidcorrigan714]

@alanvgreen Got some data out of the UART now and it looks like the welcome message. The LA on my scope is nifty but a bit cumbersome so I'm only checked the first few bytes on it. It's running a bit slow at the moment at around ~106kbps.

[alanvgreen]

@davidcorrigan714 That's awesome. Checking out your changes now.

[alanvgreen]

Woot. With your fixes, I also see data coming out the UART now too. I measure the uart baud rate at 114.1kHz, which is fine. I'm using the 12MHz clock.

I see the "sL5DdMmkekro" string that is supposed to trigger firmdownload download in litex-term. However, most output is nonsense characters, each being repeated 4 times. "9999mmmmeeee0000" is being output when I press enter. 9, m, e and 0 are every 4th character of the prompt string defined in bios/readline.h

#define PROMPT "\e[92;1mlitex\e[0m> "

The download trigger is output with uart_write(), while other output uses printf().

[davidcorrigan714]

Did some board surgery to get the FTDI hooked up on mine, I'm seeing the garbled text too. What's interesting is that it's consistent from run to run and not completely random, so it's not just noise. On mine there's some timing errors that I'm ignoring so it may be time to dive into those, also looking at the selective write feature on the RAM that isn't implemented. That latter issue is probably an easy fix so I'll knock it out pretty quick and see if it helps.

[davidcorrigan714]

Got the garbled UART fixed.

[alanvgreen]

Awesome!

Things left to do:

• Automate programming - Lattice programmer or OpenOCD
• Deal with timing error on synplify or use LSE instead
• Get BRAM inference working
• Decide on where to put the BIOS - execute in place from flash, or in onboard ROM

I think the BIOS should probably go in onboard ROM. There's plenty of room on the NX/40. I only put it in flash because that's how the iCE40 did it. Any opinions?

I was planning to work on the programmer next, try to cut out the need to fire up the Lattice programmer GUI.

[davidcorrigan714]

There's a few other miscellaneous clean-up to do in the Radiant code but it should be pretty close. I've been looking at how to set the feature row bits, mostly to keep the SPI Flash accessible over JTAG.

I haven't played with OpenOCD yet, but it seems a reasonable approach to automate. The Lattice programmer is a tad clunky.

Timing errors are solved on my builds, seems like it's a bit picky on how you define the clock constraints, and using the cs pin seemed to help the RAM timing which I believe was giving me errors earlier.

It's inferring EBR for something already, processor cache maybe?

ROM is probably best. The bit files for the FPGA can technically fill the flash I think, might as well let Radiant include it and not have to figure out exactly what offset might be safe.

[alanvgreen]

@davidcorrigan714 I pulled your updates and everything started to work. It's inferring RAM and ROM using synplify.

I have been able to download and run a simple C program using serialboot.

I'll look at the PLL next.

[enjoy-digital]

Great work @davidcorrigan714 and @alanvgreen! That's nice to see you've been able to collaborate on this and get it working. If you want to create a first PR with the initial work (Build backend, and initial Platform/Target for the Crosslink Eval board), i'll be happy to test it on hardware and review/merge it.

[davidcorrigan714]

@enjoy-digital @alanvgreen Just put up PRs for both repos with a few comments. Looks like I forgot one or two changes I wanted to make but there's plenty for people to start reviewing, or even testing.

[gregdavill]

I'm happy to update ecpprog with any changes needed to support the NX.

Last time I tried it on my eval board here it just worked out of the box, but I haven't really put it through it's paces. Some changes might be required.

[davidcorrigan714]

@gregdavill Are you referring to how the ecp5 is done with OpenOCD? I tried that route but the problem was getting an svf file. Lattice didn't include programming functionality in Radiant so I didn't see a way to drive Radiant, or the standalone programmer application to generate that file from the command line.

[gregdavill]

No, it's not using OpenOCD. ecpprog is a small utility that can program bitstreams to the ECP5 over an FTDI JTAG connection, the same that's found on the eval-board.

The JTAG commands for loading a bitstream on the NX series is the same as the ECP5, so it should work out of the box. https://github.com/gregdavill/ecpprog

[tcal-x]

Hi Greg, I tried ecpprog with my Crosslink-NX Eval board, and I see this:

$ ecpprog -t
init..
IDCODE: 0x010f1043 does not match :(
ECP5 Status Register: 0x00000110
flash ID: 0x00 0x00 0x00 0x00
Bye.

In case it's relevant, this is the output to lsusb:

$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 06cb:00bd Synaptics, Inc. 
Bus 001 Device 003: ID 04f2:b67c Chicony Electronics Co., Ltd Integrated Camera
Bus 001 Device 008: ID 18d1:5026 Google Inc. Lattice CrossLink-NX Eval Board
Bus 001 Device 004: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 017: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC
Bus 001 Device 007: ID 8087:0aaa Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[davidcorrigan714]

@tcal-x The ID thing doesn't surprise me. The ID for CrossLink-NX is 0x010f1043 .

@enjoy-digital Didn't realize that git on my home machine was still using an old username & email. Probably doesn't really matter but the copyright info would be better as "David Corrigan davidcorrigan714@gmail.com".

[davidcorrigan714]

@tcal-x Looks like I spoke too soon, and probably need to fix this elsewhere. There's a few IDs it could be based on their sysCONFIG Usage Guide for the Nexus Platform. The relevant ones for the dev board being the LIFCL-40-ES and LIFCL-40. Mine happens to be an ES but I'd assume they're shipping the production version of that chip on later runs of the evaluation board.

CrossLink-NX: LIFCL-17: 0x010F0043 LIFCL-40-ES: 0x010F1043 LIFCL-40: 0x110F1043 Certus-NX: LFD2NX-17: 0x310F0043 LFD2NX-40: 0x310F1043

[enjoy-digital]

@davidcorrigan714: i just updated your username & email with: https://github.com/enjoy-digital/litex/commit/3897acb9e4b91ad58abbcea8e3cff6e44223bd02 and https://github.com/litex-hub/litex-boards/commit/63b65e278c279a9cf8c4da31db8f7e845edba394.

[tcal-x]

I have the ES as well. After adding the device and ID, I tried programming, but the verify step fails:

$ ecpprog ./slow.bit 
init..
IDCODE: 0x010f1043 (LICCF-40)
ECP5 Status Register: 0x00000000
reset..
flash ID: 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x0C 0xE1 0x10 0x18
file size: 1016029
erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
erase 64kB sector at 0x020000..
erase 64kB sector at 0x030000..
erase 64kB sector at 0x040000..
erase 64kB sector at 0x050000..
erase 64kB sector at 0x060000..
erase 64kB sector at 0x070000..
erase 64kB sector at 0x080000..
erase 64kB sector at 0x090000..
erase 64kB sector at 0x0A0000..
erase 64kB sector at 0x0B0000..
erase 64kB sector at 0x0C0000..
erase 64kB sector at 0x0D0000..
erase 64kB sector at 0x0E0000..
erase 64kB sector at 0x0F0000..
programming..  1016029/1016029
verify..       4096/1016029Found difference between flash and file!
ABORT.

...but, it seems to work --- after power cycling the board, I see the behavior of the new bitstream.

[davidcorrigan714]

Interesting that it failed at 4096. For going to the flash you may just need to slow down the programming bus speed. On my evaluation board using the official programmer it always failed at full speed but worked flawlessly at anything slower. I plan to check out ecpprog too this evening too and see what it does on mine.

[gregdavill]

@tcal-x If you run ecpprog -S ./slow.bit does that give any errors? the -S option skips the background FLASH programming, and just loads the design directly into the FPGA's configuration SRAM.

I have an eval board here that I can experiment with, I'll try it out tonight.

[tcal-x]

@tcal-x If you run ecpprog -S ./slow.bit does that give any errors? the -S option skips the background FLASH programming, and just loads the design directly into the FPGA's configuration SRAM.

I have an eval board here that I can experiment with, I'll try it out tonight.

Oh! That works, and much quicker than either ecpprog flashing or with the Radiant programmer. Just under 5 seconds.

[enjoy-digital]

I think we can now close this since initial support has been merged and results reproduced by various users. Thanks all for the NX support and Crosslink-NX eval/vip port!

[davidcorrigan714]

Sounds good, glad people are trying it out. I've been working on getting the PLL code ready. Looks like the tooling generates strange latency constraints for PLL generated clocks and I haven't got an answer from Lattice on why, but even their reference designs seem to be working around the issue so it's not something unique to my code but the workaround is a tad annoying.

[slagernate]

Working with an ES2 device on a fairly recent crosslinkNX eval board and having trouble getting anything to respond: https://github.com/enjoy-digital/litex/issues/1441

Can't even get a wishbone bus to respond on an icebreaker (possible related): https://github.com/icebreaker-fpga/icebreaker-litex-examples/issues/11