<simeonm>
However, it sounds like he solved it by installing some redhat dev package. Going to figure out what that means.
m_hackerfoo has quit [Ping timeout: 260 seconds]
HackerFoo has quit [Ping timeout: 260 seconds]
HackerFoo has joined ##openfpga
m_hackerfoo has joined ##openfpga
<simeonm>
For anyone following my sad monologue: I installed gcc-8 and friends, and now my simulation doesn't compile ;-)... I suspect due to my verilator being relatively old.
emeb_mac has quit [Ping timeout: 240 seconds]
emeb_mac has joined ##openfpga
<simeonm>
Ok Verilator 4.036 + gcc-8 worked, no TLS linking error (have not re-tried gcc-7)
Degi has quit [Ping timeout: 260 seconds]
Degi has joined ##openfpga
Bird|otherbox has quit [Remote host closed the connection]
Bird|otherbox has joined ##openfpga
bubble_buster has quit [Ping timeout: 265 seconds]
rohitksingh has quit [Read error: Connection reset by peer]
m4gul0_ has quit [Read error: Connection reset by peer]
mithro has quit [Read error: Connection reset by peer]
emilazy has quit [Read error: Connection reset by peer]
marex-cloud has quit [Read error: Connection reset by peer]
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined ##openfpga
Asu has joined ##openfpga
mumptai has joined ##openfpga
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
Bike has joined ##openfpga
Maylay has quit [Ping timeout: 240 seconds]
Maylay has joined ##openfpga
<felix_>
i wonder how the usb is implemented in the quickfeather devboard; the chips datasheet doesn't mention usb
<tnt>
felix_: it's in the fpga fabric
<felix_>
ah. so 12 mbit/s only i guess. but still a very interesting chip :)
<zyp>
most microcontrollers only integrate FS PHYs anyway, so that shouldn't be overly limiting
<tnt>
zyp: did you receive the board btw ?
<zyp>
no, but with the whole covid fucking up international shipping at the moment I don't really expect to see it for another week or three anyway
smkz has quit [Quit: smkz]
smkz has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
oeuf has joined ##openfpga
emeb_mac has joined ##openfpga
<felix_>
true. for the application i had in mind it does though
<zyp>
if the fabric is fast and large enough, I guess you could hook up an external ULPI PHY instead
<zyp>
probably not relevant for the quickfeather itself, but something to consider if you're making your own board with that chip
<felix_>
a chip with usb2, microcontroller and fpga would also be something interesting for something glasgow-esque. i mean what i want to do could just be accomplished with a glasgow, but looked into haing a few manufactured and it didn't seem to worth the hassle to do that myself; waiting for it to become available is easier ;)
<felix_>
*having
<zyp>
I've also been interested in a hybrid mcu+fpga for a long time
<zyp>
looked into smartfusion for a project years ago, but something about it turned me away, don't remember what
<felix_>
yeah, and a zynq or whatever intel calls their arm+fpga chips often is quite a bit of an overkill
<zyp>
ended up with a stm32 with a spartan3a hooked to the external memory bus, and then the entire project died off because I got tired of dealing with ISE
<zyp>
then again, with the current abundance of risc-v softcores, the need for a hard cpu is reduced
<felix_>
for one design ended up using an atsam3u and the smallest spartan6, but ended up wanting to do a zynq-based redesign, but before that happened the project died
<felix_>
some processor in the fpga doesn't solve the bootstrapping problem though. being able to revover a device from whatever state without the need for an external programmer is something i want to have in a product
<zyp>
I'd argue that a microcontroller is as brickable as a fpga
<whitequark>
this is why glasgow uses an fx2
<whitequark>
you can't brick an fx2; the worst thing you'll ever have to do is to disconnect the EEPROM
<zyp>
well, that's not really what I meant
<whitequark>
felix_: you can write a gold bitstream to the FPGA flash and then write-protect it
<zyp>
what I meant was that just like a microcontroller often can recover by having a bootloader, so can a fpga
<whitequark>
ah, yeah
<zyp>
i.e. what you just said
<whitequark>
not all FPGAs can have bootloaders, but you can usually hack around it
<zyp>
doesn't matter as long as the one you pick can :)
<whitequark>
yep
<zyp>
which ones doesn't?
<zyp>
I'm aware of some being more limited than others in switching between images, but not of any that doesn't support multiple images at all
<tnt>
zyp: the fabric on the S3 is small and slow btw ...
<tnt>
felix_: there are some gowin fpga with embedded arm core and HS PHY built in.
<zyp>
with a hard usb core as well, I assume?
<tnt>
No
<zyp>
huh
<tnt>
just the PHY AFAICT.
<tnt>
But that's just based on the small product description ... I didn't bother reading the doc, you need an account to download and I couldn't be bothered since you can't buy those anywhere anyway and AFAIK the open toolchain has no support for those advanced features either.
<zyp>
hmm, 2400 LCs, how do they compare to e.g. ice40 LCs?
<tnt>
They;re LUT4 too so can't be too different I guess.
<felix_>
write-protecting a golden bitstream is a good idea
<zyp>
it's pretty much equivalent to what a microcontroller that's always recoverable through a rom bootloader is doing
<felix_>
stm32f042 are basically unbrickable due to their rom bootloader that iirc even speaks DFU
<zyp>
yes
<zyp>
apart from stm32f1, I think every usb-capable stm32 has a DFU-capable bootloader
<zyp>
I also prefer rolling my own instead of using it
lambda has quit [Quit: WeeChat 2.8]
lambda has joined ##openfpga
mumptai has quit [Quit: Verlassend]
Asuu has joined ##openfpga
Asu has quit [Ping timeout: 260 seconds]
Asuu has quit [Client Quit]
Asu has joined ##openfpga
Asu has quit [Ping timeout: 246 seconds]
awordnot has quit [Read error: Connection reset by peer]
awordnot has joined ##openfpga
<TD-Linux>
I'm surprised we haven't seen more microcontroller+fpga for power electronics / motor control yet. that's a relatively common discrete combination for more expensive stuff
<TD-Linux>
cheap stuff uses asics or things like stm32's built in motor control timers. which are absurdly complex yet still obnoxiously inflexible
<agg>
Have you tried the HRTIM some of them have? It dials up the absurd complexity all the way to 11
<agg>
But it's been able to do pretty much everything I've wanted entirely in the hardware
<agg>
Especially combined with internal dac and comparators
<TD-Linux>
the HRTIM is really cool, but obnoxiously it can be used only for output, not measurement, which limits the utility a bit for me. also at higher resolutions the number of bits in the counter becomes really small. annoying if I want to operate at lower frequences
<TD-Linux>
I can of course use a normal timer to trigger the hrtimer in that case but it's even more complex
<TD-Linux>
there's also been a few FAULT constraints I haven't been able to express with the way the comparators can be wired
<agg>
iirc it can be used for capture but you don't get all the LSbits when running at high clock multipliers
<agg>
But all the subtimers do have capture registers