<benh>
_florent_: not quite working yet :-) See emails
darren099 has quit [Quit: Leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #litex
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #litex
Skip has quit [Remote host closed the connection]
HoloIRCUser has joined #litex
rohitksingh has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
HoloIRCUser has quit [Quit: HoloIRCUser]
futarisIRCcloud has joined #litex
<benh>
_florent_: so your latest change is triggering its own slew of problems
<benh>
_florent_: as I wrote in my response, the values in csr.h are wrong ... I tried using my own CSR accessors via CSR_ACCESSORS_DEFINED
<benh>
_florent_: but that's broken by all the "new" accessors in common.h
<benh>
things like csr_rd_buf_uint8
<benh>
there is no extern definition of them in csr.h
<benh>
and they are not defined at all by common.h when CSR_ACCESSORS_DEFINED is set
<benh>
so essentially, whatever CSR_ACCESSORS_DEFINED might have once been intended for, it's broken
CarlFK has quit [Ping timeout: 256 seconds]
<benh>
that said, those "new" accessors are also broken in different ways (my earlier discussion on this a few days ago) since they don't do memory barriers or similar
<benh>
it's particularly broken in that the new accessors will always do 64-bit accesses
<benh>
on a 64-bit platform
<benh>
so they will always 2 consecutive accesses to a 32-bit downconverted wb/csr bus
<benh>
which is not ideal, or even broken if you don't also set csr_alignment to 64-bit
<benh>
trying to fix that stuff but I'll need help testing the changes
<benh>
somlo: ping
<benh>
somlo: is it me mis-reading the code or are the "new" CSR accessors such as _csr_rd assume that CSRs are spaced "unsigned long" appart ?
<benh>
somlo: ie, 64-bit appart on a 64-bit system, and 32-bit appart on a 32-bit system
<benh>
somlo: due to how you just index a unsigned long* to increment addresses
Dolu has joined #litex
<benh>
somlo: shouldn't it instead be incremented by CONFIG_CSR_ALIGNMENT/8 bytes ?
<benh>
somlo: for example on microwatt I can have a setup such that CSRs are 32-bit appart on a 64-bit system
<benh>
(I don't have to ... but I can :-)
<benh>
also you can have processors that can run either 32-bit or 64-bit code...
<benh>
ie, you removed adr_width= so it's now setting the *data* width
<somlo>
benh: because it's always been 32 until the first 64bit CPU was added to litex (rocket), and I had to make it 64 on 64 to get it to work properly :)
<benh>
somlo: well, that's my whole point :-)
<benh>
somlo: I don't like how you wrote that code
<benh>
and it's a mistake to make that assumption that CSRs are unsigned long spaced
<benh>
and it's a bigger mistake to dereference an unsigned long to access them for a number of reasons
<benh>
one big one being that you can't just "access" IOs like that on most CPU architectures, you need things like memory barriers etc..
<somlo>
but right now they *are* -- not opposed to expressing that better, or fixing the underlying hardware so they don't *have* to be, but right now them's the breaks :)
<benh>
but you can have a 32-bit wishbone bridged
<benh>
on your 64-bit main bus
<benh>
which means now each of your CSR access turns into *2* accesses... pointlessly
<benh>
somlo: well, my point is that code is broken :-) Anyway, see the pastebin link I pasted above
<benh>
it's a quick attempt at fixing this and re-viving the ability to provide custom accessors with CSR_ACCESSORS_DEFINED which all those new things broke
<somlo>
I remember something about the CSR bus lacking a byte select signal, and adjacent registers being inadvertently "touched" without the software meaning to, on 64bit
<benh>
it's mostly untested for now as I'm working through other changes but please provide feedback
<benh>
somlo: well, if they are 64-bit appart, that hopefully won't happen but you might end up still doing weird things
<benh>
like writing the same reg twice
<benh>
again, *hopefully* my changes should fix all that
<benh>
the basic idea is that all the new fangled accessors are expressed on *top* of csr_{read,write}_simple and don't do poitner magic, but instead calculate the proper offset between registers
<benh>
and the csr_{read,write}_simple implementation is responsible for using the right access size
<benh>
I haven't fixed the latter in the general case yet
<benh>
only for me as I provide custom ones (with the proper memory barrier)
<benh>
but I'll do that next
<somlo>
I'm ok with rewriting a[i] as csr_*_simple(a) if that's the question :)
<benh>
and taking out the pointer arithmetic
<benh>
next (which I haven't done yet) is I'll make the default implementation of csr_*_simple use a csr_type * where csr_type is defined to the right uint64_t/uint32_t/uint8_t
<benh>
however, anything with an out of order memory model will probably need to provide its own implementation using appropriate IO accessors
<benh>
I'll look into that next, it will be needed for powerpc at least
<benh>
_florent_: I'm having some trouble figuring out how the CSR address decoding is done :-) It looks like the generated verilogg checks address bits 0 and 1 on 32-bit CSRs with 64-bit aliggnment
<benh>
_florent_: so I have to pass it something padded with "000" on the right
<benh>
somlo: generally LiteX needs proper IO accessors
<benh>
provided by the CPU implementation/wrapper
<somlo>
benh: if by that you mean `csr_[read|write]_simple()`, I agree. But I'd rather keep the higher-level (compound) register code common
<benh>
somlo: agreed, which is why I would like to build it on top of the simple ones
<benh>
somlo: let me know what you think please :-)
<benh>
somlo: I'll try to test it a bit in the meantime
<somlo>
benh: tbh, I used a[i] mostly because it helped me keep track of what's going on. But now that it's moe or less debugged and seems to work, I'm totally ok with factoring out the simple accesses as standalone functions
<somlo>
de002fe does that, as far as I can tell
<somlo>
I can try to test it later today, too, see what happens
<benh>
somlo: cool, thanks !
<benh>
somlo: if you're happy with it I'll send _florent_ a PR
<somlo>
well, I tried building it, but there's syntax errors (token "=" is not valid in preprocessor expressions) :)
<somlo>
you wanna fix it and I can try again, or should I switch that to "==" locally ?
<benh>
somlo: ah I have my own CSR defs .. so I might have mangled that
<benh>
somlo: either, fixing it now
<benh>
that's the doom of constantly switching between programmingg languages :-)
<benh>
pushed
<somlo>
building now (for the trellisboard, with gateware and all, so it'll be 20-30 minutes)
<benh>
somlo: ok, thanks !
<benh>
at some point I'll try to figure out how to add a cpu.h include that's provided by the cpu definition
<benh>
we''ll need things like proper IO accessors and memory barriers for DMA etc...
<benh>
that is then included by hw/common.h
<benh>
that will esp. matter when Dolu has SMP going as memory barriers, locks etc... are going to be a must have
<benh>
and those are at least architecture specific
<benh>
unless we entirely rely on the new fangled C primitives but ...
<somlo>
like the equivalent of `[read|write][l|q]()` in linux
<benh>
yup
<benh>
and memcpy_to/from_IO for ethernet
<benh>
and smp_mb/rmb/wmb, spinlocks, etc...
<benh>
for SMP VexRiscV
<benh>
etc...
<somlo>
Rocket could also be SMP, on larger FPGAs (I can barely fit a single core on ecp5, so it's never been a direct concern :)
<benh>
yeah a lot of these things aren't a concern ... yet :)
<benh>
but we fix microwatt in an Arty 35T today.. we could fit 2 in a 100T ;)
<Dolu>
benh: 2 SMP linux ready cores in 100T ?
<Dolu>
benh: about the smp stuff hw/common.h, you talk about its integration into the litex bios ?
<_florent_>
benh: sorry, i wasn't on irc
<somlo>
benh: c9fb9cd `Reviewed-by: Gabriel Somlo <gsomlo@gmail.com>` fwiw (no mailing list to do this over) :)
<zyp>
somlo, fit on a -85, or smaller?
<somlo>
zyp: a linux-capable (though FPU-less) 64bit rocket + litex SoC utilizes cca. 60% of the -85 on a trellisboard, at the moment
<somlo>
a FPU-enabled single-core 64bit rocket will *not* fit on the -85
<zyp>
I see
<zyp>
how does the ecp5 size figures compare to the artix-7 ones? is there a rough factor for comparisons?
<somlo>
zyp: the fpu-less single-core 64bit rocket *sometimes* fits on a -45 (on the ecp5 versa 5g). Utilization dances around the 100% logic block mark, and sometimes, when the stars align, you get 99% fromthe placer and routing can proceed
<somlo>
zyp: I think that's more of a daveshah question; I know I can do a fpu-enabled single-core rocket on the nexys4ddr (artix-7-100)
<somlo>
(with vivado, so not exactly apples-to-apples)
<zyp>
also, how far are we from being able to do a full artix-7 flow with open tools?
<zyp>
(somebody stop me if I'm asking too many stupid and/or offtopic questions)
<daveshah>
nextpnr for xilinx is probably a year away from being something I would actually recommend end users to use
<daveshah>
idk about vpr
<zyp>
what's the current state of nextpnr for xilinx? working but for a subset of features?
<benh>
somlo: thanks
<benh>
somlo: I'll send a PR
<benh>
Dolu: among others yes
<sorear>
given that riscv32 is probably never going to be well supported by binary distros, a more resource-efficient riscv64 is something I would like to see
<daveshah>
zyp: yes, roughly
<zyp>
daveshah, does a full nextpnr flow rely on any non-free bits at the moment, or is it possible to go all the way from verilog to a bitstream?
<daveshah>
You can go all the way to a bitstream with prjxray
<Dolu>
Only hart 0 get through crt0 to the bios code, the others will wait, and only be unlocked at the last moment before jumping into the payload (opensbi / linux)
<Dolu>
So, nearly nothing SMP at the litex bios level
<benh>
Dolu: ok, so yes, system.h isn't a bad place for that I suppose though it should probably be cpu.h
<benh>
for core specific bits
<benh>
Dolu: we would want a way to put MMIO accessors in there as well... I can propose something later, it's past bed time here :)
<benh>
_florent_: btw, microwatt will probably break on/off with LiteX ... I'll fix things up soon. The way we feed interrupts to the core for example is probably due to change
<Dolu>
benh: Ahh right, MMIO accessors should be added
<Dolu>
sorear: unfortunatly :(, i have no good idea how much RV64 would inflate VexRiscv
<benh>
microwatt with MMU takes about half an Arty 35T
<benh>
no FPU and no SIMD
<benh>
but it boots a hacked up linux
<benh>
it also could use bigger caches/TLBs and generally be faster, it still somewhat sucks ;-)
<benh>
VexRiscV starts with a much slimmer base line, it should be possible to keep it below that, again without FP and SIMD
<sorear>
possibly interesting experiment: add FP registers and loads/stores so that setjmp/longjmp and context switches don't trap, how much that makes things faster at what cost
<benh>
sorear: pretty much waht Paul is doing right now :-)
<benh>
add the basic regs and load/stores and SW emulate the rest
<benh>
maybe with a handful of "assist" instructions
<sorear>
(Paul?)
<benh>
the load/stores do require a bit of fiddling for single/double conversion etc.
<benh>
Paul Mackerras
<benh>
(on Microwatt that is)
<sorear>
ah
<sorear>
riscv is easier, there's no single/double conversion :)
<benh>
hehe
<benh>
I am not familiar with riscv FPU... double only ?
<sorear>
this is my one contribution to the riscv base spec
<benh>
on powerpc, it's always stored as a double in the register, so load/store single have to convert
<sorear>
the registers are double-sized, loading a single value and then storing it as double pads it on the left with 32 1s
<benh>
ok
<sorear>
so it becomes a DP NaN
<benh>
so the actual arithmetic ops operate on what ?
<sorear>
the actual arithmetic ops are all tagged with a size and there's an explicit "double/single conversion with register src and dest" instruction
<sorear>
mixing sizes on a register without conversion will not do anything useful
<benh>
I see.. doesn't that make the FPU more complex ?
<sorear>
it's supported exactly to the extent to allow registers containing single to be saved and restored by generic code
<benh>
powerpc always has doubles in the registers and all arith. ops are double
<benh>
single is only an artifact of load/store conv.
<benh>
I suppose it's just a few more muxes in the FPU to select how many bits of mantissa and exponent you use based on the tag
<sorear>
ugh, FLT_EVAL_METHOD makes me sad
<benh>
but that adds to the critical timing path, doesn't it ?
<sorear>
I forget exactly what we put where, but Rocket uses an internal 65-bit float format with no subnormals and all of the annoying timing stuff happens on loads/stores only
<sorear>
doing single math in real single precision is important, it means fp behavior doesn't silently change between -O0 and -O1
<sorear>
i686 gets this catestrophically wrong (all operations are *long double* unless spilled to memory), it sounds like ppc at least does double ops in intended precision
<benh>
yup
<benh>
allright, I do need to call it a day, it's already tomorrow here :-)
st-gourichon-f has joined #litex
st-gourichon-fid has quit [Ping timeout: 256 seconds]
tmbinc1 is now known as tmbinc
scanakci has quit [Quit: Connection closed for inactivity]
<CarlFK>
xobs: bunnie: netv2 in a pc's pci slot - do I need to give it 12v on the barrel connector?
robert2 has joined #litex
Dolu has quit [Quit: Leaving]
<kgugala>
CarlFK: you can power it via pcie connector
<CarlFK>
kgugala: good. installing vivado now.. I need that right ?
<kgugala>
yep
<kgugala>
CarlFK: do you have a100t or a50t version of netv2?
<CarlFK>
both
kgugala_ has joined #litex
<CarlFK>
Vivado HLx 2019.2: All OS installer Single-File Download (TAR/GZIP - 26.55 GB) *surprised face*
kgugala has quit [Quit: WeeChat 2.7.1]
kgugala_ is now known as kgugala
scanakci has joined #litex
kgugala has quit [Quit: -a- IRC for Android 2.1.55]
kgugala has joined #litex
<CarlFK>
INFO : Installation completed successfully.
<CarlFK>
that' wasn't too bad.
<CarlFK>
kgugala: juser@cnt4:~/tv/netv2$ make gateware/target
<CarlFK>
make: *** No rule to make target 'gateware/target'. Stop.
<CarlFK>
kgugala: "4. Go back to netv2 directory and build the bitstream:"
<kgugala>
CarlFK you need to select the target e.g gateware/build or gateware/load (or clean)
Skip has quit [Remote host closed the connection]
<kgugala>
or simply run make build - this should build all
<CarlFK>
there's no makefile 'here'
<CarlFK>
and i have a feeling there is some other netv2 dir I should be in
<daveshah>
You don't need to build it from scratch
<daveshah>
(despite the ubuntu14 it seems to run fine on any linux)
<CarlFK>
application-specific initialization failed: couldn't load file "librdi_commontasks.so": libtinfo.so.5: cannot open shared object file: No such file or directory
<CarlFK>
but it is stil doing something
<CarlFK>
maybe not. cpus are all idle
robert2 has quit [Remote host closed the connection]
<tumbleweed>
CarlFK: install libtinfo5
<tumbleweed>
(or go back to compiling compilers
<tumbleweed>
or install gcc-riscv64-unknown-elf - yes we do have a packaged cross-compiler
ambro718 has joined #litex
ambro718 has quit [Quit: Konversation terminated!]