00:28 <mithro> https://twitter.com/zbandic/status/1261009505191514113?s=20

00:28 <mithro> hzeller: Two new cores to be added to sv-tests I think?

05:18 <sf-slack2> <timo.callahan> @acomodi @kgugala thanks for the ddr README improvements. The test worked on the Arty 35T board with both Vivado and SymbiFlow bitstreams. The output matched the 50MHz version.

07:20 <sf-slack2> <mkurc> @timo.callahan I think that what you've seen with the placement constraints is a bug in prjxray_create_place_constraints.py. I have a fix for that but haven't pushed it yet, I'll make a separate PR with it.

07:32 <sf-slack2> <timo.callahan> Thanks Maciej! I will try it (my) tomorrow.

07:34 <sf-slack2> <mkurc> Sure, there is the PR: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1488

07:34 <tpb> Title: Bugfixes for prjxray_create_place_constraints.py by mkurc-ant · Pull Request #1488 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

12:08 <_whitenotifier-c> [symbiflow-arch-defs] rw1nkler opened issue #1489: VPR route design through unknown GTP PIPs - https://git.io/JfRCI

13:05 <_whitenotifier-c> [prjxray] mkurc-ant opened issue #1329: Make fasm2frames enable STEPDOWN for unbonded IOBs - https://git.io/JfRlZ

15:18 <_whitenotifier-c> [symbiflow-arch-defs] litghost opened issue #1490: A200T vendor test CI is failing with out of disk space errors - https://git.io/JfR01

16:09 <sf-slack2> <timo.callahan> @mkurc yes the issue seems fixed now; at least the design finishes place and route. I'll update after I've tested it on the board. Thanks!

16:20 <sf-slack2> <timo.callahan> Update: it works on the 100t *IF I add a location constraint to the PLLE2_ADV* (it didn't work before even with the LOC constraint, so your script updates improved things). But it still fails if I don't add the location constraint --- it still assigns the PLLE2_ADV to '5', and then has the error that there are no available placements for PLLE2_ADV in '5'. But let me double check my runs.

18:11 <sf-slack2> <timo.callahan> The DDR test synthesized for the 100T board works in the sense that it communicates with lxserver, but the DDR alignment fails. The table is all "..". Maybe I need to regenerate the ddr_uart.v Verilog from nMigen/LiteX for the 100T?

18:16 <sf-slack2> <acomodi> One thing worth doing is to have a higher frequency (e.g. 60 MHz). the DDR is pretty unstable at 50MHz and that may be the reason for it not to work correctly

18:17 <sf-slack2> <timo.callahan> Where would I make that change?

18:19 <sf-slack2> <timo.callahan> More info -- the script failed an assertion because it was all "..". I tried commenting out the assertion, and doing some writes and reads. The data was corrupted so that when I wrote 0x01234567 multiple times, I read back 0x45671234 (not sure if it was getting shifted earlier or later, I need to do more tests....)

18:19 <sf-slack2> <timo.callahan> Sorry meant that I read back 0x45670123 -- so shifted by 16 bits

18:23 <sf-slack2> <acomodi> So probably 50 MHz may be at the limit, causing this behavior

18:23 <sf-slack2> <acomodi> This would require a re-generation of the design actually

18:33 <sf-slack2> <acomodi> It's worth trying the mini_ddr test though (under soc/litex) as it is designed to run at 60 MHz and has a litex soc that already performs DDR calibration

18:43 <Degi> I get a "no enum named 'PIOB.DIFFRESISTOR'" from ecppack when using a differential pair from balls "J19" (PR44A) and "K19" (PR44B) of the ECP5UM-5G 381 (the gateware is in nmigen)

18:44 <Degi> I think it should be setting the diff resistor of the PIOA tbh

18:55 <daveshah> Degi: yes, DIFFRESISTOR should definitely be on the PIOA only

18:55 <daveshah> is the constraint definitely on the positive side?

18:56 <Degi> Ohh, I think its because I didnt set the IO type to a differential one

18:58 <Degi> Of course, with LVCMOS33D it works

19:00 <Degi> Oh wow despite getting the same partially negative going trace, now it works. Thanks!

19:01 <daveshah> How negative does it go?

19:02 <daveshah> Below -0.5V ish for a significant percentage of the waveform does create a risk of long term damage iirc

19:03 <Degi> It goes -240 to +680 mV and is capacitively coupled

19:03 <Degi> (That's min/max)

19:03 <Degi> Could below -0.5 V cause latchup?

19:05 <daveshah> Lattice don't rate it below -0.5V

19:05 <sf-slack2> <timo.callahan> Thanks @acomodi, I'll try that.

19:05 <daveshah> a short transient is OK but I would avoid going much further below -0.5V if it is for a whole half cycle or something

19:10 <Degi> Now with more drive amplitude it is -200 to 3280 mV, weird

19:13 <Degi> (Oh lol, this PLL chip understands CMOS as common mode output on a differential pair? Weird.)

19:30 <Degi> Huh, the ECP5 has builtin 50 ohm output resistors?

19:32 <daveshah> I don't think so

19:32 <daveshah> It has a configurable single ended termination but I think that is for inputs only not outputs

19:37 <miek> this reminds me, i'm a little confused by what i've been seeing from the LVCMOS33D outputs. i expected to see a common voltage of 1.65V (ie: 3.3/2), but i actually see ~1.2V. it's exactly what i want for meeting normal LVDS specs, but i'd like to understand why it ends up like that - i wonder whether anyone knows more?

19:41 <daveshah> LVCMOS33D is nothing more than two LVCMOS33 outputs with an inverter on the B side

19:42 <daveshah> Do you have a termination resistor on it? That might drag the voltage down

19:42 <miek> i've got 100ohm between A and B

19:47 <daveshah> Thats a 33mA load, that's quite a bit

19:47 <daveshah> Max drive setting for ECP5 is 16mA, default is 8mA

19:47 <miek> i've got it set to 4

19:48 <daveshah> Yeah, no wonder you aren't seeing 1.65V Vcm

20:05 <sf-slack2> <timo.callahan> @acomodi mini_ddr seems to work on the 100T board! I'll cut and paste some output:

20:06 <sf-slack2> <timo.callahan> ```--========== Initialization ============-- Initializing SDRAM... SDRAM now under software control Read leveling: m0, b0: |00000000000000000000011111111111| delays: 26+-05 m0, b1: |00000000000000000000000000000000| delays: -```

20:06 <sf-slack2> <timo.callahan> ```best: m0, b0 delays: 26+-05 m1, b0: |00000000000000000000011111111111| delays: 26+-05 .... best: m1, b0 delays: 26+-05 SDRAM now under hardware control Memtest OK Memspeed Writes: 131Mbps Reads: 212Mbps```

21:09 <sf-slack2> <acomodi> @timo.callahan great! So this should also confirm that the the ddr_uart test should be upgraded to work at at least 60 MHz

21:34 <sf-slack2> <kgugala> @timo.callahan Awesome!!