<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
<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
<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 :/
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
<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]