digshadow has quit [Ping timeout: 248 seconds]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
<whitequark> cr1901_modern: hahaha https://github.com/YosysHQ/yosys/issues/524
<whitequark> it's the general iopadmap
<whitequark> reportingsjr: well, very vaguely like BPM?
<whitequark> BMP is a debugger for Cortex CPU cores, Glasgow is a debugger for anything digital
<whitequark> as long as it doesn't have pullups lol
<reportingsjr> makes sense
<reportingsjr> whitequark: are the output drivers you are using not strong enough for most pullups?
<whitequark> the FXMA108 level shifter cannot deal with pullups
<cr1901_modern> whitequark: Thanks for the hint. Fwiw, this doesn't happen with the generic "techmap" or SB_IO (ice40 iopadmap)
<whitequark> reportingsjr: it has 50 MHz of bandwidth (in theory anyway), and it has a symmetric characteristic
<whitequark> but due to the way it implements bus hold, pullups confuse it
* cr1901_modern needs to remember how to select partial design
GenTooMan has quit [Quit: Leaving]
<cr1901_modern> whitequark: How did you only apply iopadmap to dir (In my case I am trying to get the backend to infer IOBUFs)?
<cr1901_modern> (But hey, not like GP4 verilog is portable anyway, just wanted to save time/typing. LOL)
<whitequark> cr1901_modern: select i:* o:* %i
<whitequark> i think
<whitequark> some variation on that
<whitequark> maybe */i:*
* cr1901_modern nods
<cr1901_modern> What's weird to me is that in your example iopadmap decides to completely rewrite your manual IOBUF instantiations, whereas in my case, IOBUFs are inferred but the connections are wrong.
<whitequark> daveshah: balrog: cseed replied!
<balrog> oh he did?
<whitequark> yeah
<whitequark> privately in email to me
<whitequark> just a few hours ago
<whitequark> awygle: poke?
<cr1901_modern> whitequark: Cool, with this script I got yosys to "do the right thing" https://hastebin.com/etusixoted.sql
<whitequark> you should comment in the issue
<cr1901_modern> Will do once I shrink the script a bit more
<openfpga-github> [Glasgow] whitequark opened issue #51: Make SYNC pullup smaller https://github.com/whitequark/Glasgow/issues/51
<cr1901_modern> netlist has 12 nodes of type GP_IOBUF, device only has 10 <-- err. Doesn't SLG46620 have 17 GPIOs? (and 1 Input-only)
<whitequark> nope
<whitequark> 10 GPIOs, 1 GPI, the rest is GPOs
<cr1901_modern> Then the huge diagram on page 1 of the datasheet is wrong
<cr1901_modern> Also, that's annoying. I wanted to level-shift 8-bits of data from 5V CMOS to 3.3V, now I need 4 SLG46620s to do it
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<whitequark> cr1901_modern: let me rephrase
<openfpga-github> [Glasgow] whitequark pushed 2 new commits to master: https://github.com/whitequark/Glasgow/compare/d4d1ddf89ffe...eef1e1e6dd94
<openfpga-github> Glasgow/master eef1e1e whitequark: Implement `glasgow test pll`.
<openfpga-github> Glasgow/master ab1f549 whitequark: glasgow.gateware.applet → glasgow.applet
<whitequark> it only has 10 GPIOs whose direction can be switched at runtime
<whitequark> the rest are fixed in bitstream
<whitequark> and yes it is
<whitequark> consider FXMA108 :P
<cr1901_modern> Well this would explain why you didn't use gp4s for glasgow
<whitequark> no
<cr1901_modern> (one reason anyway)
<whitequark> it's too slow
<cr1901_modern> whitequark: I don't need auto sensing for my application (vintage interfacing- big surprise), although fxma108 may very well do the trick.
<cr1901_modern> If the weak drivers from autosensing are an issues, I could prob get away with 74LVC245s back-to-back (one on 5V rail, the other 3.3V)
digshadow has joined ##openfpga
<whitequark> back to back? why?
<whitequark> just use 1t45
<cr1901_modern> whitequark: Because I didn't know 1t45 existed until 15 seconds ago :P
<whitequark> azonenberg: 74AVC2T245 is better
<whitequark> 2 bits per die
<cr1901_modern> Would make a nice breakout board for me
<whitequark> cr1901_modern: wait you said 8 bit?
<whitequark> 74ALVC164245
<cr1901_modern> I also found: 74LVC8T245
<whitequark> yeah
<cr1901_modern> Okay nevermind then
<cr1901_modern> Good to know that if they stop production tho I have some alternatives
<cr1901_modern> http://www.ti.com/product/SN74LVC8T245 whitequark: Would these work for glasgow?
<cr1901_modern> And also, how do you convert the output from 3.3v to, say 1.8v? or up to 5v?
<whitequark> no they won't
<whitequark> glasgow needs individual direction control
<cr1901_modern> Oh yea I don't need that
<whitequark> what do you mean "how do I convert"?
<whitequark> I just power it with the voltage I want
<cr1901_modern> I'm asking how are you powering the voltage translators? Do you have a boost/buck supply you control from FPGA pins to provide the transceiver voltage closest to the I/O pins?
<whitequark> no I use an LDO
<whitequark> and it's controlled by FX2LP
<cr1901_modern> Ahh
<awygle> whitequark: reporting for duty
<awygle> ... sorta. I feel like crap. But I'm here.
<whitequark> awygle: I wrote the program-ice40 applet yesterday
<whitequark> it does work, at 7.5 MHz...
<awygle> whitequark: I saw, awesome! speed less awesome. and you think that's SI?
<whitequark> I don't really know, but SI seems like an obvious culprit
<awygle> could be
<awygle> I have an action to do some front end characterization already
digshadow has quit [Ping timeout: 246 seconds]
m_w has quit [Quit: leaving]
<cr1901_modern> Is it possible to force yosys to map to INV primitive? For my 4-bit level shifter, it uses 4 LUTs, but 2 bits can use INV primitive I think
<cr1901_modern> Hrm, looks like the only pass that uses them is greenpak4_dffinv
<whitequark> cr1901_modern: the PAR will do that
<whitequark> I think
<cr1901_modern> It didn't in this case (although yosys notably creates 4 GP_INV, when there are only 2)
futarisIRCcloud has joined ##openfpga
rohitksingh_work has joined ##openfpga
<cr1901_modern> Okay I see now, gp4par decides against using INV by default if there's room to spare (I had to enable --debug to see this info)
<azonenberg> whitequark: does the 2T45 have double direction controls?
<whitequark> azonenberg: yes
<whitequark> that's the point
<openfpga-github> [Glasgow] whitequark opened issue #52: TI SN74LVC1T45 https://github.com/whitequark/Glasgow/issues/52
<cr1901_modern> Why use 1T45 compared to 2T45?
<cr1901_modern> (Just curious)
<azonenberg> whitequark: ooooh
<azonenberg> in that case i may do that
<azonenberg> my understanding was that 2T45 was ganged
<azonenberg> I havent actually made a multi-port line card yet
<azonenberg> for starshipraider
<azonenberg> only single channel characterization boards
<whitequark> azonenberg: note: not 2T45
<whitequark> 2T245
<azonenberg> Oh
<whitequark> 2T45 is ganged
<whitequark> sadly they don't have an LVC version of it :/
<whitequark> so Glasgow is stuck with discretes
<azonenberg> ah ok
bitd has joined ##openfpga
<azonenberg> i'll spend more time working on the starshipraider io cell later, right now all the time i have to spend on the project is going to rtl for the host
Bike has quit [Quit: Lost terminal]
<whitequark> awygle: do you think you can finish submitting footprints?
<whitequark> there's only two of them left, both with only minor revisions needed
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/1f6ff5db559d74836fcc8e9da1f6f277e28fc15a
<openfpga-github> Glasgow/master 1f6ff5d whitequark: Move QB traces around a bit to free up space near to level shifter.
mumptai has joined ##openfpga
<daveshah> whitequark: good to hear that you heard from cseer
<daveshah> *cseed
<whitequark> wow, kicad stm32 libs are next level shit https://imgur.com/a/KiiOxwh
<whitequark> how does anyone use them
<azonenberg> whitequark: wtfff
<whitequark> corollary
<whitequark> how does stm even design this shit
<whitequark> i bet the verilog for it is *gnarly*
<whitequark> awygle: actually, looks more like just the cypress one
<rqou> azonenberg: ping
<whitequark> awygle: sweet htanks
ondrej2 has joined ##openfpga
<whitequark> clifford: maybe you could give daveshah commit bit? cseed is not opposed to that afaict
<rqou> ping azonenberg?
mumptai has quit [Quit: Verlassend]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rqou> ping azonenberg?
<clifford> whitequark, you mean for arachne-pnr? I would, but I don't have permission to give others permissions. I just have commit permission myself.
<whitequark> clifford: ahh ok
<whitequark> I'll talk to cseed about it
<whitequark> well, I already did, actually
clifford has quit [Ping timeout: 255 seconds]
clifford has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
renze has quit [Client Quit]
renze has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
manja has joined ##openfpga
manja has quit [Client Quit]
X-Scale has quit [Ping timeout: 260 seconds]
[X-Scale] has joined ##openfpga
Bike has joined ##openfpga
[X-Scale] is now known as X-Scale
<balrog> azonenberg: looks like Intel has a 10GBase-T PHY that has a full datasheet and is generally available. Unfortunately it requires (available) firmware to run its internal control MCU
rohitksingh has joined ##openfpga
genii has joined ##openfpga
indy has quit [Ping timeout: 255 seconds]
indy has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Quit: Leaving.]
SpaceCoaster has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<daveshah> q3k: I've got the ecp5 board today, thanks!
<felix_> hm, i wonder which script was used to generate the dfn/qfn footprints in kicad. using that script for the footprints i need would probably make it easier to get the stuff upstreamed
<whitequark> felix_: there's a wizard
<whitequark> hit the button in pcbnew
<felix_> ah, thx
<whitequark> also, yay, another person upstreaming things
<felix_> hmm, that qfn wizard only supports parts taht have the same number of pads on each side; the package i want to design has two short and two long sides :/
<whitequark> wait really?
<felix_> yeah, either you or awygle said that upstreaming things into those libraries is relatively painless, so i'll try to do that. also at least another pair of eyes looking at the stuff might catch some bugs ;)
<whitequark> hm, indeed, it doens't support that
<felix_> gs12281 and gs12241 are the parts i want to create footprints for at the moment
<whitequark> I think your closest chance is making a footprint with the right size and then moving pads
<whitequark> it kind of sucks though
<felix_> or just patch the wizard; it's written in python, so i probably don't have to recompile kicad
<whitequark> or that yeah
<awygle> and then upstream the wizard changes! we put an upstream in your upstream
<reportingsjr> felix_: there is a kicad-library-utils repo that has a bunch of symbol amd footprint generating scripts.
<reportingsjr> whitequark: i think the stm32 symbols were redone a few weeks back to make them more sane
<whitequark> reportingsjr: I believe I'm looking at the up-to-date ones
<whitequark> well, I pulled today
<whitequark> maybe if they aren't merged yet
carlosFPGA has joined ##openfpga
<felix_> the kicad-library-utils repo doesn't contain the footprint wizards
<awygle> the construction outside my window sounds like a giant trying to get the last bit of chili out of a bowl with a fork...
m_w has joined ##openfpga
<qu1j0t3> nice
<qu1j0t3> also, i've been guilty
rohitksingh has quit [Quit: Leaving.]
eduardo_ has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<rqou> wow blog posts/writeups take _forever_ to write
<shapr> yup
<awygle> yeah i always have that feeling too. "oh i'll just whip this up.... oh shit it's 4am"
<awygle> daveshah: awesome!
<awygle> this was finding the LUT bits in the bitstream and poking them into a new shape?
<daveshah> Yep
<daveshah> Also unpacking and repacking a bitstream, so it means all the crcs etc are good
<awygle> yup
<shapr> spiffy!
<daveshah> Also changing the IDCODE so I use the free version of diamond to run stuff on a ECP5UM5G
<awygle> ooooo
<awygle> nifty
<daveshah> Obviously no SERDES that way
<awygle> well, not yet :p
<daveshah> But it feels a lot more ethical than the "alternative" options
<awygle> daveshah: do you have any dev boards for ECP5 parts that work with free Diamond?
<daveshah> No, this is my only boards
<daveshah> *board
<awygle> daveshah: do you want one? i could send you one
<daveshah> Keep it for now, if you think you might help out with the ecp5 stuff :)
<awygle> well, i also have a versa, and a paid diamond license ;)
<daveshah> awygle: Awesome, that will be useful for SERDES fuzzing
<azonenberg> awygle: by "a versa" i assume you do not mean a shiny new FEI dual-beam
<kc8apf> daveshah: nice!
<awygle> azonenberg: no lol. Lattice ecp5 dev board is called versa
<awygle> But I also have a flea Ohm with a 25F ecp5 that realistically I'll never use
<whitequark> awygle: hm I might be interested in that
<daveshah> Happy for you to have it whitequark if you want
<awygle> whitequark: sure!
<daveshah> I'm realistically not got much more hardware stuff for a while
<daveshah> Very much just software fuzzing for a while
rohitksingh has quit [Quit: Leaving.]
<awygle> it seems like the two things that are available now are "fuzz all the things" and "yosys support"
<whitequark> I'll look at ECP5 once Glasgow is shipped
<awygle> which will meet in the middle at ~the valley of darkness~ place+route
<daveshah> I'm considering a masters project in that direction
<daveshah> Which is why it would be great to get fuzzing done before October ish
<whitequark> daveshah: noted
<whitequark> I'll try to help out then
<daveshah> That would be awesome
<sorear> Some of you may have seen rwmjones jump the gun and declare symbiflow done on newsy
<daveshah> If fuzzing is quick we could even try a simple arachne style PnR over the summer
<awygle> i'll also help out
<awygle> post-glasgow of course
<awygle> kc8apf: how's your "fuzzing in the cloud" project going? that seems like it would be a huge help for this
<daveshah> Current plan on the compute side of things is a Hetzner dedicated server that I have (i7, 32GB RAM) but mostly used for storage so idles
<kc8apf> I need to look at Airflow and https://cloud.google.com/composer/
<kc8apf> if nothing else, generating a bitstream per part should be fairly straightforward
<awygle> assuming we could get diamond running in (i assume) docker, which i understand may not be 100% straightforward?
<kc8apf> today is migrating to nom 4.0
<kc8apf> correct. I haven't looked at diamond at all
<daveshah> Diamond is just an RPM
<daveshah> Plus flexlm of course
<daveshah> All the Diamond invocation in Trellis is already scripted
<kc8apf> RPM isn't too bad
<daveshah> The only thing you'd need to do is fake a mac address
<kc8apf> hmmmm
<kc8apf> ok
<daveshah> This was actually required on any machine prior to diamond 3.10, because it didn't handle systemd network device names
<daveshah> They fixed that now
<awygle> oh did they? that's cool
<daveshah> Yeah
<rqou> ping azonenberg
<rqou> ping awygle?
<awygle> rqou: i exist
<awygle> what's up
<rqou> can you read/comment on the blog post i'm working on re: xc2par?
<rqou> also azonenberg
<awygle> lol "in the beginning there was only zonenberg"
<awygle> wow, somehow i thought all this stuff was around much longer than this
<rqou> yeah me too
<rqou> that's what i realized when doing this writeup :P
<awygle> "todo sucking at combinatorics" it me
<awygle> i'd like to see something comparative, if possible
<rqou> comparative to ISE?
<awygle> "this is about as good as ise" or "this is much worse than ise for this reason"
<rqou> heh, maybe
<awygle> "these sorts of designs will fail"
<awygle> etc
<rqou> maybe that'll be in a follow-on blog post
<rqou> otherwise it will never be done :P
<awygle> other than that, it's pretty good
<awygle> and btw, what you needed to make xbpar work was a device-specific packing step :p
<rqou> not quite
<rqou> since you can also "unpack" the macrocells
* sorear is kinda curious how much remains in vtr-for-iCE
<daveshah> Just curious, what is xbpar
<rqou> there were also unresolved issues with the FFI glue
<rqou> xbpar is azonenberg's greenpak par algorithm
<azonenberg> rqou: not quite
<azonenberg> it's my crossbar CPLD par library
<azonenberg> greenpak uses it
<azonenberg> But its not greenpak specific
<azonenberg> rqou: looks good btw
<azonenberg> no comments other than finishing your TODOs
digshadow has joined ##openfpga
<awygle> on days when I haven't slept well I have a really hard time looking people in the eyes... Wonder what that's about
<shapr> social overexposure?
<shapr> rqou: for the newbies, is there a definition list of the greenpak/coolrunner-II specific terms?
<shapr> specifically, PLA, ZIA, CTx, LOC constraint, and PTA/B/C ?
<rqou> hmm i should add one
<shapr> I think that's all the terms I didn't know.
<shapr> oh, BUFG
<shapr> rqou: would most of these be answered in an FPGA primer document?
<sorear> Programmable logic array is general, the others aren’t
<azonenberg> LOC and BUFG are generic xilinx-isms
<shapr> ah, that's what PLA means
<azonenberg> not coolrunner specific
<azonenberg> But unique to xilinx
<sorear> Also these parts aren’t technically FPGAs so there’s some non-overlap
eduardo_ has quit [Quit: Ex-Chat]
<cyrozap> rqou: It'd be nice if that blog post had a few more dates/years--e.g., when you first became interested in the project, when you first got involved in the project, when you had the hackathon with azonenberg, etc. Maybe you could include a timeline/table, too, just to make it easier to put all of those events in context.
<cyrozap> For extra bonus points, you could also link to points in the IRC logs :)
<mithro> tinyfpga / daveshah: FYI - VexRISCV on iCE40 Ultra (with no DSP blocks) https://www.irccloud.com/pastebin/ISG7jWKJ/
<tinyfpga> mithro: nice, what synthesis tool?
<mithro> Not sure...
<mithro> I'll ask
<mithro> tinyfpga / daveshah / jhol: I could use some help starting to figure out the right values for the timing stuff to put in vpr -- I'm having trouble with vpr getting NaN values and I think it's because my values are all made up (still tracking it down)
mumptai has joined ##openfpga
<tinyfpga> Nice
<rqou> mithro: wait wtf you have working PAR already?
<rqou> s.t. you can put in timing information?
<mithro> rqou: Kinda, I'm still debugging PAR
digshadow has quit [Ping timeout: 260 seconds]
Bike has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
bitd has quit [Remote host closed the connection]
ZipCPU has quit [Ping timeout: 256 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
mumptai has quit [Quit: Verlassend]
genii has quit [Remote host closed the connection]
futarisIRCcloud has joined ##openfpga
steakpizza has joined ##openfpga
<steakpizza> Hello! This is Syed :). Interested in contributing to prjxray and partial reconfig stuff.
<kc8apf> glad you found the channel
<kc8apf> what exactly do you want to work on? partial reconfig is pretty broad
<jn__> and nice nick, too, steakpizza :)
cranc has joined ##openfpga
<awygle> welcome steakpizza :)
<steakpizza> i don't really know where to start or what I want to work on for this but what I have done so far is - I did the partial reconfig lab 1 tutorial from xilinx on the zedboard and have basic understanding of the static and partial reconfigurable modules and how there can be a full bitstream and partial bitstreams in a project. Pretty much want to reproduce this workflow in open source
GenTooMan has joined ##openfpga
<steakpizza> And thanks all for the welcome :)
<kc8apf> that uses Vivado's partial reconfig flow to generate partial bitstreams but uses prjxray to merge them