FPGA programming via open source tools / OpenOCD / SVF


#1

There have been numerous cases described in this forum where people had to re-flash their LimeSDR (USB/mini) using JTAG. The “documented” method is to use some proprietary/non-free tools available only for proprietary/non-free operating systems, which excludes the freedom-loving portion of the user base from performing such programming/flashing.

The Altera/Intel MAX10 series is supported by OpenOCD since early 2017. There are other projects out there which are documenting how to program MAX10 using OpenOCD, see for example https://numato.com/kb/programming-telesto-using-openocd/

It appears that this requires SVF files to be generated, while Lime appears to only publish RBF files at this point. I would therefore kindly request to

  1. Condsider to provide SVF files as part of the standard build procedure of the gateware (important)
  2. Maybe even spend a bit of time to document the programming procedure using FOSS tools such as OpenOCD (less important)

If the SVF files were provided, the community could test it and try to put together some documentation.


#2

Hadn’t appreciated OpenOCD supported MAX10 and agree using this would be preferable!

@Zack, could we start generating SVF files also each time the gateware is updated?


#3

If @Zack or somebody else at Lime could generate a SVF file of the most recent gateware (or, actually, any known-working gateware) for me to test, I’d be happy to test it with a LimeSDR-mini as soon as possible and report back.


#5

Hi @LaF0rge,

Here is SVF file for LimeSDR-Mini 1.1v and LimeSDR-Mini 1.2v. Let me know if this works for you.


#6

Thanks a lot, @Zack! I’m on business travel this week (without JTAG / cables / LimeSDR-mini) but will try over the weekend or early next week for sure.


#7

@Zack, would you mind sharing the same file for the previous LimeSDR USB3 (if applicable)? And/or pushing it to its official repo?

Just want to make sure I have access to an good opensource toolchain when my current Intel Quartus Prime eval period expires :wink:

Thanks in advance!


#8

Hi @brainstorm,

Here is SVF file for LimeSDR-USB board. I will push it to github is you or someone else confirms that it works.

You can use Quartus Prime Lite edition which is free for all LimeSDR family boards.


#9

If it turns out they can be used I would suggest we place them on the downloads server instead of GitHub, alongside the other programming files, so then they are all in one place. E.g.:

http://downloads.myriadrf.org/project/limesuite/18.06/


#10

Uh, first time I hear about that specific location/page, I always resort to GitHub by default… I would assume most people would go there too? :-S


#11

Possibly, but I’m generally not a fan of story binary files in git.


#12

My setup is as follows:

  • LimeSDR-mini hw v1.1 (which we believe to be bricked using LimeUtil --update)
  • OpenOCD 0.10.0
  • Olimex ARM-USB-OCD-H (capable of the low logic voltage)
  • hand-made adapter cable to the 1x7pin THT connector of the LimeSDR-mini

Using the below config file, I can get the MAX10 detected with no problems:

source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
adapter_khz 1000
transport select jtag
jtag newtap 10m16da tap -expected-id 0x031830dd -irlen 10

It detects the MAX10 scan chain nicely:

Info : JTAG tap: 10m16da.tap tap/device found: 0x031830dd (mfg: 0x06e (Altera), part: 0x3183, ver: 0x0)

However, running the following command to actually execute the SVF:

openocd -f ~/limesdr-mini.cfg -c init -c “svf ./LimeSDR-Mini_lms7_trx_HW_1.2.svf” -c shutdown

will run for about 1.32 mins with output like this:

UNTEST 128 TCK;
SDR 32 TDI (EFFFFFFF);
RUNTEST 8000 TCK;
SDR 32 TDI (0000FF21);
RUNTEST 8000 TCK;
SDR 32 TDI (00000022);
RUNTEST 8000 TCK;
SIR 10 TDI (203);
RUNTEST 128 TCK;
SDR 23 TDI (001000);
SIR 10 TDI (205);
RUNTEST 128 TCK;

