Both OV1 and KDE1 were disasters, and both became usable by version 3 :-)
-
-
Replying to @marcan42 @whitequark
Did you realize an XMOS would be perfect for Glasgow as well? You get deterministic, event-driven IO, and you can program it in a C-like language, so no need to mess with RTL. XMOS has excellent USB support as well. You really should use that. It's great!
1 reply 0 retweets 0 likes -
I don't think "programming in a C-like language" is inherently an advantage (quite the opposite!), but more importantly, while XMOS can probably match HX8K on many tasks, I don't think it can match ECP5
1 reply 0 retweets 3 likes -
Replying to @whitequark @marcan42
Sorry, that was meant to be ironic: OV1 used XMOS and was quite the disaster. OV3 switched to an FT2232H+FPGA, using migen and python, and was a wonderful universal development platform. XMOS performs great on paper but projects eventually fail for stupid (but valid) reasons.
1 reply 0 retweets 3 likes -
oh. yeah I've never given XMOS more than a passing look, so I haven't even suspected it was supposed to be sarcastic.
1 reply 0 retweets 1 like -
Replying to @whitequark @tmbinc
As far as I can tell the sole decent use case for XMOS is USB audio (or maybe other audio). I have a DIY DSP thing running my speakers using an XMOS and it has better latency (0.25ms analog-to-analog, ish) than ~every high-end DSP box you can buy.
1 reply 0 retweets 5 likes -
That's running 15 biquad EQ filters × 6 channels at 96kHz 32bit internal resolution (24bit codec), on two XMOS chips. Good luck getting that latency on a traditional DSP. But for anything else? Stay far, far, FAR away from XMOS.
1 reply 0 retweets 7 likes -
In 2013 @0x111a and I designed a board that was essentially Glasgow (even the same 74LVC1T45 level translation), except with XMOS for lack of an open FPGA toolchain, and quickly came to the same assessment of the XMOS ecosystem.pic.twitter.com/eIiwtR8FBE
1 reply 0 retweets 5 likes -
At least you weren't crazy enough to try to use that cursed dual-row QFN package.
1 reply 0 retweets 2 likes -
Yeah, well the XS1-U8 we designed in wasn't actually purchasable in quantity at the time, and its integrated USB transceiver required a new version of the binary blob USB stack that clearly hadn't been tested with anything besides their audio class example.
2 replies 0 retweets 3 likes
Ah, yes, that lovely blob USB stack that runs on a thread but somehow has a choke point between completing a control xfer and polling for the next, where it can't NAK packets but instead times out at the USB level if you dare do anything between those calls.
-
-
Wow, they've released source for the USB blob. https://www.xmos.com/developer/published/lib_usb-sw?version=latest … ...and now I understand why they were reluctant to let anyone see that mess, especially while they were still pushing the "easy deterministic IO timing in software" message.
1 reply 0 retweets 4 likes -
Replying to @kevinmehall @marcan42 and
I'm glad they've found their niche in audio, though, because the XMOS CPU architecture is super interesting, just...not a FPGA replacement. Re-reading https://www.xmos.com/developer/download/private/The-XMOS-XS1-Architecture%281.0%29.pdf … now.
0 replies 0 retweets 2 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.