<whitequark> i think so yes
<whitequark> register allocators can get pretty pathological on some inputs
mumptai has quit [Quit: Verlassend]
zino has quit [Ping timeout: 265 seconds]
zino has joined ##openfpga
juri_ has quit [Ping timeout: 265 seconds]
juri_ has joined ##openfpga
emeb has left ##openfpga [##openfpga]
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
ZipCPU has quit [Ping timeout: 276 seconds]
m4ssi has joined ##openfpga
nrossi has joined ##openfpga
OmniMancer has joined ##openfpga
<OmniMancer> pepijndevos: sorry for disappearing so quickly, it was very late
moho1 has quit [*.net *.split]
Marex has quit [*.net *.split]
forrestv has quit [*.net *.split]
dfgg has quit [*.net *.split]
m4ssi has quit [Remote host closed the connection]
moho1 has joined ##openfpga
Marex has joined ##openfpga
forrestv has joined ##openfpga
dfgg has joined ##openfpga
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
pie_ has quit [Ping timeout: 245 seconds]
pie_ has joined ##openfpga
m4ssi has joined ##openfpga
<OmniMancer> are IOBUFs usually inferred?
<mwk> they can be
<mwk> and infering them is usually a good idea, unless you need some special vendor-specific stuff
<OmniMancer> where does one obtain knowledge of how to use generate in verilog?
<OmniMancer> need to make 188 IOBs
<mwk> in, uh, any verilog course?
<whitequark> mwk: i'm not so sure i agree with that
<mwk> genvar i; generate for (i = 0; i < 188; i++) IOB mah_iob (.I(mah_i[i]), .O(mah_o[i])); endgenerate
<mwk> something like that
<whitequark> er, that inferring IOBs is a good idea
<whitequark> non-tristate ones yes
<whitequark> (and even then only if you don't need any attributes)
<whitequark> tristate ones, well, yosys is very bad at handling them even today
<mwk> whitequark: got some specific issues?
<mwk> I'd very much like to get that stuff working
<whitequark> mwk: they're filed in the repo
<whitequark> iopadmap is pretty buggy
<mwk> that's about to change (see https://github.com/YosysHQ/yosys/pull/1527 )
<whitequark> ok, great
<mwk> also, iopadmap is not even used for ice40 / ecp5 targets
<whitequark> hm
<mwk> nextpnr handles iobuf insertion for those
<whitequark> I hit issues on GP4
<whitequark> and possibly arachne
<OmniMancer> does nextpnr deal with tristate ones?
<whitequark> after which I... well... just avoided autoinsertion completely
<daveshah> OmniMancer: yes, it's not always perfect but it does
<mwk> whitequark: if you have some issues to report, I'd like to hear about them, I really want to get this working
<mwk> at this moment I am aware of two issues
<mwk> (not counting ones that are already solved by my open PR)
<mwk> the other is... rather fragile handling of 'z by all passes
<whitequark> I rechecked the github issues and I don't think I've hit anything that isn't already filed
<mwk> I think we should recognize muxes involving 'z constants in the frontend, instead of emitting $mux and convertint them to $tribuf in the tribuf pass
<whitequark> agree
<mwk> I think that should cover 1364.1 requirements, which do sound reasonable
<mwk> maybe we should have a discussion about it today at the JF
<mwk> anyway, I'm fairly certain we're close to killing off that warning
Asu has joined ##openfpga
<whitequark> grreeat
<OmniMancer> hmmmm, this is not going to do the thing I want it to unless I connect something reasonable to the output enable isn't it :/
<mwk> speaking of #511, the default value of an undriven wire is 'z, right? as in, `assign x = 1'bz;` is actually a nop?
<whitequark> no
<whitequark> it's 'x
<whitequark> Verilog 'x = LLVM undef, if this helps
<daveshah> This raises a related point as to an inout only used as an input
<daveshah> I presume in this case the output part is considered driven by z rather than x
<mwk> whitequark: I know about the undef, but if something has no driver, it's in hi-z by definition, no?
<OmniMancer> not in unhelpful simulation language
<whitequark> ^
<mwk> hmm.
<whitequark> uninitialized wires or regs are just that: uninitialized
<daveshah> I'm sure unconnected cell inputs are 'z
<whitequark> interestingly 1364.1 makes no mention of inout
<mwk> for regs, I agree
<mwk> but wires are not storage devices
<whitequark> oh wait
<whitequark> you're right
<mwk> module top; wire x; initial $display(x); endmodule
<OmniMancer> oh yea verilog makes a distinction there
<mwk> iverilog says z
<whitequark> 4.2.1 says an unconnected wire is z
<anticw> what's the status of bitstream details for gw1n* ?
<whitequark> that's how undriven cell inputs end up as z
<mwk> pepijndevos: ^
<mwk> anticw: working on it
<daveshah> Worth nothing this is a difference between logic and wire
<mwk> got some early bitstream generation working, but very hacky and very experimental
<daveshah> even though logic can behave like a wire; seems like an unused logic is x
<whitequark> oh
<mwk> alright, so "opt_expr -full" seems to do a bad here
<anticw> mwk: thx
<daveshah> Also, `logic x = y;` is a SystemVerilog gotcha
<mwk> and connects 'x to undriven wires
<daveshah> that is like `reg x = y` not `wire x = y`, afaik
<whitequark> aaaaaaaaa
<whitequark> SV is an incredible language that removes one Verilog footgun and adds two new ones in place of it
<daveshah> But, it seems most synthesis tools treat this as `wire x = y`
<mwk> what
<daveshah> I looked into it a while ago and thought it was a Yosys issue. But then Vivado seemed to be the same too
<mwk> *sigh* everything would be so much easier in yosys if we had SSA
<mwk> why don't we have SSA
<whitequark> doesn't it have SSA?
<whitequark> a phi is a mux
<mwk> you have no easy way to go wire -> driver
<whitequark> oh
<whitequark> hm, yes
<mwk> and in theory you can have several drivers or zero drivers
<whitequark> that's nasty because it makes linting the case of multiple drivers very hard
<whitequark> i tried adding it and gave up
<mwk> (though that's the way to 'x, unless tribufs are involved, which we screw up on anyway)
<daveshah> Yeah, I'm glad nextpnr only allows one driver
<OmniMancer> I am trying to convince the anlogic tools to make me a design that connects something to the in out and output enable on every pad, but I am not sure what I need to connect to things to get it to actually connect them to things
<mwk> OmniMancer: tried spamming (* keep *) already?
<OmniMancer> no, will try
<OmniMancer> that has helped, but I need to attach the inputs to some kind of logic to make it route them
<pepijndevos> anticw, yea, what mwk said, we have some end-to-end blinky and PicoRV32, but it's very hacky and limited and broken. It'll be released Soon(tm) and hopefully get better over time hehe
<OmniMancer> oh btw, is the PicoRV32 prime blinky design available somewhere?
flaviusb has quit [Ping timeout: 250 seconds]
<OmniMancer> This is a very simple expression: LUTF1=~A*~B*~C*~D+A*~B*~C*~D+~A*B*~C*~D+A*B*~C*~D+~A*~B*C*~D+A*~B*C*~D+~A*B*C*~D+A*B*C*~D+~A*~B*~C*D+A*~B*~C*D+~A*B*~C*D+A*B*~C*D+~A*~B*C*D+A*~B*C*D+~A*B*C*D+A*B*C*D
<pepijndevos> OmniMancer, Micko gave it to me...
<OmniMancer> ah okay
<pepijndevos> I think all the code is online somewhere.
<OmniMancer> Why does it write out the constant 1 as that formula :/
<pepijndevos> that's the assembly at least
<OmniMancer> thanks
flaviusb has joined ##openfpga
<OmniMancer> alas the Tang Primer board has a lack of LEDs, there are 3 that can be used
<OmniMancer> so doing full blinky would require some external LEDs
<OmniMancer> or I have an LCD, but that might require reasonably good timing to work
Asu has quit [Remote host closed the connection]
Hamilton has joined ##openfpga
ZipCPU has joined ##openfpga
russell-- has joined ##openfpga
<OmniMancer> is the nextpnr json output format documented anywhere?
<daveshah> No, the nextpnr extensions aren't (they weren't really intended for public use at first)
<OmniMancer> That will make turning it into another format harder :P
<OmniMancer> can you give the placer a constraint?
<pepijndevos> You can write a primitive in verilog with manual placer annotations :)
<pepijndevos> wire clk;
<pepijndevos> GENERIC_IOB #(.INPUT_USED(1), .OUTPUT_USED(0)) clk_ibuf (.O(clk));
<pepijndevos> (* BEL="R29C29_IOB0", keep *)
<OmniMancer> thanks
mifune has quit [Ping timeout: 246 seconds]
jfng has quit [Read error: Connection reset by peer]
henriknj has quit [Remote host closed the connection]
synaption[m] has quit [Remote host closed the connection]
swedishhat[m] has quit [Read error: Connection reset by peer]
xobs has quit [Read error: Connection reset by peer]
scream has quit [Read error: Connection reset by peer]
pepijndevos[m] has quit [Read error: Connection reset by peer]
<OmniMancer> what would cause multiple drivers on a net?
<OmniMancer> daveshah: Any reason the generic synth would result in multiple drivers for a net?
<mwk> OmniMancer: assign a = b ? c : 1'bz; assign a = d ? e : 1'bz;
<mwk> there, you have legit multiple drivers
<pepijndevos> How would that get synthesized though?
<pepijndevos> I assume on FPGA you can't have multiple drivers so it becomes a mux
<mwk> in yosys, the "tristate" pass handles that sort of thing
<mwk> and converts it into logic
<mwk> but, there are targets that have legit internal tristate buffers as primitivies
<mwk> ancient ones, usually
<OmniMancer> I am pretty much asking why synthesizing the attosoc design resulted in something nextpnr refuses to load
<mwk> fun fact: Virtex 2 and earlier FPGAs could actually do on-chip tristate buses
<OmniMancer> so you wouldn't have to decompose inout busses?
<mwk> yes
<mwk> that said, if yosys produces a netlist with multiple drivers out of nowhere, it's a very bad sign
<OmniMancer> Can I get yosys to tell me if multiple drivers exist and where they are?
<mwk> the check command should do it
<OmniMancer> the check command does not seem to think there is a problem :/
<daveshah> How old is your nextpnr?
<daveshah> nextpnr more than a few months old can have trouble with new Yosys netlists
<daveshah> Otherwise, it's possibly a nextpnr bug in the generic arch
<OmniMancer> it was cloned earlier this week, I can update it
<daveshah> Oh, I know, you probably need a flatten in your Yosys script
<daveshah> Something like hierarchy -top top; flatten if it isn't in the generic tcl
<OmniMancer> does it need more than one flatten?
<daveshah> Otherwise I can have a look later
<OmniMancer> it has a flatten, what does the hierarchy -top top do?
<OmniMancer> daveshah: is flattening needed more than once, and does the top have to be set first?
<daveshah> top does need to be set first
<OmniMancer> it does not seem to set a top
<OmniMancer> does the name set there need to exist?
<OmniMancer> daveshah: how can I get the python scripts to import from a file in the same directory as they are, it seems I would have to run the nextpnr-generic command in the directory where the scripts are for this to work?
<OmniMancer> adding -auto-top to the hierarchy command made it happier
<daveshah> OmniMancer: I think it should respect PYTHONPATH
<daveshah> If not, I think there are ways of importing from a path
genii has joined ##openfpga
<OmniMancer> It might be easier for me to just cd and use a relative path for the outputs, I load some other files in the script :/
rohitksingh has quit [Ping timeout: 250 seconds]
<OmniMancer> daveshah: what is the intended way to extract output from the nextpnr-generic backend?
<daveshah> Either a post route Python script or parsing the JSON (which should be documented)
<OmniMancer> I suppose the FASM writer output is easier to digest
<daveshah> I can try and do some docs this evening or tomorrow
<daveshah> Yup
<OmniMancer> what are the occasional 1's that seem to occur in the routing string?
<OmniMancer> oh also, what is the correct way to expand the LUT init values it gives? if it uses less than the full 16 bits are the rest intended to be 0 or are they meant to be replicated to make the output independent of the unused inputs?
<ZirconiumX> It seems most people replicate them
<OmniMancer> it would be nice if nextpnr always output 16 bits if it knows it's a 4input LUT
<OmniMancer> though I suppose it is yosys that produced them
<ZirconiumX> Indeed, Yosys handles this.
<OmniMancer> Well when I have more time I will attempt to make a converter from the FASM format the generic example uses to a pnl file and see if I can convince the anlogic tools to make me a bitstream
<OmniMancer> then just hope that the timing is not horribly off :P
<OmniMancer> perhaps start with blinky I guess
<OmniMancer> possibly need to look into how I could extract timing info
swedishhat[m] has joined ##openfpga
scream has joined ##openfpga
synaption[m] has joined ##openfpga
jfng has joined ##openfpga
henriknj has joined ##openfpga
xobs has joined ##openfpga
pepijndevos[m] has joined ##openfpga
Asu has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
Hamilton has quit [Quit: Leaving]
m4ssi has quit [Remote host closed the connection]
<ZirconiumX> What's the least cursed way to implement a minimalist SD card interface? Sure, I could bitbang it from an SPI shift register, but there's probably a better way.
Laksen has joined ##openfpga
dh73 has joined ##openfpga
dh73 has quit [Read error: Connection reset by peer]
Xark has quit [Ping timeout: 246 seconds]
Xark has joined ##openfpga
mumptai has joined ##openfpga
<anticw> pepijndevos[m]: re: gw1n; thanks! is their much a novice can offer in the way of help?
<ZirconiumX> anticw: No programmer will ever say no to documentation contributions.
<mwk> documentation contributions is exactly what pepijndevos[m] should be doing himself right now, too :p
* mwk mutters something about cursed file formats
<tpw_rules> ZirconiumX: why is that cursed?
<ZirconiumX> SD itself isn't cursed, but there's a wide spectrum between "bitbang the QSPI pins" and "implement an SD Host Controller" :P
<tpw_rules> wait are you doing qspi
<ZirconiumX> I'm doing *something*, at least. SPI seems like the least painful approach.
<tpw_rules> spi is very easy
<ZirconiumX> Sure, but how do I expose that as an interface for a soft core.
<ZirconiumX> I probably should have mentioned that, but I forgot >.>
<tpw_rules> i'd say if you wanted an SD card interface, teach your spi engine to send 6 byte chunks, send and receive 512 byte chunks, receive response, and wait for not busy
<tpw_rules> the spi engine i just did would work pretty good, you might just want to add a state to wait until not busy
<ZirconiumX> The SDHCI spec uses DMA, and I'm not entirely sure I feel like writing a DMA engine and bus arbitrator.
<tpw_rules> if you're going for style points, implement a CRC function too
<ZirconiumX> Though on the other hand I'm probably going to end up with multiple bus masters anyway
<tpw_rules> have you seen elm-chan's stuff
<ZirconiumX> Nope
<tpw_rules> this is the definitive reference for sd cards in spi mode, if you're not willing to grind through the real spec
<tpw_rules> (he also has good documents on FAT and a very well known and microcontroller-optimized library for such)
pie_ has quit [Ping timeout: 250 seconds]
<tpw_rules> daveshah: so i'm not exactly experienced, but i might be able to help with implementing Rigel in nMigen. image processing is a lot of what our lab does
<daveshah> Awesome
<daveshah> I'm not going to have time to do any implementation work until next year
<daveshah> and can't even commit to that, but it's definitely interesting
<tpw_rules> nah i wasn't expecting that. but i need a phd topic still :P
<daveshah> You starting a PhD?
<tpw_rules> yeah
<daveshah> very nice
<ZipCPU> ZirconiumX: I have a working SD over SPI core on github. Feel free to ask for the URL, or any questions you might have if you run into any trouble
Laksen has quit [Quit: Leaving]
<whitequark> tpw_rules: btw, can you remind me if there's anything i can do wrt your boneless PR?
<tpw_rules> whitequark: someone still needs to update the spreadsheet
<tpw_rules> but then that's it
<whitequark> ahhh right
<whitequark> I'll probably do it next time I remember
<tpw_rules> alright. btw uh i'm getting into writing a proper register allocator for boneless. but everything i know about compilers i learned in the past 48 hours
<ZirconiumX> ZipCPU: I'll probably ask if I'm having issues; contract specifies any external code I use has to be permissively licensed, so I can't use your core verbatim, sadly.
<tpw_rules> so i may need to pick your brain for some hints
<whitequark> tpw_rules: neat
<whitequark> I don't know much about regalloc
<tpw_rules> my current sticking point is converting to SSA and/or working out the liveness ranges
<ZirconiumX> I've done that, at least a little bit, tpw_rules
<whitequark> hmm
<whitequark> do you want to allocate registers right into assembly?
<tpw_rules> yeah basically
<tpw_rules> you just say MOVI(r.whatever, 343) and it gets replaced with a real register
<tpw_rules> but to quote myself in ##wq:
<tpw_rules> like suppose you have: a=1; b=a+1; a=2; c=a+1; d=b+c; . i saw one definition that "The live range of a variable is the set of instructions which leave it live". here a is live after instructions 1 and 3. b is live after 2, 3, 4. but a=R0, b=R0, a=R1, C=R2, D=R3 is a valid allocation and i'm not sure how to decide that a's live range is actually two separate ones
<ZipCPU> ZirconiumX: No problem! Lots of folks do that ;)
<whitequark> you could add a .kill mnemonic
<whitequark> since you need use, def, and kill, and use/def are implied by instructions
<whitequark> in our 3-address code
<tpw_rules> that would be annoying to write i would think
<whitequark> iirc ia64 asm has it?
<whitequark> ok i guess it is annoying to write
<ZirconiumX> A scope form, maybe?
<tpw_rules> the definition is true iff the code is in SSA form
<tpw_rules> i've already managed to build my basic blocks, control flow graph, and use/defs.
<tpw_rules> i think i've almost figured out how to convert it to SSA
<whitequark> hm
<tpw_rules> anyway i'm about to start the holiday festivities so that's just something to let percolate for now
<ZirconiumX> Some form of scope-based management is a necessity, I think: suppose the user uses up all 8 registers doing $whatever, you have no way of knowing when the register lifetimes end, so you'd either spill a user reg, or bail out
<whitequark> you can kill registers explicitly, in which case lifetimes can be non-lexical
<tpw_rules> i mean the scope so far is one procedure. i know when the lifetime ends cause the register isn't referred to again
<ZirconiumX> tpw_rules: don't return values count under that definition of "written to, not read"?
<whitequark> those are physical registers, not virtual
<tpw_rules> yeah. the paper i was reading said you should just insert copies from virtual registers to physical at e.g. calling convention points
<tpw_rules> so it would just copy the virtual register to the unkillable return register
<whitequark> you might need to be able to kill physical registers though
<whitequark> if you're writing code that uses them
<tpw_rules> idk yet
rohitksingh has joined ##openfpga
nrossi has quit [Quit: Connection closed for inactivity]
mumptai has quit [Quit: Verlassend]
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
lawrie has joined ##openfpga
lawrie has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
Bob_Dole has quit [Ping timeout: 250 seconds]