Communication via USB to iCEstick - how? #51
Comments
|
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: 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/ |
|
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. |
I'm looking forward to it. |
|
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. |
|
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. (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). |
|
Sigh, I read this too late. There is now a little educational echo application on 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. |
|
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" [email protected] escribió:
|
|
more tutorial examples here: https://github.com/peepo/verilog_tutorials_BB |
|
@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 ;) 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). |
|
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. 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'. |
|
@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. |
|
Regarding the fx2, there are a bunch of resources you should look at;
|
|
@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... |
|
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. |
|
@mithro Sure, In general. Sorry - I'm overly accustomed to having to do raw bulk transfers, not going through some existing device class. But you are technically correct - one can just have an fx2 be any kind of standard USB device one likes, and then let the OS use an appropriate driver. One only needs to implement the functionality expected of said class in the '8051 on the fx2, and fx2lib does provide a nice starting point for this. The problem (from my perspective) is that there doesn't seem to be widespread support for virtual serial ports at 240,000,000 baud. Which is a pity, because a "rs232 3.3v ttl" extended to 2.5v or 3.3v differential logic signaling encoded 8b/10b at some rate from 160 MHz to 320 MHz or so would be ideal for interfacing to FPGA's, since that would happily go over even footlong or so twisted pair hookup wires between boards, and you'd only really need 5 wires or so: A twisted pair for each direction, and an earth return. Kind of ends up looking sorta like a poor man's PCIe lane. Or you could abuse a set of sata connectors and cable. Does anyone know if the linux CDC ACM SE support would (or could) stretch that far? I didn't look too deep into this because I assumed going so much faster than the expected max ~1MB/s for such a device class might get broken by someone else's probably reasonable assumptions with regard to buffering and timing. Honestly though I don't know. It could work, and it would avoid needing a driver. At the time I was trying this on - a few years ago now - I couldn't see the point of trying to penetrate the documentation for that, when one can just use 'vendor specific' bulk transfers directly. (although it's really a pity there isn't support for USB isochronous transfers at such speeds, since that's really what I want.). But this isn't covered by any of those convenient device classes, so one has to have one's own driver. And so this brings us to libusb. It acts as the driver, and works on just about everything. So almost everyone seems to be using it with fx2lib for every application not neatly pigeonholed into a USB device class. It'll do about 32 MB/s, on the same hardware which will do closer to 38 MB/s via the linux headers for direct bulk transfers (assuming you give it a nice queue of requests to keep it busy, like fx2pipe does). I think I quite like the idea of libfpgalink though, it would be nice to have some kind of standard OSS way to do this, and it's the first I've met. Cool. May have to reconsider my advice re: using fx2 not for FPGA configuration then. At the same time, I'm leaning further in favor of a hx8k board with sdram and fx2, and quite possibly intentionally little io and thus minimal footprint, so it can hang off a usb port like the iCEstick. |
|
Thank you both for this nice thread. @mithro I just gave fx2lib a spin on Debian which compiled nicely (mithro/fx2lib#30 with a request to help the README). The libfpgalink is also pretty impressive. I'll have a look at that, too. [Update: I just found your 2014 post https://groups.google.com/forum/#!topic/fpgalink-users/YTCqCuhds6o expressing interest in a Debian package. I just compiled it on Debian, which was not completely straight forward because of a broken reference in the README, and need to learn more about it to know how to package it. I happily take instructions or help with sponsoring/finishing an existing package.] Still, for a regular noob much like me one needs something with no risk to start out - like buy this board, buy this JTAG adapter, compile this, and see the echo to the device working/LEDs blink/some success. [Update: The manual to libfpgalink linked from https://github.com/makestuff/libfpgalink/wiki/FPGALink is pretty close to it.] |
|
Yet another web search brought my attention to https://github.com/cyrozap/iCEstick-UART-Demo which I found to be in perfect sync with my noob's mind. It does not answer my question on recipes to orchestrate the data exchange between host application and the FPGA but was close enough to let me help myself. I'll eventually submit an additional noob-helping-example as a pull request to that repository. Many thanks to you all again. Update: My noob UART example is here cyrozap/iCEstick-UART-Demo#3 . |
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
The text was updated successfully, but these errors were encountered: