Foxyloxy has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #rust-embedded
ivche has quit [Ping timeout: 244 seconds]
ivche has joined #rust-embedded
<thejpster[m]>
Also look at https://github.com/google/arm-gic. If they wrote a bare metal interrupt controller driver for 64 bit Arm they probably did it for a reason.
<thejpster[m]>
But in general Cortex-M based chips have CMSIS-SVD files and lend themselves to a monolithic HAL crate based on the autogenerated PAC.
<thejpster[m]>
Cortex-A based chips are larger, don’t usually have SVD files, and hence usually get drivers written piecemeal. See the roughly one dozen Arm PL011 UART driver crates.
<thejpster[m]>
Cortex-R chips are too expensive and hardly anything is available as open source Rust for them.
<korbin[m]>
<thejpster[m]> "Cortex-R chips are too expensive..." <- the TI AM2431 and family are an absolutely smoking deal and they have 4x R5F cores. $7 buys you a huge number of GMacs connected to aswitch chip, just an incredible number of peripherals, USB 3.1 DRD PHY, PCIe, ETC.
<thejpster[m]>
And I bet it uses ICDI and won’t work in probe-rs.
<thejpster[m]>
But I’m tempted. Someone pay me money and I’ll do it.
<JamesMunns[m]>
I'll start the bidding at 10 EUR
<thejpster[m]>
That’ll get you a couple of minutes on it, no problem
<JamesMunns[m]>
:D
<therealprof[m]>
<jsjuel[m]> "I am very much a beginner here..." <- You will always need a Cargo.toml and a memory.x; it's not possible to do anything in Embedded Rust without. .cargo/config.toml is something you *want* to have because it saves you a lot of typing. This is way simpler than pretty much any other language you can think of, if you don't see it (like in Arduino), then it just means that it is hidden from plain sight and someone
<therealprof[m]>
hardcoded it for you.
<M9names[m]>
<thejpster[m]> "$90 for the devkit though: https..." <- they don't use ICDI any more, and their modern ICE firmware's support CMSIS-DAP (as well as their new custom protocol)
<thejpster[m]>
Oooh
<thejpster[m]>
I bought one
<thejpster[m]>
£95 shipped
<thejpster[m]>
Feel free to buy some Ferrocene licences in return. Only €25 a month.
<JamesMunns[m]>
quad core 800mhz wooow
<JamesMunns[m]>
Oh wow USB 3.1
<thejpster[m]>
Bit bashed logic analyser anyone?
<Lumpio->
MCU with USB 3.1?
<Lumpio->
Wonder what sort of things it can convert from/to USB 3.1 in hardware, I mean you can't do anything with that in software
<JamesMunns[m]>
> On the LaunchPad, a USB 2.0 interface is offered through a USB Type-C connector (J10).
<thejpster[m]>
Weirdly a super speed host but only a high speed device
<Lumpio->
oh wait it does SuperSpeed host ok
<thejpster[m]>
Or PCI-Express
<M9names[m]>
huh, weird
<JamesMunns[m]>
You could put a pcie graphics card on neotron :D
<Lumpio->
But what does the SuperSpeed connect to :think:
<thejpster[m]>
Something something clock source not clock sink something
<Lumpio->
I mean it's not fast enough to actually do any sort of data processing in software is it
<Lumpio->
Or is it?
<JamesMunns[m]>
Lumpio-: I know folks doing machine vision over usb 3.1 cameras
<JamesMunns[m]>
Lumpio-: quad core 800mhz is nothing to sneeze at
<thejpster[m]>
Quad 800 MHz with internal SRAM can do a lot
<Lumpio->
I'm not a super expert but the sort of non-fixed function USB 3.1 devices I've seen came with hardware blocks that can ferry the high speed data (from cameras or whatnot) because you can't process that in software
<Lumpio->
Ok it's a bit faster than I expected
<Lumpio->
That sounds like it could actually do something with the sped
<JamesMunns[m]>
yeah, it's basically a Pi 2B, but an MCU instead of an MPU
<Lumpio->
speed
<M9names[m]>
speaking of doing a truckload of compute, the processors used by the new openmv hardware look pretty impressive
<RobinMueller[m]>
Does anyone have experience with writing low-level SDIO drivers? I am used to I2C and SPI, where I can just connect a analog discovery scope and debug the signals if I have low-level issues. Writing a SDIO driver seems more daunting because .. well I don't even have the equipment to access the pins, if I wanted to debug them. I guess it is more trial and error and looking at existing C code etc. for a task like this? I was
<RobinMueller[m]>
* Does anyone have experience with writing low-level SDIO drivers? I am used to I2C /SPI/UART, where I can just connect a analog discovery scope and debug the signals if I have low-level issues. Writing a SDIO driver seems more daunting because .. well I don't even have the equipment to access the pins, if I wanted to debug them. I guess it is more trial and error and looking at existing C code etc. for a task like this? I was
<RobinMueller[m]>
* Does anyone have experience with writing low-level SDIO drivers? I am used to I2C /SPI/UART, where I can just connect a analog discovery scope and debug the signals if I have low-level issues. Writing a SDIO driver seems more daunting because .. well I don't even have the equipment to access the pins, if I wanted to debug them. I guess it is more trial and error and looking at existing C code etc. for a task like this? I was
<Ralph[m]>
i got my hands on a pair of microbit v2 for a small drone project with the [air:bit](https://www.makekit.no/en/docs/airbit-docs/) (as if i wouldn't have enough other projects ongoing in parallel 🙈)
<Ralph[m]>
the drone uses the "microbit radio" technology (a BLE connection with a custom protocol, if i see that correctly) for the two microbits to talk to each other. is there a crate implementing support for this? at first glance i didn't see it on `crates.io` and also not in the `microbit-v2` crate. if there's no support for it: is there something else you could recommend to implement a remote control via BLE? (i was kind-of hoping that we
<Ralph[m]>
can re-use the protocol used by the air:bit so that we can always use the stock firmware on one while implementing the custom firmware on the other)
<Ralph[m]>
the other, maybe more religious question: would you recommend using the embassy-nrf HAL and skipping the microbit-v2 BSP? the BSP is of course comfortable, but i'm not sure how the HAL is to use (esp. for async stuff)?
lulf[m] has joined #rust-embedded
<lulf[m]>
<Ralph[m]> "the other, maybe more religious..." <- You can use the embassy-nrf directly, there is also the microbit-bsp crate which is based on embassy HAL and has some simplifications to setup BLE if you look at the examples https://github.com/lulf/microbit-bsp/
<Ralph[m]>
i don't think that it's worth it to re-implement that in rust? i've never used BLE for MCU to MCU communication. how hard is it to implement a protocol on top of that? or is there some crate which anyone can recommend which can be used to implement a simple protocol?
<JamesMunns[m]>
> they basically offer the same features and it's just personal preference of the APIs dictating which of the two to use
<Ralph[m]>
ok, thanks a lot for clarifying this!
<ckrenslehner[m]>
<ckrenslehner[m]> "Hi!..." <- I think this is also an answer to my question. So I can use embassy-usb and whatever using the RTICv2 builtin executor
<ckrenslehner[m]>
<JamesMunns[m]> "It's mentioned a bit here: https..." <- Yes as you say "a bit". I was also confused by a project running an embassy executor in a rtic software task, which I found in google. I assumed that this was done due to some compatibility problem
pcs38 has joined #rust-embedded
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
is anyone here interested in Rust support for FX2G3/FX5/FX10?
<whitequark[cis]>
I think the CPU cluster is similar or identical to PSoC6, is anyone working with that in Rust?
<korbin[m]>
whitequark[cis]: infineon/cypress stuff is pretty niche from what i've seen, it would be nice to have more options though
<i509vcb[m]>
iirc there was an abandoned psoc 5 or 6 repo somewhere
<whitequark[cis]>
the 8051-based FX2 is deprecated in favor of FX2G3 which is basically just cut down FX5/FX10
<whitequark[cis]>
and your options for a really high speed USB<>FPGA adapter ASIC are pretty limited
<whitequark[cis]>
there's FT600 but that's 5 Gbps only. there's whatever WCH came up with but their stuff in that particular domain is reaaaaally sketchy
<whitequark[cis]>
but yeah it's kind of niche. a lot more than the STM32 ones for sure
<korbin[m]>
<whitequark[cis]> "and your options for a really..." <- CH347F? IMXRT1011?
<korbin[m]>
the IMXRT1011 is $1.30, i've used it for this very purpose to do 60mbit/sec JTAG
<korbin[m]>
(FlexIO)
<i509vcb[m]>
On a related topic, I did wonder if trace is too fast for flexio
<whitequark[cis]>
sorry, by "high speed" i mean 5..10 Gbps
<korbin[m]>
whitequark[cis]: super speed
<whitequark[cis]>
so technically, superspeed
<korbin[m]>
hehe
<korbin[m]>
yeah, that's a bit more limited
<i509vcb[m]>
Yeah superspeed...
<korbin[m]>
i would personally just use another FPGA
<whitequark[cis]>
WCH has some devices but they look like they're pretty cursed
<whitequark[cis]>
so not really suitable for Glasgow
<JamesMunns[m]>
whitequark[cis]: I think someone said it looks like a repurposed SATA serdes? Does have SS with built in phy tho, on a smallish riscv core
<whitequark[cis]>
korbin[m]: oh this is very entertaining, shame it has a PHY and not a MII
<korbin[m]>
i wrote an nusb driver for the CH347F ($2 in tray quantities) - SWD/JTAG/SPI/UART/GPIO/etc
<whitequark[cis]>
actually for Glasgow revE the ideal outcome is probably using an UltraScale Artix with a built-in USB core and partial reconfiguration to run the applets on the same FPGA as the USB core
<korbin[m]>
you could consider using a transceivered-up zynq
<whitequark[cis]>
but for that we'll first need a toolchain that isn't Vivado
<korbin[m]>
what's wrong with vivado in TCL-only mode? open source requirements?
<whitequark[cis]>
have you seen what glasgow does?
<korbin[m]>
yes, i own one
<whitequark[cis]>
in the time vivado merely starts up and loads its junk from the disk you could build something like 50 applets
<whitequark[cis]>
not to mention there's no way i can do yowasp-vivado
<whitequark[cis]>
accessibility is something i find very important; turnkey installation was a requirement i had to finish before general availability
<korbin[m]>
whitequark[cis]: so the zynq 7 series have already been implemented i thought in yosys
<whitequark[cis]>
yosys doesn't matter too much here
<korbin[m]>
i've never used the open source tools - my designs are normally >90% occupancy and multiples beyond the rated power of these chips, 4-48 hour P&R
<korbin[m]>
(and ultrascale+, i guess, so not really compatible)
<whitequark[cis]>
prjunnamed is intended to compete with vivado, at which point it will coincidentally make yosys mostly obsolete
<whitequark[cis]>
so we aim for an end-to-end FPGA flow on a unified representation and advanced P&R features like physical optimizations or partial reconfiguration
<korbin[m]>
i didn't realize this was happening on end user machines
<whitequark[cis]>
prjcombine already has chip databases for everything from the original virtex to ultrascale
<whitequark[cis]>
unfortunately, nextpnr doesn't scale above devices bigger than the tiniest artixes (artices?)
<korbin[m]>
zynq would be cool though - running the actual P&R on the ARM core itself
<whitequark[cis]>
so we're going to have to figure out a better placer than HeAP, maybe an electrostatic one, and do a whole bunch of other work before we can seriously compete
<whitequark[cis]>
korbin[m]: what is?
<korbin[m]>
whitequark[cis]: FPGA implementation
<korbin[m]>
applet building
<whitequark[cis]>
oh. did you think i was running a web service?
<korbin[m]>
i would have thought they would have been built AOT by some CI process and then selectively loaded
<whitequark[cis]>
nope, the netlists are generated, synthesized, placed, and routed just-in-time
<whitequark[cis]>
nobody else does this because the tooling simply does not support it
<whitequark[cis]>
and this allows us to get basically all of the performance out of the FPGA, instead of having to add things like crossbar switches for pin muxing
<korbin[m]>
traditionally these flows are almost non-deterministic
<korbin[m]>
whitequark[cis]: partial reconfig would work here depending on the flexibility you require
<whitequark[cis]>
i actually compile the entire toolchain to webassembly (that's the w in yowasp) for, aside from other stuff, determinism
<whitequark[cis]>
since the wasm abstract machine is fully deterministic* this means the toolchain is, too
<korbin[m]>
some of the TI MCUs have USB 3.1 and are competitively priced with incredible peripherals btw
<whitequark[cis]>
which allows me to do transparent caching of bitstreams
<korbin[m]>
i just don't have it in me to do the toolchain/open source work for them
<whitequark[cis]>
the flow is less "nondeterminitic" and more "chaotic", this is true of yosys/abc/nextpnr and also true of more or less any practical flow
<korbin[m]>
whitequark[cis]: it's extremely granular on the ultrascale+ chips, far smaller than one clock region
<korbin[m]>
the 7 series are actually better for partial reconfig because of their global clock routing story
<korbin[m]>
you can do actual isolated horizontal implementation of reconfigurable blocks
<whitequark[cis]>
i have worked for m-labs, or perhaps the better way to phrase it is "i survived the abuse i got at m-labs"
<whitequark[cis]>
certainly i don't think my health will ever recover to the pre-m-labs state
<korbin[m]>
i think the biggest thing would be the bitstream implementation part - need an open source toolchain for that zynq 7 (artix) fabric
<korbin[m]>
brick recovery can be done via microSD
<korbin[m]>
but you could ostensibly do it all in one chip (plus a ULPI PHY if you wanted USB HS)
<whitequark[cis]>
korbin[m]: right, i wasn't sure what the hardware is capable of exactly
<korbin[m]>
whitequark[cis]: very small columns in practice
<korbin[m]>
if your implementation flow were fast enough though or you had pre-designed hand-placed blocks, you could do oneshot monolithic implementation from 0
<korbin[m]>
no reconfiguration needed
<whitequark[cis]>
the smallest artix is about the size of a mid-size ecp5 so we should be able to use the algorithms nextpnr already has to implement it
<korbin[m]>
best timing
<korbin[m]>
the zynqs with kintex fabric are much nicer but markedly more expensive
<whitequark[cis]>
korbin[m]: we also considered these options; existing nextpnr has very crude partitioning support
<whitequark[cis]>
right now, prjunnamed can synthesize a design for ice40 in less time than it takes yosys to load its data from the disk
<whitequark[cis]>
synthesis time is something we care about a lot
<korbin[m]>
i can normally synthesize, place, and route ultra dense 100-200k test core designs in 30 minutes with vivado
<korbin[m]>
(designed explicitly for maximum, eventual >90% occupancy)
<korbin[m]>
s/200k/200kLUT/
<whitequark[cis]>
in the initial release of the flow we aren't planning to target the high-frequency or the high-occupancy corner
<whitequark[cis]>
this is because it would be rather hard to compete with vivado, which had probably 1000x as many person-years sunk into it at least
<whitequark[cis]>
competing on speed of end-to-end flow and usability of partial reconfig? that's different
<korbin[m]>
yeah, very very difficult, especially for larger devices
<korbin[m]>
at least beyond 7 series, the ultrascale+ chips have substantial limitations on partial reconfig because global clock routing is kind of ugly, has to be done in-context of a lot of other things
<whitequark[cis]>
right
<whitequark[cis]>
I've actually never personally used Xilinx devices in anger (for anything besides testing Amaranth), my plan is to start with building a good FOSS toolchain for them first :3
<korbin[m]>
will be curious to see what you come up with for the next glasglow, i spent a solid year on the USB->JTAG problem (and learning a lot a long the way)
<whitequark[cis]>
i have a lot of respect for vivado though after having seen an expert use many of its more advanced capabilities
<korbin[m]>
i use it in basically TCL-only mode for designs ranging from 1-2.5M LUT
<whitequark[cis]>
people like to badmouth it but it's by far the best FPGA toolchain on market right now
<korbin[m]>
100% the best... but i am a software developer - it's awful compared to any modern tooling in other ecosystems
<korbin[m]>
ancient
<korbin[m]>
i would love for an alternative, especially open source, but it's obviously a huge lift
<korbin[m]>
SpinalHDL makes it all a lot nicer
<whitequark[cis]>
it's what we're working towards, yeah
<whitequark[cis]>
there are a lot of difficult milestones there, for example, dealing with abc is a major one
<korbin[m]>
even synopsys punts on P&R iirc back to vivado
<whitequark[cis]>
it's the gold standard in FOSS and even vivado ships a copy of it internally, but it's very ... baroque, and it's not even clear if it's that good
<korbin[m]>
the RapidWright guys at Xilinx are excellent
<korbin[m]>
Chris Lavin and another guy whose name escapes me are killing it with this stuff, next level compared to anything else at xilinx/amd for this space
<whitequark[cis]>
<whitequark[cis]> "it's the gold standard in FOSS..." <- I mean, yes, it wins semi-synthetic benchmarks it shows very good results
<whitequark[cis]>
but it's optimized for writing papers and demonstrating algorithms, less so running a production toolchain
<whitequark[cis]>
for example, abc blows away any and all name/debug information
<whitequark[cis]>
in prjunnamed we keep as much of it as feasible through the entire flow, including our own LUT mapping algorithm
<whitequark[cis]>
i've got a bad taste re: RapidWright after they DMCA'd some stuff from GitHub (which i obviously have found a way to retrieve anyway...)
<korbin[m]>
whitequark[cis]: i got the sense when i spoke to the team that they are being heavily limited by xilinx/amd
<korbin[m]>
they want to publish a lot more than they are being allowed to, for sure
<whitequark[cis]>
i have also got that sense
<korbin[m]>
whitequark[cis]: this is nice - there are a lot of places i'd like to inject scripts into the P&R process or manually resolve things
<whitequark[cis]>
but i'm not feeling very good about working with someone who might suddenly act as an adversary
<korbin[m]>
the chinese FPGA providers have that going for them - they need business, there are multiple entrenched competitors, so they have to compete somewhere
<korbin[m]>
unfortunately both the efinix and gowin skus i care about are vaporware at this point
<whitequark[cis]>
meanwhile, xilinx can do nothing about us doing black box RE
<korbin[m]>
i use zero xilinx IP in all of my designs
<korbin[m]>
i reimplemented the clock wizard, everything
<whitequark[cis]>
yeah
<whitequark[cis]>
i only support Amaranth cores in Glasgow
<whitequark[cis]>
there is support for running the Vivado Tcl flow and you could plug into it to configure their IP if you really wanted
<korbin[m]>
does this go to verilog/vhdl at any point in this implementation flow?
<whitequark[cis]>
* really wanted, in Amaranth
<whitequark[cis]>
in the current Glasgow flow, no Verilog or VHDL is ever used anywhere
<korbin[m]>
that's nice
<whitequark[cis]>
i know right
<korbin[m]>
how many LUTs do you have on that ICE40?
<whitequark[cis]>
that's seven thousand 4-LUTs, you've read that correctly
<korbin[m]>
😸
<korbin[m]>
i think the MMCME4 clock wizard in vivado is over 1k 6LUT
<korbin[m]>
that's crazy small
<korbin[m]>
at that small size there are a million options though, which is nice
<whitequark[cis]>
yep! and yet we're able to achieve a lot even with just that many
<korbin[m]>
more emerging
<whitequark[cis]>
well... not a lot of them with a FOSS toolchain
<korbin[m]>
probably easier to reverse though since 100% greenfield
<whitequark[cis]>
gowin is just about the only one, and the gowin FOSS toolchain is quite immature
<whitequark[cis]>
iCE40 is crazy complicated compared to 7-series
<korbin[m]>
gowin has some very nice stuff on paper, wish i could buy the SKUs with unique features that would make me want to buy them
<whitequark[cis]>
which sounds weird, surely 7-series would be more complex, right? but 7-series is very regular, and ice40 is very, very irregular
<korbin[m]>
can't buy the transceiver chips or those with ARM cores
<whitequark[cis]>
right
<korbin[m]>
same thing with efinix - they are locking the nice ones up for years
<whitequark[cis]>
there's quicklogic with an arm core, but the fabric is so ridiculously slow it's slower than the already unusable ice40 ultraplus
<whitequark[cis]>
i had to go from ice40up5k to ice40hx8k because the up5k part couldn't make the 48 MHz clock of the FX2
<whitequark[cis]>
and all i wanted was to clock in bytes to the FIFO
<whitequark[cis]>
had to clock it down to 30 MHz to get revA working
<korbin[m]>
what is the clock rate on the fabric?
<whitequark[cis]>
on revC we have a 48 MHz CLKIF (USB interface) and for simplicity we mostly run everything off the same clock
<whitequark[cis]>
you could conceivably go up to about 100 MHz on IO if you implement a very simple gearbox before stuff starts to break
<korbin[m]>
the 7 series artix fabric isn't great, 50MHz on a semi-occupied chip is difficult - by comparison, one of my 98% occupied vu9p ultrascale+ designs runs at >1GHz
<whitequark[cis]>
above that you can barely have a small counter run
<whitequark[cis]>
holy shit, 1 GHz? do you have one LUT between each register or something?
<korbin[m]>
whitequark[cis]: yeah, and hand placement
<whitequark[cis]>
also I gotta ask where is it that you work where you casually have vu9p's to throw at a problem?
<whitequark[cis]>
(field)
<whitequark[cis]>
i have watched a friend work with a vu19p on an htg960 and the damn thing has like 120 MB of bitstream alone
<korbin[m]>
whitequark[cis]: my own stuff, crypto/hpc
<whitequark[cis]>
almost inconceivable scale, from my position
<whitequark[cis]>
ah
<korbin[m]>
vu9ps are like $300 new maybe, i have a ton i am looking to sell at this point
<whitequark[cis]>
are you serious? you have $300 vu9p's?
<whitequark[cis]>
you didn't drop a zero there?
<whitequark[cis]>
an htg960 is like $30k new
<korbin[m]>
no, i have never paid $3000 for any FPGA and i probably have 1000 or so at this point
<korbin[m]>
but yeah - nobody pays sticker price for any of these, you can get K420Ts in china for $30ish refurbished
<korbin[m]>
z7010s are around $2
<i509vcb[m]>
oh god the fpga dungeon
<korbin[m]>
FPGA pricing and availability is a massive scam
<whitequark[cis]>
i knew that but i didn't realize they are that low in price
<whitequark[cis]>
since i never had an option to talk to someone who buys vu19ps in bulk D:
<whitequark[cis]>
* in bulk :D
<korbin[m]>
xilinx has to like and approve of what you are doing (i've never bought from them, but know a few folks who do)
<i509vcb[m]>
Are you sure you aren't breaking some sort of NDA (if it exists) for the prices you paid, or do they not care?
<korbin[m]>
new the vu19ps were around $3k i think
<korbin[m]>
i509vcb[m]: i've never bought first-hand and have no NDA with xilinx/amd 😉
<i509vcb[m]>
ah
<whitequark[cis]>
... and if you are in fact breaking an NDA please continue :p
<i509vcb[m]>
I mean if someone on an NDA told what they paid to someone not on the NDA, the person being told has no contractual obligations
<korbin[m]>
i've worked pretty hard to avoid these with xilinx/amd (no IP, no support)
<korbin[m]>
i509vcb[m]: i dont know anyone with an NDA on the *pricing* or sales side - the folks i know with xilinx NDAs were all given source code to something
<i509vcb[m]>
korbin[m]: what bandwidth were you pushing out the flexio just for reference
<korbin[m]>
6-700MHz M7
<whitequark[cis]>
the zynq route, the artix route, the fx2g3/fx5 route, are all interesting
<whitequark[cis]>
* all interesting because they do SS
<korbin[m]>
i509vcb[m]: 60mbit JTAG (limited largely by the target device), i reimplemented the FTDI MPSSE interface
<korbin[m]>
a parallel bus though would be a joke
<i509vcb[m]>
My thought was how possible would it be to do the coresight trace stuff via that
<i509vcb[m]>
or is that still too fast
<korbin[m]>
i don't know how much bandwidth it requires, but if you need to get a chunk of memory out onto parallel pins, flexio will do it at immense speeds without trying very hard
<i509vcb[m]>
Obviously I would need to test the idea
<korbin[m]>
JTAG has a lot of transitions which really eat into your speed
<whitequark[cis]>
by coresight trace you mean the SWO?
<korbin[m]>
TMS twiddling
<whitequark[cis]>
glasgow still needs a much better JTAG core
<i509vcb[m]>
whitequark[cis]: Like the `TRACED[0..3]` pins you see on something like the nrf 5340
<whitequark[cis]>
i've improved the SPI core significantly last summer, the same things could be used to make JTAG like 5 times faster at least
<i509vcb[m]>
I may have the wrong term in mind of course
<korbin[m]>
if you can get it into memory, and the pins don't have bidirectional sequencing constraints, you can put it out at >60 MHz on whatever number of parallel pins
<whitequark[cis]>
yeah i'd say just use a small FPGA like the ice40 to handle bidirectional pins like JTAG
<i509vcb[m]>
yeah the ice40 is already in my BOM
<whitequark[cis]>
glasgow should be able to do more than 60 MHz without too much difficulty
<korbin[m]>
whitequark[cis]: JTAG is a tricky one depending on the interface you want to present, the xilinx JTAG master core is basically "32 bits, N of them are TMS, N are TDI, write read, write read", more sophisticated ones attempt to break down actual things like ShiftDR/ShiftIR
<whitequark[cis]>
what i'm thinking about is using a stream based JTAG core sorta like how i implemented QSPI in Amaranth already
<korbin[m]>
you can do bidirectional turnaround with the flexio, with dma even, very quickly, but you have to make sure the specific patterns match what the IP can do
<whitequark[cis]>
and then you implement the lowest layer of e.g. ADIv5 in gateware
<whitequark[cis]>
everything above that can be most likely formed into packets on the host side and submitted to the gateware over a high latency link like USB
<i509vcb[m]>
yeah and then I can throw my M2 cores at the rest after transport
<whitequark[cis]>
but you really want to not be waiting ~1ms roundtrip latency whenever you need to turn the bus around
<whitequark[cis]>
* waiting ~1ms USB roundtrip latency
<korbin[m]>
i cloned the MPSSE interface for this, there are much nicer APIs
<korbin[m]>
the WCH one is far nicer
<whitequark[cis]>
i'm, of course, relying on the flexibility of reconfiguring the FPGA on the fly
<whitequark[cis]>
like, nothing stops me from building the gateware using the knowledge of the target topology
<whitequark[cis]>
this might actually be required with some JTAG muxes
<whitequark[cis]>
i don't like being restricted by vendor peripherals
<whitequark[cis]>
the idea is not to merely clone what FTDI or WCH did but deliver a fundamental improvement to it
<korbin[m]>
yeah, they are both pretty not good as far as software interfaces
<korbin[m]>
it would be nice if there were a cheap enough FPGA (ice40 is close but not close enough) you could do USB -> whatever on with a glasglow-style bitstream build process
<korbin[m]>
USB HS with ULPI PHYs or bitbanged LS is feasible
<korbin[m]>
(60MHz ULPI is sadly a tall order for most cheap FPGAs, as well)
<korbin[m]>
the Z7010 could be that, by the way - you could have a fully bare metal rust program right next to that $2 FPGA
<korbin[m]>
"only" USB HS, but built-in hard ULPI MAC
<korbin[m]>
the software just isn't there to make it sweet
<whitequark[cis]>
oh i just noticed ch339 has individual TTs
<korbin[m]>
so that would be another cool reason to do it against an inexpensive FPGA like the zynq, transceivers or not - it can actually then be used as a part in other products
<korbin[m]>
you can put the transceivered version in a glasglow, and then use the same IP/code/bitstreams to do USB->whatever in the cheaper non-transceiver zynqs with USB HS only
<whitequark[cis]>
this was the original goal of glasgow, actually
<whitequark[cis]>
a single chip replacement for ft2232 that is Better
Noah[m] has joined #rust-embedded
<Noah[m]>
ohhhh I should tell my partner to bring me the glasgow so I can finally try it out and tinker with amaranth :D
<whitequark[cis]>
then we had some scope creep
<korbin[m]>
the XC7Z010-1CLG400C are ~$1-$2 in CN, and would be the ultimate MCUs if there were embassy support
<korbin[m]>
ARM9 though
<RobinMueller[m]>
I made embassy work for those
<korbin[m]>
RobinMueller[m]: bare metal embassy on the z7000? sign me up
<korbin[m]>
these have an atrocious DDR ballout though, but using them sans DDR or with PSRAM or something would be excellent
<RobinMueller[m]>
I am doing my current development with direct flash via JTAG though, configuring DDR with a ps7 init script. I have not messed around with FSBL und creating a bootgen / boot image yet
<korbin[m]>
i would use these everywhere automatically if i were able to avoid the petalinux side / DDR costs
<korbin[m]>
RobinMueller[m]: this is actually a preferable way to use these
<Noah[m]>
RobinMueller[m]: do you use vivado provided tools or sth oss for that?
<korbin[m]>
Noah[m]: no need for vivado for any of the loading/programming side of things IME
<RobinMueller[m]>
Noah: yes, there is practically no way around vivado
<korbin[m]>
i reimplemented the bitstream flashing routine for the 7 series, ultrascale+ chips etc
<RobinMueller[m]>
Noah: if you want to do something with the FPGA :D
<Noah[m]>
yeah, ok so its the same as 10 years ago, fml
<RobinMueller[m]>
oh wait
<korbin[m]>
no way around vivado for the bitstream generation, but not for the actual use/deployment of the chip
<RobinMueller[m]>
yeah
<RobinMueller[m]>
okay, I use hw_server for that
<korbin[m]>
until Catherine implements a FOSS bitstream flow
<Noah[m]>
yeah back then we used some whacky flash scripts generated by vivado and I was forced to use C
<RobinMueller[m]>
it spawns a GDB server
<Noah[m]>
would love to try with Rust & probe-rs
<RobinMueller[m]>
and then I use gdt-multiarch
<RobinMueller[m]>
I saw that someone made a PR for probe-rs for the arty-z7
<RobinMueller[m]>
I think
<Noah[m]>
yep :)
<RobinMueller[m]>
have not tried that yet
<Noah[m]>
the question is how useable it is :)
<Noah[m]>
Will have to try :)
<Noah[m]>
Maybe they let me get my HW to the hospital :D
<korbin[m]>
let me look at it
<Noah[m]>
because I have time :D
<danielb[m]>
Noah[m]: you justneed a probe-rs server running at home 🤔
<Noah[m]>
danielb[m]: if only I was not a lazy ever-promising-things-he-doesnt-do fuck and set it up already
<korbin[m]>
yeah that looks very straightforward
<korbin[m]>
the z7010s can be done with just two power domains if you dont need 3v3
<JamesMunns[m]>
Let me know if you need a USB comms stack with the zynq as a USB device :D
<korbin[m]>
it's a designware core
<JamesMunns[m]>
If you get embassy-usb working let me know and I'll buy a board to get postcard-rpc working and template projects set up
<korbin[m]>
at $2 these are hyper competitive with basically every equivalently priced MCU for performance
<RobinMueller[m]>
by the way, a question to the fellow vivado users here: how do you deal with the incompatibility of versions to each other? I have a sample project/block design, but it is for Vivado 2024.1. I don't want to update it each half year, for obvious reasons..
<korbin[m]>
RobinMueller[m]: use the TCL flow for everything
<korbin[m]>
i only use the block design stuff for the zynq, i never use it for non-zynq xilinx FPGAs
<korbin[m]>
and even there - i go straight to TCL with it
<Noah[m]>
RobinMueller[m]: never update and ship the development machine to the customer upon delivery :D
<korbin[m]>
their GUI just needs translated to a nicer tool to generate the same TCL
<korbin[m]>
i have like 5 versions of vivado installed
<korbin[m]>
few hundred gigs minimum
<RobinMueller[m]>
korbin: i hate that. Vivado is soo BIG. I don't want 5 versions on my PC 😀
<RobinMueller[m]>
* korbin: i hate that about vivado. it is soo BIG. I don't want 5 versions on my PC 😀
<korbin[m]>
if i were a more casual user i could probably just get away with the most recent version
TomB[m] has joined #rust-embedded
<TomB[m]>
Each Vivado is ~120gb
<TomB[m]>
Wildly big
<korbin[m]>
but i depend on some really specific/high occupancy techniques that dont work in more recent versions in some cases
<TomB[m]>
And why is it so slow for simple small designs… are we in the Vivado grief group? I need one
<korbin[m]>
TomB[m]: it's about zen, you just get used to it
<TomB[m]>
Also why does it not synthesize correctly
<korbin[m]>
200kLUT designs take about 30m for me, end to end
<TomB[m]>
The mysteries are endless
<korbin[m]>
TomB[m]: because you didn't use primitives
<korbin[m]>
there's just no alternative at some point vs. fighting the tool
<korbin[m]>
i use a LOT of primitive SRLs, LUT6s, RAM of all kinds, etc.
<RobinMueller[m]>
I know how this is going to end, I am just going to expose the reference design SDT folder inside a cloud folder, so users can download it and use it for the zynq examples..
<TomB[m]>
It dropped all but a single std_logic signal in a std_logic_vector I had in one design
<RobinMueller[m]>
* zynq examples.. without having to download 2024.1
<TomB[m]>
Baffled me until I looked at the synthesized output
<TomB[m]>
ghdl and quartus worked…
<korbin[m]>
this would strongly suggest "missing wire/dependency" to me and is something that would be caught by modern type-safe HDL tooling
<TomB[m]>
So just a Vivado feature
<RobinMueller[m]>
vivado grief group is good. have you tried doing version control with it? fun times 🫠
<TomB[m]>
I was using vhdl and had all the type safety it provides, verified with two other tools
<TomB[m]>
Only a Vivado fail
<TomB[m]>
It must be powered by Charcot
<TomB[m]>
s/Charcot/ChatGPT/
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
RobinMueller[m]: wait you dont save the project in each step in a new zip file and upload it onto the companys ftp ?
<TomB[m]>
Shared windows drive is the only logical way
<korbin[m]>
TomB[m]: if it's pruning logic, test tools that explicitly instantiate the logic and create a dependency won't typically catch it
<RobinMueller[m]>
vollbrecht[m]: ☠️
<korbin[m]>
it sees a constant optimization or lack of dependency somewhere and culls entire trees of logic
<korbin[m]>
the places i run into issues with vivado are like "i am manually instantiating 2 SRL16CEs into a single LUT" and this behavior breaking in partial implementation randomly in some new version
<korbin[m]>
their IP is also very buggy - so not using any of that helps a lot
<TomB[m]>
There was most definitely dependencies, the signal was tied to pins in the xdc file, believe me I stared at this for like a solid week before trying quartus and seeing it just work on my cyclone board… I haven’t touched Xilinx since I burned all that tinker time on it
<TomB[m]>
Google showed I wasn’t alone in magical bugs in synth
<korbin[m]>
might also be a generation thing - i am using ultrascale+ 99% of the time
<korbin[m]>
not sure if their old stuff is maintained that well between versions
<korbin[m]>
US+ is starting to become unmaintained as well
<TomB[m]>
I used a cyclone iv with the latest quartus. Zero issues. I really with they supported vhdl 2008 though…
<TomB[m]>
s/with/wish/
<korbin[m]>
i am 100% spinalhdl these days - compile to verilog or vhdl
<TomB[m]>
Need a more rust like hdl without needing scala/python/jdk stuff
<JamesMunns[m]>
sooomeone was doing that? I forget the project name
<TomB[m]>
I’d use that
<JamesMunns[m]>
no idea what state it was in, usability wise
<dngrs[m]>
otherwise I think there have been a few discussions over the years in the #esp-rs:matrix.org room
<korbin[m]>
802.15.4 is just 20% of the problem (and the story there across all MCUs in C even isn't great at the moment)
<dngrs[m]>
word of warning, Matter is infested by a weird blockchain thing (I think they just wanted to attract venture capital by inventing a """more modern""" root of trust)
<i509vcb[m]>
Does ZigBee even exist lol
<i509vcb[m]>
I don't hear anything about it
<korbin[m]>
i509vcb[m]: it's in apple products afaik
<korbin[m]>
zwave is nicer for the tasks you use it for, 802.15.4 has the potential to be "cool" if the vendor software stacks and hardware weren't so bad
<dngrs[m]>
it's pretty widespread, e.g. IKEA uses it for their smart home devices
<dngrs[m]>
I use those with a random aliexpress dongle and HomeAssistant (instead of the blessed IKEA hub), works well