cr1901_modern has quit [Read error: Connection reset by peer]
jcreus has quit [Ping timeout: 248 seconds]
lexano has quit [Ping timeout: 248 seconds]
futarisIRCcloud has joined ##openfpga
lexano has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Client Quit]
Jybz has quit [Read error: Connection reset by peer]
Jybz has joined ##openfpga
Asu has joined ##openfpga
OmniMancer1 has joined ##openfpga
OmniMancer has quit [Ping timeout: 272 seconds]
AndrevS has joined ##openfpga
cr1901_modern has joined ##openfpga
flea86 has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Jybz has quit [Quit: Konversation terminated!]
emeb has joined ##openfpga
vonnieda has joined ##openfpga
lexano has quit [Remote host closed the connection]
<Sprite_tm>
Hm, does anyone know if trellis supports the USRMCLK macro?
<daveshah>
Probably, but I haven't tjoroughly tested it
<Sprite_tm>
I can instantiate it, but I get an error: ERROR: No wire found for port USRMCLKI on destination cell usrmclk_inst.
<daveshah>
Is your nextpnr up to date?
<Sprite_tm>
Perhaps a month old methinks... but I can update.
<daveshah>
Think I fixed that just within a month or so
<Sprite_tm>
Check :) Ah, I see nextpnr supports multiboot now?
<daveshah>
Yep, ecpmulti should be able to do that
<Sprite_tm>
Ah, another question I had: I think you're the major maintainer of the ecp5 stuff, right? Is there somewhere I can buy you a crate of beer or so?
<Sprite_tm>
(And/or reel of FPGAs, pallet of lemonade, whatever)
<Sprite_tm>
As in: do you accept donations?
<daveshah>
Don't have anything like that atm. But if you work for a company doing HDL stuff, a massive favour would be to put in a good word for https://www.symbioticeda.com/seda-suite
<daveshah>
This is the best way to support this stuff
<Sprite_tm>
I'll certainly keep it in mind.
<Sprite_tm>
Not sure if I can convince our digital team, but I can at least try.
<Sprite_tm>
Perhaps I can, once I finally get around to the pipe dream of designing some FPGA fabric to go inside our chips...
<Sprite_tm>
Ah awesomesauce, it routes now. Thanks!
<daveshah>
Great! Hopefully it works on hardware (I tested it was working with an LA but haven't got round to trying full SPI flash access yet)
<Sprite_tm>
I'll tell you once I have the USB bit working... Trying to port the TinyFPGA USB bootloader to the ECP5 using the open-source toolchain.
<daveshah>
Very nice
<Sprite_tm>
Well, it's giving me bupkins on the USB interface atm, but at least it
<Sprite_tm>
's not b0rking out in the compilation phase.
<Sprite_tm>
Ugh, I don't feel like porting ice40 stuff to the ecp5, though. For now I'll keep this one.
<Sprite_tm>
It's gonna be an when-all-else-fails-and-you-don't-have-jtag bootloader anyway.
<whitequark>
i think you can write a portable USB bootloader with nMigen
<whitequark>
(because it has a platform layer that abstracts things such as DDR IO)
<Sprite_tm>
I'm sure, but I have reasons to keep everything verilog-only. Don't want a hacker working on this to need to start learning 24 tools before being able to tinker.
<whitequark>
the obvious solution is to get rid of verilog entirely.
<tnt>
Sprite_tm: yeah at some point I'll port mine to ecp5, there is really not much, mostly just the IO, the RAM (because yosys fails at inferring them like I want) and 1 register (because yosys keeps "optimizing" into something dumb if I don't manually do the FF)
<whitequark>
tnt: hm, what are the RAM and register yosys bugs? have you filed them?
<tnt>
whitequark: They're not bugs, what it produces actually "works" (as in, implements what's described).
<tnt>
For the RAM, yosys doesn't use the built-in "width-change" supported by the hardware.
<tnt>
(i.e. you can configure the ram to be 16 bit wide on write and 2 bit wide on read)
<whitequark>
ahhh, asymmetric ports
<tnt>
Instead it will use muxes / gating ...
<tnt>
which works ... but when you try to meet 48 MHz on a UP5k, I can't affort that layer of logic.
<tnt>
For the register ... huh, let me recheck what yosys does with/without that hack. I think it was something similar where it would do something that's maybe 1 LUT smaller ... but higher logic depth.
<tnt>
which bits maps where is a nightmare on the ice40 :p
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 272 seconds]
<whitequark>
huh that's a mess
<Hoernchen>
less weird than the gsm l1 power levels..
<tnt>
Oh yeah, the issue with the register is yosys "creating" registers with sync set/reset .... which I don't like because that creates different control sets.
genii has joined ##openfpga
lexano has joined ##openfpga
<whitequark>
ah I see
<tnt>
Ah, but remembering a twitter post by daveshah I see I can avoid that by using state & { WIDTH{~in_first} } instead of in_first ? { WIDTH{1'b0} } : state
rohitksingh has quit [Ping timeout: 268 seconds]
wpwrak has quit [Ping timeout: 272 seconds]
azonenberg_work has joined ##openfpga
emeb_mac has joined ##openfpga
wpwrak has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
Asu` has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
rohitksingh has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
<emeb>
tnt: so you got DFU functionality working in your riscv/usb project?
<tnt>
emeb: yes
<emeb>
nice
jcreus has joined ##openfpga
<emeb>
need to catch up with that. I got the earlier test version working on my board (the one that just enumerated)
<tnt>
Now that's what I using on the icebreaker-bitsy to flash it :)
rohitksingh has quit [Ping timeout: 245 seconds]
<emeb>
tnt: excellent - that's pretty much what I've been waiting for. Something to bypass the need for an external spi programmer.
mumptai has joined ##openfpga
<emeb>
although I do like having my own usb/spi gizmo because it programs directly to the up5k RAM w/o needing to touch the flash.
<emeb>
a bit faster and easier on the write endurance...
<tnt>
In the end I have a 'stub' that boot by default which does nothing but test the button. If it's not pressed, it immediately boots image 2. If it's pressed then it will by default boot the USB DFU firmware, but if you release/repress it fast enough (withing 1 s IIRC) you can actually select between each 4 images which one you'd like to boot.
<emeb>
Cool - I was reading through that but hadn't quite grokked the overall effect.
<emeb>
Multi-boot is a nice-to-have.
<emeb>
So with that arrangement you get a) the initial stub, b) the DFU image, and c) & d) can be any "application" images.
<tnt>
yes
<emeb>
and if you combined the initial stub with the DFU image then presumably you could have 3 application images.
<tnt>
technically it could even have been a) the dfu image b/c/d) User app images. Because the boot image can be != from the 4 images you can WARMBOOT to.
<tnt>
I couldn't find a good way to combine them ...
<tnt>
because the user image need to be able to reboot in "forced" DFU mode ... and I can't pass any info across a warmboot.
<emeb>
I see
OmniMancer1 has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
gsi__ is now known as gsi_
rohitksingh has quit [Ping timeout: 245 seconds]
_whitelogger has joined ##openfpga
ym has joined ##openfpga
emeb has quit [Quit: Leaving.]
emeb_mac has joined ##openfpga
ym has quit [Quit: Leaving]
Jybz has joined ##openfpga
emeb_mac has quit [Ping timeout: 246 seconds]
ondrej3 has quit [Ping timeout: 272 seconds]
ondrej3 has joined ##openfpga
cr1901_modern1 has joined ##openfpga
<tnt>
Anyone know a good simple USB-PD + QC controller ? Something where it would tell me what voltage it wants, I provide it and it provides it to the device ...
cr1901_modern has quit [Ping timeout: 245 seconds]
<whitequark>
cypress ez-pd?
<tnt>
I'll have a look, thanks.
oeuf has joined ##openfpga
vonnieda has quit [Read error: Connection reset by peer]
vonnieda has joined ##openfpga
jcreus has quit [Quit: Konversation terminated!]
Asu` has quit [Quit: Konversation terminated!]
AndrevS has quit [Remote host closed the connection]
mumptai has quit [Quit: Verlassend]
Bike has joined ##openfpga
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<TD-Linux>
anyone know if it's possible to use paste to solder the GCP 16pos usb-c connector?
<TD-Linux>
*GCT
Jybz has quit [Ping timeout: 258 seconds]
gnufan_home has joined ##openfpga
emeb_mac has joined ##openfpga
<Zorix>
TD-Linux, afaik all surface mount in factory is done with paste, but i personally would just use a lot of paste flux and drag solder if doing by hand
<Zorix>
though i dont know the connector you are referring to
<Zorix>
hot air might be the only viable option if the pins are under the connector