_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
lf_ has quit [Ping timeout: 260 seconds]
lf has joined #litex
<tmbinc> Does litex_server / etherbone support scripted read/write mem32 (like m1n1) or do I need to use mem_write?
<tmbinc> I want to do a little scripting from the PC side (talking to SPI peripheral on the device, without having to actually run custom code on the device)
<tmbinc> _florent_: I tested SPI support (just for frontend), worked out of the box. This allows to configure the PLL, Frontend, VGAs, and eventually the ADCs. (https://github.com/360nosc0pe/litex-boards/tree/tmbinc/work)
<tmbinc> _florent_: next step is to add the ADC driver from https://github.com/360nosc0pe/fpga/blob/master/py/lxwrap/lvdsrecv.py and then we need a data path
lkcl has quit [Ping timeout: 265 seconds]
lkcl has joined #litex
Bertl is now known as Bertl_zZ
Degi has quit [Ping timeout: 256 seconds]
Degi_ has joined #litex
Degi_ is now known as Degi
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
<_florent_> tmbinc: nice! Being able to write Python scripts for such cases is indeed the principal usage of litex_server / etherbone, there is a short example in the Wiki:
<_florent_> with wb.write/wb.read
<_florent_> but objects for the registers are also created to avoid manipulating addresses directly
<_florent_> ex: wb.regs.ctrl_reset.write(1)
<_florent_> you can also have a look at litex_cli that provides some simples utilities over litex_server:
<_florent_> Otherwise for the repo under 360nosc0pe, we should probably avoid forking the full LiteX-Boards, this could only be: our target + scripts + software
<_florent_> I'm thinking of something like this for example: https://github.com/enjoy-digital/litesata_axiom
rj has quit [Remote host closed the connection]
rj has joined #litex
futarisIRCcloud has quit [Ping timeout: 240 seconds]
futarisIRCcloud has joined #litex
kgugala_ has joined #litex
kgugala__ has joined #litex
kgugala has quit [Ping timeout: 272 seconds]
kgugala_ has quit [Ping timeout: 256 seconds]
<tmbinc> _florent_: oh, this is much nicer than I expected, thanks!
lkcl has quit [Ping timeout: 272 seconds]
lkcl has joined #litex
TMM has quit [Remote host closed the connection]
TMM has joined #litex
<_florent_> tmbinc: I'm generally using this to play easily with peripherals I'm designing before writing proper software. This is also a way to reduce P&R time since allows creating designs with just a bridge + peripheral (so in our case we could remove the CPU/DRAM to speed up iterations is useful while working on the other peripherals).
hansfbaier has joined #litex
rj has quit [Remote host closed the connection]
rj has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
Bertl_zZ is now known as Bertl
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #litex
<mikeK_de1soc> _florent_: For what it's worth, I got the Litex VGA sync signal to work on my DE1-SoC. this is the Verilog Code Keeping a Monitor sync signal..
<mikeK_de1soc> Is this worth a PR?  again still learning at my end.
<_florent_> mikeK_de1soc: thanks, is it using the Terminal from LiteVideo of the VGA framebuffer?
<mikeK_de1soc> no.. this is next...
<mikeK_de1soc> this is where i need help..
<mikeK_de1soc> so in the code I see it for the xilix Only under framebuffer...
<mikeK_de1soc> sorry Xilinx..
<mikeK_de1soc> the changes I mode are in Litex-Boards for now... wokring on Linux for Riscv directory.. now...   Do you have an overview of the Framebuffer documented somewhere?
<mikeK_de1soc> this is where it dies in Linux-on-litex-vexriscv:    assert platform.device[:4] == "xc7a"
<mikeK_de1soc> in the soc_linux.py file.
<_florent_> Sorry there are not that much documentation and I should probably update Linux-on-LiteX-VexRiscv to also support a VGA framebuffer on various boards
<_florent_> I could try to do this in the next days
<mikeK_de1soc> ok Great!  :)    can you direct me which file to look at in the mean time? I am lookin gin the soc_linux.py file now.  Does the existing  Xilinx-only code fully work? I will use that as a template.
mikeK_de1soc has quit [Ping timeout: 240 seconds]
mikeK_de1soc has joined #litex
<_florent_> mikeK_de1soc: the assert is mostly for HDMI that is not yet supported on Intel, but VGA will works. But you'll also have to remove most of the timing constraints. I should really have a look at that and eventually do a very simple VGA framebuffer core.
<mikeK_de1soc> ok..  So the timing is currently working... but built from litex-boards only..
<mikeK_de1soc> As far as I can tell..
<_florent_> acathla: https://github.com/enjoy-digital/litex/commit/908e72e65ba42114ac398a0a0710a08d9c6d03d0 should reduce RS232PHY resource usage (~100LCs) and make the RS232 code easier to follow.
<mikeK_de1soc> it's currently 640 x 480..   BTW where can you set which resolution to pick?
<_florent_> mikeK_de1soc: Is it generating a valid signal?
<mikeK_de1soc> yes,, well my VGA monitor is locking on it!! :)
<mikeK_de1soc> just a raster.. no info...
<mikeK_de1soc> it was created from Litex-Boards, and created the Verilog file. I just complied it with quartus and loaded it manually..
mikeK_de1soc has quit [Ping timeout: 240 seconds]
mikeK_de1soc has joined #litex
<mikeK_de1soc> arrrg keeps disconnecting
<mikeK_de1soc> _florent_: Is it reasonable to use nexys_video, as a template? I see here that I am able to compile the Verilog code, The gateware. But I do get this error on the command line..
<mikeK_de1soc> make: Leaving directory '/home/mikek/Documents/Cyclone5_SOC/Litex_directory/linux-on-litex-vexriscv/build/nexys_video/software/bios'
<mikeK_de1soc> build/nexys_video/nexys_video.dts:101.48-108.15: Warning (simple_bus_reg): /soc/framebuffer@f0000000: simple-bus unit address format error, expected "c8000000"
<mikeK_de1soc> build/nexys_video/nexys_video.dts:59.48-63.15: Warning (unique_unit_address): /soc/soc_controller@f0000000: duplicate unit-address (also used in node /soc/framebuffer@f0000000)
<mikeK_de1soc> mikek@mike-AERO-17:~/Documents/Cyclone5_SOC/Litex_directory/linux-on-litex-vexriscv$
<mikeK_de1soc> running this command:  ./make.py --board=nexys_video
tucanae47 has quit [Quit: Connection closed for inactivity]
<mikeK_de1soc> Whooooaaa... The more I dig the more I find!!   There is a LOT of work done here!!!    INSANE!!
<mikeK_de1soc> Found this:  https://github.com/FrankBuss/NetHack/blob/NetHack-3.6/fpga/litex/targets/max1000.py    Not sure if this will work with current version of Linux-on-litex-riscv
<_florent_> mikeK_de1soc: sorry busy with other things, the nexys_video should be a good template yes, but it's using HDMI not VGA. I'll try to look at VGA soon
<mikeK_de1soc> no worries...   i am learning!!  :)
<acathla> _florent_ did you just rewrote everything about RS232?
<_florent_> acathla: the principle is very similar but I did some cleanup yes :)
<acathla> _florent_, it's not 100LC less than the optimisation from yesterday, is it? It seems to be the same LC usage.
<_florent_> I was testing it on a ECP5, possible results will be a bit different on iCE40, but the initial aim was to simplify/cleanup the code.
<acathla> That's a good aim
<tmbinc> _florent_: wrt. sds1104xe, I've talked with G33katWork and he said other than the backlight PWM, which is a MIO (and hence not accessible from PL, right?) PWM, the only somewhat special thing was the timing, which he put into the device tree.
<tmbinc> (for LCD)
mikeK_de1soc has quit [Quit: Connection closed]
<tmbinc> _florent_: also how convinced are you that R6 is eth phy rst? It's on bank 13, shared with the LVDS_25 ADC connections, so it's definitely not LVCMOS33.
<tmbinc> _florent_: speaking of eth phy, I only get a link when I re-plug ethernet after config. Is this a common problem?
FFY00 has quit [Ping timeout: 260 seconds]
mikeK_de1soc has joined #litex
FFY00 has joined #litex
<_florent_> tmbinc: thanks for the info about the LCD, that's useful to know, I'll have a look at the timings. Possible that the PWM pin will not be controllable directly from the PL, if not possible and really required this could still be done over AXI.
<_florent_> tmbinc: for eth_phy_rst_n/R6, I think I just reused the pinout from 360nosc0pe, not sure I have to replug here, but I could do more testing.
<_florent_> tmbinc: the reset is optional on the LiteEth PHY, so in case you have doubt, it's possible to comment it in the platform file
<nickoe> Hello. I tried to add the liteeth to my board, but vivado is not happy. See the error message in the commit message. Why is this? I think I meant this to be clock out of the fpga as input to the PHY chip, but I may have misunderstood the clocking here.
<nickoe> PHY is KSZ9031RNX
<somlo> _florent_, shorne: ... and while the timeout error flag in the linux driver just *happens* to match, it's not for the lack of trying :)
<somlo> I will rework the values checked for (inherited from the original driver): https://github.com/litex-hub/linux/blob/wip/litex-vexriscv--linux5.0_sd_card_dma/drivers/mmc/host/litex_mmc.c#L182
<somlo> to reflect the current status codes being returned via the cmd/data event register: 1=done, 2=error, 4=timeout (there is no extra bit that would match "0x8"): https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/core.py#L72
<somlo> _florent_: oh, or maybe the 0x8 (CRC error) is a "todo item"? Either way, the linux driver is leaky in terms of dealing with any possible combo of error flags...
<_florent_> somlo: yes that's probably the result of the CRC check (that is not yet implemented)
<nickoe> _florent_: Are here any examples on using AXIStreamInterface ?
<nickoe> I woner how I can conenct it to my RAM
<somlo> _florent_: I freaked out for a second -- what if I was complaining about the wrong cause for erros in Linux? :) But "luckily" the timeout flag still matches, so it's all good; I'll clean up the linux error-flag matching regardless, to have it make sense when examined side-by-side with the gateware sources...
<_florent_> nickoe: that's probably AXI MMAP that you want to use to connect to a RAM, with the AXI frontend, you can convert a native port to AXI and use the AXI port in your design: https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/axi.py
<_florent_> somlo: :)
<_florent_> nickoe: not sure there are that much examples in the repositories, but the BIST can operate on Native and AXI port, so you can look at it to see how to use a AXI port: https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/bist.py
<nickoe> _florent_: You mentioned yesterday "so it's also possible to create direct ports to the DRAM too, with get_port of the crossbar: https://github.com/enjoy-digital/litedram/blob/master/litedram/core/crossbar.py#L79 "
<nickoe> Is that port already defined for my soc object?
<_florent_> nickoe: for Ethernet, it seems you have and RGMII PHY, not MII, so you have to use: https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/s7rgmii.py
<nickoe> Ok, I will try the s7rgmii later. Right now I would like learn this AXI stuff. :)
<_florent_> nickoe: get_port will create a new Native port, that you can then convert to AXI with the AXI frontend
<nickoe> is that on the SoC object?
<_florent_> in fact, you can have a look at litedram_gen for an example: https://github.com/enjoy-digital/litedram/blob/master/litedram/gen.py#L598-L605
<nickoe> or does that LiteDRAMCrossbar exist in my soc desgin alread somewherE?
<nickoe> _florent_: my current target looks like this, https://github.com/nickoe/litex-boards/blob/mars_ax3/litex_boards/targets/mars_ax3.py can I add it in the end of my BaseSoC class?
<_florent_> yes sure
<_florent_> if you add:
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<_florent_> you can then use axi_port as and AXI MMAP port
<nickoe> mm, ok, that gets rid of the width things
<nickoe> I was having a bit of trouble with, but do I know the port width now?
<nickoe> So this create the AXI port interface, and I can then connect that streaming thing on that?
<_florent_> that's the native width of the controller. You can verify it with: print(user_port.data_width), for a 16-bit DDR
<_florent_> 16-bit DDR3 on Artix7 it will be 128-bit
<_florent_> 256-bit for a 32-bit DDR3
<nickoe> it writes 128
<nickoe> should I set that to axistream = AXIStreamInterface()?
<nickoe> _florent_: Or, ohh, I need to the axi_port from LiteDRAMAXIPort ?
<_florent_> no, AXI-ST and AXI-MMAP are different things, AXIStreamInterface is for AXI-ST (Streams, very similar to LiteX's streams)
<_florent_> with the code I provided, you can use axi_port in your logic
<nickoe> _florent_: Ok, let me step a bit back. What should I do if I want to dump a memory region to my DAC on a trigger/enable signal?
peepsalot has quit [Ping timeout: 240 seconds]
kgugala has joined #litex
kgugala__ has quit [Ping timeout: 265 seconds]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 272 seconds]
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
peepsalot has joined #litex
<_florent_> nickoe: you can use DMA
<nickoe> Hmm, ok. I will have a look, I a currently trying your suggestion about the liteeth for s7
<nickoe> _florent_: By the way, do you know if this is critical?
<nickoe> CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -include_generated_clocks -of [get_nets sys_clk]]'. [/home/nickoe/litex_test/dangerous_litex/litex-boards/litex_boards/targets/build/mars_ax3/gateware/mars_ax3.xdc:527]
<nickoe> I mean, it says soo. but...
<nickoe> Is it because my clock should be named differently? pll.create_clkout(self.cd_sys, sys_clk_freq)
<nickoe> At least the s7rgmii do synth
<nickoe> _florent_: Any tips on testing the ethernet? I do see the mdio_* commands, but not sure what to expect. I connected it to usb dongle eithernet, but no blinking. Keep in min the board has custom routing to the ethernet jack, so it has not been tested otherwise.
<nickoe> ah, that was the one I was looking for, but I only found https://github.com/enjoy-digital/litex/wiki/Create-And-Load-Software-To-The-CPU
<nickoe> but it apperas that NetworkManager want the ethernet dongle do see a network before I can select it
<nickoe> so I can't configure a static ip
<nickoe> Or, I mean I can configure it, but I can't select it in nm-applet.
<nickoe> _florent_: But back to memory acces, I guess I can do https://dpaste.com/2E8EWB2Y2 and then I need to write a FSM to excercise the dma.sink?
<tpb> Title: dpaste: 2E8EWB2Y2 (at dpaste.com)
<_florent_> nickoe: yes you can do this
<nickoe> then I can wire those to some readonly registers that are mapped to some output pads to my DAC? Having the registers only with the intent to be able to read them from software for debugging purposes.
<nickoe> I guess I can control the FSM with some other registers such that I can coltrol the reading "modes" from firmware or test script.
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined #litex
mikeK_de1soc has quit [Quit: Connection closed]