and then finally fail with

SDR 32 TDI (00000000) TDO (2C100180);
Error: tdo check error at line 194939
Error: READ = 0x20b7ff7b
Error: WANT = 0x0000000
Error: MASK = 0xffffffff
Error: fail to run command at line 195177
Error: tdo check error at line 194939
Error: READ = 0x20b7ff7b
Error: WANT = 0x0000000
Error: MASK = 0xffffffff

Time used: 1m24s950ms
svf file programmed failed


#13

The error is unfortunately reproducable. The exact line numbers vary, but I always get a similar error around the same part of the SVF file

SDR 32 TDI (00000000) TDO (220002A0);
Error: tdo check error at line 195225
Error: READ = 0x0000680
Error: WANT = 0x22d00280
Error: MASK = 0xffffffff
Error: fail to run command at line 195691
Error: tdo check error at line 195225
Error: READ = 0x0000680
Error: WANT = 0x22d00280
Error: MASK = 0xffffffff

Time used: 1m19s799ms
svf file programmed failed

Please note that the SVF file states HW_1.2 even though it’s an 1.1 board.


#14

I’ve now also tried it on a v1.2 LimeSDR-mini, unfortunately with the same result:

SDR 32 TDI (00000000) TDO (2C100180);
Error: tdo check error at line 194950
Error: READ = 0xf8b000db
Error: WANT = 0xa890005b
Error: MASK = 0xffffffff
Error: fail to run command at line 195177
Error: tdo check error at line 194950
Error: READ = 0xf8b000db
Error: WANT = 0xa890005b
Error: MASK = 0xffffffff

Time used: 1m29s141ms
svf file programmed failed

So the SVF file doesn’t seem to work on both v1.1 and v1.2 hardware, despite OpenOCD detecting the MAX10 on JTAG as expected :frowning:


#15

Reading through the SVF file comments, it seems that all the “programming” steps (UFM1, UFM0, CFM2, CFM1, CFM0) are completed but then the verification phase starts, and UFM1 cannot be verified. I don’t know enough about the MAX10 to know what those different acronyms mean.


#16

Referring to the “Intel MAX 10 UFM Design Considerations” it states that the flash must be erased before programming. In the SVF file comments, it lists only “Program” and “Verify” but I don’t see any mention of erase at the beginning. Maybe that’s a hint, not sure.


#17

Hi @LaF0rge,

These are User Flash Memory and Configuration Flash Memory. All MAX10 Flash space is divided to these sections.

This is SVF file generation window in Quartus:

image

As you can see there is no option to erase the device. Do not think that “Blank-check” option would help. But probably TCK frequency of 25MHz is an issue. Here is SVF file for Mini board with 100kHz TCK frequency.


#18

I’ve been using OpenOCD to program the LimeSDR-Mini for some time. I forked the gateware repository and added an OpenOCD folder under the bitstreams with a bash script to automatically program the gateware. I tested it with my adapters (FT2232H and FT232H) and worked without problems. I added a experimental support to @LaF0rge’s Olimex adapter with information based on this thread.

Forked Repository w/ OpenOCD Support

I also tried the bitstreams generated by @Zack but they fail to verify.


#19

Hi @luigi

Thanks for this!

How do you generate SVF file?


#20

I’m a big fan of open source software. But as FPGA designer/user I can’t see the benefit of programming my LimeSDR using SVF. I will still have to use proprietary software, i.e. Quartus, to run P&R and to generate the SVF. If I want to do something useful like running signaltap I still need Quartus. If I was Lime Micro I could see some benefit if I could use SVF files and free software during the production and testing of the cards. But I can’t see the point other than it’s cool. You could save a few dollars on the programming cable, but I can program my LimeSDR using the onboard FX3 anyways. Am I missing something?

BTW I typically just put this in my build script to generate SVF:

set_global_assignment -name GENERATE_SVF_FILE ON