sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<cr1901_modern>
rjo: I may just use OpenOCD. At this point, I can't use either program to flash (and only xc3sprog to load a bitstream). Just need some time and patience to play around w/ OpenOCD's settings. Not really looking to brick my board b/c I did something stupid.
<cr1901_modern>
I bought said Spartan-3A board b/c I wanted a small FPGA, but Xilinx seems to be phasing the 3-series out. So maybe next I'll buy a XC6LX4.
<cr1901_modern>
And if I'm totally honest, I have no idea how to use the boundary scan features of an FPGA.
<rjo>
bricking this is really difficult.
<cr1901_modern>
I'll take your word for it then :D.
<cr1901_modern>
rjo: https://github.com/jordens/bscan_spi/pull/1 <-- Stuff like this is why I use Migen. It took me 20 minutes to add support for my board and get it working.
<rjo>
cr1901_modern: i don't look into that xc3sprog stuff anymore. all the bugs you find are yours to keep!
<cr1901_modern>
Okay, sounds good lol. I was just offering :P.
<rjo>
sure. it's just that the xc3sprog codebase is dirty and annoying. and there are probably bugs.
<cr1901_modern>
Oh yes, there are.
<cr1901_modern>
Path handling isn't even consistent
<cr1901_modern>
i.e. if some flags are present, xc3sprog will choke on forward slashed paths on Windows, whereas others it will handle just fine. Just needed a quick and dirty solution
<cr1901_modern>
rjo: Are the OpenOCD proxies faster to flash for you or about the same speed as the xc3sprog in your experience?
<rjo>
same speed. limited by flash page erase and write time.
<rjo>
but with openocd you can mic and match volatile bitstream loading (directly into the fpga) and flashing bios/runtime.
<rjo>
mix
<cr1901_modern>
Ahh right, so you can put the BIOS/runtime after where the bitstream will live and then program the bitstream?
<cr1901_modern>
the addresses in Flash after the bitstream*
<rjo>
you load the proxy bitstream, then flash what you want your runtime and then load your actual bitstream directly and run the thing.
<rjo>
in that case it won't load the bitstream from flash (and you don't have to flash it) and is thus much faster for development.
<cr1901_modern>
Okay, makes sense. Presumably when ready to deploy, you'd flash the bitstream at the beginning of memory too
<rjo>
yes
<cr1901_modern>
Well, except for reasonable SVF playing times, I now have a system for flashing/programming a bunch of JTAG chips.
<cr1901_modern>
(OpenOCD is broken, libxsvf is slow as molasses for some reason)
<rjo>
why is openocd broken?
<cr1901_modern>
rjo: Well, it detects my CPLD, but when I use the SVF command, it chokes (I'll take a snapshot in a sec). Libxsvf on the other hand, will successfully program the chip, but takes 13 minutes (which, from what I'm told, is extreme).