<tmbinc>
this is CH1, and the DC offset is a bit hard to find (0x2600 constant, varies likely from scope to scope), so we need a cal tool at some point
<mikeK_de1soc>
Sweet!!!!! :)
<mikeK_de1soc>
Great Job!!
<tmbinc>
Thanks - actually litex made all of this easy and fun
<tmbinc>
_every_ single thing "just worked", 100% as expected. That is not typical for me working with FPGAs. :)
<mikeK_de1soc>
yes, I just my board up an running... the DE1-SoC.. not as exciting as the Scope tho...
<mikeK_de1soc>
do you have the display up and running?
<tmbinc>
We had it working in the old vivado-based design (just as a Linux framebuffer)
lf has quit [Ping timeout: 260 seconds]
<mikeK_de1soc>
ah ok... IS that in the files too? i wanted to check on the code, if you don;t mind.
<mikeK_de1soc>
Nice!! I am at the VGA section for my "altera" board. this is where i am stuck..
<mikeK_de1soc>
the vga seems to be setup for the xilinx dev tools.. not altera(intel)
<mikeK_de1soc>
tmbinc: I have a quick question if that's ok! Where do you call the "litex_boards/targets/sds1104xe_config.py" file from?
mikeK_de1soc has quit [Quit: Connection closed]
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex
mikeK_de1soc has joined #litex
mikeK_de1soc has quit [Ping timeout: 240 seconds]
mikeK_de1soc has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
mikeK_de1soc has quit [Quit: Connection closed]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 265 seconds]
Bertl_oO is now known as Bertl_zZ
dormito has joined #litex
<dormito>
As I understand it litex generates the hdl for a SoCs wishbone fabric (for projects that use wishbone). Is there a good mechanism for controlling the address of modules at run time? (especially simple special case situations, like swapping two bus maping addresses if a register bit is set)
<_florent_>
tmbinc: nice! So the next step would probably be to simplify the repository (with just the target + scripts) and add a capture datapath to upload the samples to the Host
<_florent_>
tmbinc: here is a simplified version what I have in mind for a first capture datapath:
<_florent_>
This would allow doing large captures (with up to 20Gbps of bandwidth from the ADC) and upload slowly at 100Mbps to the Host
<_florent_>
I could work on this part
st-gourichon-fid has quit [*.net *.split]
st-gourichon-fid has joined #litex
jevinskie[m] has quit [Ping timeout: 240 seconds]
leons has quit [Ping timeout: 240 seconds]
jryans has quit [Ping timeout: 246 seconds]
sajattack[m] has quit [Ping timeout: 246 seconds]
apolkosnik[m] has quit [Ping timeout: 244 seconds]
CarlFK[m] has quit [Ping timeout: 244 seconds]
disasm[m] has quit [Ping timeout: 244 seconds]
david-sawatzke[m has quit [Ping timeout: 244 seconds]
xobs has quit [Ping timeout: 244 seconds]
promach3 has quit [Ping timeout: 265 seconds]
<tmbinc>
_florent_: sounds good. The fifo would need to handle pre-trigger capture, but essentially it's just flushing data from the beginning.
<tmbinc>
I can simplify the repo
<_florent_>
tmbinc: ok thanks, that's just a first idea to upload the samples to the Host, we'll of course refine this. For the pre-trigger, we could add a module at the output of the FIFO that would ensure we always have the previous N samples in the FIFO (ie flush the output when more than N stored) and disable this behavior when the capture starts.
<_florent_>
tmbinc: this how pre-trigger is implemented in LiteScope (but with a BlockRAM FIFO). I'm also realizing that working on this will also be useful to use a LiteDRAM FIFO with LiteScope :) (wanted to work on this for some time now).
<_florent_>
Melkhior: that could make sense and would probably be relevant yes, do you want to do a PR this? (just saw you have a pending PR for Vex :))
<_florent_>
The RISC-V cores currently supported are:
<Melkhior>
I can do the PR if it's fine with you, didn't want to jump the gun
<_florent_>
- BlackParrot
<_florent_>
- CV32E40P
<_florent_>
- Minerva
<_florent_>
- PicoRV32
<_florent_>
- Rocket
<_florent_>
- SERV
<Melkhior>
that's one long list of cores :-)
<_florent_>
- VexRiscv (SMP)
<_florent_>
(and that's the end for now :))
proteusguy has quit [Remote host closed the connection]
<Melkhior>
_florent_ how do I describe the license ? That looks like BSD ?
<Melkhior>
_florent_ I decided against mentioning there's additional non-RISC-V cores... might not be the best place :-)
<_florent_>
Melkhior: thanks, this looks good yes; I also think we should just list the RISC-V cores
<Melkhior>
all on your list are RISC-V I think ? (i.e. microwatt isn't in there)
<Melkhior>
I know most of them but not all
sajattack[m] has joined #litex
david-sawatzke[m has joined #litex
leons has joined #litex
jevinskie[m] has joined #litex
promach3 has joined #litex
xobs has joined #litex
disasm[m] has joined #litex
CarlFK[m] has joined #litex
apolkosnik[m] has joined #litex
<_florent_>
yes I only listed the RISC-V ones
<Melkhior>
ok
<Melkhior>
thx
<Melkhior>
PR #67
<_florent_>
thanks!
<Melkhior>
_florent_ can you give an OK in the PR as enjoy-digital ? just in case they wonder why it's not the primary author doing the PR...
<tmbinc>
_florent_: any opinion about repo name? 360nosc0pe/scope? litex-scope? litex-sds? I want to express that it is based on litex but not part of litex, how do other FPGA-specific repos handle this?
<_florent_>
tmbinc: scope is a good name yes (we could still change it later if we found a better name), litex-scope would also have been a good name but is maybe too close to LiteScope so will be confusing, so scope is probably better
<_florent_>
tmbinc: I'm using this font for the ASCII art on the others repos: https://patorjk.com/software/taag/#p=display&f=Small%20Slant&t=360nosc0pe
<tpb>
Title: Text to ASCII Art Generator (TAAG) (at patorjk.com)
<_florent_>
tmbinc: but this is just a preference :), no important
<_florent_>
otherwise this looks fine and will provide us a good basis to play with the scope, thanks!
geertu has quit [Ping timeout: 256 seconds]
<tmbinc>
_florent_: fixed (the font)
geertu has joined #litex
proteusguy has joined #litex
key2 has quit [Remote host closed the connection]
Bertl_zZ is now known as Bertl
key2 has joined #litex
mikeK_de1soc has joined #litex
mikeK_de1soc has quit [Ping timeout: 240 seconds]
mikeK_de1soc has joined #litex
<mikeK_de1soc>
_florent_: I would like to submit a PR for the work that I have done on the DE1-SoC board in my tweet, (Thanks for the like btw). Again, I am not very experienced in this. I have several changes in multiple repositories. Do I submit each one individually, and you review each one? Also, I started to add the support for the Framebuffer for the
<mikeK_de1soc>
Cyclone5 devices. But currently it's not working yet. Did you want me ignore those at the moment? Currently the build will pass because I have the Frame buffer ignored in make.py makefile. Thanks! MikeK
<_florent_>
mikeK_de1soc: yes, you could create PRs for the parts that have been validated, for the framebuffer, we can wait to have something working before integrating.
<Melkhior>
darn, the micro-sd card now won't work even in SMP VexRiscv BIOS, the one place it was reliable :-(
<Melkhior>
updated everything, not sure what it could be ... previous update was done not that long ago but can't remember the exact date (definitely after Feb 4 from repos that were changed then and not since.
<Melkhior>
tried rolling back litex but didn't seem to fix (not sure I did the rollback properly...)
<Melkhior>
any idea which repo I should look at ?
<nickoe>
Melkhior: mm, how do you "update"?
<Melkhior>
python3 litex_setup.py --user update
<Melkhior>
in the top level, so that updates everything
<Melkhior>
I've rolled back litedram, and I now have a as-yet-unseen failure mode: the BIOS fails to load boot.json (standard), but instead of failing straight away at loading boot.bin it loads some of it ... and then stops. never seen that before...
<nickoe>
Ok, I don't konw. I am new to the litex ecosystem or whatever you call it, but sdcard via SPI works for me on my custom board. But I installed a week or two ago.
<Melkhior>
My hardware & sd-card have a long history of being a major nuisance:-) it works to load files (worked, past tense now) in Linux-onLitex-VexRicsv BIOS (UP or SMP), it can read data in LInux SMP, read corrupted dat ain Linux UP, and won't load anything in Linux-on-Litex-Rocket at the BIOS ... all of that in SD mode ; SPI mode has never worked with
<Melkhior>
LiteX or with my own project unrelated to LiteX with a couple of SPI sd-card controller from GitHub...
<Melkhior>
it's weird
<Melkhior>
but oh well :-)
<Melkhior>
Loading data from the BIOS was my primary use case in Litex so as it worked I thought I could ignore the problem... and not it doesn't work anymore:-)
<Melkhior>
well, I know what to took at this week-end now!
<mikeK_de1soc>
Hi Melkhior: Just wanted to let you know my RiscV is working on my De1-Soc!! Gave you Kudo's in my tweet!!!
<mikeK_de1soc>
Thanks for All your help yesterday!!
<Melkhior>
mikeK_de1soc cool & glad I could be helpful!
<mikeK_de1soc>
yeah absolutly,, Just letting you know I upped my serial to 203400 kbs, twice as fast as 115.2 and it worked! great tip on recompiling the fpga core.. that was great!
<mikeK_de1soc>
yeah, i found doing a litex-setup --user setup did not work too well for me either. Could you use a different branch of Github? and do things this way? just an idea.
<Melkhior>
just trying to rollback repo that could be relevant one by one... worse case scenario I can do like last time i had update issue: create a new user in the VM and starts from scratch to make sure I have a clean slate :-)
<mikeK_de1soc>
Wah.... and this is All from litex XXX repo's? there must be a better way...
<Melkhior>
well I rolled back litesdcard and that solved the problem (also rolled back litex & litedram) ; so I guess this week-end i'll have to do some bisecting to figure out the actual issue ...