genii has quit [Quit: Morning comes early.... GO LEAFS GO!]
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
____ has joined ##openfpga
OmniMancer1 has joined ##openfpga
OmniMancer has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Ping timeout: 260 seconds]
emeb_mac has quit [Quit: Leaving.]
Asu has joined ##openfpga
____2 has joined ##openfpga
____ has quit [Ping timeout: 264 seconds]
rohitksingh has joined ##openfpga
anuejn_ is now known as anuejn
mickdermack has quit [Ping timeout: 258 seconds]
Sinclair2 has joined ##openfpga
Ultrasauce has quit [Quit: No Ping reply in 180 seconds.]
Ultrasauce has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
cpresser has quit [Ping timeout: 256 seconds]
Bike has joined ##openfpga
<agg>
if i'm hooking an fpga (ice40) up to a microcontroller's external memory bus (stm32), would i be mad to use the asynchronous sram mode, and just have the fpga basically pretend to be an sram?
<whitequark>
how fast does it have to be?
<agg>
basically the same as the 8080/6800 mode
<whitequark>
if the async SRAM signals are much slower (think 4x slower) than FPGA's clock it should be pretty easy to get it to work
<agg>
hmm... I'd like it to be reasonably quick but my actual _requirement_ is pretty low
<agg>
the stm32 is running at 168MHz, the fpga core will probably be 100MHz, the stm32 can configure whatever latency is needed for the "sram"
<agg>
it's a 16 bit bus and i'd like to transfer at least 50Mbps
<whitequark>
if you access the "SRAM" at 25 MHz it should not be much of an issue
<whitequark>
if you want to access it at a higher rate i would suggest looking into a less hacky solution
<agg>
25MHz still gets me 400Mbps which is probably more than enough, hm
<agg>
the synchronous access modes on the stm32 seem to require very many clock cycles per access
<agg>
but I think can support a burst of multiple consecutive accesses after the setup is done, which might be better overall
<agg>
glad to hear it's not totally silly to pretend to be an sram
<whitequark>
well, your main problem is doing a clock domain crossing safely
<whitequark>
but if the FPGA clock is much faster than the minimum pulse width of the asynchronous bus, you can just use good old 2FF synchronizers
<agg>
in this case the same xo is feeding the fpga pll and the stm32 pll, so that might help a little too?
<whitequark>
not really
<agg>
i might be able to have the stm32 generate a clock while doing asynchronous access, so at least could use that to drive the fpga clock domain
<whitequark>
yes, that would actually help
<whitequark>
it's a bit tricky, but it can potentially provide you with much higher performance
<agg>
i was imagining using a bram in the ice40 to transfer data between the clock domains
<agg>
so the fpga would write into a bram which the stm32 can read from, and vv in another bit of address space
<whitequark>
yes, an async FIFO based on BRAM is the usual solution
<whitequark>
but ice40 BRAMs are all synchronous
<whitequark>
so you need some clock on the interface side
<agg>
yea, so either need to feed it with the fpga's own clock and 2ff the inputs, or i could feed it with a clock from the stm32?
<whitequark>
yes. in the latter case, there is still an issue, which is phase
<whitequark>
i.e. you might end in a situation where FPGA IO registers would capture at the same time STM32 output drivers set up the new value
<whitequark>
so you have to carefully check the timings to make sure the phase is right, and possibly adjust it via some means (PLL on iCE40 is one posibility, capturing on the other edge also is)
<whitequark>
and then there's the same issue on STM32 sie
<agg>
hmm
<agg>
I think the stm32 accesses are well defined wrt rising/falling clock edges, though a bit annoying to have the fpga do some things on the rising edge and some on the falling
<agg>
i will have a look at the timing diagrams
jfcaron has joined ##openfpga
cpresser has joined ##openfpga
OmniMancer1 has quit [Quit: Leaving.]
<zyp>
agg, I did something like that some years ago
finsternis has quit [Remote host closed the connection]
<agg>
zyp: ah cool! do you remember what fsmc mode you used/which pins you connected?
<agg>
from further reference manual research i think i can use the synchronous mode without the wait pin (which i need for another function and doesn't make sense for this anyway) and it should actually work kinda nicely
<agg>
and should let me run the fpga clock domain from the stm32's generated clock, do burst read/write, etc, at probably 80MHz
<zyp>
yeah, I just looked through it, looks like I've got the wait pin hooked up but not used
<zyp>
on the fpga side, I made some glue code between the FSMC signals and a wishbone master port
<agg>
so addr+data+clk+nadv+noe+ndw+ne(+nwait), with the fsmc in PSRAM mode or something?
<agg>
the wait pin is to support psrams that might be in the middle of a refresh when you access them so they have to stretch the latency, aiui, which isn't applicable here
<agg>
but it looks like it can just be ignored, so that's fine
<zyp>
https://paste.jvnv.net/view/H6Tqj <- this is probably not very good code, I think it was the first time I even touched migen :)
<agg>
hehe, my first migen project is a huge mess too
<agg>
it does a GUI with text rendering and touchscreen
<agg>
total spaghetti mess of nested if/elif/elif/elif forever
<agg>
more interested in your stm32 side of things though, i think the fpga side should be straightforward since i'm just going to some bram
<agg>
not much to it at all! thanks, i will see what those bits are doing
<zyp>
I'm abusing bank 2 in 8 bit mode to feed the bitstream to the fpga in parallel mode
<zyp>
and then bank 3 to actually talk to the fpga
<agg>
oh cute
<agg>
my current plan is to have an spi flash which the stm32 can master to update, or the ice40 reads at boot to configure
<agg>
with some care about not having them both master at the same time
<agg>
just to avoid having to have the stm32 do any fpga configuration really.. but i haven't fully fleshed out the details
<agg>
(the stm32 can hold the ice40 in reset whenever it masters the flash, and it can hi-z its own spi when it's not, so seems like it should work out)
<zyp>
yeah, that should work fine, that's probably what I'd do on a standalone board too
<zyp>
but in this case the fpga was on a module to go on a devboard; feeding the bitstream from the host over usb was good enough, no onboard storage needed
<agg>
makes sense
<zyp>
the FSMC also has registers to control timing, they default to slowest possible settings, so it's not necessary to touch them to make it work
<zyp>
and I never got around to actually doing anything useful with that board, I ran out of patience dealing with Xilinx ISE
<ZirconiumX>
I think mwk would agree with you there
<mwk>
... heh
<ZirconiumX>
I mean, my own lack of patience with Quartus is why Yosys has a new Intel frontend :P
emeb1 has joined ##openfpga
<whitequark>
until there was a foss toolchain i more or less refused to properly learn fpgas
<whitequark>
was not worth the effort
<whitequark>
vivado is almost okay though, even though it's awful
<agg>
migen lowered the activation energy enough that i could use altera tools in entirely command line mode and just pretend they were a slow compiler
emeb has quit [Ping timeout: 260 seconds]
<agg>
but these days the foss toolchain on ice40/ecp5 makes them such a fun choice for lots of problems
emeb1 has quit [Client Quit]
<whitequark>
yup, i don't have nearly enough patience for verilog, hence i work on nmigen :)
<agg>
yes, learning verilog was the main boring activation energy
<agg>
only have so much room for cursed languages
<whitequark>
i don't find verilog boring. i find it rage-inducing
<sensille>
:)
<agg>
that is a more apt description, yes
<ZirconiumX>
I tolerate Verilog at arm's length, and avoid it in my own code
<agg>
i just read other people's huge verilog files and it's like 10000 lines for something that could be about 50 lines of python metaprogramming
<whitequark>
it's not even metaprogramming
<agg>
sure, but i like it when it is :p
<whitequark>
after understanding how verilog does width and signedness i want to print a copy of the manual and then immediately set it on fire
Sinclair2 has left ##openfpga ["Bye Bye"]
<agg>
hah
<ZirconiumX>
agg: As of today you can use Yosys as a Quartus frontend, and let *me* deal with the ugly Verilog bits instead :P
<whitequark>
i can't believe verilog-2005 literally does not have a cast operator
<agg>
ZirconiumX: is that functionally different to using nmigen to generate a build script that just runs quartus for me?
<agg>
i appreciate not having to deal with verilog and also your work on yosys, for sure
<agg>
but not sure what advantage having a yosys frontend gets me
<agg>
(mostly thanks to nmigen insulating me from everything below the rtlil, heh)
<ZirconiumX>
Direct RTLIL synthesis, and no warning spam
guan has quit [Ping timeout: 245 seconds]
<agg>
hah, the warnings is probably worth it alone
<agg>
i am tempted to get back to doing some cyclone soc stuff, people complain about zync a _lot_ but the intel ones were ok in my limited experience
<ZirconiumX>
And - potentially - RAM initialisation that won't take yonks
<qu1j0t3>
whitequark | after understanding how verilog does width and signedness // please tweet this so i can RT it lol
<agg>
but intel stuff seems generally less popular (with foss people?)
<agg>
(i had a DE0-nano and then DE0-nano-soc as my first fpga boards, so..)
<ZirconiumX>
agg: Yeah, I don't quite get that
<ZirconiumX>
But wq's got an Intel board, and I have an Intel board, so we'll get there eventually :P
<whitequark>
I have... two I think?
<agg>
zync looks dire, the intel socs seem fine, so why aren't they popular... probably some good/cursed reason
<ZirconiumX>
Oh yeah, you have the Cyclone III right?
<whitequark>
i definitely have the CIII board
<ZirconiumX>
(I wonder why they're still in production)
<whitequark>
and i might have CV board?
<whitequark>
let me check my pile of boards.
<ZirconiumX>
The DE0-CV right?
<mwk>
... I think I have a Cyclone II somewhere
<mwk>
or, uh, my uni has
<qu1j0t3>
i kind of want to use my Cyclone I out of pig-headedness.
<ZirconiumX>
Granted, in the process of this I have learned that Intel cheaped out on the flops
<whitequark>
yup i have both
<ZirconiumX>
So we have the rare instance of the iCE40 improving on the Cyclone V
<ZirconiumX>
(and quite likely the Cyclone 10GX, I think)
<daveshah>
iCE40 improves over ECP5 in terms of I/ODDR latency too
<ZirconiumX>
agg: Another benefit I just discovered: if your RAM init file is too small, Yosys pads it with zeroes, while Quartus replaces the RAM with zeroes
<ZirconiumX>
Thus effectively optimising out ROMs
<agg>
haha, sigh
<agg>
vendor toolchains: not even once, I guess
OmniMancer has joined ##openfpga
OmniMancer has quit [Read error: Connection reset by peer]
Bird|otherbox has quit [Remote host closed the connection]
<daveshah>
nextpnr on 1.7MLUT6s should be a few months of fun :D
<whitequark>
wow
<daveshah>
I'm hoping the pinout is the same as the VCU1525
<daveshah>
otherwise actually using another other than the fabric will be a massive pita
<daveshah>
Ah, I think it was renamed the Alveo U250
emeb_mac has joined ##openfpga
<daveshah>
and the U250 is the same as the VCU1525
<daveshah>
*same pinout
<daveshah>
so basically it is just a VCU1525 with a chonkier FPGA and more cooling
OmniMancer has joined ##openfpga
jfcaron has quit [Ping timeout: 258 seconds]
Asu has quit [Remote host closed the connection]
<levi>
I've got an original Cyclone dev board; unfortunately I think the FPGA on it is dead. I have a product dev/breakout board from a couple of employers ago that uses a Cyclone and still seems to be working, though.
mickdermack has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
<kc8apf>
LLHD seems to be turning into something almost usable