<whitequark> I have uh, about a watt
<gruetzkopf> the latched versions are less common, but not hard to find at all
<gruetzkopf> no clue
<whitequark> ok, let me grab one and try to find a datasheet
<whitequark> doubt it eats more 100 mA on 12V
<whitequark> that seems excessive
<whitequark> okay, i have a cisco bl50r
<gruetzkopf> that's one of the more blinky ones iirc
<whitequark> it has seven LEDs
<whitequark> and four switches
<gruetzkopf> the ati centrecom 210t is extremely common for RJ45 transceivers
<gruetzkopf> and i have some ATI MAUs which have four AUI ports and connect to thicknet cable
<whitequark> gruetzkopf: L77SDA15S1ACH4R seems OK?
<gruetzkopf> oh, a proper implementation
<gruetzkopf> sure
<gruetzkopf> use differential drivers with direction switches or have one for CO so one could use a crossover cable and directly connect to a NIC
<whitequark> OOOH good idea
<gruetzkopf> i have been there and done that (AUI crossover)
<whitequark> so... TXO/TXI/RXO/RXI/CO/CI/XOVER on the pins?
<whitequark> I can also add the 8th pin that enables/disables 12V boost
<whitequark> in case your AUI is fucky and needs reset
<whitequark> then you could do 2 of them per glasgow
<gruetzkopf> hmm, thinking about available diff-drivers, 2* (TXO, CO, RXI, CI) would fill one 4-port driver and one 4-port receiver
<gruetzkopf> but i guess going for two per glasgow-port is a bit on the fringe side of power use
<whitequark> the spec says 6W
<whitequark> I can only do a boost for 1W
<gruetzkopf> yeah
<whitequark> I can throw in a barrel jack, not sure how to switch between it and boost
<kc8apf> after all the TBT3/USB4 discussion, I'm imagining a Futurama Bender-style rant about building my own universal external bus protocol
<gruetzkopf> i mean i wouln't bother switching the direction of the transceivers and simply have four
<gruetzkopf> TX, RX, CI, CO
<gruetzkopf> if you connect directly to a host you need a DA15M-DA15M cable anyways
<whitequark> I'm confused
<whitequark> where do OEs go?
<sorear> why do CI/CO need to be differential transceivers
<whitequark> because AUI is specified that way?
<whitequark> gruetzkopf: or rather, either I need an OE for CO/CI, or I need a connector that provides CO/CI separately
<whitequark> in the former case 2 per glasgow port won't happen
<gruetzkopf> CI is on 2/9, CO on 7/15?
<whitequark> actoh
<whitequark> *oh
<whitequark> nevermind, I was looking at one of those pinout sites instead of 802.3
<gruetzkopf> even wikipedia gets it right
<whitequark> ok yeah sure
<whitequark> also there's no real need for the boost enable because I can just shut down the entire port
<gruetzkopf> section 7.6.3 of 802.3 is of course the way to go there
<whitequark> gruetzkopf: ok, so, I think I can make 2 per port viable
<whitequark> if instea of mounting the adapter directly on glasgow, i require you to use two short IDC runs
<gruetzkopf> "short" may be up to 50m ;)
<whitequark> er
<whitequark> 50m?
<whitequark> why?
<gruetzkopf> spec
<whitequark> on what
<gruetzkopf> ah, you mean for the glasgow side
<whitequark> yes
<whitequark> each adapter would have two idc sockets
<whitequark> and you daisy chain them
<whitequark> up to two times
<gruetzkopf> going for a IDC DA15 connector and ribbon there would enable 50m
<whitequark> between DTE and MAU?
<gruetzkopf> yeah. the max length of the AUI link is specified as 50m
<whitequark> that seems extreme
<whitequark> that's like half the fucking segment
<whitequark> you could make a network entirely using p2p AUI links
<whitequark> ...
<whitequark> is that what it's for
<gruetzkopf> i mean thicknet cable is really annoying
<gruetzkopf> and "connect whole office to one 4-port MAU" was a real usecase
<whitequark> amazing
<gruetzkopf> also 10base5 segment length is 500m iirc
<whitequark> yeah, already noticed
<whitequark> ok
<whitequark> so do you think the daisy chain idea is good?
<whitequark> enables your use case, doesn't interfere with most people who only want one MAU
<whitequark> i don't even *have* two
<sorear> so the 10base5 is 500m long, then you have AUIs running 50m off the cable's flank, covering a total area of 50 000 m²
<gruetzkopf> it's certainly a neat idea
<whitequark> alrighty
<whitequark> seems like a real simple board, let me just make it right now
<whitequark> only nontrivial part is the 12V boost
<whitequark> do you know which xceivers will work?
<gruetzkopf> not really
<gruetzkopf> all the 10base equipment here is too new to have discrete ones
<whitequark> oh i mean
<gruetzkopf> i know
<whitequark> can i use something dumb like rs485?
<whitequark> right
<gruetzkopf> shouldTM work
<gruetzkopf> i've been informed that the PROPER connector is AMP 5747845-4 (which can accept slide latches)
<whitequark> btw I think bidi drivers would not have worked
<whitequark> because the receiver terminates the cable
<gruetzkopf> not sure if i want to encourage people using it in a permanent way
<whitequark> AMP?
<gruetzkopf> TE connectivity these days
<whitequark> what's wrong with the connector? expect EOL soon?
<gruetzkopf> nothing (they're both the same footprint anyways, as are almost all DA15 connectors)
<gruetzkopf> the one i named is apparently better for those sliding latches (which are AMP 5745583-5 )
<gruetzkopf> but "the cheapest DA15F connector with 'european footprint'" matches all real requirements
<whitequark> european footprint?
<gruetzkopf> distance between front of connnector and pins, mostly
<gruetzkopf> really, for this application all of them should work
<whitequark> ok
<whitequark> two SN75179B seem ok?
<gruetzkopf> classic part, but yes
<whitequark> wait, is it actually fast enough
<gruetzkopf> uh, goof point
<whitequark> nope, is not
<whitequark> spec wants 7 ns rise/fall time (I think it's 7)
<whitequark> let me find something less vintage
edbordin has quit [Ping timeout: 260 seconds]
<whitequark> gruetzkopf: ADM3490E?
<gruetzkopf> 12MBit/s specced
<gruetzkopf> should work
<whitequark> hm
<whitequark> afaict will work yes
<swetland> what's the most modern/correct way of declaring clock constraints in nextpnr-ice40?
<whitequark> set_frequency <signal> <MHz> in pcf file
<swetland> ooh, I just found --pre-pack clocks.py w/ ctx.addCLock("name", MHz) but simple pcf constraints are nicer
edbordin has joined ##openfpga
edbordin has quit [Ping timeout: 260 seconds]
edbordin has joined ##openfpga
<edbordin> am I missing something or does prjtrellis not have a script to run all the fuzzers?
<whitequark> gruetzkopf: ok, so this doesn't quite work
<whitequark> gruetzkopf: first, the RS-422 transceivers are less tolerant to high voltage DC to AUI pin fault
<whitequark> that's fine I guess
<whitequark> second, 802.3 limits the current to 150 mA at all times, and ADM3490E will do 250 mA
<whitequark> third, 802.3 uses 160 mV threshold voltage, and ADM3490E will do 200 mV
<whitequark> fourth, and worst of all, 802.3 requires 1315 mV max differential voltage, and these drivers will do, uh, much more
<whitequark> actually the latter can be matched
OmniMancer has joined ##openfpga
<whitequark> alright, awygle has suggested a matching network, so that problem is solved :)
OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined ##openfpga
Ekho- is now known as Ekho
<omnitechnomancer> edbordin: prjtrellis does not currently have a script that runs all the fuzzers no
rohitksingh has joined ##openfpga
<whitequark> gruetzkopf: can you review? https://imgur.com/a/7hFLgPR
Bike has quit [Quit: Lost terminal]
<whitequark> already did that
<whitequark> re
<whitequark> *er
<whitequark> wrong channel
_whitelogger has joined ##openfpga
<edbordin> omnitechnomancer yeah, I wrote a couple of lines of bash instead. man these fuzzers really do take a while :P
<omnitechnomancer> there is a LOT of routing
<omnitechnomancer> are you running the trellis or tang ones?
<edbordin> tang
<edbordin> I mainly wanted to check the tools were working and then figured it couldn't hurt to just start running the lot
<omnitechnomancer> basically everything except the routing ones should be fast
<omnitechnomancer> the routing ones are trial and erroring every possible routing connection of specific types
<edbordin> yeah I could see it was basically a case of combinatorial explosion hehe
<edbordin> anyway I'll just leave it running for now. I'm a bit tired today so wouldn't have gotten much further anyway
<edbordin> hmm, I'm having trouble finding a .db that has anything in it after fuzzing though
<edbordin> omnitechnomancer after fuzzing mslice_lut_init are the results supposed to be in prjtang/database/eagle/tiledata/plb/bits.db ?
<omnitechnomancer> yes, if you want html run tools/html_all.py and give it an output directory as an arg
<edbordin> the .db file is empty :/
<omnitechnomancer> those fuzzers will wind up adding stuff to pib and plb
<omnitechnomancer> hmmm
<omnitechnomancer> interesting
<edbordin> well, it has the headings "# Routing Mux Bits\n\n# Non-Routing Configuration\n\n# Fixed Connections"
<omnitechnomancer> hmmmm
<edbordin> I stole create-empty-db.sh from prjtrellis so perhaps I haven't initialised it properly
<omnitechnomancer> um
<omnitechnomancer> there should be a create-empty-db.py in the tools dir to run
<edbordin> ah I see it. "create_empty_bitdbs.py"
<omnitechnomancer> but it just makes those files in those folders so the db code in the library doesnt complain
<edbordin> hmm, well. I guess I'll try building the folders with your script and see if it starts working
<omnitechnomancer> oh one question
<omnitechnomancer> what did you run before all this?
<edbordin> source environment.sh
<omnitechnomancer> did you run annotate_tilegrid.py?
<omnitechnomancer> at some point after extracting it
<edbordin> and to build the C++ I just did "cmake . && make"
<edbordin> no I did not run annotate_tilegrid. that would probably be the problem
<omnitechnomancer> yes
<omnitechnomancer> that is what staples the tile sizes into the tilegrid
<omnitechnomancer> I really should list the steps in the README.md
<edbordin> looks like create_empty_bitdbs.py expects a directory structure to already be there
<omnitechnomancer> it will want the tilegrids I think
<edbordin> oh right. *facepalm*
<edbordin> I just had to order wrong
<edbordin> the order*
<omnitechnomancer> run get_tilegrid_all.py then annotate_tilegrid.py then the empty bitdbs one
Jybz has joined ##openfpga
<omnitechnomancer> then the fuzzers should work
<edbordin> roger that
<edbordin> OK, yeah. the script from trellis didn't run annotate_tilegrid which is why it almost worked but didn't
<omnitechnomancer> annotate_tilegrid is not a trellis thing
<omnitechnomancer> trellis gets the benefit of the toolchain telling you how large the tiles are in the bitstream
<edbordin> yep. in summary trying to copy trellis was not a good idea on my part
<omnitechnomancer> for tang the ones I know I had to work out from repetitions in positions
<omnitechnomancer> copying trellis is fine as long as you make necessary adjustments
<edbordin> yeah, that's better. it's building the db now
Asu has joined ##openfpga
jjjaaaccckkk has quit [Remote host closed the connection]
Zorix has quit [Ping timeout: 260 seconds]
Zorix has joined ##openfpga
_franck_ has quit [Ping timeout: 246 seconds]
<ZirconiumX> I've got to really admire Intel's commitment to open source
<ZirconiumX> Putting debug symbols in the release builds of Quartus
<ZirconiumX> omnitechnomancer: do Anlogic have internal muxes like ECP5 appears to? (So you can mux up to bigger LUTs)
<omnitechnomancer> ZirconiumX: some stuff in the sim models implies they do, but I think only the ones that combine the two LUTs in a slice are ever used AFAIK
<ZirconiumX> Ah, I see; so that means it still tops out at LUT5 then?
<omnitechnomancer> They have a mux that lets you use one of the MI inputs (the one that usually can feed the FF directly) as another MUX input to combine both LUTs into a bigger one, so the mslices become LUT5s and the lslices LUT6s
<ZirconiumX> Altera seem to have no way of muxing beyond what a single ALM provides
<omnitechnomancer> There is an implication that there is a similar situation to the ECP5 going on with the other MI input muxing other stuff together but I am not sure if it never worked out or if they couldnt make the tools effectively use it so they dumped it from the tools
<omnitechnomancer> the datasheet mentions being able to combine up to LUT7
<ZirconiumX> Sounds like something fun to investigate
<omnitechnomancer> but the tools map output only seems to use up to LUT6
<omnitechnomancer> so perhaps there is more but it would need someone to do some bitstream fiddling to find out with an actual chip
<omnitechnomancer> for now I will not bother to look into it since other stuff is higher priority for having anything useful occur
<ZirconiumX> omnitechnomancer: did I mention that I wrote an ALM packing pass for Yosys to get a better idea of area?
<omnitechnomancer> ZirconiumX: no you did not
<ZirconiumX> Using PicoSoC as a benchmark, Quartus produces 2.4k ALMs in balanced mode and 1.9k ALMs optimising for size
<ZirconiumX> Yosys gets 2.6k ALMs, but my packing is not the most efficient in the world
<omnitechnomancer> Ah
<omnitechnomancer> I actually do wonder how one handles a flow that makes too large a number of large LUTs such that they cant all be placed, do you just fail and tell the user to give synth different settings?
<ZirconiumX> Pretty much; it's a placement constraints just like running out of multipliers
<ZirconiumX> My ABC9 lut table has LUT6s listed with twice the area of the others
<ZirconiumX> Which makes ABC dial down on LUT6 packing everything it can
<omnitechnomancer> ah okay you can tell it how much area things take up
<omnitechnomancer> I guess one problem I will have is that LUT5s and LUT4s kind of have equal area, but if you have more than a certain number of LUT5s they cant place anymore
<omnitechnomancer> or start eating larger area
<omnitechnomancer> because there are two ways to make a LUT5
<ZirconiumX> The Cyclone V is actually pretty slow in terms of logic delay, and Quartus must pull off a bloody miracle to get it to run as fast as it does
<omnitechnomancer> interesting
<ZirconiumX> Like, if you want to build an adder, the delay from input to carry-out is like 1.2ns
<ZirconiumX> Which is pretty huge
<omnitechnomancer> because yea, LUT4 can be placed in the LUTs on any slice, LUT5 can take a whole mslice or half of an lslice, LUT6 takes a whole lslice
<ZirconiumX> Honestly, try to pull up some delay numbers and prototype
<omnitechnomancer> Also if you have two LUT4s with common inputs you can place them both in one half of one of the LUTs in a n lslice
<ZirconiumX> That's what I did
<omnitechnomancer> That will probably help figure out the best one, for speed
<ZirconiumX> Yosys instructs ABC to optimise first by delay and then by area
<ZirconiumX> (thus if you look at the ABC9 stats, delay will decrease first before area does)
<omnitechnomancer> ah yep
<omnitechnomancer> though I cant imagine the ECP5 multi slice muxed wide luts win that much in delay?
<omnitechnomancer> I guess they might over building it out of more LUTs
Patater_ is now known as Patater
<ZirconiumX> omnitechnomancer: An ECP5 LUT6 is 618ps; a CV LUT6 is 605ps, but an ECP5 LUT4 is 379ps to the CV's 462ps
<omnitechnomancer> Ah yes I see, so chaining slices very slightly slower than a CV LUT6 but LUT4s are faster
<omnitechnomancer> can you get any improvement by picking which intputs to use for the LUT4?
<ZirconiumX> And you're more likely to encounter LUT4s than LUT6
<ZirconiumX> It's a bit tricky to measure
<omnitechnomancer> I know ECP5 has variable delay depending on which inputs are used, so when doing <4 width it matters which ones you pick as your inputs
<ZirconiumX> An ALM has overprovisioned I/O - 8 combinational inputs, and a whole host of outputs
<ZirconiumX> Indeed, that applies for the CV
<ZirconiumX> But you end up with two LUT4s in an ALM
<omnitechnomancer> because really its a tree of MUXes with 16 config cells
<omnitechnomancer> providing the LUT values
<omnitechnomancer> do those two LUT4s have equal or unequal delay?
<ZirconiumX> Equal, judging by the numbers I have and my general knowledge of the ALM
<ZirconiumX> Because they're delays relative to the combinational outputs
<omnitechnomancer> yes
_franck_ has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Bike has joined ##openfpga
Bob_Dole has quit [Ping timeout: 260 seconds]
Bob_Dole has joined ##openfpga
<tnt> In nmigen, can you define a platform that always include a given submodule and that has resource that are connection to that always included submodule rather than IO pins ?
<whitequark> no, but this has been requested by ZirconiumX as well
<whitequark> can you open an issue? I'll need to think of a design
<whitequark> but it has to be supported eventually
<whitequark> what do you need it for? hard CPU?
<tnt> no, actually, a "soft cpu + usb core" that's just exposed as a fifo in/out to the user of that platforms.
<whitequark> ok, so it can't be just an Instance, hmmm
<whitequark> I'm actually not sure if nmigen's platform interface is entirely appropriate for this
<whitequark> but let's not be overly strict here
<whitequark> it doesn't seem too inappropriate either
<whitequark> ok, yes, please open an issue and list your wishes/requirements in detail
<tnt> well, this would probably end up being an existing design that already exists in verilog, so it wouldn't be far from an "Instance".
<whitequark> "not far" and "is specifically" is quite different here wrt some possible implementations I had in mind
<tnt> ok sure. Writing an issue now with as much details I can think of.
lutsabound has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 272 seconds]
freemint has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
<tnt> In nmigen, I get DeprecationWarning: instead of `Signal(min=0, max=123)`, use `Signal(range(0, 123))`
<tnt> Is it really range(0,123) or should it be range(0,124) ?
<tnt> Oh wait, no the 'max=' was already exclusive in the previous notation (so more like maxvalue+1 and not maxvalue)
<whitequark> yes
<whitequark> which is why I deprecated it
<whitequark> it was very confusing
ZirconiumY has joined ##openfpga
ZirconiumX has quit [Ping timeout: 252 seconds]
ZirconiumY is now known as ZirconiumX
Laksen has joined ##openfpga
Laksen has quit [Client Quit]
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
diadatp has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
<tnt> How do I stop nmigen from creating the SB_IO ?
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
<tnt> ok, got it : dir="-"
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
Asu has quit [Remote host closed the connection]
<omnitechnomancer> whitequark I think something like what tnt wanted would be helpful for exposing the package bonded SDRAM in some of the Anlogic FPGAs in an easy to use fashion, though that can just be an Instance
edbordin has quit [Ping timeout: 260 seconds]
<tnt> whitequark: Would you have any objection to supporting .il file in platform.add_file ? Obviously that would only work for yosys ... not sure if that's an issue to have something only supported on ECP5/ice40.
<whitequark> tnt: nope, this is ok
<adamgreig> whitequark: did you see the presentation about using 10SPE over i2c sda/sck traces as an i2c replacement? http://www.ieee802.org/3/cg/public/adhoc/Widger_3cg_01_0918.pdf
<adamgreig> the presentation isn't very interesting really, but the idea is entertaining/vaguely horrifying
<whitequark> ugggg
<whitequark> *uhhhh