<_florent_>
sajattack[m]: indeed there is no default serial on the acorn_cle_215, you can use --uart-name=crossover or --uart-name=jtag_uart
<_florent_>
for the CSR, 512-bit should be ok yes but probably not very efficient (in resource and performance)
<_florent_>
st-gourichon-fid: Hi, that's true that we only focused on the gateware side for CSRField, having software support in csr.h for them would be nice. Instead of inject/extract, we could maybe just use write/read but create additional functions for the CSRFields.
<_florent_>
ex: we have a control CSR with an enable Field: csr.h would then have a xy_control_write/read functions and also xy_control_enable_write/read functions?
<zyp>
having write functions for individual fields is inefficient if you want to set more than one of them at the same time
<zyp>
it's better to compose all the changes in a local variable before writing everything at once
<_florent_>
zyp: yes sure, that would just provide an easy way to access the fields when inefficiency is not an issue and this could be based on a generic inject/extract functions (maybe renamed to write_field/read_field? set_field/get_field?) that could also be used by the user for better efficiency.
<st-gourichon-fid>
_florent_, hi and thanks for your comment.
<st-gourichon-fid>
hi zyp too.
<st-gourichon-fid>
So far I wrote some local code that reflects both your inputs.
<st-gourichon-fid>
Reading/writing the whole CSR is already provided by LiteX. Pondering a rename. Currently mycsrname_myfield_inject, could be mycsrname_set_myfield() mycsrname_write_myfield(). (Same consideration for extract/get/read.)
<st-gourichon-fid>
It works here for us at the moment. Makes very shot and readable client code. Will use it for a moment before offering a PR.
<st-gourichon-fid>
TL;DR: makes fields as easy to use as plain registers.
<st-gourichon-fid>
s/very shot/very short/
KSmith has quit [Read error: Connection reset by peer]
<tpb>
Title: Fix syntax error preventing to use CSRField. by fidergo-stephane-gourichon · Pull Request #673 · enjoy-digital/litex · GitHub (at github.com)
<_florent_>
st-gourichon-fid: thanks, sure when you think you have something that would useful for others, feel free to create PR :), we could discuss the naming in the PR.
<_florent_>
daveshah: ping? (just got your results with Alveo U250)
<daveshah>
pogn
<daveshah>
*pong
<_florent_>
thanks for the test, i just got the XCU1525 working on my side (but with UDIMM)
<_florent_>
the automatic Clk/Cmd scan still has difficulties in some cases
<daveshah>
that's useful to know
<_florent_>
maybe you could try to force it with the command from the bios, 2s
<_florent_>
you could use sdram_force_cmd_delay command with a delay between 0 and 511
<_florent_>
with steps of 50 for example
<_florent_>
and then look at the write leveling data scan
<_florent_>
to try to see a full cycle of ones on each module
<daveshah>
no dice on sdram_force_cmd_delay based on a quick test. All I observe is that the first 4 bytes then start failing between 250 and 300, no value seems to make the last 4 work
<daveshah>
that's a good idea; if that doesn't work I will check the RCD config again
<_florent_>
ah otherwise, before rebuilding a bitstream
<_florent_>
it's now possible to write the MR registers from the bios
<daveshah>
oh nice
<_florent_>
and i've found it to be useful when debugging
<_florent_>
because it easily allow you to see latency related issues (for example by reducing cl/cwl by one cycle)
<_florent_>
daveshah: the best is around 400 where we see the beginning of the 0 to 1 transition for all modules except m4
<_florent_>
daveshah: otherwise you can try to increase the sys_clk_frequency
<_florent_>
this will reduce the side of the ones window and could help
<_florent_>
on the xcu1525 i tested up to 200MHz (i had problem at more, but with the compilation, will look at it)
<daveshah>
hmm, having trouble with the PLL config above 125MHz too
<daveshah>
200MHz fails as do other common freqs inbetween
<daveshah>
ah, maybe I need to change the IDELAY reference too
<_florent_>
yes, 400MHz for the idelay_clk_freq was fine with a sys_clk_freq of 200MHz
<_florent_>
but i should change that and use a separate PLL for the idelay clk (that's already done in LiteDRAM generator IIRC)
<daveshah>
not happy at 200MHz system clk (and changing force_cmd_delay doesn't do much either) unfortunately - perhaps it needs cmd_latency back at 1?
<_florent_>
daveshah: ah possible for cmd_latency, but m7 seems to no longer be responding during the write leveling
<daveshah>
I can get a 0/1 transition for m7 by changing force_cmd_delay although it doesn't actually find a delay
<daveshah>
e.g with force_cmd_delay at 100 `m7: |11111111110000000000001110| delay: -`
<_florent_>
ah interesting, now that write latency can be calibrated, the write leveling could probably simplified a bit and just use the last transition
krickit has joined #litex
<krickit>
Hi everyone,
<st-gourichon-fid>
Hi
<krickit>
I have to folder: gateware e software, but I didn't understand how to use them
<krickit>
two*
<daveshah>
gateware contains the generated Verilog and resultant build products, including the final bitstream
<krickit>
yes, i know this difference, but i can't generate bitstream directly because i have to add other circuit in my fpga ed i don't understand how to use software folder in my project.
<krickit>
Can you help me?
<daveshah>
You can probably ignore the software folder and use the top level verilog in the gateware folder; combined by the memory init files also in the gateware folder that contain the software in a format suitable for readmemh
<daveshah>
pointing your tool to the top level verilog in the gateware and any verilog dependencies (like the CPU verilog source, check the generated tcl or whatever file for a list of these) should be enough
<krickit>
oh thanks. So the memory init files are the "compilation" of software folder
<daveshah>
yeah
<krickit>
thank you so much, now it's all more clear
CarlFK has quit [Ping timeout: 260 seconds]
CarlFK has joined #litex
CarlFK has quit [Quit: Leaving.]
CarlFK has joined #litex
CarlFK has quit [Quit: Leaving.]
_franck_5 has joined #litex
_franck_ has quit [Read error: Connection reset by peer]
_franck_5 is now known as _franck_
KSmith has joined #litex
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
_franck_ has quit [Quit: Ping timeout (120 seconds)]
_franck_ has joined #litex
krickit has quit [Ping timeout: 245 seconds]
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 - https://znc.in]
feldim2425 has joined #litex
awordnot has quit [Quit: Ping timeout (120 seconds)]