<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>
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"
<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>
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
<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
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>
> 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
<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>
(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>
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.
<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)
<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"?
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