<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>
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
<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
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>
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
<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>
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
<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>
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
<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 ...
<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 :^)