<_whitenotifier>
[nmigen] RobertBaruch commented on issue #256: Consider adding a --platform (or -p) option to generate - https://git.io/JeRvl
harryho has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> @astro so in your opinion, the zynq trash-hardware-corner-cases make it impossible in practice to use Ethernet unless the SDRAM is also used?
<mtrbot-ml>
[mattermost] <sb10q> this makes it a bit annoying for network-enabled bootloaders...
<_whitenotifier>
[nmigen] whitequark commented on issue #256: Consider adding a --platform (or -p) option to generate - https://git.io/JeRvo
<whitequark>
wait, what?
<whitequark>
you can't use ethernet without sdram?
<whitequark>
that sounds nuts
<whitequark>
does it not have its own buffers?
<mtrbot-ml>
[mattermost] <sb10q> Not sure if there's a mode that would work without DMA?
<whitequark>
ah
<mtrbot-ml>
[mattermost] <sb10q> according to the doc there isn't, the packets go straight into the DMA engine, and then there are typical intellectual-poverty-vendor decisions that make it not work correctly with on-chip memory
<mtrbot-ml>
[mattermost] <sb10q> so, network bootloaders would have to run from the SDRAM
<mtrbot-ml>
[mattermost] <sb10q> or the bootloader could deploy a less shitty Ethernet MAC in the PL, but that also sounds complicated...
<mtrbot-ml>
[mattermost] <sb10q> the suggested startup sequence for zynq has no fewer than three stages of bootloaders (BootROM, FSBL, U-Boot)
lkcl has quit [Ping timeout: 250 seconds]
X-Scale has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
X-Scale has joined #m-labs
<ZirconiumX>
If you declare a signed signal, does it get sign-extended if you add it to a wider signal?
<whitequark>
yes
<whitequark>
that's kind of the point of signed signals
<whitequark>
well, half of it? the other half, changing the behavior of most arithmetic operations
sb0 has joined #m-labs
<mtrbot-ml>
[mattermost] <harryho> whitequark, sb10q: Sorry I didn't catch up with the discussion about CSR until today. Here are some questions I have:
<mtrbot-ml>
[mattermost] <harryho>
<mtrbot-ml>
[mattermost] <harryho> 1. Could you clarify what you meant by naming the CSR busses internally? Did you mean the interface signals (re, we, etc)?
<mtrbot-ml>
[mattermost] <harryho>
<mtrbot-ml>
[mattermost] <harryho> 1. If we remove the bus-dependent address (e.g. Wishbone address) from the list of `CSRBank` attributes, wouldn't it be impossible to implement the logic to check whether the bus is accessing the right CSR register? I think instead of requiring setting the address at `CSRBank`'s init, we can let an external class to access to such address attribute when finalising the address mapping.
<mtrbot-ml>
[mattermost] <harryho>
<mtrbot-ml>
[mattermost] <harryho> 2. When you talked about separating CSR bus logic from CSR register logic, do you mean the logic that detects r/w strobes should be separated from the logic that determines which actual CSR fields can be written (i.e. fields that are not read only)? I suppose, the former be in CSR bus and the latter be in CSR DSL, maybe?
<mtrbot-ml>
[mattermost] <harryho>
<mtrbot-ml>
[mattermost] <harryho> 3. Are there any urgent changes needed for the Wishbone Python module?
<mtrbot-ml>
[mattermost] <harryho>
<mtrbot-ml>
[mattermost] <harryho> 4. After we fix the CSR classes, WB interconnect and WB-to-CSR bridge, I'd like to propose a Python module that adopts some part of `misoc.integration.soc_core`: a class that allows init-ing with a base CPU address for CSR banks, makes a WB-to-CSR bridge, interconnects the bridge with the CSR busses in the banks (array of banks?), and generates the CPU address mapping for the fir <message clipped>
<whitequark>
harryho: your last message got clipped after "generates the CPU address mapping"
<mtrbot-ml>
[mattermost] <harryho> ... for the firmware later on (e.g. through a SVD generator and SVD-to-Rust tool).
<whitequark>
CSR signal naming: yes
<whitequark>
two questions re CSR bus logic: I'll hopefully push some code today that answers it
<whitequark>
Wishbone: the layout should at least not be fixed at 32 bits
<whitequark>
the Wishbone spec allows 8, 16, 32 and 64 bit datapath
<whitequark>
soc_core: maybe, but it is usually best to avoid such utility classes by making other components fit together more closely
<whitequark>
if the amount of code required to integrate WB/CSR/registers is 2 or 3 lines, then obviously there is no need for a class, since it is trivial to instantiate that for any sort of SoC
harryho has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 250 seconds]
harryho has joined #m-labs
harryho has quit [Remote host closed the connection]
<ZirconiumX>
So, I updated my nMigen and found Signal((3, True)) is deprecated for Signal(signed(3)), except that the latter gives a NameError that signed is not defined
<ZirconiumX>
I'm probably missing something
<whitequark>
how are you importing Signal ?
<ZirconiumX>
Okay, yeah, I needed to import it from nmigen
<ZirconiumX>
from nmigen import Signal
<ZirconiumX>
I have a snippet of "from nmigen import Elaboratable, Module, Signal; from nmigen.back import pysim, verilog" because I need to do it so much
bradbqc has quit [Remote host closed the connection]
<whitequark>
ZirconiumX: `from nmigen import *`
<_whitenotifier>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JeRYS
harryho has quit [Remote host closed the connection]
Stary has joined #m-labs
<_whitenotifier>
[m-labs/nmigen-soc] whitequark pushed 1 commit to master [+4/-0/±1] https://git.io/JeRZw
<_whitenotifier>
[m-labs/nmigen-soc] whitequark dc918fc - csr.bus: add CSRElement and CSRMultiplexer.
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
<mtrbot-ml>
[mattermost] <astro> @sb10q I honestly don't know yet
<_whitenotifier>
[nmigen-soc] jordens commented on commit dc918fc20b667c24bd91cf2b9b2e6ef6c69e12e0 - https://git.io/JeRCf
<_whitenotifier>
[nmigen-soc] whitequark commented on commit dc918fc20b667c24bd91cf2b9b2e6ef6c69e12e0 - https://git.io/JeRCl
<_whitenotifier>
[nmigen-soc] whitequark commented on commit dc918fc20b667c24bd91cf2b9b2e6ef6c69e12e0 - https://git.io/JeRCu
<_whitenotifier>
[nmigen-soc] jordens commented on commit dc918fc20b667c24bd91cf2b9b2e6ef6c69e12e0 - https://git.io/JeRCX
mumptai has joined #m-labs
<mtrbot-ml>
[mattermost] <astro> the zc706 has been disconnected from nixbld. I'll continue with my cora z7-10 for now...
bradbqc has joined #m-labs
<_whitenotifier>
[nmigen-soc] whitequark commented on commit dc918fc20b667c24bd91cf2b9b2e6ef6c69e12e0 - https://git.io/JeRW3
<bradbqc>
sb10q: can you provide any more hints? I've tried to do what you said but can't seem to figure it out. I created a security wrapper for pkgs.iproute.ip with added net_admin capability and then added /run/wrappers to sandboxPaths but I keep getting a "file does not exist" when I try to execute it from within vivado.nix
bradbqc36 has joined #m-labs
bradbqc36 has quit [Remote host closed the connection]
bradbqc has quit [Ping timeout: 260 seconds]
bradbqc has joined #m-labs
<_whitenotifier>
[nmigen-soc] jordens commented on commit dc918fc20b667c24bd91cf2b9b2e6ef6c69e12e0 - https://git.io/JeRlw
<bradbqc>
Even if I disable sandboxing I get "cannot raise the capability into the Ambient set" (which I don't get when running the wrapped ip executable in a normal shell)
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 276 seconds]
sandeepkr has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
lkcl has quit [Ping timeout: 240 seconds]
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #256: Consider adding a --platform (or -p) option to generate - https://git.io/JeREB
balrog has quit [Ping timeout: 276 seconds]
balrog has joined #m-labs
lkcl has joined #m-labs
mumptai has quit [Remote host closed the connection]