Communication via USB to iCEstick - how?

[smoe]

I find it to be beyond my immediate capabilities to figure out how to communicate with the HX1K via USB. I can follow the instructions on https://wiki.debian.org/FPGA/Lattice, can modify that code, all fine. I have a USB-TTL converter and could imagine to use that to communicate with the device via some extra cables, basically along the examples for the IrDA. But if somehow possible I would want to use the USB port that the device is using already.

Does anybody reading this have any respective code (host and fpga) available? Maybe something along the "echo" example at ztex (http://www.ztex.de/firmware-kit/example.e.html)?

Many thanks

Steffen

[cliffordwolf]

Hi Steffen,

I think this tutorial (and the tutorials leading up to it) answer your question. You can use e.g. google translate to translate it to english:

https://github.com/Obijuan/open-fpga-verilog-tutorial/wiki/Cap%C3%ADtulo-24%3A-Unidad-de-transmisi%C3%B3n-serie-as%C3%ADncrona

Please note that this is NOT a general discussion board but an issue tracker. If you are not reporting a potential bug, please consider posting on the Yosys subreddit instead: https://www.reddit.com/r/yosys/

[smoe]

Thank you, Clifford!

Well, this issue is the missing example that icestorm could ship to get people going ;o) Thank you for the pointer to that tutorial. It happened, that via YouTube I found the also helpful and at first sight simpler setup of Paul Martin at https://youtu.be/s7fNTF8nd8A?t=34m38s and his code repository at https://github.com/nesl/ice40_examples/tree/master/uart_transmission . So, let us see what I can come up with and if you allow I will eventually craft a patch with that "missing" example I moaned about.

[cliffordwolf]

So, let us see what I can come up with and if you allow I will eventually craft a patch with that "missing" example I moaned about.

I'm looking forward to it.

[smoe]

I just adapted Paul's TX direction for the HX1K and it worked like a charm, see nesl/ice40_examples@e613665 . I now preserve that moment of deep satisfaction and address the RX direction over the weekend.

[RGD2]

If I might chime in here: Jame Bowmans' Swapforth/j1a SoC core runs on the icestick and uses the serial link quite heavily to enable the user to reprogram the soft-core whilst it runs.
Here's the uart.v which it uses.
It interfaces to the core via a simple 16 bit processor IO bus, documented in the j1a.v top code.

(disclaimer: I am a huge fan of swapforth on j1a, and I wrote the j4a. It is perfect for what I do: Laboratory control / data logging systems, although it needs at least a ice40??4k chip. Apologies for the advertisement).

[smoe]

Sigh, I read this too late. There is now a little educational echo application on
nesl/ice40_examples#2
and I hope this gets accepted. It is a bit (six lines) more than just doing the RX and TX, actually getting the flow from RX to TX I failed to implement - piece of cake for Ruben, though. So it is not completely redundant to the uart implementations out there and hopefully as educational for others as it was for me. @RGD2, I admit that I had felt those CPUs implemented on FPGAs would be mostly for fun - unless you call it Zync on a very large chip. I am somewhat enthused to hear that (after quadrupling my chip) one can do something useful and was suprised about the environment with which to program your environment. Your advertisment was much appreciated. Could you possibly describe your use case of such smallish FPGA sticks somewhere on/beneath wiki.debian.org/FPGA? With enough detail for others to implement such a laboratory control / data logging system? Does Debian feature everything you need or should we add anything?

My initial certainty that there should be more examples shipping with icestorm has mostly vanished. However, even if there are more intelligent ways to search than what I had done (like using github rather than google and youtube - I did check opencore but apparently used the wrong keywords and felt a bit lost upfront), some home page for an Open Source icestorm with various examples or references to such would certainly help. The one of Paul Martin to me felt very natural to follow, even more so than the Spanish one.

[Obijuan]

You can also find some examples here:

https://github.com/FPGAwars/FPGA-peripherals/wiki

I will add more examples soon: servos, pwm, spi and so on

El 07/08/2016 22:29, "Steffen Möller" notifications@github.com escribió:

