<bubble_buster> is that metal fill?
<bubble_buster> the slightly diagonal pattern of wide rectangles with kinda rounded corners
Sellerie1 has joined ##openfpga
mangelis has quit [Ping timeout: 240 seconds]
tms_ has quit [Ping timeout: 240 seconds]
ym has quit [Ping timeout: 240 seconds]
mangelis has joined ##openfpga
Sellerie has quit [Ping timeout: 240 seconds]
Sellerie1 is now known as Sellerie
tpw_rules has quit [Ping timeout: 252 seconds]
tpw_rules has joined ##openfpga
ym has joined ##openfpga
tms_ has joined ##openfpga
genii has quit [Quit: Time for beer and hockey.]
Bike has quit [Quit: Lost terminal]
Jybz has joined ##openfpga
m_w has quit [Ping timeout: 268 seconds]
parataxis has quit [Ping timeout: 246 seconds]
OmniMancer has joined ##openfpga
m4ssi has joined ##openfpga
<pepijndevos> daveshah, what would be the correct way to cite project trellis? (in bibtex)
<pepijndevos> (any project x-ray if anyone knows)
<daveshah> pepijndevos: ^
<daveshah> This is what I've used in the past
<pepijndevos> alright
Asu has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Ping timeout: 240 seconds]
ym has quit [Ping timeout: 250 seconds]
ym has joined ##openfpga
<daveshah> I'm sure it had a purpose once, but I don't know
<daveshah> I would advise against copying the deduplication code from Trellis. I don't think it's anywhere near the best approach
<daveshah> Going through a flat database to produce a deduplicated one is not really optimal
<OmniMancer> hmmk
<OmniMancer> what alternatives are reasonable?
<daveshah> I would probably look at using pips for wires connected between tiles and have wires per tile only rather than merging tiles
<daveshah> That way you only need to store tile types; and different combinations of bounding tile types
<daveshah> Otherwise I'd just do a flat database and think about deduplication later
<daveshah> The Trellis approach is not worth using imo
<OmniMancer> hmmk
<OmniMancer> I suppose flat is probably not too unweildy at only 41x72 tiles for the largest device in the family
<daveshah> No, it's not great in the long term but it's better than wasting time on poor deduplication
<OmniMancer> so would having pips for the inter tile wires allow just not connecting them to anything on the edges so the tile can be the same everywhere?
<daveshah> Yes
Asu has quit [Remote host closed the connection]
<OmniMancer> I suppose that would also allow me to keep the (n|s|e|w)N(beg|mid|end)N naming for the pips/intra tile wires and just have a pass to add the connecting wires and the ones that hang off the edge just won't have any drivers
<OmniMancer> hmmm, where would one put those wires though
Hamilton has joined ##openfpga
<OmniMancer> hmmm, I will finish sorting the routing graph then I think
<OmniMancer> daveshah: does the trellis db try making a flat DB then deduplicating the tiles that are identical if co-ords are relativised?
<daveshah> yes
<OmniMancer> would it be okay to make up wires that don't really exist as long as they have no drivers?
<daveshah> Yeah, it doesn't even matter if they have drivers (if they have drivers they would very slightly slow routing though)
<OmniMancer> Since I expect a pip expects a valid input wire?
<daveshah> Yes, it does
<OmniMancer> I mean for the inter tile wires, when you get to the edge you'd start having pips that attach to wires that either don't exist or go somewhere other than the usual place
<daveshah> Yeah, they need to connect to a wire but it doesn't need to be a useful one
<OmniMancer> Is the nextpnr trellis db import code tied to the deduplicated nature of the db?
<daveshah> Yes
<daveshah> The iCE40 code is an example for a flat database
<OmniMancer> Should I try to get the RoutingGraph working in libtang first?
<daveshah> Yeah, probably a good start
<OmniMancer> Oh, does it make sense to have multiple bels in a location that are mutually exclusive?
<daveshah> Yes
<daveshah> the validity checks (checkBelLocationValid and isValidBelForCell) can deal with effectively arbitrary constraints
<OmniMancer> so like a bel for the whole slice, one for just the FF, just the LUT, one that overlaps with 3 of them for the DPRAM?
<daveshah> No, I wouldn't do that
<OmniMancer> ah okay
<daveshah> in that case I would have bels for the finest granularity cells only
<daveshah> and use relative constraints for macros like DPRAM
<daveshah> I would probably have one bel for (LUT+carry+one LUT unit of DRAM) and one bel for the FF
<OmniMancer> ah
<OmniMancer> so one BEL for the "logic" part and one bel for the FF part?
<OmniMancer> what would apply the relative constraints?
<daveshah> The "packing" step
<OmniMancer> so packing would not pack anything, just apply rules for how they could be placed?
<daveshah> although ECP5 uses a coarser granularity, it's the same idea to combine three SLICEs for DRAM https://github.com/YosysHQ/nextpnr/blob/master/ecp5/pack.cc#L1038-L1053
<daveshah> yeah basically
<daveshah> it would also do things like convert cells to a common type etc
<OmniMancer> so would the synthesis produce a DPRAM cell and the packer produces the several cells actually required for this?
<daveshah> yeah
<OmniMancer> and adders would be carry chain cells?
<daveshah> yes
<daveshah> and you would also relatively constrain the chains themselves in the packer too
<OmniMancer> yes
<OmniMancer> daveshah: is the binary format used for the trellis db capable of representing a flat db?
<daveshah> OmniMancer: yes, it could be
<sorear> Please think hard about compile time memory usage with whatever you do
<sorear> A big recurring complaint with Trellis is that it’s hard to build on things like rpi ultimately because of the way deduplication is designed
pie_ has quit [Ping timeout: 265 seconds]
<whitequark> what if we made it easier to cross-compile instead
<sorear> wouldn’t that require rewriting it in a different language
<sorear> normal people can’t set up a crossgcc and configure a sysroot
<tnt> but why would you want to use it on a rpi ... ice40, fine, compile time are not too large. But non trivial designs on a ECP5 will take forever on a rpi.
<daveshah> You don't even need to cross compile
<daveshah> just copy the bba files
<tnt> daveshah: 32b/64b is not an issue ? I guess just LE/BE might be.
<whitequark> tnt: if people are ok building nextpnr for 20 hours they are probably ok running it for minutes
<daveshah> tnt: the bba files are totally arch independent
<gruetzkopf> hm, i am next to my powermacg5 this evening
<daveshah> They are the slow part
<daveshah> The bbasm part depends on endianness only
<gruetzkopf> i should build for ppc64be
<tnt> oh yeah, .bba right, not the .bin
<tnt> whitequark: just one more evidence I don't understand "people" I guess.
<daveshah> I mean I've got nextpnr to build a blinky for ECP5 on an ECP5
<daveshah> It took about 15 minutes but that was almost entirely waiting for a slow nfs rootfs
<tnt> daveshah: sure, as a tech demo. I'm assuming it's not your daily workflow.
<daveshah> No
<daveshah> But I can see someone doing fairly small designs and only having an ECP5 board
<daveshah> On an RPi it shouldn't be too slow
<OmniMancer> daveshah: are the things in Bels.cpp in libtrellis actually used at all anymore?
<daveshah> Yes
<daveshah> They create the bels that are ultimately imported to nextpnr
<OmniMancer> ah yes I see now, I was searching wrong
Hamilton has quit [Quit: Leaving]
m4ssi has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<OmniMancer> Oh in regards to compile time memory usage, I don't think anyone would have a good time compiling libtrellis on an rpi
genii has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
m4ssi has joined ##openfpga
<eddyb> wow I didn't realize how flexible this chip was https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf#page=9
<eddyb> you could just... hook it up to some ancient 8-bit CPU?! maybe even an ISA bus or something
<whitequark> it's also overpriced, buggy, and comes with a vendor that hates your guts
<eddyb> feels kinda silly to use it for just basic UART
<eddyb> whitequark: heh, the only reason I'm looking at the datasheet is because it's on the iCEstick
<whitequark> you can't quite hook it up to ISA because it's not 5V tolerant
<whitequark> but yes, it's more flexible than just an USB-UART
<whitequark> for the latter you can use CP2102, which is very cheap and much simpler
<eddyb> nice
<whitequark> that said, a pure USB-UART doesn't let you bitbang the FPGA's programming port
<eddyb> Lattice, I don't think this is a block diagram... https://www.latticesemi.com/icestick#_128A360799DA425689D8C242595BAB56
<eddyb> or I guess it is in the sense that a graph with no edges is still technically a graph
<whitequark> lol
<eddyb> *downloads manual* `icestickusermanual (4).pdf`
<eddyb> I wonder if anyone made an extension to just force the browser to ignore forced downloads, especially for file types that can just be displayed in the browser
<eddyb> wait that one doesn't seem to work?
* eddyb doesn't really understand why Lattice are so proud of IrDA
<whitequark> because they put a huge IR LED driver on the die and now have to convince people to use it
<eddyb> wait the TX side is driven from inside the FPGA?!
<whitequark> the Ultra series has various LED drivers inside the FPGA, yes
<whitequark> one of them (not UP; I think UL?) can put over 400 mA into the IR LED
<whitequark> the FPGA on icestick does not have any dedicated LED drivers though
<daveshah> Pretty sure at least one also had hard IR remote decoding
<daveshah> This was I think for smartphone remote control emulation
<daveshah> Another intended use for the high current driver was barcode emulation
<whitequark> the UP5K devboard has an RGB LED driven directly from the FPGA
<eddyb> okay that would be fun to play with but I don't think I have access to any device with a remote, other than maybe the coworking space TVs hmm
<whitequark> if you turn it on with like assign rgb = 3'b111 it blinds you
<whitequark> 24 mA into one of modern high-power LEDs = more power than your retina is prepared to take
<whitequark> high-efficiency*
<eddyb> heh I was going to suggest that RGB might make more sense than IrDA in this day and age but then I was like "what would all that power go into, blinding yourself"
m4ssi has quit [Remote host closed the connection]
<daveshah> the irony is the main use was smartphone notification LEDs
<daveshah> Which probably run at a fraction of an mA
<eddyb> lol
<whitequark> a lot of the time watching vendors decide on features to include feels like watching brownian motion
<eddyb> I'm surprised we even do notification LEDs that way anymore (although I guess there might be a dedicated chip off-SoC that can handle all of the blinking or whatever?)
<daveshah> Oh if anyone wants evening TV and hasn't seen this yet
<eddyb> hmm has anyone played with making the notification bar more like an e-ink thing, separate from the main display?
<whitequark> the lattice FPGA is that chip
<whitequark> or some other vendor's
<eddyb> whitequark: oh I thought everyone used dedicated Texas Instruments ones or w/e
<whitequark> and yes, having a tiny LCD on the oter side with just notifications has been a thing on flip phones
<whitequark> it'd be transflective or OLED or something
<eddyb> I was thinking more that with e-ink you'd be able to get away with having it on all the time, which might be convenient
<whitequark> flip phones mostly predate eink
<eddyb> although I guess people are starting to get smart watches for that purpose anyway
Johnny_Mnemonic has joined ##openfpga
<whitequark> but yes, this idea has been implemented somewhere, i'm pretty sure
<daveshah> Some OLED phones can keep part of the screen on permanently for notifications
<eddyb> whitequark: well yeah I was thinking more of the 16px/32px tall android notification bar :P
<daveshah> Not sure what the battery life impact of this is though
<eddyb> daveshah: wait wh- oh right it's a goddamn matrix
<daveshah> Guess a lot of the screen driver stuff needs to stay on
<anticw> daveshah: some phones had a second (usually lower power) display as well, i think some maybe still do
<whitequark> I wonder if they have panel self-refresh maybe?
<daveshah> Yeah, I guess they do
<whitequark> I think by this point phones use eDP
<daveshah> But all of that logic and the OLED power supply needs to stay on
<daveshah> MIPI has panel self refresh (command mode) too
<daveshah> And partial updated
<daveshah> *s
<eddyb> for some reason I thought DP had partial updates for a while and then I saw the PSR/eDP stuff and now I'm mostly confused
<daveshah> I haven't looked for a year or so but haven't ever seen an eDP phone
<daveshah> All MIPI DSI, sometimes with compression and/or dual link
<anticw> are there any robust open mipi (dsi) cores out there?
<daveshah> Haven't looked recently, I tried writing one a few years ago but didn't get that far
<anticw> it seems there are quite a few neat bits of hw to play with if you can work out how to drive it
<daveshah> Indeed
<eddyb> but I think if you get an DP2 display you can do partial updates to it to get 4K @ 60Hz without using enough bandwidth to do full frame-buffers (think cursor updates at 60Hz, or even higher, but a large image wouldn't change that fast - it would still take less than a second though, you just couldn't game or w/e on it)
<daveshah> Part of the problem is dphy being a bit of a pain to interface with
<daveshah> Need a resistor network that then causes signal integrity issues
<anticw> mikeselectricstuff showed sorta you can drive the ipod nano displays with some effort and those are cheap and pretty cute
<daveshah> Yeah, at lower frequencies the resistor network type tricks are fine
<anticw> i don't think he did that
<daveshah> Not sure how well they'd scale to the fancy smartphone displays etc
<eddyb> (one of the things that I kind of want to try if someone makes a board I can easily hook up to both PCIe and DP is make the barest-bone-iest virtio-gpu device)
<anticw> iirc he used a buffer with some tolerance to get the signals to shift into high speed mode
<daveshah> Interesting, I remember the video at the time but it was a while ago
<anticw> daveshah: did you have access to dsi spec or draft at one point?
<eddyb> I was looking at the intel integrated GPUs out of curiosity and it looks like nowadays the (e)DP output is in the CPU and everything else is handled in the PCH, which makes me sad about the proliferation of HDMI, because it's just overhead
<eddyb> anyway I was trying to figure out how the FPGA is hooked up to the FTDI on the iCEstick
<eddyb> page 17 in the manual shows RS232 and SPI, and I'm guessing the SPI is for programming?
<eddyb> oh, following pages have schematics, thank goodness
<eddyb> page 18, {A,B}CBUS is not connected at all, ADBUS is in MPSSE mode, and BDBUS is in RS232 mode
<daveshah> anticw: yeah, I found a leaked copy in a Google search
<eddyb> this feels a bit wasteful, aren't there simpler chips they could've used?
<whitequark> devboards are generally wasteful
<whitequark> the UP5K one uses a voltage regulator with like 1 mV ripple
<whitequark> that costs something like ten dollars each, instead of a usual jellybean 3.3v/1.2v part
<eddyb> would make more sense if they somehow made it possible (e.g. via extra soldering) to take some of the FPGA pins and use them for faster communication
<eddyb> but AFAICT there's no traces coming out of the pads for the disconnected FT222H pins
<eddyb> sorry, I'm just bitter I found out about all of these features and I don't get to use them :P
<eddyb> > RS232/RS422/RS485 UART Transfer Data Rate up to 12Mbaud. (RS232 Data Rate limited by external level shifter).
<eddyb> does this mean that I've been limiting myself to 115200 for no good reason?
<whitequark> you can get it to work at least at 1 Mbps I think
<whitequark> 3 might work
<eddyb> is the board not designed well enough for 12 or something?
<whitequark> it's a few things
<whitequark> first, beyond 1 Mbps, drivers start being annoying
<whitequark> second, it depends on your UART implementation
<whitequark> if your FPGA clock is 12 Mbps you can't get it to run an UART at 12 Mbps too
<eddyb> right
<whitequark> you have to oversample by at least 2 times, 3 is more realistic
<whitequark> probably more like 4
<whitequark> so, 3 Mbps.
<eddyb> there's a PLL you can use to pick a higher clock on the iCEstick iCE40, right?
<whitequark> yes
<whitequark> with the PLL you'll be limited by the FTDI chip and the IO buffers
<whitequark> in general I'd say beyond ~20 MHz you have to really start thinking about how the interfaces really work electrically, timing-wise, etc
<whitequark> but below that you can usually just halfass it and it works ok
<eddyb> okay that was easy, 1Mbps just works with my existing code
<eddyb> at least for FPGA -> host
<eddyb> whitequark: so does 3 and I can't go faster because of your `assert divisor >= 4` :P
<whitequark> right
<eddyb> I get lovely garbage if I try 4M with that commented out
<whitequark> I think my implementation specifically requires a factor of 4
<whitequark> I don't remember exactly why but that assert is there for a reason lol
<eddyb> it is the same garbage every time, which makes it mesmerizing and it's not sending ANSI escape codes so that's nice
<eddyb> <3 asserts
<eddyb> whitequark: wait, is the 12MHz default clock literally a FTDI thing?
<whitequark> sorta, it's cheaper to put one oscillator on board than two
<whitequark> and USB clock is often derived from 12 or 24 MHz
<eddyb> and configuring the PLL isn't as easy as just plugging in a frequency somewhere, is it?
<whitequark> almost as easy
<whitequark> you can probably grab get_pll() and make f_in, f_out, idomain, odomain normal arguments
<eddyb> so this SB_PLL40_CORE is a primitive that has to be instantiated, and nmigen doesn't by itself understand it?
<eddyb> I think this is what I was missing to complete the picture
<whitequark> yes
<eddyb> thanks :D
<eddyb> whitequark: can I refer to the default iCEstick clock as `ClockSignal("clk12")`?
<whitequark> no
<whitequark> there's no direct correspondence between domain names and clock signal names
<whitequark> the default domain is "sync" but you can omit that
<whitequark> so just ClockSignal()
pie_ has quit [Ping timeout: 276 seconds]
<eddyb> idk why I bothered doing this by hand (well, I've never configured a PLL before so I was curious), but I think that `divr=0, divf=63, divq=4` give me 4x clock speed, and the only reason I even need a divf that large is the 533MHz min f_vco
indy has quit [Ping timeout: 240 seconds]
Bob_Dole has joined ##openfpga
<eddyb> whitequark: oh, looking at this, `.i` on the resource is how I get access to the default clock https://github.com/m-labs/nmigen/blob/master/examples/board/02_domain.py#L11-L17
<eddyb> to feed the PLL
<whitequark> ClockSignal() is just fine for this, too
<eddyb> but I want to hook that up to the PLL output
<whitequark> ah yeah
<eddyb> wait for the 4Mbaud test I forgot to change the stty command....
<eddyb> > stty: invalid argument ‘12000000’
<eddyb> oh you have to be kidding me
<eddyb> well, the PLL works at 4Mbaud :D
<eddyb> whitequark: okay I don't get garbage with the 12MHz clock and commenting out your assert, at 4Mbaud, I just had to tell stty as well...
<eddyb> and I can't test higher than that because it doesn't even accept 6000000 :(
<eddyb> whitequark: looks like these are all the non-POSIX baud rates linux supports :| https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/termbits.h#L144-L159
indy has joined ##openfpga
<whitequark> like i said, drivers become a problem past 3M
<whitequark> 1M is the last one that works semi-reliably
<eddyb> yeah I was just hoping I could at least tell the driver what I want :(
<daveshah> seems that BOTHER might work
<eddyb> anyway, at least now I know what the situation looks like
<eddyb> BOTHER just looks like the bit that non-POSIX baud rates have
<TD-Linux> fun fact, the syscalls for setting custom baudrates are different based on which arch of linux you're on
<eddyb> oh what okay I misunderstood gravely
<eddyb> daveshah: thanks, that makes a lot of sense
<gruetzkopf> hehe, sparc should be especially bad there iirc
<TD-Linux> e.g. on ppc there isn't a TCGETS2, only a TCGETS which already supports arbitrary rates
<whitequark> aaaargh
<TD-Linux> this means I can't build a lot of software that uses USB serial on ppc, because it uses TCGETS2
<whitequark> why :(
<eddyb> OH
<eddyb> `ispeed 6000000` instead of just `6000000` works
<daveshah> ah
<daveshah> useful to know
<eddyb> wait does it actually do anything
<TD-Linux> (I should probably send a patch to lkml sometime that just adds TCGETS2 as an alias on ppc)
<eddyb> s/it works/it doesn't error
<whitequark> hm, I can simulate Minerva with cxxrtl at 1.5 MHz if I cheat a bit and treat it as fully synchronous apriori
<whitequark> not sure if that's good or bad
<daveshah> Sounds pretty much in line with Verilator tbh (I've head around 1MHz max for CPUs)
<daveshah> but those were probably a bit more complex than Minerva
<eddyb> uhhhh so my office internet died
<whitequark> okay, cool
<eddyb> looks like the FTDI chip doesn't reset so I can't test this correctly without changing the baud rate in the nmigen
<eddyb> so that a mismatch is actually visible as garbage
<_florent_> whitequark: yes that seems very similar to verilator, i generally get around 1MHz for a simple SoCs (CPU + ROM + RAM)
<whitequark> if I enable full delta cycle tracking then it becomes 0.5 MHz
<whitequark> but you can simulate multiclock designs just fine in that mode
<whitequark> or ones with derived clocks
<eddyb> okay so `ispeed N` does do something, but I'm unconvinced that it actually takes effect if I use a larger value
<whitequark> the FTDI chip might not be able to use arbitrary divisors
<eddyb> 3Mbaud in the FPGA, told it 5M, no error it just kept it unchanged
<eddyb> same for 6M or 12MB
<eddyb> s/B//
<eddyb> > stty: /dev/ttyUSB1: unable to perform all requested operations
<eddyb> this is new
<gruetzkopf> which ftdi is this
<eddyb> anyway 4M does take effect, making my 3M output from the FPGA turn into garbage
<eddyb> the one on the iCEstick, 2232H I think
<eddyb> it advertises 12M max
<eddyb> this API is too silly, if I use `ispeed N ospeed N` and then check `speed` it's still stuck at `38400` :|
<eddyb> oh it does that even `stty 4000000` so `stty speed` is just useless
<eddyb> *even after
<eddyb> not even sure why I keep wasting time on this but ugh
<eddyb> so it will just silently fail. thanks, GNU
<eddyb> it works at 6M :D
ZipCPU has quit [Excess Flood]
<eddyb> whitequark: your UART also works at 6M with the assertion commented out :D
ZipCPU has joined ##openfpga
<eddyb> maybe the problem is the RX side? my test is "Hello world!" TX'd to host roughly every second
<eddyb> or maybe longer bursts would show issues idk
<eddyb> aaand it works at 12M too. no PLL. amazing :D
<whitequark> hm
<whitequark> that's probably because the FTDI clock is synchronous to the FPGA clock
<whitequark> so by definition there's no skew or drift
<whitequark> it's not really U"A"RT anymore
<eddyb> USRT
<whitequark> sort of yes
<eddyb> whitequark: presumably the programming interface relies on this more?
<whitequark> afaik no
<whitequark> but i'm not sure
<eddyb> well it's convenient nevertheless :D
<eddyb> finally a good thing about this board :P
<whitequark> i'm not sure if you can actually rely on it
<eddyb> right, this is nowhere near a stress test
<whitequark> nextpnr doesn't guarantee you any specific skew between clock and uart input
<eddyb> so it also helps that this design is super simple
<whitequark> yes
parataxis has joined ##openfpga
<eddyb> > Info: ICESTORM_LC: 479/ 1280 37%
<eddyb> I would probably have to configure the block RAM as ROM if you wanted a larger blob
<eddyb> but this is getting silly at this point
pie_ has joined ##openfpga
<anticw> does anyone have a source/link for cheapish ecp5 dev boards?
<eddyb> can I disable the mouser nonsense that asks me for my location every single time I go to it?!
<eddyb> or did I Just have to press the "accept cookies" button :|
<eddyb> oh I don't think I've ever seen the bottom of this board https://ro.mouser.com/datasheet/2/225/FPGA-EB-02017-1-0-ECP5-Evaluation-Board-1633766.pdf
<eddyb> arduino and raspberry pi, cute
<TD-Linux> this will also be good when it comes out (timeline unknown) https://www.crowdsupply.com/radiona/ulx3s
<TD-Linux> I built my own
<anticw> yeah, that's the only one i could find sorta-cheap that was stocked as well
<anticw> perhaps i'm being unrealistic wanting it to cost less
<daveshah> I mean for the number of LUTs it's not a bad deal
<daveshah> I don't think anything on the horizon will be significantly cheaper
<eddyb> I still think the SERDES count for the Versa is wrong
<eddyb> why can't I have something like this but for ECP5 https://www.crowdsupply.com/rhs-research/nitefury
<TD-Linux> anticw, I have a spare LFE5UM I could sell you
<TD-Linux> I think it's a 45 not 85 but would have to check
<eddyb> there's also https://picoevb.com/
<TD-Linux> not ecp5?
<eddyb> yeah they're both artix :(
<anticw> i have a strong preference to ecp5 because of tooling right now
<anticw> eddyb: that's cute, but for testing/experimenting it's sometimes nice to have a more minimalist, often that means w/o the ftdi on them (many people have box of such cables)
<eddyb> the picoEVB is also super expensive
<eddyb> like why wouldn't I just get a versa at that point?!
<anticw> maybe they have parts left over from something else?
<eddyb> actually that's 4x, the versa is 1x hmpf
<whitequark> 4x?
<eddyb> x4 oops
<eddyb> erm the PicoEVB isn't, the NiteFury is
<eddyb> it also has 4 times more LUTs, but still the same family
<eddyb> anticw: so in terms of experimenting with protocols, I feel like I'm going in the opposite direction from a lot of other people, because I'm seeing opensource boards being built to exploit the LUTs on ECP5, but not the SERDES
<eddyb> that's pretty much what I want, + SERDES
<eddyb> actually, does that one even have any SERDES? it doesn't say
<eddyb> there's something about those connectors that's really pleasing for some reason https://alchitry.com/collections/all
<sorear> USRT or at least USART is a specific thing with a specific definition that isn’t just “UART w related clocks”
<sorear> eddyb: remember that a Lattice SERDES is a Xilinx transceiver, and a Xilinx SERDES is something unrelated
<eddyb> f u n
<sorear> terminology hell is a thing here
<anticw> eddyb: isn't that more that tinkering/low-end has less of a need for SerDes vs say simpler logic?
<anticw> once more (and cheaper) boards will supported toolchains become available that will change
<eddyb> so "GTP 6.6Gb/s Transceivers" is the SERDES equivalent
<eddyb> apparently it has 4 huh
<sorear> yes
<sorear> Lattice has 3.3 and 5 Gb/s
<eddyb> (the one on the Alchitry Au should have 4 of those, I mean)
<eddyb> at this point I'm wondering if anyone has made just SERDES boards and whether that even makes sense
<eddyb> anticw: sure, that makes sense
<anticw> it would be interesting to see lattice or someone make some part# available at really-low cost to make some sort of rPi prices fpga board to get wider adoption, i'm surprised one of the vendors hasn't considered this already
pie__ has joined ##openfpga
russell-- has quit [Ping timeout: 268 seconds]
russell-- has joined ##openfpga
russell-- is now known as Guest19254
<sorear> anticw: lfe5-12f is $5 @ 1 and most of the ice40s are lower than that
<sorear> the cost of the chip is not an obstacle for a rpi range eval board
<anticw> sorear: yeah, i have some of the cheaper ice40s ... the 384 lut version though lacks pll and internal oscillator so limited use
pie_ has quit [Ping timeout: 268 seconds]
<sorear> there’s only so much interest I have for a chip without BRAMs
<sorear> when you can get one with for Literally A Single Dollar
<anticw> sorear: rpi0 is $5 i think? it would be really hard to make anything to sell at that price point
<eddyb> this is a p neat one
<eddyb> but then there's a $560 eval board for it, lol
<sorear> anticw: the “pi price point” discourse is old enough that I generally assume people mean $35
<whitequark> let's not forget that rpis are open hardware in name only and primarily serve as reputation laundering for broadcom
<anticw> yeah sorry, i mean $10 or less so they are basically disposable without thinking hard, for $35± there are some options but i'm more annoyed when the magic smoke escapes
<daveshah> Well upduino was that kind of price point
<anticw> whitequark: oh sure, they also have probably very high volume ... but there conceptually is no reason lattice if they wanted to get some visibility because gowin is looking to eat their low-end couldn't support/help making some ecp5 boards at a much better price
<daveshah> Unfortunately the price didn't include a reliable pcb layout (I think the second revision is a bit better at the expense of being pricier)
<anticw> daveshah: v1 has weird pcb layout
<whitequark> "weird"
<anticw> daveshah: right, there is a v2.0 and i think i v2.1 from someone else (name reused?)
<daveshah> Yeah
<anticw> whitequark: bad signal integrity wrt to ground iirc
Guest19254 is now known as russell--
<whitequark> "totally broken" is a more accurate description
<daveshah> When I did the UltraPlus support in icestorm the upduino was the only readily available up5k board
<eddyb> daveshah: Q_Q I was googling something and one of the results was https://twitter.com/fpga_dave/status/1067479449980100608
<daveshah> I spent half a day wondering why the PLL was acting up and checking bitstreams
<daveshah> Of course it was the shitty pcb layout
<daveshah> Adding a load of capacitors did fix it
<anticw> i don't know if any connection to the previos
<anticw> meh ... *u
<anticw> daveshah: the decoupling cap for the spi flash on the tinybga bx is close enough to the package ... if you aren't careful when using a tsop-8 clip ... and are dumb like me ...
<anticw> eddyb: the last comment i saw about that was he got busy with life so not eta on the 'ex
<sorear> rpi is sold below cost iirc, it’s not just volume
<whitequark> yes
<TD-Linux> yeah I wish lattice had better devboards for ecp5. the evm is kind of weird
<daveshah> I would imagine the SoCs are free for the RPi to start with
<eddyb> okay so AFAICT, I should just wait for the TinyFPGA EX and hope that someone makes some adapters for miniPCIe and/or DisplayPort
<eddyb> if I want to play with that stuff
<whitequark> rpi started out as a way for broadcom to liquidate inventory of ancient crappy SoCs no one wanted
<eddyb> i.e. forget about FPGAs for a few months
<eddyb> the other thing that's pissing me off is how expensive ExpressCard to miniPCIe adapters are (probably due to ExpressCard dying out)
<eddyb> but I guess I should be thankful they exist at all :P
<gruetzkopf> the rpi soc was made for the same thing the steamlinks "marvell berlin" soc was made
<gruetzkopf> streaming TV boxes slaved to a central Cable TV STB
<eddyb> is there no external PCIe availability on laptops post-ExpressCard other than Thunderbolt?
<whitequark> correct
<whitequark> Thunderbolt is even more expensive
<whitequark> or, you could be gruetzkopf and solder a few wires
<eddyb> lmao
<anticw> those broadcom SoCs are (or were) used in lots of devices
<anticw> i think some sold into asian markets in pretty high volumes
<TD-Linux> eddyb, you also have a hackerspace right? you could take it as an opportunity to get a reflow oven :)
<eddyb> no I don't
<daveshah> Oh cool Radiant 2.0 has just been released with support for the first new lattice part
<gruetzkopf> bga deep frying is the nicer process
<daveshah> called CrossLink-NX and 40k LUT4s
<daveshah> 10 mins early :)
<eddyb> all I have is an overpriced 30m^2 office
<TD-Linux> daveshah, spoilers aaa
<TD-Linux> disappointing spoiler though ;_;
<TD-Linux> the ulx3s was the first bga I did and I got it right on the second try
<anticw> using a reflow oven?
<TD-Linux> yes
<TD-Linux> well second try replaced the bga using hot air
<anticw> not bad ... i have avoided bga as much as possible but it's becoming the only option for just about everything
<TD-Linux> first try almost worked but missed a couple of balls to ddr
<eddyb> at least the new guy finally set up the 3D printer we've had since August
<anticw> that and wlcsp
<eddyb> tiby was paranoid about chinese brass containing lead or something like that
<eddyb> and he never ended up doing anything with it until he left us
<anticw> are you eating it?
<TD-Linux> I think the cycle was just a bit too short because I had set it up for less loaded boards
<eddyb> ... no
<eddyb> not even eating the plastic being printed
<TD-Linux> even american brass is usually 2% lead
<daveshah> guess it's time for
<daveshah> is this the fastest launch bitstream doc project ever :D
<whitequark> :D
<TD-Linux> -6 minutes nice
<TD-Linux> why oxide?
<eddyb> wait is this an entirely new product line?
<TD-Linux> because of fdsoi?
<eddyb> this is what I get for not being on twitter I guess :P
<azonenberg> eddyb / TD-Linux: almost all brass is a bit of lead
<daveshah> TD-Linux: yep
<zkms> daveshah: :D
<eddyb> azonenberg: he wanted to replace the nozzle with a steel one
<eddyb> azonenberg: but to do so you have to heat up the hot end so he just never did it lmao
<sorear> I’m still disappointed that my suggestion of “diffraction” = “studying lattices using x-ray methods” was not well received
<whitequark> ha
<TD-Linux> really digging this music
<TD-Linux> I think it's at least 2x hold music quality
<TD-Linux> >1 in stock
<anticw> qfn
<TD-Linux> who's doing it
<eddyb> why is this a google result
<eddyb> well, the only google result
<daveshah> fuck they've encrypted the sim models
<daveshah> so wave goodbye to ever using vendor models with incarus
<daveshah> *icarus
<whitequark> do you need help with that
<whitequark> let me grab newer radiant
<daveshah> you have to scroll down to see the 2.0 link
<eddyb> why is that only on the South African Digi-Key?!
Jybz has quit [Quit: Konversation terminated!]
<whitequark> is latticesemi.com down
<daveshah> yes
<daveshah> maybe we all killed it
<gruetzkopf> looks like it
<gruetzkopf> my download froze
<whitequark> did ... did i scare the website into hiding
<TD-Linux> the stream is still giving me the awful music
<eddyb> what's this stream?
<TD-Linux> eddyb, it's on american digikey too
<anticw> saw that, $34ish
<eddyb> TD-Linux: but google can't find it, did they fuck up robots.txt on .co.za?
<TD-Linux> probably just not indexed yet
<TD-Linux> given it was probably added minutes ago
<eddyb> oh lol
<eddyb> I guess it doesn't say how recent it is
<daveshah> 40k LUTs in QFN72 is interesting
<gruetzkopf> also pcie is quite hard to mess up
<eddyb> first other google result
<daveshah> bitstream format is pretty similar to ecp5, cool
<eddyb> what does "hardened" mean here? turned into hard IP?
<gruetzkopf> for the germans here "Der geldschrank liegt schon am boden" "Noch ein schnitt und er ist offen"
<feuerrot> gruetzkopf: "Kuchenblech ist das!"
<anticw> daveshah: how do you know what the bitstream is like?
<eddyb> it keeps making me think of radiation hardening or the software thing
<daveshah> anticw: I downloaded radiant 2.0 before the website crashed and created a bitstream
<anticw> ah, gotcha
<eddyb> I wonder if they have taken USB4 into account in their plans :P
<TD-Linux> yes it means hard IP
<anticw> presumably it's in the pipeline for upcoming products like everyone else? but how much need/demand is there right now
<anticw> usb 3.x gen y (i can't keep up) exists at 20 Gbps already
<TD-Linux> does it actually have no general purpose serdes?
<whitequark> does lattice have 10 Gbps SERDES anywhere?
<eddyb> oh right USB doesn't let you have lower bitrates does it now...
<whitequark> it does
<whitequark> but then you don't need to implement any of the USB4 PHY parts
<daveshah> TD-Linux: looks like it has hard PCIe, DPHY and SGMII at a glance
<emily> where's this announcement stream I presume people are watching?
<emily> latticesemi.com seems down
<emily> "You are not registered for the current event. Please check your email for the specific date and time of the event." really...?
<eddyb> whitequark: right, I was thinking specifically of USB4 w/ lower-speed PCIe
<whitequark> what?
<whitequark> USB4 can encapsulate PCIe TLPs, but it doesn't have much to do with PCIe PHY
<daveshah> 12 bit 1MSPS ADC
<TD-Linux> is the ADC new to?
<daveshah> yes
<TD-Linux> nice
<daveshah> copied from Xilinx balatantly
<eddyb> you still have to use the USB4 bitrate even if your PCIe TLPs could go over the lower PCIe bitrates
<adamgreig> it has 32373 LUT4s and they're calling it 40k?
<daveshah> *blatantly
<daveshah> adamgreig: yeah just noticed that
<adamgreig> quite a cheeky rounding-up
<TD-Linux> same for the 36 bit multiplier (unless that was in ecp5 I forget)
<anticw> 9 * 11 * 109
<TD-Linux> 32256 luts is the number to factor I think
<TD-Linux> 32373 is count of registers including IO registers
<TD-Linux> guess they are going to heavily emphasize the MIPI bus
<cr1901_modern> adamgreig: Same shenanigans for ice40 8k parts, which have ~7600 LUTs
<adamgreig> that's much better (95%) than this (80%) though :p
<eddyb> hmm, for the stuff I want to do that isn't protocols, the only reason to want SERDES is data transfer rates to an accelerator, so it might make more sense to take some RISC-V core and clock it slower than the actual accelerated logic
<TD-Linux> cr1901_modern, you can technically round that up though
<eddyb> and/or just have enough RAM to work on
<TD-Linux> I wonder if I could use SERDES to implement the high precision timer/pll I was wanting the other day
<eddyb> at that point the larger ECP5's are probably overkill (other than allowing doing more of the same in parallel)
<TD-Linux> daveshah, do they just have 2x timing models for that body bias setting?
<cr1901_modern> TD-Linux: touche :P
<daveshah> TD-Linux: not sure
<daveshah> TD-Linux: they have "high performance" and "low power" modes
<daveshah> I've just ordered one of the samples from digikey
<daveshah> Looks like they've got better multiboot than ice40 or ecp5 - the multiboot primitive just takes a 32-bit SPI address
<daveshah> so you could have almost an unlimited number of bitstreams
<TD-Linux> can't wait to poke a pin into my crosslink to overclock the body :^)
<daveshah> ah, product page is up now
<TD-Linux> daveshah, very nice combined with their claimed faster boot
<whitequark> poke a pin?
<adamgreig> i guess NX is for nexus and there will be more -NX
<TD-Linux> whitequark, to touch the bottom of the die
<adamgreig> but what an unwieldy name
<TD-Linux> doesn't roll off the keyboard quite like ecp5
<TD-Linux> also nx makes me sound like I'm talking about a nintendo
<daveshah> Oh, the sim library is encrypted because it's literally the verilog from the standard cell library
<eddyb> ChangeLog: add NX bit to bitstream
<daveshah> it has files like "C8T28SOITV_LRV_LSOUTX32_P0.v"
<gruetzkopf> ooh
<daveshah> So they must have literally just shipped post-synth verilog instead of writing sim models
<TD-Linux> from... [pause] Intel
<tnt> Is that QFN72 dual row ?
<daveshah> No I don't think so in the end
<daveshah> 10x10mm
<adamgreig> if nothing else, ~40k gates in a normal qfn would be really nice
<daveshah> Yeah
<tnt> yup seems normal. Too bad it doesn't have pcie.
<eddyb> so I just looked at the icebreake specs and they're really good for the kind or hardware accelerated stuff I want to play with
<eddyb> and it seems like it doesn't neuter the FTDI chip?
<adamgreig> what are you hoping to hardware accelerate with an up5k?
<tnt> neuter ?
<daveshah> I wonder if xobs could do an uber fomu with the wlcsp72 package
<daveshah> 3.7 x 4.1 mm
<TD-Linux> can't wait for my usb port to boot Linux
<daveshah> (only the 17k in that variant)
<daveshah> omg this gem in the datasheet explains the 40k thing
<daveshah> 1. Logic Cells = LUTs x 1.2 effectiveness.
<daveshah> it's super effective
<TD-Linux> that's a lot of pins for a wclsp isn't it?
<adamgreig> oh my god
<adamgreig> marketing factor of 1.2
<adamgreig> that still only gets it to 38707 "logic cells"
<xobs> They do claim its low power... I wouldn't want to try a xilinx in a USB port, even if it fit.
<eddyb> tnt: 16 lines of the 2232H are just not connected to anything on the iCEstick
<eddyb> forcing you to max 12Mbps
X-Scale` has joined ##openfpga
<tnt> eddyb: Well you can't go much higher on the icebreaker.
<eddyb> also yeah you wouldn't accelerate anything realistic, but it feels decent for prototyping something. other than simulation :P
<tnt> eddyb: Fastest is SPI at ~ 30 MHz.
<eddyb> tnt: the specs mention 480Mbps but it might be misleading
X-Scale has quit [Ping timeout: 240 seconds]
<eddyb> it might refer to the FTDI FIFOs
<tnt> The PC to the FTDI is 480 MHz ...
X-Scale` is now known as X-Scale
<eddyb> oh well
<tnt> but then you need to get the data to the ice40
<eddyb> it has multiple parallel modes, I still need to check the schematic
<eddyb> maybe it's hooked up the same as on the iCEstick :/
<eddyb> the block diagram does write UART nvm
<tnt> Through solder jumper on the back you can connect it for "245 FIFO Async" mode.
<tnt> But that mode really only allows maybe 100 mbits.
<eddyb> it's what I was hoping for on the iCEstick
<TD-Linux> annoyingly about half the i/os are 1.8v max
<TD-Linux> I guess that's not so bad though as you're going to usually use those for dram anyway
<eddyb> tnt: just got home, and I now see it's also in the annotated board diagrams
<TD-Linux> is the ALUREG new?
<TD-Linux> it says it's a complete RISC-V 32 bit ALU
<daveshah> what?
<daveshah> wow
<eddyb> clever
<eddyb> RISC-V is becoming a standard lol
<TD-Linux> also with M-extension multiply but no divide (but signals for a soft implementation of divide if needed)
<tnt> and that includes a register file ?!?
<TD-Linux> yes it does
<daveshah> So Lattice had muttered about a RISC-V hard core but who expected this
<daveshah> It reminds me a bit of azonenberg's idea of small RISC-Vs scattered around the fabric
<daveshah> just add PC logic
<daveshah> and load/stores
<TD-Linux> "the register file provides a single write port and two read ports"
<tnt> I'm wondering how many registers it'll have.
<daveshah> 32
<tnt> (to implement multiple register sets)
<TD-Linux> the datasheet is unclear but I assume it has all
<daveshah> the address is 5 bits
<daveshah> from the radiant webhelp
<TD-Linux> oh yeah it also has rotate which is not part of risc-v
<daveshah> hah so it even implements part of clifford's bitmanip
<TD-Linux> yeah though I dunno if they read that before implementing it
<tnt> Mm, looks like you don't have to use the built-in registers if you don't want to and just use EBR.
<daveshah> yep
<daveshah> even the clocks are separate
<tnt> kind of wonder why they put it in the same primitive ...
<daveshah> CONFIG_LMMI looks like fabric access to config which is interesting
<daveshah> might have self-partial-reconfig possibilities
<TD-Linux> daveshah, yeah they have a pdf for that
<TD-Linux> er
<azonenberg> daveshah: lol @ shipping post synth verilog
<azonenberg> on the plus side that means pretty faithful sim models
<azonenberg> is it a lut4 or lut6 based architecture?
<TD-Linux> their datasheet links to that but I don't see any info on it there
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 276 seconds]
<tpw_rules> does lattice's website almost never work for anyone else
X-Scale` is now known as X-Scale
<tpw_rules> i can't load any of the links that have been shared
<TD-Linux> working for me right now
<tpw_rules> hm. i get a connection refused
<tpw_rules> maybe they've blocked my ip
<tpw_rules> or something is broken around us geographically. i'm at the uni
<daveshah> it's gone down again
<tpw_rules> how many ALUREGs does this deal have?
<TD-Linux> just one
Asu has joined ##openfpga
<TD-Linux> oh apparently 2 on the bigger one
<tpw_rules> and it also does multiply? or you have to wire in one of the dsp blocks
<TD-Linux> it has integrated multiply
<tpw_rules> man there's gonna be so many weird risc-v variants
<TD-Linux> it's single cycle for all the ops
<tpw_rules> at what clock rate
<TD-Linux> no idea, would need to make a design in radiant to find out
<tpw_rules> is that not a datasheet parameter
<TD-Linux> oh lattice is now falling over for me too
<TD-Linux> tpw_rules, looking
<TD-Linux> daveshah, btw found the LMMI doc. the link was wrong http://www.latticesemi.com/view_document?document_id=52297
<daveshah> and now I can't access it...
<daveshah> oh Lattice
<TD-Linux> I can't either :)
<TD-Linux> btw on their site the "Quick Links" box is actually tabs for their docs
<TD-Linux> *quick reference
<TD-Linux> tpw_rules, the datasheet provides no timing info for that block
<tpw_rules> huh
<TD-Linux> other than telling you "use the tool"
<daveshah> Looks like 200MHz max in Radiant
<daveshah> That's pretty good if it can really do single-cycle multiply
<eddyb> oh I had forgotten about https://github.com/gregdavill/OrangeCrab
<daveshah> but sadly only one block in the 40k
<eddyb> the DRAM on that is sweet
<daveshah> datasheet says up to two, so maybe more parts are planned
<daveshah> eddyb: have you seen the elgato stuff recently btw?
<vup> eddyb: fyi the Alchitry Au doesn't actually have serdes / GTP, they use a package that doesn't break them out...
<eddyb> vup: heh was wondering about that
<eddyb> cause they don't advertise it at all
<eddyb> daveshah: nope been out of the loop for months
<eddyb> oh wait do you mean the board greg is reverse engineering rn?
<daveshah> yup
<eddyb> cause I just saw that on his twitter, it looks rly sweet
<eddyb> hopefully repurposable :D
<omnitechnomancer> The Anlogic Eagle also has a 12bit 1MSPS ADC
<TD-Linux> the LMMI doc is back up
<TD-Linux> it's a generic cpu bus, doesn't say anything specific about configuraiton
<eddyb> can't wait to see how much ALUREG gets abused for non-RISC-V uses :P
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
Asu` has quit [Remote host closed the connection]
<azonenberg> daveshah: so it looks like the crosslink-nx serdes is hard pcie?
<azonenberg> i.e. cant be anything else?
<daveshah> Yes
<daveshah> There is also hard SGMII CDR that is probably more reusable
<daveshah> to 8b10b stuff at a similar rate
<azonenberg> ah ok. So still can do gig-e, but not faster
<azonenberg> i'm looking forward to seeing future products on this architecture
<daveshah> ditto
<azonenberg> it would be really cool to have an fpga with transceivers in QFN
<azonenberg> but even without transceivers, 40k logic cells in 72qfn is quite nice
<azonenberg> i only wish they had 1mm bga options, but i get why they dont
<azonenberg> 0.8mm bga means i have to go to a "real" fab and not a batch fab
<azonenberg> Which is the big thing holding me back from doing more designs on lattice right now
<azonenberg> well that, and their generally low capacity
<azonenberg> but if they come out with a next-gen ecp5 successor i'd definitely consider that for some of my future projects
<Ultrasauce> the ram capability seems a bit slow compared to the io
<azonenberg> at some point i might want to make an integralstick-compatible module based on either an ecp5 or a similar lattice part
<adamgreig> azonenberg: 0.8mm is ok for eg jlbpcb 4/6L though?
<azonenberg> adamgreig: Dont know, I don't use jlc
<azonenberg> my current fab list is oshpark for low end and multech for high end
<adamgreig> they're a cheap batch fab
freemint has joined ##openfpga
<adamgreig> certainly worked fine for my 0.8mm bga stuff
<azonenberg> so basically i judge parts as "can do on oshpark" vs "need to go to china"
<adamgreig> fair
hackkitten has quit [Ping timeout: 246 seconds]
<adamgreig> in the uk oshpark is a harder sell since shipping cost and time is no better than china
<adamgreig> so overall price is usually a reasonable bit more
<azonenberg> yeah oshpark is vastly cheaper for small/simple designs
<adamgreig> i can see why it's very popular if you're in the states though
<azonenberg> most of my oshpark designs are << $100 pcb
<azonenberg> i've done some for <$1
<adamgreig> jlcpcb are $2 for 5x 2L 100x100mm board, then $7 shipping to the uk
<azonenberg> meanwhile if i go higher end, i'm normally doing full custom
<adamgreig> add another $7 to include a steel stencil
<adamgreig> obviously 4l and so on is a bit more but it's very cheap
<azonenberg> custom stackup, tight design rules, often controlled impedance
<adamgreig> sure
<azonenberg> There's not much in between for me
<adamgreig> if you did want to do 0.8mm stuff without going to a custom stackup there are definitely very cheap options for it
<azonenberg> like, the design i have in the works now i was quoted "about $600" for a batch of 50 based on my specs
<azonenberg> But "my specs" start with RO4350B and controlled impedance :p
hackkitten has joined ##openfpga
Bike has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
<TD-Linux> azonenberg, I did my ulx3s oshpark
<TD-Linux> as did others
freeemint has joined ##openfpga
freemint has quit [Ping timeout: 265 seconds]
gregdavill has joined ##openfpga