<sf-slack2>
<timo.callahan> Ah, my 100t issues are my fault, due to setting XRAY_IOI3_TILES arbitrarily. I hadn't realized that this variable specifies special handling of some 50t tiles because their frame addresses are shifted one frame higher than the rest. No wonder it's messing up the programming for that one IOB. I guess I'm lucky that one of the tiles I chose for XRAY_IOI3_TILES is used in the small tests, so I ran into this
<sf-slack2>
issue right away.
Bertl is now known as Bertl_oO
ZipCPU has joined #symbiflow
kraiskil has quit [Ping timeout: 260 seconds]
<daddesio>
sorry if this has been asked before, but does symbiflow/prjtrellis support the SerDes on the ECP5-5G? I don't see a mention of it on the website, readme, devices.json, etc.
<daddesio>
I need to upload lots of data (~100Mbit) fast (~100Mbit/s) to an ARM microcontroller, and I'm wondering if that could be realistic with symbiflow in the near future. :)
<daveshah>
It's supported but experimental
<daveshah>
But it wouldn't be any use for that case, it's minimum data rate is 270Mbit/s
<daveshah>
At 100Mbit/s regular IO maybe with a DDR primitive would be the way to go
<daddesio>
have you successfully used Lattice's DDR/PCIe/ethernet cores?
<daveshah>
No, they are encrypted with a stupidly expensive license
<daveshah>
LiteX has open source DDR3 and Ethernet cores for ECP5
<daveshah>
There isn't a working open source PCIe core yet
<daddesio>
in my case I'm thinking of DMAing the data via DDR3, so my FPGA would be like a "peripheral" or slave device, then send an interrupt to the ARM chip once the upload is done
<daveshah>
DDR3 is working nicely with litedram
<daddesio>
I'll look into LiteDRAM/LiteX, thanks.
<zyp>
oh, I had the impression that litepcie already supported ecp5
<daddesio>
(aside: the i.MX6ULL ($10 ARM SoC) has an on-chip DDR3 controller. hopefully it will play nicely :p)
<daveshah>
zyp: no, it doesn't, it relies heavily on the Xilinx hard PCIe IP
<daveshah>
daddesio: oh do you want to use the ECP5 to emulate a DDR3 memory? that is not something litedram supports
<daddesio>
no no, just upload lots of data (about 1GB collected over 1 second) *somewhere* the ARM chip can access at a way later time.
<daddesio>
(it's more like 1 GiB, not 100Mbit like I said before, now that I think about it)
<daveshah>
Does the ARM chip have an Ethernet PHY interface like RMII or similar?
<daveshah>
That can be connected "crossover" to a similar interface on the ECP5 to emulate an ethernet link between the two (and you can use raw ethernet frames, no need even for UDP)
<zyp>
imx6 would probably have RGMII
<daddesio>
I've never heard of RMII
<zyp>
daveshah, guess I shouldn't be in a hurry to do that m.2 board with ecp5 that I've been thinking about then :)
<daddesio>
and, it doesn't necessarily have to be an i.MX, it's just the first ARM chip I happened to find that has DDR3 support
<zyp>
daveshah, why DDR3?
<zyp>
daddesio*
<daddesio>
it doesn't have to be DDR3, I just thought it would work as an option since the ECP5 Versa supports it :p
<daveshah>
Shared DDR3 probably isn't a very good idea
<zyp>
shared DDR3 is probably very unfeasible
<daveshah>
I suspect it may work at low speeds if you were careful with the termination, but probably not at full speed
<daveshah>
And you'd need to find a way to turn off the iMX6 DDR3 interface totally while the FPGA accessed it (in particular stop the iMX from driving the CA lines) which may or may not be possible without causing other problems
<daddesio>
erm, I thought the DDR3 controller would have taken care of bus mastering. I guess the DDR3 controller is *just* a transceiver then?
<zyp>
DDR3 is not designed to be shared between multiple masters
<daddesio>
I must be thinking of PCIe then ?
* daddesio
has never read the DDR/PCIe specs
<daveshah>
PCIe is definitely not designed to be shared either
<daddesio>
> DDR3 is not designed to be shared between multiple masters
<daddesio>
I intended for the FPGA to be a slave, and the ARM chip to be the master
<zyp>
daveshah, apples and oranges
<lambda>
daddesio: how should the FPGA and MCU communicate?
<daddesio>
maybe I should take a step back now
<daddesio>
my FPGA is a logic analyzer that will collect about 1GiB of data over the course of 1 second. I'd like to save it somewhere, then do post-processing on it via an ARM chip (or maybe my laptop)
<litghost>
PCIe cannot be "shared", but there are ways to endpoint to endpoint communication setup via a master
<litghost>
e.g. DMA from a NIC to disk or vise versa
<daddesio>
there's no realtime requirements other than the data collection itself. I can be as slow as I want to process the data.
<zyp>
daddesio, in that case you'd connect the DDR3 memory or whatever directly to the fpga, and then use some other interface to read it out via the fpga
<zyp>
you could drop the arm chip and collect the data from your laptop via e.g. ethernet or usb3
<lambda>
if you have USB3 you might even get away with streaming everything at 5Gbps, no memory required
robert3 has joined #symbiflow
robert3 is now known as rw1nkler
OmniMancer has joined #symbiflow
OmniMancer1 has joined #symbiflow
OmniMancer has quit [Ping timeout: 272 seconds]
<daddesio>
alright, I admit it, that is a much easier solution. only downside is I need twice the memory (1GiB for the fpga and 1GiB for the host), but the benefit is the fpga has guaranteed low-latency write access to the DRAM. (the ECP5 only has about 468KiB of internal RAM so doesn't afford much room for jitter)
<daddesio>
instead of waiting around for its turn to master the (pcie) bus