<keesj>
gregdavill: on your example foo.eq(foo +1) I think it should normaly work (at least it doen in VHDL) but the thing to remember is that in such case there are twoo foo's , the input foo and the output foo and that the output foo will not be updated until en the of the statment e.g. doing 10 times foo.eq(foo +1) would in the end result in foo.eq(foo +1)
<tpb>
Title: GitHub - keesj/orange_crab_drc: Script to perform some drc tests on the orange crab fpga board (at github.com)
<gregdavill>
in migen if I type self.comb += foo.eq(foo + 1). It locks-up the simulator, rightly so. The isn't a way you can create a loop like that in combinational logic.
<keesj>
thanks . I will have a look at your script
<gregdavill>
The one I'm using pulls net groups out of the KiCad project itself, so it's very easy to configure. But it runs in a separate terminal window, and it's not an Action Plugin.
<keesj>
the default lenght matching was taking the full trace lenght including the terminaor resistors
<gregdavill>
Yep, there are changes I made so it's now only checking distance of traces between two ICs.
<keesj>
anyway.. I will have a good look at your script
<gregdavill>
The pad2pad_track_distance code is pretty cool, looks a bit better than mine performance wise.
<gregdavill>
I ended up coding a messy tree structure based on track segments corresponding to a net, I then do a recursive search on this tree until I find a segment that connects to the target chip.
<keesj>
Still.. quite slow. but .. in my search for a ddr3 layout.. I only found olimex and you doing stuff
<tpb>
Title: GitHub - enjoy-digital/litepcie_aller_test: Test with LitePCIe and Numato Aller board. (at github.com)
<dkozel>
Thanks will switch to that
<_florent_>
With the current LiteX design, the device should be 10eee:7021, so i think the Numato bitstream is still loaded
<dkozel>
Ok, Vivado does think it programmed the FPGA
<dkozel>
Hmm, can we get a mask file from LiteX/Migen to use Vivado to verify the loaded bitstream?
<dkozel>
yes, found the migen opts
<dkozel>
My build environment for the kernel module is clearly different from yours, paths don't match
<_florent_>
since you are probably just loading the bistream, you can only do a reset of the host computer, not a power on/power off otherwise the FPGA will reload the bitstream from SPI Flash
<_florent_>
dkozel: which paths for example?
<dkozel>
ah, and the host isn't reenumerating the PCIe device with the new bitstream
<dkozel>
home/dkozel/src/litepcie_aller_test/software/kernel/csr.h:12:10: fatal error: hw/common.h: No such file or directory
<dkozel>
12 | #include <hw/common.h>
<dkozel>
and the soc, mem, csr.h files needing to be in kernel/generated/ or the kernel/ directories
<_florent_>
and then do litepcie_test record dump.bin 0x1000 for example
<dkozel>
Ok, that's useful
<dkozel>
is there a CPU on the current bitstream? I think the default SoC does include one? I didn't pay attention to the build log
_whitelogger has joined #litex
<dkozel>
Splended, works
<dkozel>
I really like this ecosystem. Lots to learn!
<dkozel>
Memspeed Writes: 253Mbps Reads: 320Mbps
rohitksingh has quit [Ping timeout: 240 seconds]
<_florent_>
cool, that's the speed tested from the CPU, the actual speed with DMAs is a lot higher (probably around 10Gbps on Aller with a 100MHz sys_clk)
<dkozel>
the netv has Gen2 x4 for it's PCI interface right?