<_whitenotifier-3>
[nmigen-boards] mithro opened issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fji1O
<_whitenotifier-3>
[nmigen-boards] whitequark commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fji13
<_whitenotifier-3>
[nmigen-boards] mithro commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fji1E
<cr1901_modern>
as a nested fcn inside SPIResource?
<whitequark>
no
<whitequark>
it'd be a function somewhere in nmigen-boards
<whitequark>
or... hm
<whitequark>
maybe in Resource() itself?
<whitequark>
yeah probably the latter
<whitequark>
I'll put it in....
<cr1901_modern>
Where is a resource going to get it's default_name?
<whitequark>
for SPI it's, well, "spi".
<cr1901_modern>
Actually I didn't even know it was possible to go from pos args to kwargs and then back
<whitequark>
you can't go back
<whitequark>
that's a keyword-only required argument
<cr1901_modern>
Oh...
<whitequark>
makes it so that downstream code is *unable* to pass a boolean as positional, even
<whitequark>
very good feature
<whitequark>
the only thing better would be to completely remove booleans from the language
<cr1901_modern>
haha
<cr1901_modern>
I don't see how default_name factors into Resources that a user defines themselves without using any of the wrappers under nmigen_boards.dev
<cr1901_modern>
if you're defining a vanilla resource, chances are you will be supplying the name already
<cr1901_modern>
so a default_name is redundant
<whitequark>
yeah but nmigen-boards isn't the *only* boards repo that should be possible
<whitequark>
so it's better to provide an abstraction that's more baked in
<whitequark>
also, that solves the question of where to put it
<cr1901_modern>
I will have to see what you mean. Does this mean that _every_ Resource now gets a mandatory default_name argument to fill in now?
<whitequark>
not mandatory
<whitequark>
if it's in nmigen.build.dsl.Resource it just becomes optional
<whitequark>
and there's another check that you supply it if you're missing the name
<whitequark>
kind of a lot of checks, but that's kind of how eDSLs roll
<cr1901_modern>
Well, providing a default keeps stuff like SPIFlashResources convenient
<cr1901_modern>
where you just supply the number and the names will be autogenned for you
<cr1901_modern>
I just can't visualize how this'll be implemented right this moment
<cr1901_modern>
It'll click once I see it
<whitequark>
ughhh that doesn't quite work
<whitequark>
because Resource() accepts *args
<cr1901_modern>
>yeah but nmigen-boards isn't the *only* boards repo that should be possible
<cr1901_modern>
Putting this aside for a moment, my view is if you're using a wrapper Resource under nmigen_boards.dev, the name in general will be decided for you. SPIResource should be an exception to this rule, but it should also >>
<cr1901_modern>
have a consistent interface w/ the other Resource wrappers
<whitequark>
and why is SPI so special?
<cr1901_modern>
the "only supply a number as mandatory argument" is the consistent interface.
<cr1901_modern>
B/c we've already decided on spi_flash_{1x,2x,4x} and you'll make ppl unhappy if you change that
<cr1901_modern>
Should be consistent on each board
<cr1901_modern>
Basically, I think SPI is "unfortunate" that the abstraction breaks, rather than being special
<whitequark>
to repeat: and why is SPI so special?
<whitequark>
why does its abstraction break? you haven't answered that
<cr1901_modern>
Because you've already hardcoded names for the uart and spiflash and irda resources
<cr1901_modern>
If you didn't, there's no problem.
<whitequark>
why would the current hardcoded names be a problem?
<cr1901_modern>
And an spi device can be much more general than a uart, irda, or spiflash
<cr1901_modern>
Because the interface of the resource wrappers becomes inconsistent if you're allowed to supply names to some resource wrappers but not others
* cr1901_modern
retrieves a comment
<whitequark>
so why is it that UART is less general than SPI?
<_whitenotifier-3>
[nmigen-boards] whitequark opened issue #23: Use Resource.family where appropriate - https://git.io/fjiMc
<_whitenotifier-3>
[nmigen-boards] whitequark commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiMW
<_whitenotifier-3>
[nmigen-boards] mithro commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiM4
<_whitenotifier-3>
[nmigen-boards] whitequark commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiMR
<_whitenotifier-3>
[nmigen-boards] mithro commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiME
<_whitenotifier-3>
[nmigen] mithro commented on commit 367ad5aee76228916677acf2937f6f1c346686ea - https://git.io/fjiMu
<_whitenotifier-3>
[nmigen] programmerjake opened issue #141: tracer.get_var_name returns None instead of default on pypy3 - https://git.io/fjiM6
<_whitenotifier-3>
[nmigen] whitequark commented on issue #141: tracer.get_var_name returns None instead of default on pypy3 - https://git.io/fjiMD
<_whitenotifier-3>
[nmigen-boards] whitequark commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiMH
<_whitenotifier-3>
[nmigen] whitequark commented on commit 367ad5aee76228916677acf2937f6f1c346686ea - https://git.io/fjiMQ
<_whitenotifier-3>
[nmigen-boards] mithro commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiMF
<_whitenotifier-3>
[nmigen] programmerjake opened pull request #142: allow tracer.get_var_name to work on pypy3 - https://git.io/fjiMN
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #142: allow tracer.get_var_name to work on pypy3 - https://git.io/fjiMh
<_whitenotifier-3>
[nmigen-boards] whitequark commented on issue #22: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiMj
<_whitenotifier-3>
[nmigen] mithro opened issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiDe
<_whitenotifier-3>
[nmigen] mithro commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiDU
tweakoz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<_whitenotifier-3>
[nmigen] whitequark commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiDI
<_whitenotifier-3>
[nmigen] programmerjake synchronize pull request #142: allow tracer.get_var_name to work on pypy3 - https://git.io/fjiMN
<_whitenotifier-3>
[nmigen] mithro commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiDm
<_whitenotifier-3>
[nmigen] whitequark commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjiDO
<zignig>
whitequark: did you wait until I was on an away mission to drop the bonless v3 ? ;P
* zignig
is nowhere near his workshop.
<whitequark>
zignig: it is still very, very far from being complete
<whitequark>
much less from running at a respectable frequency on up5k
<zignig>
After landing in SA I saw that it updated..
<zignig>
:) looking better though. I like what you have done with the assembler.
<whitequark>
yea
<whitequark>
i'm open to extending it with more directives
<whitequark>
though they should be well motivated
<zignig>
I was wondering how to handle the EXTI instructions and shifing labels.
<zignig>
I have a bunch of commands and macros that I am using, but it will need to be well considered before adding.
<zignig>
some guru meditations will be needed.
<zignig>
some thoughts that I had after reading the source...
<zignig>
Is it possible to make CMPI imm8 ?
<whitequark>
that wouldn't fit well into the ISA, I think
<whitequark>
why?
<zignig>
being able to compare +/- 127 rather than the 3 bit table might be more flexible.
<whitequark>
you can use EXTI;CMPI if you need more flexibility
<whitequark>
(EXTI works on any instruction)
<zignig>
indeed , it's only 1 instruction...
<zignig>
and ... in the fullness of time an interrupt controller :)
<zignig>
Is it in a runnable state at the moment, looking forward to having a poke at it.
<whitequark>
not really, conditional jumps aren't even implemented
<zignig>
once this 5MW is commisioned.
<whitequark>
and it's untested...
<whitequark>
5MW?
<zignig>
5 Mega Watts of solar.
<whitequark>
oooh sweet
<whitequark>
that's really cool
<zignig>
' do not lick '
<zignig>
:)
<zignig>
still keep up the good work, looking forward to getting one running.
<whitequark>
yea
<_whitenotifier-3>
[nmigen] programmerjake commented on pull request #142: allow tracer.get_var_name to work on pypy3 - https://git.io/fji9B
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #142: allow tracer.get_var_name to work on pypy3 - https://git.io/fji90
owo has joined #m-labs
X-Scale has quit [Read error: Connection reset by peer]
flammit has quit [*.net *.split]
adamgreig has quit [*.net *.split]
daveshah has quit [*.net *.split]
mithro has quit [*.net *.split]
whitequark has quit [*.net *.split]
uberardy has quit [*.net *.split]
uberardy has joined #m-labs
flammit has joined #m-labs
daveshah has joined #m-labs
adamgreig has joined #m-labs
mithro has joined #m-labs
whitequark has joined #m-labs
owo has quit [Quit: Leaving]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern1 has quit [Client Quit]
cr1901_modern1 has joined #m-labs
cr1901_modern1 has quit [Client Quit]
cr1901_modern has quit [Ping timeout: 244 seconds]
cr1901_modern has joined #m-labs
mumptai has joined #m-labs
m4ssi has quit [Remote host closed the connection]
MLichtman has joined #m-labs
MLichtman has quit [Remote host closed the connection]
<_whitenotifier-3>
[nmigen] whitequark commented on issue #134: Add FSM state name annotations to generated Verilog output - https://git.io/fjijQ
rohitksingh has quit [Ping timeout: 244 seconds]
<_whitenotifier-3>
[nmigen] Fatsie commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjPvU
<_whitenotifier-3>
[nmigen] mithro commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjPvu
<_whitenotifier-3>
[nmigen] mithro commented on issue #134: Add FSM state name annotations to generated Verilog output - https://git.io/fjPv2
<_whitenotifier-3>
[nmigen] Fatsie commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjPfw
<_whitenotifier-3>
[nmigen] mithro commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjPfh
X-Scale has joined #m-labs
acathla has quit [Remote host closed the connection]
acathla has joined #m-labs
mumptai has quit [Quit: Verlassend]
<mtrbot-ml>
[mattermost] <mgielda> mgielda joined the team.
<_whitenotifier-3>
[nmigen] mithro commented on issue #143: Support silkscreen references (and other information) in platform definitions - https://git.io/fjPUN