<gruetzkopf> so, as someone who likes "it's pcie, it'll survice that" (personal distance record is over a 7.5m SFP DAC plus several adapters of my usual grade) i'm really interested in pcie-over-solderless-breadboard (which might actually kill it)
<azonenberg_work> loool
<s1dev> o.o
<azonenberg_work> Breadboard parasitics are pretty bad
<gruetzkopf> yeah
<azonenberg_work> My favorite example of this is, years ago
<gruetzkopf> enough for an avr oscillator to drive a quartz :D
<azonenberg_work> I was building a simple "music over free space LED optics" circuit
<azonenberg_work> Couldn't figure out why the audio level was so low on the RX
<azonenberg_work> poked and poked to no avail, i heard it fine but it was really quiet
<azonenberg_work> then i realized, my headphone jack was plugged in one breadboard column away from the amp output
<azonenberg_work> And I was AC coupling through the parasitics :D
<awygle> tinyfpga: oo, yay! <3 thermal diodes
<s1dev> so as someone who hasn't really paid attention to the Lattice offerings, what's the difference between the ECP and iCE families?
<awygle> s1dev: they're more or less entirely distinct. iCE was an acquisition from siliconblue
<awygle> ECP5 (http://www.latticesemi.com/Products/FPGAandCPLD/ECP5) has SERDES and is in general somewhere between a Spartan and an Artix
<awygle> (yes that's a bad comparison don't @ me)
<awygle> the iCE ones are focused more on low power consumption and glue logic and show up in phones and things
<awygle> max iCE logic is 8k 4-LUTs, max ECP5 is 85k 4-LUTs
feuerrot has quit [Ping timeout: 276 seconds]
<gruetzkopf> tinyfpga: how'd you hook up the usb-c port (i've read the spec far too many times)
grantsmith has quit [Ping timeout: 256 seconds]
argh_ has joined ##openfpga
feuerrot has joined ##openfpga
<pie___> welp, lmao, forgot to repost this here, thx qu1j0t3 . https://twitter.com/mjg59/status/1024795553761128448 ""memory safety isnt real," i assure myself as i close my eyes and let the wifi card wantonly DMA into system memory"
<gruetzkopf> if you cheat and hook up both SSTX and both SSRX to 2 sepeate serdes instead of muxing, you only need 1 gpio and one resistor to be fully spec compliant
<s1dev> and I guess they're in the market segment where nobody cares what fab node they're made on?
Miyu has quit [Ping timeout: 248 seconds]
<awygle> pie_: I mean that's amusing but what's the alternative really?
<whitequark> azonenberg_work: here
<awygle> s1dev: the ice40s are called that because they're on 40nm
<azonenberg_work> whitequark: oops, forgot what i was going to ask you about
<azonenberg_work> Lol
<sorear> the ice40 replaced SB's previous offering, the ice65, no points for guessing how they differ
<azonenberg_work> Lol, is it just a die shrink or are there uarch changes?
<sorear> no clue
<sorear> ice65 documentation is basically gone from the internet
<pie___> awygle, i have no idea, i reposted in another chan where gruetzkopf mentioned something about "i want channel io, it's what the big iron does. devices don't get to access memory, instead a channel controller executes transfers according to a channel program generated by the driver (which the rest of the kernel / a hypervisor can then trivially check and edit"
<jn__> nice diagram about channel I/O: https://susepaste.org/view/raw/47222060
<sorear> as I commented in #riscv a year or so ago, channel i/o is a simple and elegant system for transferring data, the far more complicated x86 iommu system exists because of the needs to transfer *persistent capabilities* e.g. textures in system meory
<pie___> persistent capabilities?
<tinyfpga> gruetzkopf: I cheated like you said and also connected the USB2 differential pair. I didn’t connect the resistor or GPIO for this revision, but I want to in the next. Do you have a schematic or simple diagram showing what you suggest?
<tinyfpga> gruetzkopf: I’ve been going through the spec myself and there’s a lot to parse, but the simple stuff is simple
<gruetzkopf> the usb-c connector contains four diffpairs for usb-3 speeds
<gruetzkopf> 2 on the top and 2 on the bottom
<gruetzkopf> these MUST NOT be connected
<gruetzkopf> a usb-c cable will contain 4 pairs, you're gonna do horrible things to your signal if you connect them at the pcb side
<gruetzkopf> let me think a while and draw something minimal for each of device/host/otg capable
<gruetzkopf> i'll guess you don't need usb pd direction flipping (only be powered by bus), that's a bit ugly
<tinyfpga> gruetzkopf: I’m super confused, I have 5gbit transcievers connected to the USB3 differential pairs
<tinyfpga> gruetzkopf: I’m planning on running a USB3 device on the FPGA
azonenberg_work has quit [Ping timeout: 240 seconds]
<tinyfpga> gruetzkopf: why would I not connect these signals to the USBC connector on the PCB?
<gruetzkopf> not what i meant
<tinyfpga> gruetzkopf: you mean “don’t connect them with each other”
<tinyfpga> gruetzkopf: that makes more sense
<gruetzkopf> yes, dont connect RX1 to RX2
<gruetzkopf> and TX1 to TX2
<tinyfpga> gruetzkopf: i understand now
<tinyfpga> gruetzkopf: yes, i did not do that XD
<gruetzkopf> if you don't want to include a external mux, connect TX1/RX1 to one serdes and TX2/RX2 to another
<tinyfpga> gruetzkopf: that’s exactly what I did
<gruetzkopf> good
<zkms> is connecting the two USB 2 diff pairs ok?
<gruetzkopf> (this enables alt-mode and usb3.2)
<tinyfpga> And then I also connected the USB2 pair
<gruetzkopf> zkms: in almost all cases you have to do that
<tinyfpga> But I did not connect to any of the sideband signally on these prototypes
<gruetzkopf> no CC1/CC2?
<tinyfpga> correct...so I’m using USBC to USBA cables for now
<tinyfpga> And I believe that should work for these prototypes
<zkms> gruetzkopf: ok good, because someone asked me about that and i gave them that answer
<gruetzkopf> you may for special applications not connect them directly, and have a mux select the right one
<gruetzkopf> this allows you to use the other HS pair for alt mode stuff, but only in the case that there's a captive cable on the device you're connection
<gruetzkopf> read: only super-special docks
<gruetzkopf> never seen it used
<gruetzkopf> tinyfpga: so DP alt mode is pretty much out in your case, since you can't get a serdes TX onto a usb-c RX pair
<gruetzkopf> so you don't need to care about SBU1/2 either
<gruetzkopf> (which would be DP AUX)
<gruetzkopf> leave them nc
<gruetzkopf> for the config channel there's the strictly spec compliant way and the "should work with all practical implementations" way
<gruetzkopf> the bad thing with letting the user get at CC is that they might raise VBus to up to 20V
<gruetzkopf> which might make your voltage reg go up in flames
<sorear> which aux modes can you do with only two serdes?
<gruetzkopf> i don't know in which order DP alt uses the diffpairs
<gruetzkopf> 1-lane DP might be doable
<sorear> is 1-lane DP1.2 or whatever the last open version was compatible with readily obtainable monitors?
<gruetzkopf> yes, though i don't know which resolution you'll be able to push at 5GBit/s
<gruetzkopf> quite interesting (though host support is lacking) is usb 3.2 dual-lane usb
<gruetzkopf> which would get you 10G/s with 2 5G serdes
<gruetzkopf> and 20G with 2*10G (superspeed+) lanes
<gruetzkopf> pcie is plausible
<gruetzkopf> (haven't seen the official spec yet, though)
<tinyfpga> gruetzkopf: yes, I didn’t seriously consider USB 3.2, but it is a real option
<tinyfpga> gruetzkopf: I just don’t think the Daisho USB3 core supports it
<tinyfpga> gruetzkopf: i think PCIe should work with a simple adapter board
<gruetzkopf> do you have a local oscillator that's refclk-level stable?
<tinyfpga> gruetzkopf: yes, I feed in a 200mhz refclk that the FPGA multiplies to either 2.5g or 5g
<gruetzkopf> (or do as the miners do and put it on D+ and D-)
<tinyfpga> gruetzkopf: this is a dedicated clock that goes straight to the TX PLL in the SERDES/PCS
<sorear> 1080p/24bpp/60Hz is 3 GBit/s of pixel data + ??? coding and blanking overhead, so it's probably around that
genii has quit [Remote host closed the connection]
<gruetzkopf> ok (currently trying to find the minimum viable implementation for UFP)
<sorear> imlementation for what?
<gruetzkopf> spec-compliant usb-c
<sorear> upstream facing port?
<gruetzkopf> yes. one facing a power source, never providing power to a attached device. this is independant of the data direction
<gruetzkopf> if you want a pragmatic implementation, and no proper PD (and therfore no proper alt mode), a 5.1kOhm pulldown on each of the CC1 pins is enough to get you 5V/3A
<sorear> alt modes require PD?
<gruetzkopf> yes :(
<gruetzkopf> (but there's a reason)
<rqou> lol i looked at this at one point and alt mode is a fucking disaster
<gruetzkopf> usb direction, power direction and alt mode direction are independant of each other
<sorear> is the ECP5 DTR block documented beyond the half-page in TN1270?
<gruetzkopf> in practice there's basically only the DP alt mode and TB
<rqou> don't forget legacy HNP/SRP :P
<gruetzkopf> ?
<rqou> gruetzkopf: does the legacy "inject some coulombs into Vbus" SRP still allowed on USB C?
<gruetzkopf> haven't seen any mention of it :D
<gruetzkopf> (and never seen any implementation)
<rqou> afaik TI calculators support HNP/SRP
<rqou> but they do it with a super-legacy mini-ab, not a type-c
<rqou> gruetzkopf: in case i wasn't clear, this is the legacy 2.0 OTG spec, not something new
<gruetzkopf> thought you were talking about PD 1.x
<rqou> the same spec that originally had an artificial limitation of only one OTG port per device to avoid users creating a USB ouroboros
m_t has quit [Quit: Leaving]
<rqou> *cough* *cough* type-c charging loops
<gruetzkopf> yeah, those are unresolved afaict
s1dev has quit [Quit: Leaving]
Zorix has quit [Ping timeout: 265 seconds]
Zorix has joined ##openfpga
s1dev has joined ##openfpga
<sorear> random EE question: transmission lines are linear, so assuming proper termination why *can't* I run data in both directions simultaneously?
pie__ has joined ##openfpga
pie___ has quit [Ping timeout: 240 seconds]
<sorear> apparently RS-485, POTS, and GbE do this. i wonder why USB and PCIe don't
<sorear> conjecture: this cannot be done electronically, and ethernet-style hybrid transformers were considered cost-prohibitive by USB-IF
<sorear> doesn't make a huuuge amount of sense because ethernet has always been "full duplex" in a limited capacity (carrier detect while transmitting)
rohitksingh_work has joined ##openfpga
s1dev_ has joined ##openfpga
s1dev has quit [Ping timeout: 268 seconds]
Bike has quit [Quit: Lost terminal]
<sorear> the ice65 has very similar fabric to the ice40, but the ice65 "4k" is a real part - it has a different sized bitstream from the "8k"
s1dev_ has quit [Quit: Leaving]
s1dev_ has joined ##openfpga
azonenberg_work has joined ##openfpga
<daveshah> tinyfpga: blockram fuzzing is done now, just need to add to nextpnr
<daveshah> Wanted to add global clock routing first, that is also needed for more complex designs
<daveshah> Hopefully we'll have micropython+picosoc+other bits running some time this month
<azonenberg_work> :D
<pie__> wow these wiki pages are getting fucking fancy https://en.wikipedia.org/wiki/Multiple_patterning
<daveshah> azonenberg_work/tinyfpga: bit docs here, click on a tile
<pie__> pretty sure there werent as many pictures last i looked at that one
<zkms> wait is there gonna be an open source toolchain for ECP5 fpgas?
<daveshah> There is already
<daveshah> It just only supports LUTs, FFs and IOs right now
<zkms> wait really? this is **awesome**
<daveshah> And it's been public for 20 hours or so, so I forgive you for not knowing :D
<daveshah> Here are the current examples: https://github.com/SymbiFlow/prjtrellis/tree/master/examples
<rqou> azonenberg_work: let me restart OTR sessions
<azonenberg_work> daveshah: looks great, although i freely admit to being a bit lost
<azonenberg_work> I don't know ECP5 microarchitecture to the level i know 7 series
<rqou> azonenberg_work: is it working now?
<rqou> i hate OTR
<daveshah> Yeah, I need to do some more high level stuff
<daveshah> Right now even the general docs at http://prjtrellis.readthedocs.io/en/latest/ probably assume too much arch knowledge
<rqou> eh, makes sense to me
<azonenberg_work> daveshah: once this construciton has wound down and i have more time to work on things
<azonenberg_work> I think i am probably going to start by tinkering around with the existing codebase
<azonenberg_work> Then try to write an arch lib for either greenpak or coolrunner
<azonenberg_work> To see how well a crossbar fabric can play with it
<daveshah> Yeah, that would be awesome
<rqou> although i probably don't count because apparently i've inducted myself into the "crazy people who know too much about low-level fpga arch details"
<azonenberg_work> rqou: lol
<daveshah> The iCE40 isn't fully one hot, FWIW
<azonenberg_work> you wrote a PAR
<azonenberg_work> i think that qualifies you :p
<daveshah> And the ecp5 global networks are full crossbars
<azonenberg_work> daveshah: anyway trivial degenerate case
<azonenberg_work> greenpak is two tiles
<azonenberg_work> one per matrix
<azonenberg_work> each primitive is a bel
<azonenberg_work> have fun :p
<azonenberg_work> realistically i want to try modeling primitives as separate tiles and just have weird arcs between them
<zkms> what is "7 series
<zkms> "
<azonenberg_work> But i'm not yet sure how i'll do that
<azonenberg_work> zkms: xilinx's 28nm architecture
<daveshah> I don't think that should break anything. We dont actually use tiles for that much
<azonenberg_work> spartan7, artix7, virtex7, kintex7
<azonenberg_work> and zynq7
<rqou> goddammit azonenberg_work why don't you just write a "constraint-satisfaction-problem"-formulated PAR for greenpak
<azonenberg_work> rqou: if we can have one unified par that works for everything
mmicko has joined ##openfpga
<azonenberg_work> it will be a lot easier to drop in new algorithms
<azonenberg_work> rather than having even more ecosystem fragmentation
<daveshah> Yes. Notice that the placer in nextpnr is called placer1 for a reason
<azonenberg_work> my current long-term thought, although i dont know if it will work
<zkms> azonenberg_work: oh! I have a zynq i think.
<azonenberg_work> is to replace both gp4par and cr2par
<daveshah> We do want to support multiple algorithms
<azonenberg_work> with nextpnr techlibs
<rqou> i don't think this will work for xc2par
<azonenberg_work> then keep the existing yosys passes and bitstream gen backends
<zkms> Is there an open source toolchain for it?
<azonenberg_work> zkms: Not yet
<rqou> xc2par was specifically written to take advantage of the maximum amount of arch-specific hacks
<daveshah> zkms: there are some bitstream docs, but not a toolchain
<azonenberg_work> Project X-Ray has reverse engineered a sizeable amount of the bitstream
<azonenberg_work> And nextpnr will support it one day
<daveshah> Yeah
<azonenberg_work> But there is no code based on that RE
<azonenberg_work> (yet)
<rqou> if you like vaporware, i will still be working on KinglerPAR
<azonenberg_work> rqou: thats the point, i want to try to make something generic
<azonenberg_work> i want to see what happens if we shoehorn the coolrunner and greenpak arches into nextpnr
<azonenberg_work> and tell it "this is an fpga with a really messed up interconect topology"
<daveshah> So we certainly allow arch specific hacks in nextpnr
<azonenberg_work> after using yosys to techmap to the appropriate bels
<rqou> xc2par isn't even a traditional PAR
<rqou> it's mostly a greedy algorithm with min-conflicts
<azonenberg_work> Yes i know
<azonenberg_work> thats the thing, i want to see what happens
<azonenberg_work> if i pretend its an fpga
<azonenberg_work> i dont know how the qor or runtime will compare
<sorear> maxv? s6?
<rqou> it's formulated very explicitly as a CSP
<rqou> i'm going to be putting max v in KinglerPAR
<azonenberg_work> wolfspraul did some work on s6 years ago
<azonenberg_work> but there is nothing useable
<azonenberg_work> i dont think any of the active projects now are targeting it
<rqou> whether or not anything will go into nextpnr depends on how much people are willing to clear the air
<daveshah> rqou: you coming to ORConf by any chance?
<sorear> Unfamiliar with that idiom
<rqou> was that in Poland?
<daveshah> Yeap
<rqou> sorry no, way too far for me
<s1dev_> pie__, I had to double check the channel after seeing multi patterning in more than one place :P
<pie__> :PP :D
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 244 seconds]
<rqou> hey azonenberg_work, can you fix mode flags on #antikernel?
<rqou> it's full of spam
<rqou> might want to do #homecmos too while you're at it
<s1dev_> so what is a bel?
<rqou> lol, depends on the arch
<rqou> usually a LUT+FF
<s1dev_> so what Intel calls an ALM?
<rqou> lol um
<rqou> afaik that's just a fracturable LUT
<rqou> i don't think an ALM includes the FF?
<rqou> it's what intel calls a BLE in the LUT4 archs
<daveshah> We consider a bel to be what the packer packs into and the placer places
<daveshah> That's a LUTFF for iCE40 or slice (2LUT, 2FF) for ecp5
<azonenberg_work> rqou: i did fix mode flags earlier today
<azonenberg_work> no?
<azonenberg_work> rqou: no
<azonenberg_work> a bel is a lut or a ff
<azonenberg_work> in xilinx terminology
<rqou> lol not in the papers i was recently reading
<daveshah> yeah, not in nextpnr either
<rqou> hooray for inconsistent terminology everywhere :P
<azonenberg_work> for example in xilinx land
<rqou> azonenberg_work: well both channels are still full of spam, so check again?
<azonenberg_work> you can do LOC=SLICE_X3Y6 BEL=A6LUT
<daveshah> Although for the iCE40 its impossible to use the LUT or FF separately so a LUTFF pretty much is a Bel
<daveshah> I don't know how we'll do that in nextpnr for 7-series
<azonenberg_work> Can you do fracturable luts yet?
soylentyellow__ has quit [Remote host closed the connection]
<rqou> kinglerpar will be plumbed for fracturable luts
<rqou> the papers it's based on are explicitly for 7-series
<daveshah> azonenberg_work: nextpnr doesn't support LUTs at all, fracturable or otherwise
<azonenberg_work> daveshah: so the packer comes before that?
<daveshah> azonenberg_work: yeah, the packer is part of the arch code
<azonenberg_work> ah, i see
<daveshah> It's in nextpnr, but not common
<daveshah> We will do a generic packer once we know a bit more about what is needed
<azonenberg_work> So in greenpak the packer will probably be the part responsible for attaching comparators and voltage references
<daveshah> Without making the same mistakes as VPR
<azonenberg_work> replicating vrefs as needed
<azonenberg_work> etc
<daveshah> Yeah, exactly
<azonenberg_work> But for the most part in greenpak a lut or a ff will be considered a placeable element
<daveshah> Yes, that makes sense
<daveshah> That doesn't work for a big FPGA, as SA starts to get very slow
<azonenberg_work> Also if at all possible i think you should try to use the term bel consistently with other stuff
<azonenberg_work> i.e. a lut or ff is a bel, and have another term for a packed group
<rqou> nah, you'll run into conflicts no matter what
<rqou> i realized this when trying to write a "FPGA glossary" that somebody here asked for
<daveshah> Yeah, unless we make up nonsense words or just use anime or something then we're stuck
<azonenberg_work> well you have the nuts who think that a flash fpga is a CPLD
<rqou> afaict everybody just picks either "xilinx-style" naming or "altera-style" naming
<azonenberg_work> Lol
<azonenberg_work> does altera use the term bel?
<rqou> xilinx-style seems to be more popular in the newer papers
<daveshah> The worst word is arc. That means at least three different things
<rqou> and altera-style seems to be more popular in older papers
<rqou> azonenberg_work: altera has "BLE" instead
<rqou> it's a LUT+FF
<azonenberg_work> Then you can be consistent?
<rqou> i guess
azonenberg_work is now known as azonenberg
<rqou> except altera doesn't use BLE for their LUT6 parts
<rqou> or at least i don't think they do
<daveshah> So this is the nextpnr terminology
<daveshah> It's broadly Xilinx
<rqou> hmm i just checked an ALM does include the FF in altera
<rqou> s1dev_: ^
<rqou> so ALM ~= "slice"
<rqou> in Xilinx/Lattice terminology
pie___ has joined ##openfpga
<rqou> i think lattice also uses the term "PLC" for this?
<daveshah> PLC is a tile, ie 4 slices, afaik
<rqou> i thought that's a PLC2?
<rqou> anyways
<daveshah> No, PLC2 is just the tile name
<rqou> this is why this problem is impossible :P
azonenberg is now known as azonenberg_work
<rqou> hardest 2 problems in computer science :P
<daveshah> Yeap
pie__ has quit [Ping timeout: 260 seconds]
soylentyellow has joined ##openfpga
<mmicko> @cr1901_modern thanks for confirmation of fix
<cr1901_modern> mmicko: Thank you for the fix :P
<cr1901_modern> Does the --asc option have no effect if the file already exists?
<mmicko> hmm it should overwrite it, but with gui it does not get effect
<mmicko> since you anyway need to do that part manually
<mmicko> by clicking at the save asc icon
<mmicko> @cr1901_modern if you could also close that issue, would be great :)
<cr1901_modern> Maybe that should be documented if that's intended behavior :P?
<mmicko> still doing changes, cleanups, and making things available for all architectures, so it needs some time to settle down
<mmicko> will take care of Ctrl-C as well, it is just that it needs to be properly handled for Qt
<cr1901_modern> I've lost the ability to duplicate the crash consistently
<mmicko> thing is it depends of some internal Qt things, intention is to make Ctrl-C actually do Application close, so same as when you click on X
<cr1901_modern> I guess I wonder what it actually does now... (Even though Windows doesn't have signals, some of them are supported anyway in msys2. I don't think CTRL+C is one of them.)
<cr1901_modern> In any case, I'm very happy this went from "multiple crashes that make nextpnr GUI unusable" down to "1 crash that can be worked around" in < 24 hours :)
azonenberg_work has quit [Ping timeout: 240 seconds]
<mmicko> windows have totally different way of signal handling, and it is actually in different thread causeing troubles, so it needs some ifdefs :) in order to make it work on all places
azonenberg_work has joined ##openfpga
plaes has quit [Ping timeout: 256 seconds]
bibor has quit [Ping timeout: 256 seconds]
miek has quit [Ping timeout: 256 seconds]
plaes has joined ##openfpga
plaes has quit [Changing host]
plaes has joined ##openfpga
bibor has joined ##openfpga
miek has joined ##openfpga
<mmicko> @cr1901_modern added Ctrl-C handler for windows only https://github.com/YosysHQ/nextpnr/pull/13
massi has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
s1dev_ has quit [Ping timeout: 260 seconds]
<rqou> high voltage is weird: https://www.youtube.com/watch?v=QarKXkXox6M (warning: that annoying iranian guy :P )
ondrej2 has joined ##openfpga
s1dev_ has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
s1dev_ has quit [Ping timeout: 260 seconds]
<rqou> whitequark: https://twitter.com/whitequark/status/1024956343218790401 <-- this is why my father likes to describe Avago as "you know all of the silicon valley chip companies that failed? Avago got them all and then kept only the useful parts"
<whitequark> lol ok
<rqou> they have basically every kind of chip imaginable
<rqou> including (at one point) those little sensors that go into optical mice
<rqou> this got spun off a few years back
<daveshah> it's anything from a tricolour LED to a SATA controller
<rqou> to a fancy network switch named after a missile :P
<rqou> PLX is also avago (now broadcom)
<rqou> so is brocade
<rqou> and of course LSI which was the previous "acquire all the shit" company
<rqou> which itself merged with agere with was another "acquire all the shit" company
<daveshah> yeap. It's only because of agere's fpga sell-off to Lattice that Broadcom don't have an FPGA now
<daveshah> Lattice are a bit like a shrunk down version of that
<daveshah> they've bought various random HDMI things over the years and both their FPGA families ultimately come from acquisitions
<rqou> i can't find a good reference, but apparently lucent's fpgas in turn came from a partnership with xilinx
<daveshah> yes
<daveshah> AT&T originally made pin compatible ones IIRC
<daveshah> not sure if it was actually a partnership
<rqou> which is why lattice parts use neocad and have "xilinx-style BSB" architectures
<rqou> meanwhile siliconblue has an "altera-style muxes and local lines" architecture
<daveshah> there are actually a few Chinese FPGA companies like Anlogic that have somewhat ECP5 inspired architecures
<daveshah> they aren't quite close enough to be copies and they add in some Altera ideas too
<daveshah> I wonder if they poached staff
<rqou> i was told some of them definitely did
<daveshah> it's actually an improvement over the ECP5 arch
<daveshah> some of the LUTs are LUT5s instead of LUT4s
pie___ has quit [Ping timeout: 264 seconds]
<daveshah> but they have the same thing as ECP5 of pitch matching 4 BRAMs to 9 logic tiles
pie_ has joined ##openfpga
mumptai has joined ##openfpga
mumptai has left ##openfpga [##openfpga]
soylentyellow_ has joined ##openfpga
soylentyellow has quit [Ping timeout: 276 seconds]
X-Scale has quit [Ping timeout: 264 seconds]
sorear has quit [Remote host closed the connection]
nickjohnson has quit [Remote host closed the connection]
_florent_ has quit [Remote host closed the connection]
sorear has joined ##openfpga
nickjohnson has joined ##openfpga
_florent_ has joined ##openfpga
m_t has joined ##openfpga
tinyfpga has quit [Ping timeout: 256 seconds]
tinyfpga has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
tinyfpga has quit [Ping timeout: 240 seconds]
tinyfpga has joined ##openfpga
rohitksingh has joined ##openfpga
genii has joined ##openfpga
X-Scale has joined ##openfpga
<gruetzkopf> tinyfpga: so with the board space you have, i'd say put a 5.1k pulldown on each CC line in the connector. that's fully spec-compliant for usb2 data rates, and spec-compliant enough that even a usb-c 3.x host should simply work. if you're doing superspeed you're supposed to check cable e-marks, but it's usually enough if the host does (and a user could work around that with a C-A and A-C cable combo)
<daveshah> personally I'd like to see the SBU pins connected to the FPGA, for people that want to abuse the USB-C connector (e.g. 2L displayport), while keeping D+/D- available for the bootloader
<gruetzkopf> that's fine for "you know it's abuse" (afaik 2L DP mode uses TX2 and RX2 for the data lanes, not TX1 and TX2), if you wanted spec-compliant DP alt mode you need a USB PD implementation :(
<gruetzkopf> (all not as bad as nintendo, who apparently chose to use myDP instead of normal DP alt mode on the switch..)
<balrog> clifford, daveshah, q3k has there been any consideration of patent licenses for nextpnr?
<balrog> Apache 2.0 is quickly becoming a very popular permissive license for this reason
<balrog> (or dual Apache 2.0 / {MIT,BSD,ISC})
<balrog> I'm bringing this up now because it probably should be discussed internally before a ton of external contributions are brought in
<q3k> i don't think we really cared (yet) because most of the pre-existing contributors aren't in jurisdictions that allow for software patents
<q3k> but we'll discuss it
<daveshah> we tend to prefer ISC because of its simplicity
<balrog> "not in jurisdictions that allow for software patents" is something that has to be treated carefully too, because many of these jurisdictions do allow for some types of software patents :(
<q3k> (re: contributors from the US and other kinds of patents)
<daveshah> it's clear what you can and can't do with ISC, doesn't create any FUD
<balrog> daveshah: and so do I, but the additional patent protections from Apache 2.0 are nice and a lot of people like them.
<balrog> it could become an issue if, e.g. the company developing nextpnr gets bought by a company that's litigation happy... yes, hypotheticals, but still worth thinking about
<q3k> that shouldn't matter anyway, because there is no other copyright ownership here than individual contributors
<q3k> (for contributors working for symbioticeda)
<balrog> q3k: if you have a major outside contributor that has submarine patents, then you could have a problem
<balrog> you could also adopt a policy similar to PostgreSQL, though that's got its own issues (heh)
<balrog> (Rust is a major project that did a dual Apache 2.0 / MIT for this reason)
<balrog> anyway, this is veering off topic, feel free to take this discussion somewhere else if you'd like
Miyu has joined ##openfpga
<balrog> all I'm saying is "this can become an issue, it's good to think about it"
<q3k> personally, and abstracting away from nextpnr i'd rather have no contributions with code falling under patents than contributions with a patent grant clause (especially the whole it-disappears-if-you-sure-us business)
<balrog> same, but depending on employer or situation that's not always under one's control, and that especially becomes the case when bringing in outside contributions
<balrog> https://lwn.net/Articles/760834/ -- the stance of PostgreSQL
<balrog> > we will not accept any code that is known to be patent-encumbered
<balrog> > any patent assignment to Postgres would have to allow free patent use for all code, under _any_ license. This effectively makes the patent useless, except for defensive use, even for the patent owner.
<q3k> yeah, that's my point as well
<q3k> isc is such a weak copyleft that basically any patent grant becomes transitive
<q3k> it's silly
<q3k> s,isc,isc or apache,
<sorear> did I miss something about nextpnr
<balrog> q3k: if you have a patent grant; if you don't, there can be issues
<balrog> :/
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
massi has quit [Remote host closed the connection]
azonenberg_work has quit [Ping timeout: 264 seconds]
soylentyellow__ has joined ##openfpga
key2 has quit [Ping timeout: 252 seconds]
soylentyellow_ has quit [Ping timeout: 268 seconds]
azonenberg_work has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
digshadow has quit [Ping timeout: 245 seconds]
m_t has quit [Quit: Leaving]
pie_ has joined ##openfpga
utanapischti has joined ##openfpga
drawkula has quit [Ping timeout: 264 seconds]
<kc8apf> azonenberg_work: there is _some_ code for xc7. Both a C++ library in the prjxray repo and a Rust version in https://github.com/gaffe-logic/gaffe-xilinx. Both only get up to the config frame level because moving up to tiles involves non-trivial address decoding and a chip database.
utanapischti is now known as drawkula
<kc8apf> I've been writing blog posts for everything up to that point. Then I'll get back to building up the pieces to resolve config frames to tiles and signals.
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
Sellerie_ has joined ##openfpga
cr1901 has joined ##openfpga
<q3k> G33KatWork: ^
<q3k> (you were interested in 7-series RE)
Sellerie has quit [Quit: leaving]
Sellerie_ is now known as Sellerie
<G33KatWork> oh yeah, I have zynq boards piling up here
<G33KatWork> and *really* would like to be able to build bistreams on the thing directly. even if it's only partial reconfiguration
Sellerie has quit [Quit: Reconnecting]
Sellerie has joined ##openfpga
<G33KatWork> bu I have no overview about what still needs to be done to make this work in the future. I know it's nowhere near that right now, but I also don't know what still needs to be done
<sorear> they’ve had the zynq how long and never did arm vivado?
<daveshah> So AIUI the bitstream documentation for logic, interconnect and DSPs is done
<G33KatWork> dunno. long. even before vivado came out
<daveshah> BRAMs might still need doing, but not much work
<daveshah> What remains is PnR
<G33KatWork> that's all project xray, right?
<G33KatWork> the documentation bit
<daveshah> Yes
<G33KatWork> I might dig into that, find out how it works and play around with it first
<G33KatWork> algorithms are not exactly my strong domain :(
<G33KatWork> like PNR
<daveshah> So we can provide (basic) algorithms in nextpnr
<kc8apf> G33KatWork: xc7-tool in gaffe-xilinx can patch bitstreams at a frame level
<daveshah> It would mostly be a case of integrating the device database with nextpnr, and writing a packer and FASM backend
<kc8apf> logic and interconnect are documented
<awygle> lol @ arm vivado
<kc8apf> BRAM is partially understood (we know where the data is stored but not all the config details)
<G33KatWork> goal is partial reconfig right now?
<G33KatWork> so no IO tiles, serdes etc. yet?
<kc8apf> daveshah: sortof. There is exactly one device database: xc7a35t
<daveshah> I may be applying too much ecp5 thought onto this
<kc8apf> FASM was a quick hack to make it possible to program a tile symbolically
digshadow has joined ##openfpga
<azonenberg_work> kc8apf: the 35t is the same die as the 25 and 50
<kc8apf> azonenberg_work: I'm aware
<daveshah> kc8apf: this is my proposed spec for the ecp5 config format: http://prjtrellis.readthedocs.io/en/latest/libtrellis/textconfig.html
<azonenberg_work> I assume you are not implementing the capacity limiting?
Sellerie has left ##openfpga [##openfpga]
<kc8apf> azonenberg_work: I haven't even figured out what, if anything, changes other than the idcode
<azonenberg_work> Nothing
<azonenberg_work> folks have tested
<azonenberg_work> they literally just have vivado refuse to use more than X percent of the fabric
<daveshah> Same between ecp5 12k and 25k
<azonenberg_work> Interesting question... what legal recourse would xilinx have if we released support for nextpnr to use the full fabric?
<azonenberg_work> DMCA would be hard to apply because its not DRM that controls access to copyrighted content
<azonenberg_work> And we're not using their tool so the EULA doesnt apply
<daveshah> I don't think there is anything they could do, other than cut the supply of parts to big customers that cheat
<kc8apf> that's what i thought. My only reasons for bringing up the 35t db is that we have nothing for zynq or other parts in the xc7 lineup
<daveshah> And refuse support
<azonenberg_work> Yeah
<awygle> the zynq fabric is just artix fabric though
<azonenberg_work> awygle: or kintex
<azonenberg_work> depends on the size
<awygle> at the lower capability pcns
<awygle> ... *skus
<kc8apf> daveshah: I _think_ that works ok for expressing a tile config. Mapping it to config frames is rather non-trivial
<zkms> what's the difference between artix and kintex
<awygle> kintex is Much Gooder
<azonenberg_work> zkms: kintex is faster mostly
<kc8apf> zkms: mostly the types of columns included in the die
<azonenberg_work> everything is tuned more for performance vs area
<azonenberg_work> kintex performance actually matches virtex for each tile as far as i can tell
<daveshah> kc8apf: that's less of a worry for ecp5 because there's no partial config
<azonenberg_work> they're just smalelr and dont have the super high end GTYs etc
<zkms> azonenberg_work: i see
<daveshah> And the tile/frame relationship is nice and simple
<zkms> what is a GTY
<awygle> ah, so bigger-faster-more-power layouts of the cells and whatnot?
<azonenberg_work> one of their higher end transcievers
<azonenberg_work> 28 Gbps NRZ iirc
<awygle> GTY is the hella-fast serdes on the Virtex 7s
<zkms> (sorry for asking ignorant questions i'm kinda ignorant about all this)
<zkms> oic
<azonenberg_work> vs the 6 Gbps GTP on artix and 12 Gbps GTX on kintex
<zkms> whoa 28Gbps is fast!!
<kc8apf> that's what makes the chipdb tricky. The internal structure of the config memory isn't a flat map. It requires quite a bit of knowledge about the device to even figure out what address is being written.
<azonenberg_work> daveshah: What i think makes the most sense re the small chips
<awygle> actually the V-7 doesn't have a GTY
<awygle> it has a GTZ and a GTH
<azonenberg_work> ah yeah i'm thinking vu+
<awygle> and a GTX which Kintex also has
<azonenberg_work> has GTY
<awygle> i don't really get the point of GTH btw
<kc8apf> pt3 of my blog series covers this insanity of the device internals
<azonenberg_work> daveshah: is to apply xilinx's limit by default if you specify a lower density SKU, to prevent accidentally creating an out of spec bitstream that would potentially cause legal problems
<awygle> it's only 0.6 more gbps, what does that buy you over 12.5?
<kc8apf> off to an appt. bbiab
<azonenberg_work> Then have an off-by-default argument that says "allow using full capacity of smaller devices"
<azonenberg_work> "use at your own risk"
<azonenberg_work> Basically this lets the end user decide whether they want the legal exposure or not
<azonenberg_work> Sound sane? I know its a long way off, just occurred to me
<pie_> sometimes i feel like "use at your own risk" buttons should come with a small explanation
<pie_> or should people just know better
<pie_> because the devs presumably know a lot more than a random end user
<jn__> pie_++
<pie_> ok perhaps i should phrase more strongly, but i wont :p
<daveshah> azonenberg_work: tbh we never bothered with the 4k/8k ice40 and no one cared
<daveshah> But I think it could be a good idea re Xilinx
<azonenberg_work> daveshah: yeah just thinking xilinx is more likely to sue :p
<azonenberg_work> i figure this gives the best of both worlds
<pie_> "use at your own risk" doesnt quantify the risk at all so will probably just be ignored if "fixes my shit"?
<azonenberg_work> well you'd document more than that
<pie_> ok
<azonenberg_work> but basically it respects their limits by default, lets folks who care about following the rules do so
<azonenberg_work> But also lets you use the full capacity of the part if you dont mind pissing off xilinx and potentially getting blacklisted :p
<pie_> just wanted to be sure, i mean i figure you guys push out bettersoftware than $random_company
<awygle> you could do like a particular wii homebrew application once did
<awygle> and put a "do you want to enable breaking the rules" button
<awygle> which, if you push "yes", prevents you from using the tool
<azonenberg_work> have the argument be "nextpnr --xilinxpleasesueme"
<azonenberg_work> :p
<pie_> heh
<daveshah> I am also curious whether Lattice will respond at all when we release bit docs/tools for the SERDES
<azonenberg_work> Yeah
<jn__> azonenberg_work: that reminds me of flashrom's -p internal,laptop:force_I_want_a_brick
<daveshah> Which is currently only support in $900 diamond
<azonenberg_work> how cheap are the ecp5 serdes parts?
<awygle> is diamond really that cheap?
<azonenberg_work> lowest end one
<awygle> azonenberg_work: like, 25$
* awygle sent this to you last week
<awygle> nope, 12$
<daveshah> you can get full diamond with a $200 dev kit
<azonenberg_work> ooooh
<awygle> daveshah: yeah that's what id id but i thought the regular license was ilke 2k
<azonenberg_work> 12 bucks plus a $3 sfp cage
<azonenberg_work> and a $1 ebay sfp
<awygle> azonenberg_work: you see why i am interested in trellis now? :P
<daveshah> awygle: maybe that is a floating license
<azonenberg_work> cheapest ethernet devkit? :p
<awygle> daveshah: could be
<azonenberg_work> gig-e
<pie_> <@gchristensen> libxml2 contains an ftp client
<pie_> lul
<pie_> wut
<gruetzkopf> 1$?
<gruetzkopf> .5$ more like
<azonenberg_work> i got my 1g sr sfps for 20 bucks
<azonenberg_work> ... Per bag of 25
<azonenberg_work> so far they all work lol
<gruetzkopf> yeah, i got most of mine in a literal paint bucket
<gruetzkopf> so far, outside of the -BX ones, most do 2, some 4G too
<azonenberg_work> yeah i have some fibre channel ones too
<azonenberg_work> Meanwhile my 10g and 40g SR SFPs actually cost real money from FS :p
plaes has quit [Quit: Reconnecting]
plaes has joined ##openfpga
plaes has quit [Changing host]
plaes has joined ##openfpga
<gruetzkopf> yeah, like 16$ for a 10G one :D
<gruetzkopf> i have quite a few finisair 1GE/1GFC/2GFC SFPs
<gruetzkopf> (dell branded, but for some reason my old HP switches like them)
pie_ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
sgstair has quit [Ping timeout: 276 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou> <drama> wtf so many people backing sarah jeong
<sorear> > cheapest Ethernet devkit
<sorear> Would you be doing your own PHY with several SERDES?
sgstair has joined ##openfpga
<awygle> with SFP you can just ram the serdes right into the SFP is my understanding
<awygle> provided it's fast enough (which the ECP5 is, for gigabit)
<tinyfpga> daveshah: i think Lattice will be happy to have open SERDES support, but maybe Synopsys won’t be happy
<daveshah> Not sure if Synopsys will really care
<daveshah> There's LSE after all anyway
<sorear> So does nextpnr have any chance in running with a zynq’s ram budget
<daveshah> Yeah
<daveshah> For the ecp5 I've developed a deduplicated database that massively cuts ram
<daveshah> The same could be used for 7 series
<daveshah> The idea is not to build a full routing graph but to store identical tiles routing wise only once
<azonenberg_work> Makes sense
<azonenberg_work> then just have a pointer to each
<daveshah> Yeah
<awygle> ... picture the butterfly meme, where the butterfly is "not storing massive amounts of redundant information", and the caption is "is this innovation?"
<daveshah> Well, it beats VPR in that sense
* awygle really needs to learn Gimp at some point
<azonenberg_work> yeah xbpar makes a full routing graph
<azonenberg_work> but that makes sense given that its targeting CPLDs :p
<balrog> [14:44:30] <rqou><drama> wtf so many people backing sarah jeong
<balrog> because she's done some very good reporting, and certain people's continuing attacks on her for having and voicing opinion have reached a point of being ridiculous, and seem to be energizing a dogpiling effort (look at her mentions)
<balrog> (sorry)
<shapr> balrog: I got hit by the edge of the twitter lynch mob targeting sarah, I get it.
<rqou> hmm not aware of that
<rqou> i certainly don't support her after what she did to Naomi Wu
<balrog> "what she did to Naomi Wu" was primarily having and voicing an opinion -- she was not part of Vice at the time as far as I am aware
<rqou> I'm fairly certain she was?
<awygle> no, she wasn't, she used to work for Motherboard
<shapr> Naomi Wu targeted me in the past few months, for something I didn't do, but there was no discussion, just a lynch mob.
<balrog> the whole thing happened after Sarah Jeong had left Vice
<balrog> From what I can tell, Sarah Jeong voiced her opinion once, while Naomi Wu has continued to @-mention and attack her for that (to this day), drawing Naomi's followers to attack Sarah as well
<shapr> yup
<balrog> I wasn't personally attacked like @shapr, but that's what I can tell
<rqou> um, isn't motherboard part of Vice?
<balrog> it's an unfortunate situation
<balrog> rqou: I think the implication was that the whole thing happened after Sarah Jeong had left Vice
<rqou> i wouldn't call "endangering your sources" "voicing an opinion"
<awygle> the whole thing is complicated. naomi's reaction seems excessive to me, but i don't know what actual consequences naomi experienced, so maybe not. and sarah jeong did basically voice an opinion, but she did it in a very antagonistic way, and "i'm korean so i understand china" is always going to be a bad take. so i basically choose not to take an "x is wrong, y is right" position on this.
<awygle> rqou: *used* to work at motherboard. she was out before the thing with naomi.
<balrog> rqou: to the best of my knowledge Sarah Jeong did not have any part in that decision making process
<balrog> people are entitled to their opinions, even if said opinions are shitty :/
<balrog> or if others disagree with them
<awygle> i'll also say that i literally _only_ have heard of sarah jeong in this context, i have no idea who she is otherwise and have never read any of her allegedly good reporting afaik.
<balrog> I don't think repeated dogpiling is cool
<balrog> awygle: she did some VERY excellent reporting on oracle v. google
<balrog> and was one of the people responsible for this: https://teespring.com/shop/wouldnt-reimplement-an-api#pid=369&cid=6513&sid=front
<shapr> bwahaha
<shapr> now I want one
<balrog> (the other person was Parker Higgins - @xor)
<awygle> shapr: sorry to hear you got hit with a mob though, that's really shitty :(
<qu1j0t3> ( also surely we can separate the issues of Jeong / Wu from Jeong / NYT. If I understand the recent mobbing it's all over bullshit anyway )
<qu1j0t3> ( i mean, faked up outrage )
<shapr> awygle: yeah, sucks that "you got the wrong guy" got no response, just more mob
<balrog> qu1j0t3: it is, but it wouldn't surprise me if followers of Wu are involved in doing the mobbing.
<awygle> balrog: i generally have very limited sympathy both for "they did this other good thing" and "people are entitled to opinions" to excuse bad behavior. speech is action, especially in this context. but on the other hand, there's a context for sarah jeong too. so yeah, i don't take a position here.
<qu1j0t3> the NYT has a catastrophic representation problem, so this attack mob surely isn't improving things, but is getting their way
* qu1j0t3 personally thinks the NYT is beyond saving, but w/e
<awygle> ^ yep
<balrog> for reference, here is the twitter thread from Sarah Jeong that's in question: https://twitter.com/sarahjeong/status/981558161566920704?s=19
<awygle> and it's hard to separate "we have a representation problem, let's hire WoC so we can fix it" and "we have a represenation problem, let's hire WoC so our stock doesn't go down as much"
<qu1j0t3> awygle: right, i don't trust the NYT
<rqou> i definitely don't support dogpiling, and Naomi definitely doesn't present herself as easy to work with, but overall I'm still inclined to believe Naomi's account of what Vice did to her
<qu1j0t3> awygle: but i am definitely not on the side of the shitbags going after jeong
<qu1j0t3> (on this issue. other issues are well, OTHER)
<balrog> rqou: believing that account doesn't mean I should excuse her for effectively directing shitbags on jeong by repeatedly bringing jeong up
<qu1j0t3> rqou: i think everyone does? but why conflate Jeong and Vice?
<awygle> i don't really have any context for what's going on with jeong at the nyt, again i only know of her through wu so i've only seen her "you gotta be fucking kidding me" tweet
<balrog> rqou: if that makes sense
<qu1j0t3> awygle: yeah this is something unrelated
<awygle> "people hate women of color" is not a new problem unfortunately so i wouldn't be surprised if there were hit pieces and whatnot, i just haven't seen them
<qu1j0t3> awygle: yeah, and certain groups will do anythign to stop them writing for prominent papers. ugh.
<balrog> rqou: one other thing is that Sarah Jeong, after that aforementioned tweet thread, has not continued to voice said opinions about Wu, while.... https://twitter.com/RealSexyCyborg/status/1024780015706075137 from yesterday
<qu1j0t3> i don't think we need to relitigate this. I think most of us are 100% behind Wu on the Vice shenanigans. I certainly am.
* awygle would like to express a desire for the channel to move on from this topic, as it seems unlikely to go anywhere good
<qu1j0t3> ^^
<balrog> thanks
<shapr> gosh I love FPGAs
<qu1j0t3> shapr: Gosh I love you!
<shapr> speaking of which, did you see Microsoft's E2 EDGE cpu design?
<awygle> yes, jan gray was very excited
<shapr> awygle: you know jan gray?
<awygle> shapr: i follow him on twitter, and i met him at the one seattle fpga meetup that's actually happened
<awygle> (okay two happened but one was a xilinx sales pitch so i didn't go)
<shapr> I desperately want a copy of the E2 bitstream, if I can't get the HDL source
<shapr> I want to know how it compares to the graph reduction cores like the reduceron
<awygle> well the name's not as good, for starters
* shapr snickers
<qu1j0t3> haha
<awygle> why the fuck is visual studio trying to open My Music
<awygle> more importantly, why is it _failing_ given that it's running as _administrator_
<shapr> anyway, the whole article is interesting: https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10/
* awygle leaves IRC to fix garbage windows permissions, again
<shapr> downside of graph reduction CPUs is that they require way more memory bandwidth
<shapr> from what I understand of EDGE ( https://en.wikipedia.org/wiki/Explicit_data_graph_execution ) , they're finding strongly connected components of the execution graph
<shapr> and then packaging those up into single 'chunks' where a bunch of work can be done without hitting main memory
<sorear> edge is dataflow, not graph reduction
<sorear> i've read some of the past papers, it has ~nothing in common with haskell
<shapr> fair enough
<shapr> sorear: any thoughts on the E2 core?
<sorear> this is the first i've heard of the specific core
<azonenberg_work> Soo guys
<azonenberg_work> I'm going to be making an improved user manual for jtaghal and jtaghal-apps
<azonenberg_work> right now there is basically no documentation :p
<shapr> will it have javascript animations?
<azonenberg_work> What format do you think makes sense? the two obvious options are github wiki and latex pdf
<rqou> github wiki please
<azonenberg_work> there will also be doxygen on the C++ codebase for the library proper, i have comments there but it needs lots of work
<shapr> pandoc can get you just about anything from just about anything
<azonenberg_work> its incomplete and out of date
<shapr> I'm willing to help with LaTeX
<azonenberg_work> oh i can latex easily enough
<azonenberg_work> its more a question of, wiki or offline pdf
<azonenberg_work> as the target
<rqou> i don't ever want to see "there's no line here to end" "overfull hbox" ever again now that I'm finished with academia
<shapr> eh, I enjoy writing LaTeX
<shapr> :-D
<shapr> does github wiki allow PRs? I've never tried to edit some other project's wiki
<azonenberg_work> "Well, my paper's due at midnight
<azonenberg_work> And I can't get the layout just right
<azonenberg_work> And I write it up in LaTex"
<azonenberg_work> And an emergency stop
<azonenberg_work> With an underfull h-box
<gruetzkopf> autobuilt, properly linked pdf?
<azonenberg_work> gruetzkopf: yeah thats what i have for the gp4par docs right now
<azonenberg_work> I'm going to start with an end user manual for jtagd, jtagclient, and jtagsh
<gruetzkopf> sadly there's no really great process for building epub/mobi
<azonenberg_work> That seems to make sense as a github wiki
<shapr> gruetzkopf: pandoc claims some support for epub, or do you mean wiki -> epub,mobi ?
<pie__> ugh github wiki sux
<shapr> pie__: what's better?
<rqou> certainly not latex :P
<pie__> i dont want to admit it but plain old nicely formatted html might not be a horrible idea
<rqou> heh i would accept that too as long as someone who isn't me can write a stylesheet to make it look slightly less awful
<pie__> and the beginning of the "nicely formatted" curve is asymptotic in ...ugh fuck it, overcompliated sentences
<rqou> not a fan of browser default styles
<pie__> just center it, 800px wide or something and its already a shitton greater than a big blob of text
<pie__> thats about all i know :D
<pie__> but really id probably just torture myself with latex
<rqou> badness 10000 badness 10000
<pie__> because im dumb
<qu1j0t3> pie__: nicely formatted html math. yepppp
<qu1j0t3> pie__: srsly tho jsmath seems to work ok
<rqou> IME whatever thing that ipython/jupyter uses to render latex math seems to work significantly better than real latex
s1dev_ has joined ##openfpga
<rqou> (not so great when i try to export my problem sets though, since it leads to bullshit mismatches)
<pie__> inb4 it uses latex
<pie__> i like whoever wrote this
* pie__ isnt actually using swig for anything
<rqou> i have not heard much praise for swig
<rqou> but i haven't personally used it
<rqou> I really wish Rust had a way to hook into the compiler after all names are resolved (rather than the current "after tokenization")
<rqou> a lot of auto-API-binding things would be significantly easier
<awygle> azonenberg_work: literally why not both
<azonenberg_work> Woo passed insulation inspection
<azonenberg_work> Good to hang sheetrock :D
<rqou> nice
<rqou> now your house can be nice and warm?
<azonenberg_work> we've had the hvac on for a week or so
<azonenberg_work> since we hit the ~80% complete mark on ceilings
<azonenberg_work> i figured i could handle the high energy bill for a few days and it was really hot
<azonenberg_work> Running out to the tool rental place now to get the lift for hanging rock on the ceilings
<awygle> it's nice and cool today though!
<pie__> just centered, already much better
* awygle basks in "64 and raining"
<pie__> ugh
<cyrozap> <pie__> ugh github wiki sux
<cyrozap> Personally I prefer to just use Markdown files in a standard Git repo. That way, anyone can fork and edit it.
<s1dev_> awygle, pretty nice weather. Apparently the Blue Angels will practice in it based on the sounds I've been hearing out the window
<awygle> oh really? cool
<rqou> azonenberg_work: so, think your house will be put together enough to live in by December? :P
<azonenberg_work> awygle: yeah it was annoying, i tried to look for insulation leaks with the FLIR
<azonenberg_work> but inside and outside were almost the same temp :p
<awygle> "oh darn i'm no longer boiling"
<awygle> solution - reverse the direction of your HVAC
<azonenberg_work> And the blue angels buzzed me on my way to work yesterday
<awygle> look for cold spots
<azonenberg_work> So they're practicing now :p
<azonenberg_work> rqou: we just rented the sheetrock lift, waiting for them to drop it off
<rqou> wait why do you need a lift?
<gruetzkopf> because sheetrock is annoying to handle and easily damaged on the edges
<azonenberg_work> rqou: have you tried to sheetrock a ceiling before?
<azonenberg_work> if you had, you'd know why i got one :p
<gruetzkopf> this usually involves 2 people and a yard brush :P
<azonenberg_work> Lol
<azonenberg_work> I've got myself and $wife with a bad back and inner ear problems (so she can't stand on a ladder)
<balrog> yeah if I were doing a ceiling I'd want a lift too
<azonenberg_work> its only $116 a week
<rqou> whee, active-high vs active-low strikes again
<rqou> fortunately i had hedged for this and had two resistor pads (one DNP)
<rqou> ECO time :P
<azonenberg_work> Lol
<gruetzkopf> happens way too often
<awygle> sheetrock is the worst
<shapr> azonenberg_work: personally, I feel that you had the best strategy for distracting people from an unwanted topic, throw out an opportunity for bikeshedding!
<gruetzkopf> prjchibi board?
<azonenberg_work> Speaking of bikeshedding
<gruetzkopf> building a bike shed?
<azonenberg_work> no, but i have a fun idea of how i might want to do the management CLI for my switch
<azonenberg_work> So, there is always going to be a kintex7 for the switch fabric
<azonenberg_work> I also need a CPU for the CLI, and a small FPGA for I/O expansion since the kintex fbg484 doesnt have enough pins, and going ffg676 would mean adding more pcb layers
<azonenberg_work> Idea 1: Octavo OSD3358 + spartan7
<azonenberg_work> Running linux and openssh
<azonenberg_work> Idea 2: Moving both into a Zynq would be about the same price and less PCB space, i don't need tight coupling
<azonenberg_work> Still runnin linux and openssh - but this would mean doing DDR layout myself
<azonenberg_work> Idea 3: STM32F7 can run uclinux - so have a stm32f7 plus a spartan7 (this is the least expensive option so far and would probably also use less power)
<azonenberg_work> No DDR layout but probably a parallel sram on the stm32
<awygle> lol uclinux
<azonenberg_work> Anyway, continuing down the pile of ideas
<azonenberg_work> Bare minimum SSH doesnt seem that complex if you dont implement tcp port forwarding, x forwarding, and all that other stuff
<azonenberg_work> So I could do TCP/IP and symmetric crypto in the FPGA, then have stripped down libsodium for ed25519 key exchange and the ssh app-layer protocol on the stm32
<azonenberg_work> Bare metal, no os
<azonenberg_work> support aes128-gcm and ed25519 as the sole cipher suite
<azonenberg_work> using verified pubkey crypto code and as much of the low level parsing as possible in RTL
<azonenberg_work> am i crazy or does that sound like a frighteningly viable option? :P
<azonenberg_work> So basically the kintex does the gig/10g switch fabric
<azonenberg_work> It has a few fast LVDS links to the spartan
<azonenberg_work> The spartan has a 100M PHY hanging off it for the management port, I2C/MDIO to all of the low speed stuff, some internal logic for power rail sequencing and sensor monitoring of the line cards
<azonenberg_work> then a MII link to the stm32
<azonenberg_work> stm32 then has a uart, spi, or whatever back to the kintex for executing CLI actions
<daveshah> Why not just picorv32 etc instead of STM32?
<azonenberg_work> Because then i'd be consuming a lot more fpga resources on sram for code and data
<gruetzkopf> do you have a few spare LVDS links on the spartan so people can implement terrible ideas?
<azonenberg_work> and i'd probably need an external ram
<rqou> azonenberg_work: you probably don't want "uclinux" the distro
<azonenberg_work> rqou: i really want to avoid linux period
<rqou> just "nommu linux"
<azonenberg_work> which is why i *wanted* a bare metal ssh library
<awygle> yeah that was what i meant about "lol uclinux"
<azonenberg_work> But no good one seems to exist
<awygle> uclinux hasn't been a serious thing for a long time
<azonenberg_work> gruetzkopf: Soo my current architecture proposed for the system as a whole
<azonenberg_work> Line cards have a q-strip bringing out reset, power rail enables, i2c, mdio, and 8 lanes of SGMII
<azonenberg_work> Backplane connects a bunch of line cards to brain
<azonenberg_work> Brain contains the kintex, its power supply, the front panel SFP+ modules, the front panel RJ45s for CLI SSH and RS232
<rqou> yeah, jeff dionne freely admits that uclinux went to shit after he handed it off
<azonenberg_work> The brain will also have a pair of qth-060 or qth-090's, depending on final PCB size
<azonenberg_work> that connect to a CPU SoM
<daveshah> The last time I ran uclinux was on a Nintendo DS tbh
<azonenberg_work> The SoM will have a stm32f7 and a spartan7
<daveshah> That would have been around 2009
<azonenberg_work> exact p/n's TBD
<daveshah> No idea if its changed much
<azonenberg_work> The QTHs will break out basically all of the GPIOs on the stm and the fpga
<azonenberg_work> except for whatever goes between them, to boot flash, to the PHY, etc
<rqou> what i was told is that jeff went to japan and handed off uclinux and the new maintainers dropped the ball
<azonenberg_work> Most of the FPGA pins will probably be used for talking to the kintex or IO expansion
<azonenberg_work> But i might have a few left over
<azonenberg_work> the STM pins will be broken out to the connector but largely unused
<azonenberg_work> as my plan is for it to basically be a "CPU on a stick"
<azonenberg_work> Input: cleartext SSH connection layer packets (transport layer plus TCP/IP side will be in FPGA)
<azonenberg_work> output: register writes to the kintex
<gruetzkopf> (also: who thought that the micro-d connector was a good idea)
s1dev_ has quit [Quit: Leaving]
<awygle> daveshah: yeah i last ran it on a PSP
<rqou> cr1901_modern why are you always a weirdo trying to run strange protocols?
<rqou> trying to run classic doom multiplayer? :P
<awygle> okay so. i'm trying to build a zynq thing, and it has an 8-bit bus of bidirectional DDR outputs. and what's happening is that it works fine when it's a *one*-bit bus, but as soon as i add a second bit, i get an error that the tristate control signal is being routed from the ODDR into the fabric, which is illegal. but i'm not doing that. what is going on, and how can i get more information?
<rqou> sounds like you could use a xray :P
<awygle> okay but like, a suggestion that works _today_ would be helpful lol
<daveshah> awygle: it's been a while since I did anything like this (tristate OSERDES for DPHY)
<daveshah> Are you able to post your code?
<daveshah> Might trigger some memories
<awygle> daveshah: hrmm possibly, give me a second to gather it and put it in a presentable form.
<cr1901> rqou: Bite me :). And it's for a blog post and I needed a section on ARP. I figured asking about other layer 3 protocols would give me an idea of how to word "why is ARP necessary"?
<qu1j0t3> cr1901: dunno at what level you want that answered but this might be of interest ? https://apenwarr.ca/log/?m=201708#10
azonenberg_work has quit [Ping timeout: 240 seconds]
<cr1901> It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address
<cr1901> Well, that _is_ relevant lol
Bike has joined ##openfpga
<gruetzkopf> VPN?
<rqou> um, cr1901: IPoIB
<gruetzkopf> all layer-3 interfaces
<gruetzkopf> everything on tun, SLIP, wg...
<cr1901> I was quoting the article
<cr1901> I forgot the quotes
<gruetzkopf> ah
<mithro> https://lujji.github.io/blog/bare-metal-programming-stm8/ -- you can get sub $0.20 USB devices in that series IIRC
rohitksingh has quit [Remote host closed the connection]
<rqou> qu1j0t3: that article is actually pretty great
<qu1j0t3> yw
s1dev_ has joined ##openfpga
azonenberg_work has joined ##openfpga
<awygle> how many actual FPGA resources would you need to use to take in a source-synchronous interface and pipe out the exact same data on 8 copies of the exact same interface?
<awygle> seems like that could almost be done fully combinatorially
azonenberg_work has quit [Ping timeout: 240 seconds]
<s1dev_> 3 buffers? fan-out of 4 and all
<awygle> i guess it depends on how fast the internal buffers are vs the iobs... might have to slow and widen the datapath and then shrink and speed it up again?
digshadow has quit [Ping timeout: 265 seconds]
<awygle> which i guess might even require the SERDES
<awygle> (xilinx ISERDES version not gigabit)
azonenberg_work has joined ##openfpga
Miyu has quit [Ping timeout: 240 seconds]
<azonenberg_work> awygle: you'd want to retime for sure
<azonenberg_work> But minimal. a bunch of ioserdes and a pll plus fabric routing
<awygle> *nod, nod* cool
<awygle> oh yeah i guess you do need 2x PLLs to retime and unretime
<awygle> but that's what IOPLL is for (i assume)
<azonenberg_work> Why two plls??
<azonenberg_work> is this bidirectional?
<awygle> don't you have to go down to a fabric clock and then up to the source-synchronous clock on the output?
<azonenberg_work> how fast is the interface?
<awygle> if you just forward the SS clock it won't be SS anymore
<awygle> uh hang on, math.
<azonenberg_work> you can push a fabric clock to an OBUF via an ODDR
<azonenberg_work> tie the inputs to hard wired 0 and 1
<awygle> like, 625 Mbps?
<azonenberg_work> what FPGA? artix7?
<awygle> yeah
<awygle> (this is an "is this even possible" analysis, to make it clearer)
<azonenberg_work> So say a 5:1 serdes rate for 125 MHz parallel clock
<azonenberg_work> Is it differential?
<azonenberg_work> Or single ended