<mtrbot-ml>
[mattermost] <sb10q> @astro are you sure that this is the SDRAM support that we want?
sb0 has quit [Remote host closed the connection]
<mtrbot-ml>
[mattermost] <sb10q> the Zynq already has its own SDRAM controller and we should probably use that. I'm not even sure that the Zynq SDRAM can be routed to the FPGA fabric with the correct I/O structures as would be required to use the MiSoC soft controller and PHY.
<mtrbot-ml>
[mattermost] <sb10q> in fact I think it cannot
<harryho>
emily: Thanks for the tips. I ran into some issues when building nextpnr from source in nixpkgs 19.09, so I've been using 19.03 to build nmigen v0.1rc1.
<mtrbot-ml>
[mattermost] <sb10q> harryho: you shouldn't try to use heavyx with 19.09, there are lots of non-trivial issues with the new rustc there
<mtrbot-ml>
[mattermost] <sb10q> of course you could solve them, but it's better to keep things focused
<harryho>
Yea, just letting emily know that it might not be possible for me to use nixpkgs-unstable right now.
<mtrbot-ml>
[mattermost] <sb10q> there's also the option of copying the whole .nix files for yosys/nextpnr/etc. from nixpkgs-unstable straight into heavyx. they seem pretty self-contained and should work fine on 19.03 from what I can tell
<mtrbot-ml>
[mattermost] <sb10q> you could just copy them and then import those in the overlay
<mtrbot-ml>
[mattermost] <sb10q> and super.callPackage is probably easier than import, then they can be copied verbatim
<mtrbot-ml>
[mattermost] <sb10q> @hartytp @rjo do you happen to have some numbers on the exact TTL/DDS-frequency latency difference on Kasli+SMA-DIO+Urukul systems?
<mtrbot-ml>
[mattermost] <sb10q> or DDS phase
<harryho>
emily, whitequark, sb10q: I'm thinking either it's me being unfamiliar with nix, or there's actually an issue with nix: when I explicitly put `export PATH=...` to include yosys and sby in the `checkPhase` line in my .nix, Python prints a different `$PATH`. The same happens if I use `checkInputs = [yosys symbiyosys]` instead.
<harryho>
Interestingly, Python can't find sby only during my Minerva test, not during the nmigen test.
<whitequark>
harryho: sorry, I am not familiar with nix
<harryho>
Okay, just "fixed" it by manually adding a checkPhase for my .nix that builds the Minerva core.
<harryho>
Yea, nmigen v0.1rc1 is fine :)
rohitksingh has quit [Ping timeout: 264 seconds]
<whitequark>
harryho: so, the experiment I was going to try with the CSR bus (turn it into a shift register of sorts) did not turn out to be very beneficial
<whitequark>
the rest of your proposal is fine architecturally, but I think many changes would be valuable. it should be split into constituent parts (CSR bus, CSR DSL, Wishbone, CSR-to-Wishbone bridge) and reviewed as separate pull requests, ideally
<whitequark>
alternatively, I could also take the code and tests I wrote already for the experiment, merge them with the rest of your changes myself, and commit it all, then explain what I changed and why
<whitequark>
any preference?
harryho has quit [Remote host closed the connection]
<whitequark>
s/the rest of//
<mtrbot-ml>
[mattermost] <sb10q> @harryho if the Minerva test requires symbiyosys then the latter should be in checkInputs
<mtrbot-ml>
[mattermost] <harryho> @sb10q yes, I've done that :D
<whitequark>
harryho: yes, I looked at your latest code
<whitequark>
(as of a few hours ago)
<whitequark>
some of the issues:
<whitequark>
- in this case Timeline does not do anything that would not be more elegantly expressed with an FSM (since in nMigen you can put an FSM into an If)
<whitequark>
- the CSR bus should use nMigen naming internally, rather than Wishbone, since the plan is to make it generic, and also because it is a purely nMigen construct
<whitequark>
- I would probably make the CSR register addresses assigned by the CSR interconnect and not have them an attribute of the registers themselves, since their placement (aligned to word size) depends on the word size of the bus that is driving the CSR bus
<whitequark>
- I would separate the CSR bus logic (read/write strobes and data) from the CSR register logic (mapping from/to fields, and side effects on field access)
<whitequark>
- the use cases for non-atomic CSR registers seem very slim as they would be quite hard to use correctly
<rjo>
Sb10q: that'll depend on several factors: serdes or not, which dds. We'd have to measure it. I don't have the data
rohitksingh has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> okay I will measure it then
harryho has joined #m-labs
harryho has quit [Remote host closed the connection]
<harryho>
yes. I sent that message with mattermost, and just now I logged in using hexchat and this happened.
<harryho>
I saw your suggestions. Are you gonna push some new codes on -soc or should I try to make some changes myself?
<whitequark>
would probably be faster if I finished the implementation of CSRBus I wrote today and combined it with the rest of your code
<whitequark>
oh, by the way, how would CSR memories work? aren't they inherently impossible to make atomic?
<mtrbot-ml>
[mattermost] <sb10q> are we doing CSR memories?
<whitequark>
harryho's PR includes some unfinished stuff for CSR memories
<whitequark>
I don't really understand the use case or how could that be implemented
<mtrbot-ml>
[mattermost] <sb10q> in misoc they were a regular source of problems when the memory was larger than the CSR space of one device
<mtrbot-ml>
[mattermost] <sb10q> and they don't seem very elegant in general
<whitequark>
I concur
<whitequark>
I'd like to not add them to nmigen-soc at all
<mtrbot-ml>
[mattermost] <sb10q> also if one does need CSR memories, they can be implemented as a simple module that just uses the existing CSR API and adds two CSRs: address and data
<mtrbot-ml>
[mattermost] <sb10q> and this has another advantage
<mtrbot-ml>
[mattermost] <sb10q> in many cases, the CPU and the gateware aren't accessing the memory at the same time, so you don't want to dedicate a memory port to either
<mtrbot-ml>
[mattermost] <sb10q> that CSR memory access module could have an optional mode where it could mux the port and add a third CSR for the CPU to control the mux
<whitequark>
yes, that is also my concern
<whitequark>
especially with various issues around TDP RAMs
<whitequark>
(Yosys can't infer TDP BRAMs at all, some FPGAs don't even have them, etc)
<mtrbot-ml>
[mattermost] <sb10q> hmm, many designs do require them, so they should get well-supported at some point
<whitequark>
that will happen, yeah
<whitequark>
not very quickly though as Yosys BRAM inference pass has a lot of technical debt
<whitequark>
sb: so I had this idea of making a CSR interconnect that organizes the read/write shadow registers (that are used for atomic access) into CSR word wide shift registers. read access would strobe the capture signal then shift out, write access would shift in then strobe the update signal
<whitequark>
this seems really useful for exposing CSR over UART, SPI, I2C or somesuch
<whitequark>
and it is even more resource efficient
<whitequark>
unfortunately I can't come up with a really robust mapping of this scheme to something like Wishbone
<whitequark>
it is easy to do if the Wishbone master is guaranteed to access the words sequentially, but if e.g. it accesses a 32-bit register via a 8-bit bus in an order like 0, 2, 1, 3 it would silently get bad results
<whitequark>
one option would be to make this explicit by making all wide registers consist of two halves: one that triggers capture/update, and one that shifts data in/out
<whitequark>
but that would break mapping a u64 directly into MMIO space
<whitequark>
on the other hand, the generated code with explicit capture/update would work regardless of e.g. the order of access LLVM chooses, and regardless of any endianness
<whitequark>
what do you think about this scheme?
<whitequark>
so, let's say we have a 8-bit CSR bus, and a 32-bit Wishbone bus driving it. any register between 1 and 32 bits would be a single Wishbone cycle to a single location. a register between 32 and 64 bits would be two cycles: read from bottom half, then read from top half, and vice versa for writes.
<whitequark>
a register between 64 and 96 bits would be two reads or writes to top half and one read or write to bottom
<whitequark>
cc rjo who I think was interested in very wide registers some time ago?
sb0 has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> what if the CPU is interrupted in the middle of an atomic read operation?
<mtrbot-ml>
[mattermost] <sb10q> the core would get out of sync and then all subsequent read return broken data?
<whitequark>
sb: no, that is the reason to have the high/low parts explicit
<whitequark>
a write to the low part is used as a synchronization point, so there is no persistent state in the interconnect
<mtrbot-ml>
[mattermost] <sb10q> hmm
<mtrbot-ml>
[mattermost] <sb10q> what I like about the initial scheme (without shift register) is it's as surprise-free as it can get
<whitequark>
yes, that is a good thing about it
<mtrbot-ml>
[mattermost] <sb10q> and when you're reading manually e.g. with a memory dump command, you get the correct value
<whitequark>
but adding atomicity removes that property
<whitequark>
since strictly speaking neither compilers nor debuggers guarantee the order of memory accesses wider than machine word
<whitequark>
it may work most of the time (what about big-endian or1k vs little-endian risc-v though?) but when it breaks, it will break in a very confusing way
<whitequark>
another concern: what if e.g. gcc and llvm decide to access the words in different order?
<mtrbot-ml>
[mattermost] <sb10q> the CSRs could be zero padded and aligned to machine words, like it's done right now
<whitequark>
sure, I am talking about CSRs wider than machine words though
<whitequark>
like the RTIO u64 registers in artiq
<mtrbot-ml>
[mattermost] <sb10q> I mean the CSR bus is 8-bit
<mtrbot-ml>
[mattermost] <sb10q> yeah this RTIO register is a very special case
<mtrbot-ml>
[mattermost] <sb10q> in fact it would be fine if this isn't supported by the new CSR system but we need to write a special CPU interface for that
<mtrbot-ml>
[mattermost] <sb10q> if we make a 8-bit CSR bus, and then all CSR 8-bit values are zero-padded and aligned to machine words and each 8-bit access is explicit in the software (this is the default misoc behavior) then we're good, no?
<whitequark>
that would be very easy to do, yes
<whitequark>
I was thinking about doing the width conversion in the Wishbone-to-CSR interface
<whitequark>
but maybe that is not necessary
<mtrbot-ml>
[mattermost] <sb10q> yeah, that increases complexity and brings a small and likely unnecessary improvement in performance
<whitequark>
there is one benefit to it, namely that register layout would be determined only by their size and alignment
<whitequark>
so one could change the CSR bus width but keep the rest of software
<mtrbot-ml>
[mattermost] <sb10q> hm, true
<mtrbot-ml>
[mattermost] <sb10q> but changing the software is just recompile...
<whitequark>
I was thinking that the new CSR system could be useful in that it could represent existing register layouts
<whitequark>
say you have existing code written for some sort of peripheral and want your gateware to be compatible with it
<whitequark>
or, maybe you want to use nmigen-soc design as a part of larger project where you do not want to regenerate the headers each time
<whitequark>
replacing CSRStatus/CSRStorage with the new CSRField DSL solves almost all of that problem
<whitequark>
the only remaining part is predictable memory layout
<whitequark>
hm
<whitequark>
that would preclude the high/low shift register scheme anyway, though
<whitequark>
so I guess it's out
<whitequark>
and the choice is between "map CSR bus to Wishbone with CSR bus width" or "map CSR bus to Wishbone with Wishbone bus width"
<whitequark>
which is actually not an either-or situation at all, there simply needs to be a Wishbone interconnect converting between 8-bit and 32-bit buses (or any other desirable combination)
<whitequark>
and the CSR registers in the memory map should be aligned to the machine word
<mtrbot-ml>
[mattermost] <sb10q> it could be a CSR bus converter that converts between different widths of CSR buses
<whitequark>
but CSR is single-cycle, no?
<mtrbot-ml>
[mattermost] <sb10q> hm, right that wouldn't work
<rjo>
sidenote: about the CSR bus I remember someone a long time ago praising the idea of using a backing RAM for CSRs that are not changed from gateware to get rid of the big read data mux (or the bit OR tree).
<rjo>
about very wide CSRs, I don't remember where I wanted that. But may have been mapping the ethernet frame buffers of a MAC. The wide RTIO timestamp may indeed be a an exception. I wouldn't focus the design on that. But the wide RTIO data register (512b currently) is another use case. It may be similar to the Ethernet frame storage though.
Stormwind_mobile has quit [Ping timeout: 268 seconds]
<whitequark>
yes, it was the RTIO data register I think.
<whitequark>
a 512 bit register on 8 bit CSR bus will become 168 4-LUts
<whitequark>
that doesn't seem too extreme
rohitksingh has quit [Ping timeout: 245 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #m-labs
rohitksingh has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #m-labs
<ZirconiumX>
whitequark: did you synthesize that to check, or is there a rule of thumb for these things?
<whitequark>
ZirconiumX: i calculated the optimal representation from first principles
harryho has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 245 seconds]
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #m-labs
sb0 has quit [Quit: Leaving]
Stormwind_mobile has quit [Ping timeout: 268 seconds]
Stormwind_mobile has joined #m-labs
_whitelogger has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 265 seconds]
<Astro-_>
@sb10q the zc706 has 2x 1GB DDR3 for each PS + PL. I have transcribed the signals in py. ain't ram very useful to SoCs?
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #m-labs
<adamgreig>
is there any way to have nmigen generated verilog/rtlil contain elaboratable names for modules instead of all being U$$0, U$$1, etc? using verilator to simulate the output verilog is working well but it's a real pain to work out what's what in gtkwave
<adamgreig>
maybe it's because I'm doing "m.submodules += ..." instead of "m.submodules.x = ..."
<adamgreig>
but in a few places I have a m.submodles += [X() for _ in range(10)] sort of deal, so it would be lovely if a name could be inferred from the class name or something
<vup>
adamgreig: yes, i think it is a python limitation, that m.submodules += ... does not give you the names
<vup>
but you could use setattr
<adamgreig>
what attr would I set? i've just seen that using m.submodules.x = ... does lead to the right name in gtkwave which helps a lot already
<adamgreig>
but if it could grab the name from the type when unspecified that seems like it would be better than nothing
<adamgreig>
ah, but of course it's just got the returned module, not the class that made it
<vup>
yeah thats the basic problem i think
<vup>
but for more details i guess you'll have to ask whitequark
<vup>
for setattr i meant something like this:
<vup>
for i in range(10):
<vup>
setattr(m.submodules, "x" + str(i), X())
<adamgreig>
oh I see what you mean
<adamgreig>
that'd work I guess, bit less neat but oh well
<adamgreig>
swee
<adamgreig>
sweet*
<adamgreig>
now to actually fix my logic :p thanks vup!
<vup>
well you can of course fold it into a list comprehension if you want, but not sure thats actually better: [setattr(m.submodules, "x" + str(i), B()) for i in range(10)]
<vup>
great ;)
Stormwind_mobile has quit [Ping timeout: 268 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 276 seconds]
Stormwind_mobile has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> @astro not planning to use the PL RAM. How's the CSR interface going?
<Astro-_>
ok
<Astro-_>
I'm still figuring out the CSR interface
<Astro-_>
as always, tinkering on multiple projects (artiq, misoc, migen) is difficult for keeping an overview
<Astro-_>
I wouldn't structure it differently however :)
<Astro-_>
sorry for my slowness once again, but I don't want to deliver something that I don't understand
<_whitenotifier>
[nmigen] andresdemski commented on issue #236: How to simulate with two clock domains? - https://git.io/Je4Xv
mumptai has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 264 seconds]
bradbqc has joined #m-labs
<bradbqc>
sb10q: do you know how to create the interface inside the sandbox? It seems like sudo is required, but sudo doesn't work in these environments
bradbqc has quit [Remote host closed the connection]
<whitequark>
vup: you don't need setattr at all
<whitequark>
you can use m.submodules["name"] = module
<whitequark>
as for the default U$$ name, it's not entirely clear what is the best way for it to work, I'll probably revise it in future though
<mtrbot-ml>
[mattermost] <sb10q> bradbqc: read the nix code, see how sandbox paths are handled, do something similar
<vup>
whitequark: oh right, thanks. adamgreig: ^
<adamgreig>
Ah of course, thanks whitequark
rohitksingh has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> you can also do builds with the sandbox disabled