<adamgreig>
lol ugh, yea, that would be a real pain
<OmniMancer>
let me see if I can find a pinout for the thing the relevant pins might be exposed except reset
<OmniMancer>
Oh apparently the VID:PID it is using is one that those Cypress FX things enumerate as before you load firmware into them
Jybz has quit [Quit: Konversation terminated!]
Jybz has joined ##openfpga
OmniMancer1 has joined ##openfpga
Bike has joined ##openfpga
OmniMancer has quit [Ping timeout: 240 seconds]
<OmniMancer1>
the swd pins on that micro are routed out to pads on the board, but they are on the half pitch outer ones, the JTAG port is also just routed out however, so I can probably just use the ft232 based jtag adapter I got with it which is for use with the RISC-V softcore that is on it by default
<OmniMancer1>
would still be nice to eventually use it just from the USB though
<OmniMancer1>
Also you get the JTAG adapter MCU into DFU mode by holding the USER button while plugging it in
rohitksingh has quit [Ping timeout: 250 seconds]
<OmniMancer1>
daveshah: is there a particular reason why the Trellis command line tools get linked with the python libraries?
<daveshah>
They aren't particularly supposed to be
<OmniMancer1>
I think the cmakefiles are a bit wonky currently the
<OmniMancer1>
then
<daveshah>
Yeah, sounds like it
<OmniMancer1>
CMake is somewhat vexing after becoming used to cargo and Rust
<OmniMancer1>
daveshah: I think the trouble is that looking for Boost Python adds it to the Boost libraries, so when the tools are linked they will try to link that
<OmniMancer1>
Ah you can't build both the python module and static versions of the tools at the same time
Laksen has joined ##openfpga
<OmniMancer1>
I wonder how hard it would be to replicate the fuzzing portion of stuff and the python module with Rust and pyo3
<daveshah>
That's what I'd probably do if I were starting again with no constraints, tbh
<OmniMancer1>
Is libtrellis used in nextpnr?
<daveshah>
No, it isn't
<daveshah>
(at least not by the C++ part of nextpnr)
<OmniMancer1>
Ah, so none of the complication of needing a C++ library then
<daveshah>
it's a build time dependency for a Python script that creates the bba database files
<daveshah>
Nope
<OmniMancer1>
the Python script uses the pytrellis module to read the Trellis db?
<daveshah>
yeah
<OmniMancer1>
I might have a play with that sort of thing in a bit, though just copying stuff straight out of libtrellis is easier for fast progress
<daveshah>
Well, if you do, I may end I up stealing it in the future :)
<daveshah>
Would certainly be interesting to see how you got on if you do go that way
<OmniMancer1>
heh
<OmniMancer1>
I might not make up a custom db format though
<OmniMancer1>
since nice serialisation libraries exist
<daveshah>
I went for a custom format mostly because I wanted something that git diff'd nicely
<daveshah>
But I'm sure there are still better options
<OmniMancer1>
ah, well I guess it depends how what is serialised is laid out
<OmniMancer1>
one can probably get RON or JSON to git diff pretty well with the right internal structures
<tpw_rules>
in case anyone was waiting, my hub75 driver is probably complete now
zkms has quit [Quit: zkms]
zkms has joined ##openfpga
<tpw_rules>
how do i set up search paths and whatever for Instance?
promach has quit [Quit: Ping timeout (120 seconds)]
<zkms>
i have an nmigen question; is there a way i can declare Signals differently if i want some to be only internal to the module and some to be the module's input/output interfaces?
<tpw_rules>
uh my solution was to just prefix input and output interfaces with i_ and o_
<tpw_rules>
super internal signals you could also only declare in elaborate, so that external code can't get to them
<zkms>
ah ok
<whitequark>
what tpw_rules said, yes
<zkms>
perfect, thanks
<whitequark>
the __init__ method would add some signals as self.[io]_ attributes, then the elaborate method would use whichever internal signals it wants
<whitequark>
there's currently no enforcement or other logic that checks / guards / looks at which signals are a part of elaboratable's interface
<whitequark>
that might change later but no concrete plans, it works quite well as it is
<tpw_rules>
btw is it considered gross to be like self.i_sig = self.submodule.i_sig
<whitequark>
there's nothing wrong with that
<tpw_rules>
cool
<whitequark>
if you do it for an output, then if the output is not used, it won't appear in the gtkwave signal tree etc
<tpw_rules>
where does Instance find verilog modules?
<zkms>
whee, nmigen is fun
<whitequark>
:D
<whitequark>
tpw_rules: it does not
<whitequark>
think of Instance similar to calling a function in C
<tpw_rules>
also yes nmigen is great fun
<whitequark>
it's the job of the build system to provide a definition for this function
<tpw_rules>
except when i screw up
<tpw_rules>
well i'm using nmigen's build system soooo
<whitequark>
if you screw up and nmigen stops being fun i generally consider that a bug
<whitequark>
usability bug, to be specific
<tpw_rules>
i feel like there should be alarms somehow for .eq of a larger signal to a smaller, and of using the wrong clock domain
<whitequark>
that alarm would trip each time you do x.eq(x+1)
<whitequark>
now, some actually think that would be correct
<tpw_rules>
maybe if it's not an equation on the rhs?
<tpw_rules>
like x.eq(y)
<whitequark>
right, so the rules need working out
<whitequark>
now that I've added the "linter options", we can actually introduce this noninvasively
<whitequark>
linter options can be set per-file with a magic comment like # nmigen: UnusedElaboratable=no
<whitequark>
oh yeah re instances
<whitequark>
platform.add_file("foo.v", open("/path/to/foo.v")) would do it
<whitequark>
or .vhd
<whitequark>
or .sv
<tpw_rules>
great
<tpw_rules>
and then i can Instance all the modules in it?
<whitequark>
yep
<whitequark>
you can also do way weirder things with yosys
<whitequark>
for example, you can use nmigen modules from verilog
<whitequark>
without pre-generating them to verilog, and while being able to parameterize them (in a limited way)
OmniMancer1 has quit [Quit: Leaving.]
<tpw_rules>
hm. something is not working on account of i'm synthesizing precisely one LUT
<tpw_rules>
and it says there are no clocks.
<tpw_rules>
oh, i guess i gotta attach something to the outside world. that's slightly silly
<whitequark>
yep
<whitequark>
dead code elimination
<tpw_rules>
i was somehow under the impression that dealing with bram counted as alive, but i'm not sure why
emeb has joined ##openfpga
<whitequark>
nope
<tpw_rules>
so relatedly, what sort of risc-v ISA resources are there that aren't the big honking manual? like instruction list, register set, basic encoding ettc
<tpw_rules>
somewhere i have a 1 page reference of mips, it would be nice to have that for risc-v
<tpw_rules>
ah, found one
<tpw_rules>
btw the gtkwave integration is really nice. i'm using a kinda hacked up CLI but it's eons better than the shit quartus put me through
<tpw_rules>
it was easier there to just use an on-fabric logic analyzer than to simulate
<tpw_rules>
can an Instance be simulated though?
<zkms>
other nmigen question; is there an idiomatic way to do base-2 logs and 2^n (like to go from stuff like memory lengths to address width or vice versa)
<tpw_rules>
idk about nmigen, but i use (x-1).bit_width() to store x addresses, or 2**x_bits to get number of addresses in x bits
<whitequark>
zkms: nmigen.utils.log2_int and nmigen.utils.bits_for
emeb has quit [Read error: Connection reset by peer]
<whitequark>
the former is the same as (x-1).bit_length() but it handles the case of x==0 and also optionally checks that it's a power of 2
<whitequark>
the latter also handles signed values
<whitequark>
tpw_rules: you can't simulate an Instance yet, that's something I want to fix in 0.2
<tpw_rules>
is there an easy way to use another simulator?
emeb has joined ##openfpga
<whitequark>
nope
<tpw_rules>
wq did you just subtweet me
<whitequark>
you can emit verilog but then you lose the ability to cosimulate
<whitequark>
also, nmigen really ought to have better docs
<tpw_rules>
the problem is that i'm one of those people who is convinced deep down that breathing is inconveniencing others
<whitequark>
i mean, that's a mood
<whitequark>
98% of that tweet is just reflecting on how "RTFM" is a really toxic thing to say
<tpw_rules>
ooh exciting, Minerva does fit on an ice40, and it has better timing than boneless. of course, at like 3.5x the LUTs
<tpw_rules>
but sadly synthesis doesn't take 5 seconds anymore
<whitequark>
aw, did you decide to go with risc-v instead?
<whitequark>
boneless too slow?
<tpw_rules>
for now, just curious
<tpw_rules>
but like, i want a barrel shifter for cool graphics tricks. other than that it's probably fast enough
<tpw_rules>
oh also i can't stall it which complicates bus stuff
<whitequark>
oh we can just add stalls
<whitequark>
in fact let's do it now
<tpw_rules>
yeah i looked at it briefly and it didn't seem hard, but you know it way better than i
<tpw_rules>
plus also risc-v is more buzzwordy which is important for its intended purpose :P
<whitequark>
aw
<tpw_rules>
but see the counterpoint is that i would have to actually set up a toolchain, which is gross
<tpw_rules>
i bought some risc-v microcontrollers a while ago but never got to use them
<tpw_rules>
or rather haven't found a use yet
<tpw_rules>
while you're in a boneless mood, can you signoff/can we tweak the jump renaming? i remember you said that we shouldn't prioritize signed/unsigned jumps, which I agree with
<whitequark>
hm
Bob_Dole has joined ##openfpga
<zkms>
whitequark: thanks!
<zkms>
also i'm sincerely enjoying nmigen so far
<whitequark>
zkms: i'm glad to hear that
<whitequark>
tpw_rules: so what's the new proposal?
freemint has quit [Ping timeout: 246 seconds]
<tpw_rules>
i am too, nmigen is wonderful
<zkms>
it's all the delight of writing gateware in verilog without actually having to deal with verilog's...footguns
<tpw_rules>
proposal wrt what? it should be on the github issue
<tpw_rules>
also now that i'm looking back at it, it's honestly a lot of that you know x86 and i never learned it
<whitequark>
yes but your current proposal prioritizes signed comparisons
<tpw_rules>
oh, ok. i figured just instead of BGE for signed we would put BGES
<tpw_rules>
or BSGE, just changing the J to B
<whitequark>
just changing J to B sounds good to me
<tpw_rules>
cool
<whitequark>
i'm not sure how i feel about signed/unsigned as a suffix
<whitequark>
is the plan here to make it less ambiguous with BS?
<tpw_rules>
no, just because it sounded better to me
<tpw_rules>
i just edited the table to just change J to B along with the rest of the branches
<whitequark>
i actually feel like it might be better to have S/U as a suffix
<whitequark>
it sorta sounds better *and* it meshes nicely with BEQ/BNE
<tpw_rules>
yeah that's what i thought too
<whitequark>
also, i have this radical proposal about flag based branches
<whitequark>
i don't like BZS/BZC at all, i'd much rather have BZ/BNZ
<tpw_rules>
x86 weirdos ;P
<whitequark>
i think it wasn't x86
<tpw_rules>
i did some research and that's the only one that had Bf/BNf
<tpw_rules>
others were BfS and BfC
<whitequark>
hm
<whitequark>
i guess
<whitequark>
if we gotta go BfS route i'd much rather have Bf0 and Bf1
<tpw_rules>
is having aliases in scope
<whitequark>
we already do have aliases, like BEQ
<tpw_rules>
like i wouldn't mind Bf/BFn as long as there was also BEQ/BNE and BMI/BPL
<tpw_rules>
oh yeah i guess we do
<whitequark>
i really don't like how BPL insinuates zero is positive
<whitequark>
it will absolutely trip me up at some point
<whitequark>
BMI/BZ/BPL
<tpw_rules>
isn't that definition of BPL a new condition though?
<tpw_rules>
like not n and not z or something
<whitequark>
sure and if i keep my microarchitectural knowledge in my head at all times it'll be fine
<whitequark>
except i would rather not think about it
<whitequark>
it's a footgun, i don't think any more justification is needed
<tpw_rules>
i mean like we would have to encode a new condition to make it work that way
<whitequark>
yes
<tpw_rules>
anyway ditching bpl is fair. but i, in my heart of hearts, assert that 0 is a positive number
<whitequark>
sure :p
<tpw_rules>
anyway i think Bf/BNf/ is fair, plus BEQ/BNE. my 6502 fingers can type the wrong ones and then they'll just fail to assemble
<whitequark>
it feels like whichever choice we pick it will trip up *someone*'s muscle memory
<whitequark>
so the decision should be made to make that trip harmless
<tpw_rules>
well we could also minimize change
<whitequark>
from old boneless?
<tpw_rules>
yeah. like if switching the mnemonics to what i like will just trip up the other half of the users, then why bother. we should just switch the letter and flags and keep the structure
<whitequark>
i didn't really spend any effort picking good mnemonics for that, so i applaud any attempt to make them nice and tidy
<whitequark>
you're like a third of boneless' current user base i think
<whitequark>
you know the story of how make ended up with tabs? yeah i'm not afraid to do something to avoid that
<tpw_rules>
i don't think i'm that old
<tpw_rules>
but in that case i'm gonna say my way or the highway. wrt. unconditional jumps
<tpw_rules>
by the way why did JALR become JRAL?
<whitequark>
so, the author of make thought tabs were a mistake but make had like 20 users already
<whitequark>
so he decided to not break it
<tpw_rules>
oops
<whitequark>
i'm not sure what you mean re unconditional jumps
<whitequark>
did we have any disagreement there?
<tpw_rules>
sigh
<tpw_rules>
flags-based jumps
<whitequark>
oh
<tpw_rules>
i tried to mean not signed/unsigned
<whitequark>
oh i see
<tpw_rules>
the only unconditional jump thing is that bit about JRAL. it was kind of unexpected to me, especially as i've found old docs referencing it as JALR
<whitequark>
you're seeing them as "not based on a condition but on flag value" and i'm seeing them as "based on condition referencing a flag"
<tpw_rules>
knowing me, it wasn't that deep
<whitequark>
let me rephrase
<whitequark>
when i write JZ i want to jump if the result is zero, not if the zero flag is set. i don't care if it's set, it's an implementation detail
<whitequark>
it could for all i know check if accumulator is zero [if we had an accumulator] and i'd still call it JZ
<whitequark>
or BZ, you get the general idea
<tpw_rules>
oh i see what you mean. so you jump based on some attribute of the result rather than if you have some flags
<whitequark>
exactly
<whitequark>
they also happen to have a 1:1 correspondence to flags, so if for some reason you specifically want flags, it's not too hard to read the mnemonics that way
<whitequark>
but i think that latter case is relatively rare
<whitequark>
like, you could shift into sign bit and then BSS/BSC would make more sense
<tpw_rules>
but it's an unsigned value
<whitequark>
exactly
<tpw_rules>
there's also considerations like a couple 6502 instructions used the flags for non-arithmetic results. like V was bit 6 of a BIT instruction
<tpw_rules>
boneless doesn't do that, but it could maybe, unless that just horrifies you :P
<whitequark>
i meant that S == 15th bit of the result, so BSS/BSC makes sense for unsigned values, BS/BNS less so
<whitequark>
re flags for non-arithmetic results, i'm not totally opposed to it in principle, but if we ever pipeline it that'll cause problems
<tpw_rules>
but that would be branching based on a flag rather than an arithmetic result
<whitequark>
and i think pipelining boneless makes a lot of sense
<tpw_rules>
why would it cause problems? e.g. BIT is just AND $ff with that mux on V
<tpw_rules>
i might have read you explaining the behavior of jumping on a result attribute as something that you more preferred
<whitequark>
hm
<whitequark>
what i mean is that mnemonics like BS/BNS are jumping based on a result attribute, that happens to be stored in flags
<tpw_rules>
do you prefer to make the flags implicit or explicit?
<whitequark>
implicit
<tpw_rules>
ok, so you would prefer those mnemonics then
<whitequark>
yep
<whitequark>
i feel like you could make a case for having both BS/BNS and BS0/BS1
<whitequark>
"branch if S == 0"
<tpw_rules>
then it would probably make more sense to rename S to N
<tpw_rules>
branch if negative, vs branch if not negative
<tpw_rules>
then branch if N flag == 0 or 1
<whitequark>
BNN, ew
<whitequark>
not having a weird JNN mnemonic is why i went for S for that flag originally
<tpw_rules>
then we should get rid of it and have BN0 and BN1 exclusively :P
<tpw_rules>
also i'm not anything else has ZSCV flags
<whitequark>
> then we should get rid of it and have BN0 and BN1 exclusively :P
<whitequark>
i literally just explained why i'd rather have Bf/BNf
<tpw_rules>
yes you did
<whitequark>
if you want to have BN0/BN1 exclusively, fine
<whitequark>
but i insist we get rid of all aliases like BEQ and BGTU and so on.
<whitequark>
yes, i'm being intentionally obtuse to make a point
<tpw_rules>
so i see three categories of conditional branches. compare-type ones that branch based on the result of a compare, so the 8 >= > < <= signed/unsigned (e.g. BGTU), then flag-type ones that branch based on a flag like BZ or BN0 or BVS or whatever, then result-based ones that branch based on arithmetic result, like BE or BN
<tpw_rules>
type 1 we have no argument with
<whitequark>
type 3 too, i think?
<tpw_rules>
well i think the difference is that i want to express using the flags as type 2, you want to express them as type 3
<whitequark>
yes
<tpw_rules>
would you be opposed to having Bf, BNf, then Bf0 and Bf1? we can keep the 15th bit as S
<tpw_rules>
(except branch if sign still makes no sense to me...)
<tpw_rules>
(but then branch if negative is ugly...)
<whitequark>
not opposed. that's what i meant by 20:36 < whitequark> i feel like you could make a case for having both BS/BNS and BS0/BS1
emeb_mac has joined ##openfpga
<tpw_rules>
to me, BS/BNS reads as being a type 2. like an arithmetic result being "sign" or having "signed" doesn't make sense. if we wanted it to be type 3, because a result can be "negative", then we would have to accept BNN which yes is silly
<tpw_rules>
maybe we could do something like BPZ, branch if positive or zero. it would still be a bit silly.
<whitequark>
mhm
<tpw_rules>
but i think i've explained where i'm coming from and i'll let you decide
<whitequark>
weird compromise: we could just omit BS/BNS
<tpw_rules>
so you would have to say BN1/BN0?
<whitequark>
so JZ/JNZ/JC/JNC/JV/JNV and then you have to use BS0/BS1
<tpw_rules>
well as we can see, will it then be the S bit or the N bit
<whitequark>
we still can't have BN0/BN1
<whitequark>
"JNC" is "Jump if Not Carry". "BN1", then, is "Jump if Not 1"
<whitequark>
er
<whitequark>
i'm mixing up J and B
<whitequark>
but you get the idea
<tpw_rules>
if it's not going to be N, then i think keeping BS/BNS is okay
<whitequark>
let's do that then, and have aliases for BS0/BS1 as a compromise for everyone who started out using ... not x86
<whitequark>
well, BS0/BS1 would probably be the actual instruction, and BS/BNS the alias
<whitequark>
we... do end up with *three* ways to express "jump if zero flag set"
<whitequark>
JZ, JZ1, JEQ
<whitequark>
which is kind of weird but whateer
<whitequark>
btw if we get interrupt support there probably is going to be an I-flag
<whitequark>
wonder what else would end up stuffed into flag register
<tpw_rules>
BI1
<tpw_rules>
well it probably doesn't make sense to branch on it
<tpw_rules>
anyway i updated the comment with that stuff
<tpw_rules>
so the 2 remaining things are 1. just making sure you're okay with JN becoming NOP
<tpw_rules>
and 2. JRAL?
<whitequark>
JN becoming NOP is totally okay, and in fact i've searched for a good while for any use for JN at all
<whitequark>
JRAL, well, think of what happens if you do JRAL Rx, Rx
<whitequark>
it jumps first and links second
<tpw_rules>
ok, JALR R31 on mips is explicitly banned
<tpw_rules>
so that makes sense
<tpw_rules>
well in that case can you comment on the PR with like "this looks good" and then i can start fiddling with the manual sometime soon. should I make a PR for the actual boneless code update too?
<zkms>
what does the little "self.submodules.foo = self.foo" stanza do exactly?
<tpw_rules>
i would expect that to be m.submodules.foo
<zkms>
yeah that
<tpw_rules>
it registers the module as a submodule of m
<zkms>
idk what it does exactly >_<
<tpw_rules>
otherwise it's just floating there and doesn't actually get compiled
<zkms>
oic
<zkms>
ahhh
<tpw_rules>
you can also say m.submodules += self.foo i think, or += [an iterable]
<zkms>
ic
<whitequark>
yep
<zkms>
also i have an other question; if i have a module A, which instantiates n count of submodule B (with n known only at run time based on parameters of module A) and hooks them together, what's the right way to do that?
<zkms>
(i am making a shift-register-like structure, with each element of the shift register being a submodule B, and the entire shift reg is module A)
<whitequark>
you can create B's inside the elaborate method
<tpw_rules>
yeah i did that once and it was just a for loop
<whitequark>
you can also create B's inside the constructor of A, really
<whitequark>
but then you can't do `a.b_count = 10` and have it work
<whitequark>
and yes as tpw_rules says the rest is just a for loop
<zkms>
but like, how do i name each of the B submodules?
<zkms>
they need to have names right?
<tpw_rules>
nah
<zkms>
so i can add them to the B.submodule thing as well as come up with their signals (since each B's output goes into a different B's inputs)
<tpw_rules>
iirc. i did setattr cause i didn't know that
<tpw_rules>
but you could just say m.submodules[name] = buffer
<whitequark>
yes
<whitequark>
but you could also do m.submodules += buffer and it'll be anonymous
<whitequark>
with an autogenerated name like $1
<tpw_rules>
ok so it is anonymous then
<tpw_rules>
i wondered if there was some python dark magic to get the name
<zkms>
ok
<whitequark>
there isn't. the name doesn't even exist before you do the RTLIL conversion
<tpw_rules>
no i mean like that could work out that i was adding a thing called buffer
<tpw_rules>
wq so how are we going to update all the boneless instructions? will you do that or should i submit a PR?
<zkms>
i understand the m.submodules += thing for each instance of the sub module; but how do i connect the signals? do i just have a for loop where one variable is the current sub module and an other variable is the previously-instantiated one and iterate?
<zkms>
or should i be doing it differently?
<tpw_rules>
you can connect them whenever
<tpw_rules>
like you could make a list of subshifters and then just m.submodules += list
<whitequark>
zkms: yes, I would do it like you just described
<zkms>
sure but i cant name them individually
<whitequark>
in nmigen itself I use zip() for this case
<tpw_rules>
they don't need to have a name.
<zkms>
because there's a runtime-dependent number of them
<zkms>
oic
<whitequark>
so something like
<whitequark>
for a, b in zip(things, things[1:]): m.d.comb += b.i.eq(a.o)
<tpw_rules>
yeah
<zkms>
and the [1:] staggers the arrays, got it
<zkms>
thanks a lot for the advice!
<whitequark>
np
<zkms>
oh also what is the idiomatic way to do boolean operators on nmigen Signals
<zkms>
i tried "and" and it didnt work so i did '&' was that the right thing to do?
<tpw_rules>
yeah
<zkms>
nice
<zkms>
thanks~
<tpw_rules>
is lattice's site down for anyone else...
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
<ZirconiumX>
Right, I caught up with the Boneless stuff (since small processors interest me)
<tpw_rules>
wq by the way i wanted to do a PR for some improvements to nmigen/cli.py, namely the ability to build and program the platform and the ability for the caller to set the clocks instead of only via command line
<ZirconiumX>
Is there a convention for the link register in Boneless, as such?
<tpw_rules>
nah, my code uses R3 cause that was next in the list of registers i hadn't used yet :P
<ZirconiumX>
I use R7 because, well, I learned MIPS first
SpaceCoaster has joined ##openfpga
SpaceCoaster_ has joined ##openfpga
SpaceCoaster has quit [Read error: Connection reset by peer]
<tpw_rules>
also the most complicated code i've written has 1 subroutine and 0 window switches
<ZirconiumX>
I tried writing a memcpy. The core loop seemed reasonably okay, but odd copy sizes are rather painful :P
<tpw_rules>
oh, i'm treating a byte as 16 bits
<ZirconiumX>
That would be the sensible thing, but I'm not all that sensible
<ZirconiumX>
I feel like you could use register window shenanigans to copy things, but I'm not that brave.
freemint has quit [Ping timeout: 245 seconds]
<tpw_rules>
well then you would have even more annoying alignment requirements
<ZirconiumX>
Still seems like a fun challenge
<tpw_rules>
also i'm not sure if it would be possible without some memory mapping help...
<tpw_rules>
or self-modifying code
<ZirconiumX>
That's the fun of it :P
<ZirconiumX>
Anyway.
<ZirconiumX>
For whatever my vote counts, `BN[01]` would be my choice
SpaceCoaster_ has quit [Read error: Connection reset by peer]
SpaceCoaster has joined ##openfpga
rohitksingh has joined ##openfpga
<whitequark>
tpw_rules: re boneless update: feel free to submit a PR
<whitequark>
re nmigen.cli: could work yeah
<whitequark>
but there's some difficulty in actually doing it
<whitequark>
since you can't simulate anything that uses the platform
<tpw_rules>
i don't understand. i did it and it took like 5 lines. there's just another case that calls .build() on the platform
<whitequark>
that's mutually exclusive with using the simulate subcommand, right
<tpw_rules>
yes
<whitequark>
i think the convention currently is to add `if __name__ == "__main__": SomePlatform.build()`
<whitequark>
since you can't simulate anyway
<tpw_rules>
i mean it works fine for me?
<whitequark>
nmigen.cli is not super well thought out
<tpw_rules>
like i just have an if name == main that calls build and another that calls nmigen.cli to let me simulate and i just uncomment the one which i want. and i'm finally getting tired of it :P
<zkms>
is there a way to convert a python string or a python character into hex so it can be used as a nMigen value?
<tpw_rules>
ord
<tpw_rules>
ord('A') == 65
<zkms>
oic
<zkms>
nice
<tpw_rules>
(if i remember my ASCII correctly)
<zkms>
thanks so much
<whitequark>
tpw_rules: right but those use different fragments, right?
<whitequark>
since you can't simulate a fragment that expects to be able to use a platform
<tpw_rules>
not really? the only thing i need to change between them is the clock speed so that the thing doesn't try and create a PLL
<zkms>
is there a way to get nmigen to print out which signals in which modules/submodules are currently unassigned or is that not a thing
<whitequark>
zkms: not currently a thing
<whitequark>
uh, you could do a quick hack, let me see
<tpw_rules>
idk how or why but i can still platform.request all the signals i need, and the clocks work out (except for as mentioned), and so on
<whitequark>
tpw_rules: hrm
<whitequark>
right, that's uh
<whitequark>
that's more or less a bug that you can
<tpw_rules>
i mean i don't think it should be, since it's so great to not have to worry about simulation...
<whitequark>
that also only really works if your thing has no inputs
<tpw_rules>
well yes
<tpw_rules>
so this change may not be as general as i had hoped
<whitequark>
nmigen.cli really exists solely to make examples work
<whitequark>
it's currently more of an attractive nuisance for any real design
<tpw_rules>
me irl
<tpw_rules>
well do you think it's something that might be useful for simple examples
<whitequark>
i don't think so, not while it's mutually exclusive with simulation
<whitequark>
promoting a workflow which eschews simulation in favor of just running it on the device isn't very good
<tpw_rules>
i see it as the opposite
<tpw_rules>
but idk. i'm not too hip on simulation yet. i just like being able to tell my script to "simulate" if there's a problem
<tpw_rules>
oh oops, i used a flag that doesn't work on python 3.6. well then i'll close it and we can think later
<tpw_rules>
well anyway i think i'm all FPGA'd out today. i think i've been working for like 8 hours. my led driver is basically perfect. now i just need to work out the spi flash and spram. and then think of something cool to display...
<tpw_rules>
one idea was to hook up the multipliers and get metaballs going. conway's game of life is easy but not a very exciting demo of a 16 million color panel
<tpw_rules>
also see if i can kludge in a barrel shifter. maybe as a peripheral
<zkms>
other question, if i have a list of signals, how do i do a bitwise operation on all of them (like ANDing them all or ORing them all)