cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> bradbqc: that's not what sandboxPaths does inside nix
harryho has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> @astro coming back soon. is it OK if I connect it to a raspberry pi?
mtrbot-ml has quit [Remote host closed the connection]
mtrbot-ml has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> bradbqc: what bitstream are you trying to build?
<mtrbot-ml>
[mattermost] <sb10q> and disabling the sandbox makes your preexisting interfaces visible, it doesn't give you the ability to create new ones inside builds
<mtrbot-ml>
[mattermost] <sb10q> there are many ways to fix this problem...
<_whitenotifier>
[nmigen] whitequark commented on issue #256: Consider adding a --platform (or -p) option to generate - https://git.io/JeR2J
rohitksingh has joined #m-labs
<_whitenotifier>
[m-labs/nmigen-soc] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeR2D
harryho has quit [Remote host closed the connection]
harryho has joined #m-labs
<harryho>
whitequark: Thanks for the code. Based on your model, we can actually write a CSR DSL that
<harryho>
that's separated from the Elaboratables that define the r/w access logic and multiplexing, right?
<whitequark>
indeed that is the goal
<harryho>
Okay, I can try to handle the DSL part.
<whitequark>
I'm going to look into Wishbone next
<whitequark>
oh and I think I didn't mention this. the CSRBank in my scheme is replaced by using .align_to() before populating registers for each peripheral
<whitequark>
there is no real advantage to giving each peripheral its own 0x1000 of address space for a typical MMU-less nMigen SoC that always generates headers / modules used for CSR access
<whitequark>
in fact, closely packing each peripheral probably saves a small amount of logic
<whitequark>
but, (a) people like round numbers, (b) aligning peripherals to MMU pages allows some access control schemes to be used, (c) the CSR system I propose is intended to be able to emulate almost any existing CSR layout from some other chip
<whitequark>
and that can all be done with align_to()
<whitequark>
here's my rough plan for the Wishbone bridge.
<whitequark>
the Wishbone bridge would have the same .add()/.align_to() interfaces as CSRMultiplexer
<whitequark>
you could select the Wishbone and CSR datapath width independently when instantiating one
X-Scale has quit [Ping timeout: 264 seconds]
<whitequark>
then, it would appropriately set CSR mux alignment, and translate the addresses back and forth, so any code that runs WishboneCSRBridge.add() gets the actual address on Wishbone bus
<harryho>
I see
<zignig>
whitequark: csr code looks good, is there going to be named bit access aswell ?
<whitequark>
sure, on top of that
<zignig>
cool, after reading the code , this should bolt directly into the boneless external interface... ;) whee!
<zignig>
omigen, has a AutoCSR mixin. Is this going to be a goal for nmigen or do you have a different plan ?
<whitequark>
I'm planning to get rid of AutoCSR completely
<zignig>
I suspected as much. ;)
bradbqc has quit [Ping timeout: 260 seconds]
<whitequark>
nmigen doesn't have any magic like that so far (other than arguably Record, but even that is more restricted)
<zignig>
will try the new CSR tonight , I have written a hacky autobinder that will need to be replace with the new way.
<whitequark>
autobinder?
<zignig>
kind of like the CSR , it takes a series of named signals attaches them to the boneless external port, numbers them and creates an ASM fragment of addresses.
<whitequark>
ah.
<zignig>
it made it easier , because I could just wrap an elaboratable and it would glue it to the external bus automagically.
<harryho>
whitequark: The name for the CSRElement Record isn't relevant to the user-specified name for the CSR register, right?
<whitequark>
it may be specified for debugging and to make the generated code more readable
<harryho>
I see. Do you think it's good to have the DSL to instantiate the CSRElement interface for you?
<whitequark>
I think it should be done by the DSL, yes
<harryho>
ok
<whitequark>
rjo: sb0: any particular opinions on how wishbone should work in nmigen-soc?
<whitequark>
the main thing I want to change is to make address assignment more structured, a bit like CSRMultiplexer is currently done
<rjo>
yes. IMO address spaces should be first class citizens. also maybe wishbone can be seen or implemented as a subset of axi(lite). then one could focus on that. but I'm no expert.
<whitequark>
I agree re address spaces. I just came up with that conclusion independently.
<whitequark>
Wishbone seems awkwardly designed to me
<sb0>
whitequark: I: g.device.hardware: building bitstream ID 785599d201e2e64abe71667ae4f27541
<sb0>
ERROR: unsupported PCF command 'set_frequency' (on line 57)
<sb0>
ERROR: Loading PCF failed.
<whitequark>
sb0: update nextpnr
<whitequark>
rjo: i don't think axi bursts are compatible with wishbone bursts
<key2>
axi lite is not a stream definition ?
<key2>
do we need to have it on one specific bus type ?
<key2>
I mean can't we have both/any ?
<whitequark>
yes, i think we should just have separate wishbone and axi4 buses
<key2>
that's what I think too
<key2>
the idea is, we need to be able to map CSR on any bus
<key2>
then, if someone is using an AXI bus, it will work with his axi cores
<whitequark>
axi requires knowing burst length, wishbone provides no way of doing that
<whitequark>
so you can at best connect wishbone devices to axi buses
<key2>
yes I am not talking about mixing them
<whitequark>
rjo did
<whitequark>
so my response is to him
<whitequark>
it would be very easy to map CSR to any bus
<key2>
i say, suppose I have... an AXI core (cpu?) so I want to make a SoC with AXI. I should be able to
<whitequark>
it just needs to support registered feedback
<key2>
then the CSRBank will be mapped on AXI
<key2>
right
<key2>
the reason I am saying that is, I was doing some shit with a Zynq the other day
<key2>
with migen
<key2>
and
<key2>
I had to convert axi<>wishbone in order to have my CSR seen
<whitequark>
yeah, that's stupi
<key2>
it would have made my life easier to have directly axi there
<key2>
also
<key2>
another thing, a SoC should not necessarely have a CPU like misoc does. but rather be just a bus (more like litex)
<sb0>
whitequark: works, thanks
<whitequark>
yes
<key2>
it's often that we have a bus + CSR and control them from outside (wishbone master) without having a CPU
<whitequark>
that is how glasgow will use csr
<whitequark>
via i2c
<key2>
right
<key2>
well, i2c is usually more for accessing a bunch of regs pre-defined
<key2>
what i mean is that, ideally, you have a map of some registers here and there, and make them accessible trhough i2c
<whitequark>
yes
<whitequark>
that is also what i mean
<key2>
but not necessarely accessing the entire wishbone
<key2>
then yes
<key2>
then yes, you get a (wishbone) master, then give it a dictionnary or whatever of all the address of the CSR you are interested in, and make that accessibe through i2c
<whitequark>
no wishbone would be involved
<whitequark>
csr directly bridged to i2c
<key2>
that is better
<key2>
but one design could go access those CSR over the bus as master
<key2>
that is OK too
<key2>
and easier to implement
<key2>
rather that having the bus writing to the CSR and the i2c at the same time
<whitequark>
I don't understand what you mean
<key2>
let say you have some CSR on one bank, and some on another bank. you could have a I2C core that access those CSR directly. but you could also have your i2c core being master on the main bus, and accessing those CSR through the bus
<whitequark>
there's no CSR banks anymore
<key2>
?
<key2>
why not ?
<whitequark>
what is their usefulness?
<key2>
well I have a core, and I declare CSR. I want them to be mapped on the final bus i am using at the end
<key2>
what is wrong with that ?
<whitequark>
so you make a bridge to your final bus, and give it all of your CSR
<whitequark>
that's i
<whitequark>
*it
<key2>
it's not clear to me
<whitequark>
there are no "Wishbone banks", why would there be CSR banks?
<key2>
ok. suppose we have a UART core as we do today in misoc. the simple fact that I add the UART core to my design brings all its CSR to the wishbone bus today
<key2>
what would it be with nmigen-soc ?
<whitequark>
let's see
<whitequark>
when you add something like an UART to a design you are declaring that you want to reserve some CSR address space and map it to the registers you declare
<whitequark>
exactly how the address space will look like, is determined by the interconnect that your design is using
<whitequark>
so a 32-bit register could be mapped consecutively to 4 8-bit machine words, or to 4 32-bit machine words, or 1 32-bit machine word, depending on how the rest of the logic looks like
<key2>
yes
<key2>
but when coding
<key2>
what do I have to do?
<key2>
beside adding the UART core to my SoC ?
<whitequark>
when instantiating the UART you give it the interconnect you want to use
<whitequark>
so it will ask that to actually place the register
<key2>
why not have something that knows that we are using wishbone or axi and does the job automatically for you ?
<whitequark>
what I have in mind is: suppose you have some complicated set of interconnect you have built as a SoC designer, that may have, in any sequence or order, things like CSR, WB, AXI, bridges between any of these, things like serwb or debug UARTs, and so on. I want to make a structured way to trace a path through this interconnect, from any endpoint to the other
<whitequark>
then, generating accessors for example, would consist of simply asking the interconnect for all paths that end on a specific CPU, and grouping together all paths to the same element
<whitequark>
it would work the same way for a Wishbone memory, a Wishbone peripheral, an AXI peripheral, a CSR through any bus, whatever, what you get is e.g. "this CSRElement() instance can be accessed at addresses 0x1000, 0x1004, 0x1008, 0x100c with 8 bit width" or somesuch
<whitequark>
it would also be quite interesting if you could connect existing memory maps (say loaded from an SVD file) to your interconnect and have them nicely integrate
<whitequark>
another thing ARTIQ already needs, actually
harryho has quit [Remote host closed the connection]
<whitequark>
aside: is Record's Direction functionality all that useful? it can't be used for CSR (because you need to split them into chunks), it can't be used for Wishbone (because the spec doesn't define behavior with cyc/stb deasserted), it can't be used for AXI4 or AXI4Lite for similar reasons
<whitequark>
it can't even be used for AXI4-Stream, since you would need to AND the ready signals, not OR them
<whitequark>
it's a declarative interface for connecting buses, but it can't describe practically any interesting bus. worse, most buses are configurable (e.g. wishbone has application-specific tag bits), and you can't really say "if a device doesn't support this tag field, it can be ignored, but if it doesn't support that other tag field, connect must fail because it carries memory protection bits" or something
<whitequark>
a Record is handy for describing the *payload* of a stream, but that always goes in one direction, so you can just use .eq()
<whitequark>
IMO we should deprecate and remove Direction and .connect()
harryho has joined #m-labs
<mtrbot-ml>
[mattermost] <harryho> whitequark: In nmigen, is there a convenient way to apply a bitmask over some Signal (or Cat of Signals) and make the result usable on the LHS of `eq`?
<whitequark>
harryho: what sort of bitmask? continuous string of 1s or just a random set of bits?
<mtrbot-ml>
[mattermost] <harryho> A constant binary value, not necessarily having continuous 1s in it
<mtrbot-ml>
[mattermost] <harryho> *consecutive
<whitequark>
harryho: you can do something like v[0,1,2,5] and that will give you a 4-bit value usable on LHS and RHS
<whitequark>
with just those bits in that order
<mtrbot-ml>
[mattermost] <harryho> Ok, yea that's what I thought
<mtrbot-ml>
[mattermost] <harryho> Thanks
rohitksingh has quit [Ping timeout: 250 seconds]
<mtrbot-ml>
[mattermost] <sb10q> @astro the zc706 is now on rpi-4.m-labs.hk
<mtrbot-ml>
[mattermost] <sb10q> if anyone else wants remote access to any board let me know
rohitksingh has joined #m-labs
sb0 has quit [Quit: Leaving]
rohitksingh has quit [Ping timeout: 264 seconds]
jayaura has quit [Remote host closed the connection]
xobs has quit [Remote host closed the connection]
marble[m] has quit [Read error: Connection reset by peer]
rjo has quit [Write error: Connection reset by peer]
jryans has quit [Write error: Connection reset by peer]
synaption[m] has quit [Remote host closed the connection]
jfng has quit [Remote host closed the connection]
bradbqc has joined #m-labs
<bradbqc>
sb10q: I'm trying to build a kc705 variant. And okay, I thought that disabling the sandbox would make the existing interfaces visible, but if I remove the tap interface creation altogether I just go back to getting the same license error I started with
<bradbqc>
And if there are many ways to fix the problem that's great. At this point, I'll take any solution I can get
mumptai has joined #m-labs
bradbqc has quit [Remote host closed the connection]
<_whitenotifier>
[nmigen] akukulanski opened issue #257: Unexpected behaviour of `Record.connect()` - https://git.io/JeRFg
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
rjo has joined #m-labs
mumptai has quit [Remote host closed the connection]
rjo has quit [Ping timeout: 276 seconds]
rjo has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> You can create the tap interface outside the build, then disable the sandbox
<mtrbot-ml>
[mattermost] <sb10q> Another way would be to convince xilinx that they should actually improve their software, which isn't very good to begin with, instead of actively crippling it with flexlm trash like this
<mtrbot-ml>
[mattermost] <sb10q> whitequark: why can't it be used for CSR and wishbone exactly? Seems it has worked fine in misoc for this purpose