<scanakci>
_florent_: In a clean vm, I gave a shot to Vexriscv for genesys board using standard flavor. I used the most recent commit.
<scanakci>
Unless something is wrong with my FPGA, I am observing failures
<scanakci>
I will try other frequencies than 125MhZ and see if the behaviour matches with BP
captain_morgan has quit [Read error: Connection reset by peer]
captain_morgan has joined #litex
<scanakci>
I tried 100MhZ for Vex. It prints meaningless characters. I tried a variety of baudrates but no luck. Overall, the behaviour of Vex and BP matches.
CarlFK has quit [Quit: Leaving.]
awordnot has quit [Ping timeout: 265 seconds]
awordnot has joined #litex
randomloopsa has joined #litex
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #litex
randomloopsa has quit [Remote host closed the connection]
HoloIRCUser has joined #litex
HoloIRCUser2 has joined #litex
HoloIRCUser1 has quit [Ping timeout: 260 seconds]
HoloIRCUser has quit [Ping timeout: 246 seconds]
<_florent_>
scanakci: ok thanks, i'll do a test on a Genesys2 board
<scanakci>
_florent_: thanks. I tried Rocket using 125MhZ. Memory tests failed for it as well.
HoloIRCUser has joined #litex
HoloIRCUser2 has quit [Read error: Connection reset by peer]
mattytrentini has joined #litex
<mattytrentini>
OK, I'm finally returning to an old goal - trying to improve MicroPython support on Fomu and, hopefully, for GregD's OrangeCrab. But I've only got a tentative understanding of how the systems hang together. (Maybe I'm in the wrong place; please tell me if there's somewhere else I should be asking these questions!)
<mattytrentini>
Let's say I want to add a standard digital GPIO that I want to be able to access in MicroPython on Fomu. I get that Migen/Litex is responsible for building the gateware including - I think - the VexRiscv softcore for Fomu. How would I go about modifying the softcore to map a pin to the outside world? And then I think I need to provide a way (as a
<mattytrentini>
register on the wishbone bus?) to provide MicroPython with a hook to setting that pin. Finally I need to update MicroPython (currently xobs/MicroPython) to use that hook. Am I even in the ballpark of understanding things correctly?
<sajattack[m]>
sounds about right to me. I'm not sure how to add a gpio in a way linux can see but I'd be curious to know too
<sajattack[m]>
the wishbone part should be taken care of
<sajattack[m]>
my guess would be whatever gpio interface in linux raspberry pi uses would be similar to what's used in litex
<sajattack[m]>
since it's on the device tree
CarlFK has joined #litex
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #litex
<mattytrentini>
OK, perhaps I can add both an LED and a Switch to have in/out pins...
CarlFK has quit [Ping timeout: 246 seconds]
captain_morgan has quit [Quit: Ping timeout (120 seconds)]
captain_morgan has joined #litex
mattytrentini has quit [Remote host closed the connection]
mattytrentini has joined #litex
mattytrentini has quit [Remote host closed the connection]
mattytrentini has joined #litex
nrossi has joined #litex
<mithro>
mattytrentini: There was a library which could auto-generate MicroPython functions for the registers provided by the FPGA SoC
<disasm[m]>
Hi everyone! I'm looking at the latest litex and now it uses python modules for CPU core sources. Is there a way to declare all the needed python-module dependencies so that my soc generator "just works" as earlier?
<disasm[m]>
(I have been using lxbuildenv.py for maintaining git-deps)
<disasm[m]>
I kinda love that good old submodule-dependency approach as you can just `git clone --recursive` a project and build it, without any specific pre-installation instructions and custom python environment
<mithro>
disasm[m]: You can actually go even better with git-subtrees
Dolu has joined #litex
<Dolu>
Sorry, I miss reported the usage of the SMP quad cores VexRiscv, 13K was when i was testing the cluster itself. With all the required peripherals (DDR, UART, ...) from litex, it is actualy 14762 LUT.
<mithro>
Dolu: So, 8 core? :-P
<mithro>
Dolu: ~13k LUT for the CPU core complex and roughly ~2k LUT for all the support peripherals like DDR / UART / etc? ?
ambro718 has joined #litex
<Dolu>
mithro: 8 cores, maybe, but not on 35T. Let's do 5 cores on 35T ^^
<Dolu>
Yes, the cluster itself, is reported as 13433 LUT, while the top (litex) is reported as 1332 LUT
<Dolu>
But will have to see how much the DDR suffer from having so many cores to handle.
<mithro>
Dolu: good thing that we are working on improving litedram's performance!
<Dolu>
yes ^^
Skip has joined #litex
Dolu has quit [Quit: Leaving]
HoloIRCUser has quit [Quit: HoloIRCUser]
HoloIRCUser has joined #litex
<mithro>
john_k[m] / Skip: At 15k LUTs for 4 cores, the Pano Logic G2 could have up to like 20 cores! :-P
<_florent_>
mithro: also for the Pano Logic G2, now that LiteX is supporting SERV, we could use it to have two LiteDRAM standalone core each initialized with a SERV CPU and the VexRiscv SMP in the main SoC would just see the DRAM as a traditional memory already initialized.
<tpb>
Title: Error building for Panologic platform ( Spartan 6 xc6slx150) · Issue #38 · enjoy-digital/liteeth · GitHub (at github.com)
<Skip>
mithro: Wow. I wonder how long it will take to route ... one way to find out !
<_florent_>
Skip: yes, sure can look at it
<scanakci>
@_florent_, @mithro: Did you test pythondata-cpu-blackparrot to check if modules are properly imported during simulation&synthesis? I am trying to adapt BP to this new form and clean BP repo.
<_florent_>
scanakci: i'm not sure we tested it. On my side i was not able to clone the previous submodule correctly: https://github.com/enjoy-digital/litex/issues/391, so haven't been able to test the previous version of BP
<Skip>
_florent_: The odd thing about the Pano is that the 125 Mhz clock from the Phy is the ONLY external clock coming into the FPGA and the frequency changes to 25 Mhz when the Phy is reset which is why I made the Phy reset optional.
<Skip>
I wasn't sure what bad things would happen else where if the system clock suddenly changes when the Phy is reset.
<_florent_>
Skip: ok, it's possible the issue is specific to the MII/GMII dynamic mode (we have two clock input going to the BUGMUX since the clock is different in MII and GMII), using a MII or GMII only PHY would probably fix the issue.
<mithro>
scanakci: How are you installing litex? If you are using litex_setup you need to rerun it
<mithro>
scanakci: If you are using a virtualenv or other system, you can use the command it tells you
<scanakci>
BP is not part of litex_setup as far as I see
<tpb>
Title: GitHub - litex-hub/litespi: Small footprint and configurable SPI core (at github.com)
<Skip>
mithro: Thanks, that helps a lot.
<mithro>
Skip: litex-buildenv has been around a *long* time and it a bit behind the latest "best practices" around LiteX development
<Skip>
That's a good thing. "tried and true" !
<_florent_>
mithro: for the copyrights we could discuss it, but i think the current copyrights in LiteX better reflects the contributions than a generic "LiteX Authors".
<mithro>
Skip: We are slowly trying to get rid of and reduce the mishmash of make/shell/python
<Dolu>
scanakci: I think i had the same, i had to install "sudo apt install libevent-dev libjson-c-dev"
<scanakci>
oh my bad. thanks @Dolu, I totally forget dependencies in the fresh vm.
<Dolu>
florent spoted it ^^
<scanakci>
vexriscv works fine (verilator).
rw1nkler has quit [Quit: WeeChat 1.9.1]
<zyp>
I'd like to instance a dual ported block ram with differently sized ports, are there any convenient ways to do that, or should I just instance the block ram primitive?
<zyp>
as far as I can see, the Memory class in migen assumes a common width for all ports
<daveshah>
This is a Yosys limitation atm, afaik
<daveshah>
If you are using vendor synthesis tools, I guess the right logic around memory ports might create the Verilog needed to infer an asymmetric RAM, but it's unlikely
<zyp>
if that's the case, I'll just go with the primitive
<zyp>
at the moment I just need it to work on ecp5, can deal with portability later
<mithro>
zyp: are you using litex / migen?
<zyp>
I assumed that was a given since this is #litex :)
<mithro>
zyp: You never know :-) -- It should be pretty easy to create an abstract "DualPortRAM" class which gets instantiated into block rams correctly
<mithro>
zyp: In fact someone might have already done exactly that?
<mithro>
IIRC nmigen has that?
<mithro>
I was wondering if the ASyncFifo has that already
<mithro>
zyp: That should show you how to provide an override for a specific platform
<zyp>
fair enough
<mithro>
zyp: Assuming you want to go the "generic dual port block ram" approach
<zyp>
but I really don't want to spend a ton of time on this right now, I just want a memory so that I can work on the interesting stuff that hooks up to the memory
<daveshah>
Also note if you want wider than 18 bits you need to use PDPW16KD which is only pseudo dual port
<zyp>
oh, right, I read too fast on the cascading ports, thanks for spotting that
<daveshah>
I'm not sure if it is required, but tying the CE and OCE ports to 1 and RST to 0 is a good idea too
correlation_zone has quit [Ping timeout: 245 seconds]
CarlFK has quit [Remote host closed the connection]
CarlFK has joined #litex
<zyp>
daveshah, so if I'm understanding this correctly, the active address lines are always the upper ones, and then the lower two or four bits are the byte lane enables for 18b and 36b wide ports, right?
<zyp>
in the file you linked, why does only line 54 have the EN signal, not line 55? (and correspondingly for line 61/62)
Skip has quit [Remote host closed the connection]
_whitelogger has joined #litex
FFY00 has joined #litex
zyp has joined #litex
m4ssi has quit [Remote host closed the connection]
tcal has quit [Remote host closed the connection]
Dolu has quit [Read error: Connection reset by peer]