Sigh, I read this too late. There is now a little educational echo
application on
nesl/ice40_examples#2 nesl/ice40_examples#2
and I hope this gets accepted. It is a bit (six lines) more than just
doing the RX and TX, actually getting the flow from RX to TX I failed to
implement - piece of cake for Ruben, though. So it is not completely
redundant to the uart implementations out there and hopefully as
educational for others as it was for me. @RGD2 https://github.com/RGD2,
I admit that I had felt those CPUs implemented on FPGAs would be mostly for
fun - unless you call it Zync on a very large chip. I am somewhat enthused
to hear that (after quadrupling my chip) one can do something useful and
was suprised about the environment with which to program your environment.
Your advertisment was much appreciated. Could you possibly describe your
use case of such smallish FPGA sticks somewhere on/beneath
wiki.debian.org/FPGA? With enough detail for others to implement such a
laboratory control / data logging system? Does Debian feature everything
you need or should we add anything?

My initial certainty that there should be more examples shipping with
icestorm has mostly vanished. However, even if there are more intelligent
ways to search than what I had done (like using github rather than google
and youtube - I did check opencore but apparently used the wrong
keywords and felt a bit lost upfront), some home page for an Open Source
icestorm with various examples or references to such would certainly help.
The one of Paul Martin to me felt very natural to follow, better than the
Spanish one.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#51 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOfrv1HtUgJXXrUU0pfmvy1FdGVVftdks5qdkAxgaJpZM4JbonV
.

[peepo]

more tutorial examples here: https://github.com/peepo/verilog_tutorials_BB

[RGD2]

@smoe I'm not sure when I'll get around to documenting on wiki.debian.org - probably after I have the acquisition side of things done. But documentation with enough detail to reproduce is in my APA. ;)

I hadn't actually noticed icestorm appearing in debian - I've just been running straight from github. (also occasionally under MacOSX). But I do end up doing most of my work under ubuntu or debian (also armbian) for convenience of duplication.

So far as everything I use being in debian - not quite: jamesbowman/swapforth would be nice ;)
In fact, James' paper on the J1a is a good place to start, assuming at least an icestick (or hx8k breakout board).

On the data acquisition side of things, I've been using a few old ztex.de 'usb-fpga' dev kits, all of which are Xilinx based. This because I needed >10 MB/s BW, but had not the budget for jumping to a PCIe card. I ended up able to sustain 30 MB/s (for >TB - until the disc filled) from ADC's through USB 2.0, but not through an FT2232.

I looked very briefly at firewire, and then saw that most of the day had passed whilst I was still coming to terms with it's architecture. Beautiful: Reliable, DMA built in, real time priority built in - democratic (it's peer to peer) utopian, really, where USB is really just the host being an absolute dictator: everyone else will speak only when spoken to! Perhaps some day someone will release a functional open-sourced verilog module implementing fw400. That'd be nice.

The really critical trick turns out to be to have at least about 8MiB deep of fifo available just ahead of the USB-fifo chip: for it will only have (at most) a few kb, far too little for reliable HiSpeed USB2.0 streaming. And when USB 2.0 appeared, the spec didn't tell root hub designers to use hardware timed DMA capable bus masters, so most require CPU polling, which depends on how busy the OS is... On a good intel root hub controller, linux sometimes drops the ball for ~800 usec every now and again, maybe once or twice overnight... windows, about 4 ms several times per second. Either way, to keep the capture from losing data at 30,000,000 Bytes per sec, one needs several 100 ms worth of buffer to weather sequential glitches.

This pretty much requires an sdram chip.

The FX3 doesn't have much more local buffer, but at least 'use DMA at the host adaptor' got added to the rules for USB3 root hubs, which means the host's RAM can be the buffer. FX3's are fairly expensive though - probably practical if up to several hundred MB/s is needed, though by that point you're playing in a different ball park entirely, where costs start to skyrocket if you want to be able to keep up with it. You'll probably still want the local deep sdram fifo though.

I'm seriously considering designing a board with a '8k, some SDRAM and an FX2LP, possibly in addition to the FT2232 to keep the data acquisition side separate from the FPGA configuration side.

I think I recall one ice40 board which had the FT2232 hooked up for the only 'fast enough' interface it has: 8bits synchronous parallel at 60 MHz - but most don't have all the wires attached correctly, and i found getting a parallel bus to work reliably above 30 MHz or so over hookup wires between boards is an exercise in futility. (serial LVDS over twisted pair at >160 MHz between FPGA pcb's is child's play by comparison.).

