Well... I've been partially back to work since Monday. There's a lot of catching up to do.
Anyway, 'tis time to dust off a ToasterCo project that's been dormant for a few months, involving one of the Lattice MachXO super-CPLD parts (almost an FPGA, but not quite). We're using the older MachXO rather than one of the more modern variants, because it's available in automotive-grade (and a convenient package, and other such fiddly details).
Now, last time I was working on this - basically doing some feasibility testing, making sure I could attain the required timing and so on - it took some fiddling. I remember that much. In order for the Diamond toolchain's programmer to detect the FTDI-based programming cable under Linux, one must rmmod ftdi_sio, right? So the software can use its own, user-space driver instead of the usual FTDI comm-port driver?
Well, that didn't work this time.
After much fiddling, I determined that I had to unplug all the other FTDI-based serial ports (there were two plugged in, for unrelated projects), then re-connect the breakout board with its programming hardware, then do the rmmod ftdi_sio again. After that, it's working.
Looks like I can't use the programming interface and have any FTDI-based serial dongles plugged in at the same time. (Couldn't the FT2232 on the board be programmed with a distinctive VID/PID to mark it as a bit-bashing interface and not a serial port? Seems like FTDI could designate an alternative PID or two for that sort of thing.)
It's never simple, is it? And this isn't even the part they pay me for.
Update: Now things are together, and I can do some testing....
I'm trying to use Lattice's I2C slave peripheral module (RD1054). The documentation, such as it is, seems to imply that sequential reads ought to work, and that data_vld should be asserted per byte. Only... that's not what's happening. I routed some signals out to test points, and hooked up a scope on the big, deep memory setting. I see data_vld happening for the first byte, only. Guess I need to dig into their code.
Foo. I'm only trying to use the vendor's module because it seemed like it ought to be easier than coding my own. I may end up dumping it and doing my own anyway (most likely using a state machine and a high-frequency sampling clock, just because I find synchronous designs easier to deal with than these weird things that try to create clock pulses using implied logic delays).
Update 2: Bleah. The signals actually coming out of that module, as routed to pins and observed on the oscilloscope, bear little or no resemblance to those shown in the documentation. (Also, the handling of the data0 state is clearly wrong, though I'm not sure what the right handling would be.) Presumably it works in the simulation, but I'm not inclined to get up to speed on the simulation environment. Um. Maybe it works in simulation because those #1 thingies scattered through the code actually have an effect in simulation, while synthesis ignores them and lets the delays fall where they may?
Time to look on OpenCores. Actually, I'm quite certain I did that before, and rejected all projects listed there. Why? Dunno; that would have been long ago. Looks like there are some candidates, with BSD licensing (so OK for this project). Have to review their documentation, and see if there's one with a decent interface and that isn't too resource-hungry when configured as a slave.
Update 3: Yeah, looks like the known-good-and-BSD-licensed one on OpenCores is designed to work with a processor, which is something I definitely don't have in this design. Or, rather, there is one, but it's in a different chip, and the I2C is for it to communicate with the CPLD.
So, gotta write my own. Or use SPI, maybe. SPI is easy.
And furthermore: Southmoon has been trying to help all day. Right now, she's lying on the Aardvark pod I was using to exercise the I2C (and will be, again, once I get my implementation done). Maybe she thinks she can hatch it.