peepsalot has quit [Remote host closed the connection]
peepsalot has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter_ is now known as PyroPeter
<awygle>
wishbone is irritatingly complicated and also badly explained
<awygle>
i should probably cave and write some formal properties for it
<awygle>
jfng: i notice there's no `rst` signal on the wishbone interface in nmigen-soc. i assume the intent is to use ResetSignal/clock domains generally, but wishbone specifically requires a synchronous reset. thoughts on how to require that?
<awygle>
(or if it's worth caring about)
<awygle>
also it's conceivable that the wishbone reset may not be a module-wide reset (it's explicitly permitted in the spec, observation 3.20)
<TD-Linux>
the spec seems to say all resets should be tied together to a SYSCON reset
<TD-Linux>
>A module called the SYSCON provides the system with a stable clock [CLK_O] and resetsignal [RST_O].
<TD-Linux>
that seems to pretty well match up with a clock domain reset
<awygle>
that's true. i suppose if the wb interface doesn't reset some of the module logic then they're in different domains anyway
<awygle>
something about that feels a bit odd to me, but it is the logical fallout of how nmigen handles domains and how wishbone handles clk and rst
<awygle>
probably just verilog-holdover
hitomi2505 has joined #nmigen
<d1b2>
<314> is there anything important to keep in mind when using nmigen-compat modules alongside nmigen modules?
<d1b2>
<314> uhhhhhhhhhhhhhhhhh
<d1b2>
<314> so lets say I have some logic that starts working ~60% of the time (the other 40% might just be an unrelated problem since resetting fixes it), but when I make one tiny change that should only change one LED connection, everything breaks and it stops working
<d1b2>
<314> no warnings from nmigen, no relevant warnings from yosys, no warnings from nextpnr
<daveshah>
Could be a bug, probably in nextpnr by the sounds of things
<daveshah>
Could also be a design issue, do you have any derived clocks or clock domain crossings?
<d1b2>
<314> no derived clocks and no CDC unless nmigen is doing something behind the scenes
<d1b2>
<314> i tried diffing the generated and merged verilog (the single giant file that i feed into yosys) and there's no difference other than anonymous variable/net names being different and that one line with the LED code being different
<d1b2>
<314> could
<d1b2>
<314> output [7:0] errorcode;
<d1b2>
<314> reg [7:0] errorcode = 8'h00;
<d1b2>
<314> (these lines are right next to each other)
<d1b2>
<314> be a problem?
<d1b2>
<314> or is that verilog standards compliant
<whitequark>
04:58 < awygle> wishbone is irritatingly complicated and also badly explained
<whitequark>
yup
<whitequark>
i Do not like it
<daveshah>
I wonder if Avalon is useful as a "simpler/lighter than AXI" bus
<daveshah>
I remember using it a few years ago and finding it perfectly acceptable, and it's quite widely used in the Intel side
<whitequark>
awygle: re wishbone reset, TD-Linux is correct, i went for an "implicit SYSCON"
<whitequark>
this seems to lie in spirit of the spec
<d1b2>
<314> awygle: see above (this is regarding the I2C core for RL)
<awygle>
Oh, you changed your name lol
<awygle>
whitequark: I don't have an issue with that but the requirement to be synchronous remains, dunno if we care tho
<awygle>
daveshah: I'm uncomfortable using something owned by Intel for OSS ip
<awygle>
personally
<awygle>
I'd rather fix the wb spec tbh, it seems like that should be permissible
<daveshah>
Ah, I didn't realise Avalon was essentially Intel proprietary
<daveshah>
for some reason I thought it was more of an open standard
<awygle>
That's my understanding but I could be wrong I suppose
<daveshah>
even AXI is a bit dubious in that regard (iirc you aren't allowed to use it with your own implementation of the ARM ISA...)
<awygle>
I can't figure out how to ping through the bridge...
<daveshah>
IRC pings become Discord pings
<daveshah>
don't know if it works the other way round
<awygle>
314: let's see. I don't have any suggestions but if you push stuff I'll look in the morning (going to bed now). when you say "everything breaks" what do you mean exactly?
<d1b2>
<314> by that I mean that I stop getting acks back from the I2CInitiator
<d1b2>
<314> (and yeah I was getting ghost pings so I had to change nickname)
<awygle>
single letters will do that
<awygle>
I owe you logic analyzer hookups too. I'll do that tomorrow, for sure.
<whitequark>
awygle: I think that should be at most a linting violation
<whitequark>
I can see e.g. a case where a full design (that happens to use WB internally) has an async reset
<whitequark>
and there's nothing wrong with it
<whitequark>
in fact if you make an ASIC that is most certainly what you actually want
<DaKnig>
whitequark I think I should ask this here, instead of using the issue tracker as a chat platform (about the two issues I opened). regarding adding a PS7 instance, it didnt work.
<DaKnig>
I added the line `m.submodule += Instance("PS7")` and this did not do anything
<whitequark>
what's the equivalent verilog that you know would work here?
<daveshah>
yes, but the keep attribute applies to the PS7 too
<DaKnig>
PS7 is the arm chip in a zynq board
<DaKnig>
ah
<DaKnig>
I dont have the verilog that should work, I only did that in vhdl, lemme check
<DaKnig>
ok I cant find it sadly, tried a few things but the only things I find are old reports with the same error message... I could have sworn I "fixed" this warning in one of my projects
<daveshah>
Have you tried the keep attribute yet
<DaKnig>
nope
<DaKnig>
replace this `self` with the top level module right
<DaKnig>
?
<DaKnig>
for my test
<daveshah>
that's Migen, I don't know how to add an attribute in nMigen
Asu has joined #nmigen
<whitequark>
Instance("PS7", a_keep="TRUE")
<DaKnig>
trying this one right now
<DaKnig>
yep even with this line added it still gives the same error
<vup>
whitequark: it seems like nmigen doesnt emit instances without any connections
<vup>
the PS7 isn't even in the rtlil for DaKnig's testcase
<DaKnig>
I really dont remember the specifics, but I think there should be one line in that module connected to 0 (or 1? I really dont remember) to make the ARM not work
<DaKnig>
to keep it shut down
<whitequark>
vup: oh hmm
<whitequark>
that might be a bug actually
proteus-guy has quit [Ping timeout: 240 seconds]
<DaKnig>
ok I followed that tutorial and installed the editable version
<DaKnig>
it still gives the same warning
<DaKnig>
how do I check, from within python if possible, that I do indeed run the correct version of nmigen?
jeanthom has joined #nmigen
chipmuenk has joined #nmigen
<DaKnig>
whitequark
<DaKnig>
should I mention your name every time I send a message addressing you, or would this be too annoying for you?
<DaKnig>
Im a bit confused; looking at the verilog output, I see a few signals that do nothing
<DaKnig>
I see a signal that's assigned to but whose value is never used
<_whitenotifier-b>
[nmigen] DaKnig commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ8T4
<_whitenotifier-b>
[nmigen] DaKnig edited a comment on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ8T4
<DaKnig>
seems like I am not on the correct branch, as I dont see the changes from 444 in the nmigen directory
<miek>
it's a pull request that hasn't been merged yet. you'd need to check out the `xilinx-sim_device` branch to try it
<DaKnig>
yeah and I dont see said branch. I might have to compile git :(
<DaKnig>
I have git 1.8
<DaKnig>
the only branch I see is master
<_whitenotifier-b>
[nmigen] rroohhh commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ8IZ
<vup>
DaKnig: I just tried #444 myself, see my comment
<_whitenotifier-b>
[nmigen] rroohhh edited a comment on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ8IZ
<DaKnig>
vup: maybe it is a bug on their side; however this does not happen when using the vivado gui
<vup>
DaKnig: do you have a vhdl / verilog example that doesn't hit this warning?
<DaKnig>
I do, lemme find it
<vup>
preferably using BUFGCE
<DaKnig>
well; I never used bufgctrl so
<DaKnig>
or bufgce
<DaKnig>
I only ever used bufg
<vup>
because I can also get rid of the warning if I manually transform the BUFGCE into BUFGCTRL
<DaKnig>
ok lemme try
<miek>
DaKnig: old git shouldn't be a problem. have you done a `git fetch` recently? is the remote set correctly (check `git remote -v`)?
<DaKnig>
I did `git pull`
<DaKnig>
nvm I already compiled the newest git (it also has nicer defaults and other improvements I already got used to so I was gonna do this anyways)
<miek>
hm. it should be all good then. you should see it in `git branch -a` (needs the -a), and should be able to do `git checkout xilinx-sim_device`
<DaKnig>
ah. I did not know that. now I see that and am on the right branch
<_whitenotifier-b>
[nmigen] jeanthom opened issue #446: nmigen generates _n signals when using diff pairs causing issues with nextpnr - https://git.io/JJ8t1
<_whitenotifier-b>
[nmigen] jeanthom commented on issue #446: nmigen generates _n signals when using diff pairs causing issues with nextpnr - https://git.io/JJ8tp
<_whitenotifier-b>
[nmigen] jeanthom opened pull request #447: Add SSTL135D_I to the list of diff io types in ECP5 - https://git.io/JJ8qO
<_whitenotifier-b>
[nmigen] miek commented on pull request #447: Add SSTL135D_I to the list of diff io types in ECP5 - https://git.io/JJ8qR
<_whitenotifier-b>
[nmigen] jeanthom synchronize pull request #447: Add SSTL135D_I to the list of diff io types in ECP5 - https://git.io/JJ8qO
<_whitenotifier-b>
[nmigen] jeanthom edited pull request #447: Add SSTL135D_I/SSTL15D_I/SSTL18D_I to the list of diff io types in ECP5 - https://git.io/JJ8qO
<DaKnig>
are there any optimizations performed on the ast level in nmigen? where should I start looking for reading about that kinda stuff?
<DaKnig>
in the src code
<whitequark>
DaKnig: there aren't
<_whitenotifier-b>
[nmigen] whitequark closed issue #446: nmigen generates _n signals when using diff pairs causing issues with nextpnr - https://git.io/JJ8t1
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJ8mT
<_whitenotifier-b>
[nmigen] whitequark closed pull request #447: Add SSTL135D_I/SSTL15D_I/SSTL18D_I to the list of diff io types in ECP5 - https://git.io/JJ8qO
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJ8mt
<_whitenotifier-b>
[nmigen/nmigen] whitequark 58138d9 - Deploying to gh-pages from @ f7a8fcc94c59907d144cde194194018d98386129 🚀
<DaKnig>
whitequark: so yosys should do this part instead?
<whitequark>
whatever synthesizer you are using
<whitequark>
nmigen produces verilog that corresponds more or less directly to the code you write
<DaKnig>
why the signals that do nothing though
<jeanthom>
cause yosys can delete them very easily
<jeanthom>
you could optimize an RTLIL with Yosys if needed
emeb has joined #nmigen
<whitequark>
which signals that do nothing?
<lkcl_>
jeanthom: it optimises them out correctly only on flattening
<lkcl_>
whitequark: if you recall we discussed this some months ago
<lkcl_>
hierarchical models, based say on OO design, where some bits of some signals connected to some modules are not connected as inputs (or outputs)
<lkcl_>
that the module has but the parent does not connect up.
<lkcl_>
yosys will *not* optimise those input signals that are not connected up... *unless* the *entire design* is flattened.
<lkcl_>
we have such a massive design that it takes 85 minutes for coriolis2 to lay out (if flattened)
<whitequark>
lkcl_: that's how hierarchy works in yosys, yeah
<lkcl_>
this time could be drastically cut if it is done non-flattened (hierarchical)
<whitequark>
it doesn't do intermodule optimization unless you flatten
<whitequark>
in principle, it could, there's nothing conceptually hard about it
<jeanthom>
lkcl_, define "correctly" :)
<lkcl_>
whitequark: indeed. and it adversely affects completion time, as well as causes problems for alliance / coriolis2, if there are any "unused" signals
<lkcl_>
jeanthom: :)
<lkcl_>
okok yosys does _a_ job - one that stops coriolis2/alliance complaining - when flattened :)
<lkcl_>
alliance actually converts BLIF files back to a (small) subset of VHDL
<lkcl_>
we were the first team to submit designs to it that had "unconnected" signals
<lkcl_>
it didn't go well :)
<lkcl_>
fortunately, jean-paul was able to fix the issues, but at the cost of an increase in gate count
<lkcl_>
it's a "hack" basically
<lkcl_>
it's quite fascinating, really, following all of these innovations in libre tools, finding the interactions and watching them unfold
<lkcl_>
whitequark: indeed. AST-walking _should_ be quite straightforward, to identify places where Const is passed in as a parameter to a module for example (that's also an important one that yosys misses unless the hierarchy is flattened)
<DaKnig>
I meant that I have , in the verilog output, some temp lines that are assigned to but whose values are not used, or just used to transfer something as is to another (sometimes temp) signal
<lkcl_>
if the Const was substituted *inside* the module instance, yosys would find it and do const-optimisation
<lkcl_>
DaKnig, yes, exactly.
<DaKnig>
I didnt say anything about const
<lkcl_>
if you use yosys "flatten" command, yosys then does a decent job
<DaKnig>
would it make more readable verilog files?
<lkcl_>
DaKnig: we cross-typed :)
<DaKnig>
ah sry
<lkcl_>
DaKnig: i honestly don't know, you'd need to try it
<whitequark>
lkcl_: no, I'm not going to do this in nMigen, that's not only obnoxious to implement but also slow and doesn't solve the complete problem
<whitequark>
if this transform is implemented somewhere it has to be yosys
<lkcl_>
whitequark: interesting. if you know of a better... ah :)
<DaKnig>
makes sense
<lkcl_>
yes it does
<whitequark>
DaKnig: regarding signals whose purpose is only to transfer the value to another temporary signal, there are a few causes of it
<whitequark>
that all ultimately derive from the fact that verilog is awful
<lkcl_>
well, we have NLNet funds available to sort it out (for anyone willing to try)
<whitequark>
e.g. in verilog-2001 you cannot cast a value to a given bit width
<whitequark>
at all
<whitequark>
you have to define either an intermediate wire, or a function
<whitequark>
sv2v uses a function, nmigen uses an intermediate wire (well, yosys does)
<whitequark>
anyway, this will improve with time somewhat
<DaKnig>
I can show you an example, I doubt you'd find a way to defend that
<DaKnig>
:)
<FL4SHK>
Verilog is also awful for not supporting user-defined types
<FL4SHK>
to me that's the worst thing about it
<whitequark>
DaKnig: oh, i will
<DaKnig>
ok lets see
<FL4SHK>
people are *still* using it
<DaKnig>
lemme paste
<whitequark>
do you know how changes to the yosys verilog backend are approved?
<lkcl_>
Cadence modified SV specially to give it "Records".
<whitequark>
you have to run randomized testing against it for several dozen (ideally hundred) CPU hours
<FL4SHK>
lkcl_: how is that different from a struct?
<lkcl_>
ariane (pulpino) uses that variant, and the code is vaaaastly clearer and cleaner
<whitequark>
because even people who know verilog in detail can very easily get it wrong
<lkcl_>
and also won't compile with verilator :)
<FL4SHK>
lkcl_: SystemVerilog already has structs
<whitequark>
so... write_verilog for the most part uses the most conservative possible lowering
<lkcl_>
FL4SHK: no conceptual difference
<FL4SHK>
then how did they add records?
<lkcl_>
FL4SHK: but not as parameters to modules
<FL4SHK>
what are you talking about?
<lkcl_>
that's the bit that really matters.
<FL4SHK>
you mean you can't use a struct as a parameter?
<lkcl_>
FL4SHK: i called them records because i didn't know the official name was "structs"
<FL4SHK>
SV seems to have that
<lkcl_>
FL4SHK: correct.
<FL4SHK>
when did this addition happen, during the creation of the original version of SV?
<lkcl_>
honestly i don't know if it's that SV has structs as parameters, or that verilator doesn't support it.
<FL4SHK>
I'm about 90% certain that SV *does* let you have parameters that are structs
<FL4SHK>
It lets you specify built-in types for parameters
<FL4SHK>
I'm not sure why you'd need to convert SV to nMigen given that you can just use an SV module with nMigen
<FL4SHK>
unless you really want to use yosys with SV
<lkcl_>
FL4SHK: because we want to be able to do python-based simulations of the full design
<FL4SHK>
that is a good point
<FL4SHK>
but it'd be slow
<FL4SHK>
I'm pretty sure I don't recommend doing Python-based simulations
<lkcl_>
that's what cxxsim is for :)
<whitequark>
cxxsim would let you combine SV and nMigen modules, eventually
<whitequark>
there are still some parts left to implement
<whitequark>
but all of the hard parts are done
<FL4SHK>
I feel like yosys should integrate sv2v
<whitequark>
:/
<DaKnig>
does yosys allow for optimization passes via external programs?
<DaKnig>
like in clang
<whitequark>
because fuck good error messages, right? who needs that
<FL4SHK>
hmmmm
<whitequark>
yosys' verilog parser is bad enough
<lkcl_>
FL4SHK, you're right - it's faster now, but when i started 2 years ago hoollyy cowww, the IEEE754FPU unit tests were doing 2 clocks *per second*.
<whitequark>
i know what it needs: another translation layer
<lkcl_>
it's much better now, but still... woo :)
<whitequark>
why do people working with HDL have no goddamn standards for tools
<DaKnig>
what standards do you have for C tools
<lkcl_>
whitequark: lol because they're not software engineers and because proprietary.
<whitequark>
DaKnig: clang has outstanding error messages, so much so that it caused status quo to improve across the board
<whitequark>
clang made sanitizers usable and popularized their usage
<DaKnig>
I did not say anything about error messages
<FL4SHK>
apparently hardware is difficult to develop in general
<lkcl_>
DaKnig: lots! each OS and each processor has an "ABI", for consistent linking, binary formats, and more
<sorear>
ariane and pulpino are two different things
<FL4SHK>
I haven't been developing hardware for *that* long
<FL4SHK>
yet somehow I'm a master of it, according to lkcl_
<DaKnig>
lkcl_: ah, this kinda standards
<whitequark>
no
<whitequark>
lkcl has no idea what he's talking about, again
<FL4SHK>
cool
<lkcl_>
sorear: hello. thank you for clarifying.
<DaKnig>
whitequark : you did not answer
<lkcl_>
yes, i have memory problems. i only remember things half-right.
<sorear>
cv64a (nee Ariane) is a core developed by PULP at ETH Zurich
<DaKnig>
well I should ask in #yosys
<DaKnig>
gonna do that right now
<lkcl_>
sorear: yes, that i got right. ahh PULP not "pulpino"
<whitequark>
DaKnig: i'm not sure what you've asked. to rephrase, i'm saying that people who use HDL tooling do not generally place a lot of value into usability of that tooling
proteus-guy has joined #nmigen
<sorear>
oh the repo is CV6A but the readme is still Ariane
<FL4SHK>
whitequark: so is that why VHDL 2008 support is so weak
<lkcl_>
sorear: that's a change in... the past 2 years? that was when i did sv2nmigen
<lkcl_>
haven't looked at ariane (cv64a) since
<whitequark>
FL4SHK: and SV support, yeah
<FL4SHK>
SV support is poor
<whitequark>
and even just plain Verilog
<whitequark>
until I started working on it, Yosys did not even have end-to-end preservation of public names
<FL4SHK>
It kind of bothers me that hardware people don't seem to care as much about metaprogramming or reuse
<_whitenotifier-b>
[nmigen] jeanthom opened issue #448: [RFC] Adding RoundRobin to nmigen.lib - https://git.io/JJ8lf
<FL4SHK>
whereas my code is generally pretty generic
<whitequark>
i think that's not necessarily bad
<FL4SHK>
in part because I just don't know everything in advance
<lkcl_>
it's a common thing, for free software tools to not be completed
<FL4SHK>
lkcl_: that'd explain the Hurd
<whitequark>
if you don't have a lot of SWE experience, writing generic code can be a good way to make things more complicated and less usable
<lkcl_>
jeanthom: can i recommend also adding PriorityPicker to that?
<FL4SHK>
I don't know if I'd say I have a lot of SWE experience given that I was never trained in it
<FL4SHK>
don't have a CS or CE degree
<whitequark>
neither was i, formally
<FL4SHK>
just ME and EE
<DaKnig>
FL4SHK thing that does one thing well vs thing that works for all situations but takes more resources
<FL4SHK>
generics don't take more resources in synthesis
<FL4SHK>
probably only for development time, maybe
<DaKnig>
I find that writing generic code that performs just as well takes more time
<FL4SHK>
it's... not quite true
<FL4SHK>
wait
<FL4SHK>
no, maybe you're right
<FL4SHK>
but it's generally not a lot more time
<whitequark>
FL4SHK: to rephrase, my observation is that some people consider code purely as means to an end, whereas others also focus on code in its own regard
<whitequark>
and if you've spent your career in the former camp for some reason, you probably don't know how to use generics well
<whitequark>
and that's fine i think
<FL4SHK>
I fit into the latter
<lkcl_>
jeanthom: PriorityPicker is the "other type of commonly needed Arbiter"
<whitequark>
i suspect most people here fit into the latter group
<FL4SHK>
On another topic, I'm trying to decide whether or not to buy this "fancy" dev board that's $150 off
<whitequark>
i try to make nmigen usable for both
<FL4SHK>
It's got Displayport and VGA both
<FL4SHK>
I see
<lkcl_>
except, a back-to-back Encoder-Decoder is not gate-efficient. discussed... 2 days ago?
<lkcl_>
FL4SHK: if you can put up with 180nm / 130nm, and are doing Libre work (public good), you can get a EUR 50,000 Grant from NLNet to pay for development time *and* the layout.
<lkcl_>
FL4SHK: Staf Verhaegen has a contact which is EUR 600 per mm^2 for 180nm
<lkcl_>
it's low enough that NLNet were happy to pay EUR 18,000 for us to do LibreSOC in 180nm
<FL4SHK>
what about testing and packaging?
<lkcl_>
eurosilicon or europractices or something
<DaKnig>
how expensive we talking
<lkcl_>
packaging is part of the price, QFP.
<lkcl_>
testing, Staf can do, with the NLNet Grant money.
* lkcl_
needs to get up and walk around... sorry been sitting too long :)
lkcl_ is now known as lkcl_away
<whitequark>
15:54 < lkcl_> FL4SHK: Staf Verhaegen has a contact which is EUR 600 per mm^2 for 180nm
<whitequark>
isn't that just CMP?
<whitequark>
they have a MOQ of 6 mm^2 and pretty affordale packaging
<whitequark>
once i'm no longer broke i should tape out my CPU there
<whitequark>
jeanthom: what does that actually do?
<jeanthom>
you pass that to the RoundRobin constructor
<whitequark>
no, i know that
<whitequark>
i mean, how do they affect the semantics of the module?
<whitequark>
it's not documented and it's not clear from the code either
<jeanthom>
if it's SP_CE, then it will check if will only update the output if ce is high
<whitequark>
sorry, i can't parse that sentence. typo?
<jeanthom>
my write_english command is broken, will try that again :)
<jeanthom>
if you create a RoundRobin with SP_CE as its switch policy, then the output of the RoundRobin (self.grant) will be updated only if self.ce is high
<jeanthom>
otherwise (SP_WITHDRAW) there is no self.ce signal
<whitequark>
do we need that configuration parameter? we can have a CE signal that is reset=1
<whitequark>
similar to memory ports
<jeanthom>
yep I was thinking about that solution but wasn't sure if it was the cleanest approach
<jeanthom>
I think I'll do it this way
<whitequark>
I have no real preference here, but using ce (well, should be called en in nmigen) with reset=1 seems simpler and consistent with other places
<whitequark>
ok I guess that's actually a preference
<whitequark>
but I don't feel very strongly about it :)
<whitequark>
jeanthom: do you think you could clean up the implementation a bit, too? the omigen one seems kinda hard to understand
<whitequark>
maybe based on the one in -soc if that's useful
<jeanthom>
yep I'll base it off the -soc implementation
<whitequark>
great, thanks for taking care of this!
<miek>
would wrapping it in EnableInserter do the same thing?
<whitequark>
oh, that'd be even better
<whitequark>
I missed it, good catch
<jeanthom>
jfng suggested we should rename "ce" to "en", what do you think?
<jeanthom>
> should be called en in nmigen
<whitequark>
jeanthom: what do you think about miek's suggestion?
<jeanthom>
I should read more carefully your messages x)
<jeanthom>
whitequark, I think that the way to go
<whitequark>
I think it should work, but I didn't look very carefully
<whitequark>
great
<whitequark>
okay, now the hard part of the PR
<jeanthom>
the code
<whitequark>
no no, that's the easy part
<whitequark>
the hard part is me asking you to add omigen roundrobin to nmigen.compat with a deprecation warning that explains how to migrate off it
<whitequark>
it should check for the switch policy and change the message depending on that
<whitequark>
I think there are already examples of how to do it, but I can explain it as well
<whitequark>
(elsewhere in nmigen.compat)
<jeanthom>
well that's still code
<whitequark>
yeah, but it's UI work first and foremost
<whitequark>
personally I find it hard... though you might differ
<_whitenotifier-b>
[nmigen] whitequark commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ8BW
<_whitenotifier-b>
[nmigen] whitequark closed issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJcU4
<_whitenotifier-b>
[nmigen] whitequark reopened issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJcU4
<_whitenotifier-b>
[nmigen] whitequark commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ8B4
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJ8BR
<_whitenotifier-b>
[nmigen/nmigen] whitequark 08a6d6d - Deploying to gh-pages from @ c75fa45fd80063ad5681f389fb038d6d98f4f0a0 🚀
hitomi2505 has quit [Quit: Nettalk6 - www.ntalk.de]
<_whitenotifier-b>
[nmigen] DaKnig commented on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8B9
<_whitenotifier-b>
[nmigen] whitequark commented on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8B5
<_whitenotifier-b>
[nmigen] rroohhh commented on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8Rq
<_whitenotifier-b>
[nmigen] whitequark commented on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8Rn
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8Rn
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8Rn
<_whitenotifier-b>
[nmigen] whitequark commented on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8RB
<_whitenotifier-b>
[nmigen] DaKnig commented on issue #441: PS7 block not initialized on series-7 Zynq targets - https://git.io/JJ8RD
jeanthom has quit [Ping timeout: 256 seconds]
<_whitenotifier-b>
[nmigen] rroohhh commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ80n
<_whitenotifier-b>
[nmigen] rroohhh edited a comment on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ80n
<_whitenotifier-b>
[nmigen] whitequark commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJ80F
<awygle>
is it just me or do there seem to be more users lately?
<DaKnig>
nah its just me filling up the space
<DaKnig>
I talk too much :)
<DaKnig>
and have many problems
<lkcl_away>
awygle: just more people yapping :)
<DaKnig>
you still away?
<DaKnig>
:)
lkcl_away is now known as lkcl
<whitequark>
awygle: there's a lot of activity though
jeanthom has joined #nmigen
<cr1901_modern>
Uhh, anybody own an Arty_Z7? Based on the nmigen-boards file, does it really not expose any DDR RAM to the FPGA pins?
<daveshah>
No, it doesn't, all the RAM is on the PS side
<daveshah>
This is typical for all the cheap Zynq dev boards
<cr1901_modern>
PS?
<cr1901_modern>
I have a cora_z7
* cr1901_modern
considers doing something fun today. Like porting cora_z7 to nmigen. Because it's not like I'm doing anything else productive w/ my life rn
<daveshah>
programmable system or somesuch
<daveshah>
the "ARM" side
<d1b2>
<emeb> IIRC from my days working with Zynq, you can put an AXI bus drop into the PL that will enable the fabric to access the DDR RAM, but it doesn't get exclusive access to it.
<daveshah>
Yeah, and you need the ARM side running to initialise the DDR and AXI bridges
<d1b2>
<emeb> Yep - the design flow that Xilinx promotes really focuses on the ARM side running the show.
<d1b2>
<314> is this still w/ xilinx tools or symbiflow?
<cr1901_modern>
What's the nmigen-boards philosophy on "the same dev board can have different FPGAs?"
<d1b2>
<314> and yeah- it's really annoying to have to dig through a huge amount of C boilerplate initialization code just to figure out how a sample design is configured :v
<cr1901_modern>
prior art (tinyfpga_ax) seems to suggest they are different boards?
<vup>
cr1901_modern: yes thats what wq suggested for the zturn lite aswell
<vup>
(another zynq board available with two different zynqs)
<whitequark>
cr1901_modern: vup: tbh this is not set in stone at all
<whitequark>
for now we're doing that but by no means i'm certain this is the best way
<whitequark>
i know that if resources differ (eg different FPGAs have different sets of usable pins, like on ecpix) going with different boards is appropriate
<whitequark>
but for something like tinyfpga or zturn, not sure
<vup>
Yeah, one simple thing to consider might be putting these in the same file. The zturn lite already uses inheritance to avoid duplicating the pinout, that might be something to consider for the tinyfpga aswell?
<whitequark>
can you open an RFC on the boards repo so we can discuss it?
<whitequark>
or just an issue
<vup>
sure
<_whitenotifier-b>
[nmigen-boards] rroohhh opened issue #89: [RFC] handling boards that are very similar - https://git.io/JJ8zy
<_whitenotifier-b>
[nmigen-boards] rroohhh edited issue #89: [RFC] handling boards that are very similar - https://git.io/JJ8zy
Kekskruemel has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
Asuu has joined #nmigen
Asu has quit [Ping timeout: 264 seconds]
Kekskruemel has quit [Quit: Leaving]
Asuu has quit [Quit: Konversation terminated!]
jeanthom has quit [Ping timeout: 240 seconds]
<d1b2>
<נמר הגוקו> I might asking a dummy question so please forgive me about it :P Is it possible to simulate my own LiteX SoC with lxsim?
<whitequark>
LiteX doesn't use nMigen yet
<whitequark>
so... asking in the wrong channel
<d1b2>
<נמר הגוקו> Can you suggest me the right channel please?
<awygle>
#litex
<d1b2>
<נמר הגוקו> I can't find it
<d1b2>
<Qyriad> #litex on freenode IRC, not the 1b2 Discord