Doing both bulk data transfer and fpga config in the fx2's horrible 8051 firmware hurts a lot, needlessly when Wolfgang's 'fx2pipe' exists, and works quite amazingly well on the faster armbian hardkernel boards. ztex do have an open source SDK to do that, but you'll need to install fpc and sdcc (and jdk) for it. fx2pipe won't do FPGA config, but it just works, an so long as you wire the fx2 as 16bit parallel synchronous 'slave fifo' mode @ 30 MHz, you'll find it works very reliably. (please note, you need much more BW between usb-fifo and fpga than your budget, since the data will stop moving entirely every time the host end is late to pick it up out of the tiny fx2 fifo buffers, and this will happen very often.)

From what little testing I've done so far, it looks like just fx2pipe and nc are enough to stream data at around 38 MB/s through a relatively cheap SBC from an fx2 over gigabit ethernet, provided it's one (unlike the RasPi's) which doesn't use the only usb 2.0 root hub to handle the ethernet as well, but which actually includes a true Gbit controller on the SoC or via separate usb3. (almost everyone besides broadcom seem to be good at this).

This is a good thing in a larger (dustier, wetter) laboratory, since it's easy to deploy an inexpensive SBC into an electrical box to do that job, and just run ethernet to wherever is kinder for computers.

Of course if you only need a few kb/s of data capture, the j4a/j1a core can just spit it out over the rs232 link. And since it's so easy to append more rs232 links onto the j1a/j4a, I quite imagine one could do enough with just a ice40, some flash memory (to hold a few 10-100kb of client-side js), and an esp8266 module.

There seems to be some interest in running yosys through emscripten, so that hardware combination might conceivably also be just enough - assuming a thick enough browser at the byo client, say a good smartphone, with memory enough to load an emscripten'd icestorm - to meet the 'tools+source included' philosophy too. Food for thought.).

But for now - linux SBC's are cheap enough and good enough to spare one per such lab control system. And provided something in the enclosure to pipe captured data to (and somewhere on the lan to save it): Well, differential logic is really easy to use to link FPGA's via 'SPI' like links, at easily ~160 Mbps, even for the ice40, and even over wirewrapped AWG30 twisted pairs between boards (just don't forget a ground return path).

This means it's actually really easy to add small fpga's as needed, pipe data where it needs to go, and just get the job done 'well enough'. This is all more than sufficient for electronic direct-injection engine management (and measurement) systems.

It may not be as convenient as plugging some proprietary modules into some proprietary PLC system, but it actually performs a lot better than almost all of those, and for something like 10 to 30 times less cost. (and small FPGA's take far less time to compile for than the giant ones, and segmenting a system across multiple FPGA's means one can avoid fixing what isn't broken too).

[RGD2]

Also @smoe : I have some Zynq's (about 6, but I've never deployed any). They're actually quite big FPGA's, and relatively poor SBC's. Very high I/O performance, but you also have the downsides of dealing with Vivado and it's licensing. They can't host their own tools. They usually max out at 1 GB ram.
An ice40 attached to a linux SBC can host its own tools.

You can also install cloud9 ide locally to that SBC. (there's a script in the c9/core repo which does the trick on debian).

Ergo, all of the programmer's UI, tools and documentation can be kept in the same box as the actual deployed equipment, which makes it far more useful to whoever inherits the gear, either for maintenance or reuse.

Having had to work with inherited systems, I can tell you this is a very desirable feature. Ever more so in my field which is essentially 'industrial experiment/development', since the person 'inheriting' it is likely to be me - comp. eng on the team - after it has collected dust for a few years while we go pursue some other contracted work. I already have... 8 (? huh, time flies) such systems to maintain/support/develop extensions to, this one with the ice40 + SBC is the 9th one, and I am certain that it, too, will suffer mission creep.

But even after 7 years at this, I don't find the performance specs (in terms of data rate / timing accuracy, at least) getting any higher than what small FPGA's can comfortably handle. This leads me to believe that they aren't likely to, either. Linux SBC's over the same time have gone from 'possibly could implement a touch screen UI with video on a small one for maybe <$1000/unit' to 'effortless. fast enough to run quake3 playably, cheap enough you might spend more dining out than on the whole system'.

[smoe]

@RGD2 , thank you for this amazing collection of gems. I'll start with the J1a paper as suggested.

Anything that helps to see the wider public adopting FPGA technology with Debian and beyond I happily help with. This apparently now starts with looking into preparing packages for jamesbowman/swapforth and fx2pipe. I also have a ztex.de fx2+Spartan-6 and once packaged their SDK. All its build+runtime dependencies like the sdcc to program the fx2 are in Debian.

My plan for the upcoming months is to provide a decent FPGA for accelerating the http://distributed.net efforts. It seems like everyone is up to it - I asked - we just need for something as easily deployed as an iCEstick to help. Once there are a couple of thousands of users I anticipate that we will see more projects aiming at FPGA for their acceleration. Communication for these problems is minimal. The advantage of an USB (or Ethernet) attached FPGA is that we can have multiple connected to a single computer and the also run with your OpenWRT WLAN router. If you have an idea how to position the Lattice 8K (or multiple 8K chips on a single board) to best perform as an application accelerator, maybe even without compromising your demands, then please consider me (and maybe many d.net contributors) a customer.

As a pleasant side-node: There are now close to 140 users of yosys+icestorm on Debian alone (https://qa.debian.org/popcon.php?package=yosys) which I find amazing. Many thanks to @rubund for his packages. The package for hopefully-at-some-point-usable-for-mere-mortals fpgatools (https://github.com/Wolfgang-Spraul/fpgatools) has 15.

[mithro]

Regarding the fx2, there are a bunch of resources you should look at;

• fx2lib - The library provides a lot of infrastructure to build stuff on the FX2 chip. I have a fork at http://github.com/mithro/fx2lib where I'm trying to improve a lot of the examples and reusing Linux Kernel headers to make it easier to develop USB devices.
• ixo-usb-jtag - This enables the FX2 to emulate a Altera USB Blaster JTAG programmer. See my fork at https://github.com/mithro/ixo-usb-jtag
• makestuff / libfpgalink - Another library for interfacing with FPGAs using the FX2. https://github.com/makestuff/libfpgalink

[RGD2]

@mithro Very interesting, thanks for the links!

Kudos for your work on fx2lib, too: libusb (of any version) is a bottleneck, fx2pipe also goes the route of avoiding it in favor of the linux kernel headers - and it performs much better because of it. I had seen fx2lib some time ago, and had passed on by precisely because it was so messy and used libusb. The ztex guys have a custom C preprocessor so 'app' firmware becomes very succinct, which is nice, but their preprocessor is written in freepascal!

All that said - one problem with changing between the 'host side' software talking to fx2's (and with fx2 + FPGA in general), is that there are a few different, (and, sadly, incompatible) ways to wire an fx2 to the FPGA.

For instance, the fx2 comes in different packages, with different pins connected or not, and some of the cheap 56 pin SOIC's also have the undocumented 'feature' that the inputs to the GPIF master FSM module may not have been wirebonded where they're supposed to be, so that only the slavefifo mode works properly, and the GPIF master FSM doesn't respond to inputs, and so can only be run in counted bursts. (I learnt this the very hard way - with unchanged code suddenly working flawlessly when I first ran it on the very overpriced CY3687 FX2LP18 official dev kit.. (I wanted to interface to 2.5 V LVCMOS at the time, and I was trying to avoid adding an FPGA at all. Doesn't work, at least, not reliably. not enough buffer. The fx2lp18 can go down to 1.8V, and has a Vio control pin, but any FPGA seems to be happy with 3.3V these days.)

Most of the real incompatibility isn't to do with the actual fifo interface though - same pins used for GPIF master or slavefifo controller -- but rather with how the FPGA is wired to be configured. This varies even among ztex's boards, but it looks like you have it in hand there with ixo-usb-jtag, So I will be looking more closely into that...

[mithro]

fx2lib has nothing to do with libusb. fx2lib is for the code which runs on the FX2. (There is some libusb code for getting the fx2 firmware onto the chip but once that is loaded you can do anything you want.) Normally you emulate an existing device like a UVC camera, USB bulk or other device.