dh73 has quit [Quit: Leaving.]
<anticw> gregdavill: qfn72 variant has one mipi port with 1 or 2 lanes?
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
<m_w> gregdavill, what was the magic to get the DDR litex test with trellis?
<gregdavill> I'm still digesting the docs. From what I can tell it has one D-PHY with 4 lanes broken out. So 1x CLK, 4x DATA.
<gregdavill> m_w: The magic for me was updating my prjtrellis libraries.
<m_w> hmmm
<gregdavill> And also when switching between the DDR test (wishbone bridge) and the DDR SoC I had to change 1 line in my ecp5ddrphy. I've commented the line on my repo.
<gregdavill> ecp5ddrphy.py line 443
<gregdavill> What issues are you having getting it working specifically? synthesis problems? or runtime problems once the bitstream is loaded?
<m_w> let me run the compile again with the updates trellis installed
<m_w> looks like routing failed this time
<anticw> gregdavill: thx, i never understood why fpga vendors don't just put a pinout table in the datasheet ... vs some .xls thang i don't want
<anticw> daveshah: how can you tell the sram is double pumped?
<gregdavill> anticw: I get that, but also I don't want to hand transcode pins from a datasheet (esp. for a 400 pin BGA...) into a schematic symbol, a csv/xls file I can machine process.
<gregdavill> m_w: You'll need to update: trellis, nextpnr_ecp5, yosys.
<m_w> okay on it
<TD-Linux> anticw, it explicitly says so in the memory reference doc
<m_w> what does it mean when it was it cant import database again?
<m_w> *it says
<m_w> nevermind the path
<m_w> okay I updated everything
<m_w> gregdavill, now it is saying "Trellis limitation: DRIVE can only be set on 3V3 IO pins."
<gregdavill> You can ignore that, I get that error too. Lattice recommends using spare I/O in DQS banks for virtual VCCIO/GND pins, in their diamond examples they set the drive value to 10 to accomplish this.
<gregdavill> But even diamond complains "No virtual VCCIO pins have been assigned for this DQS bank". Seems to work either way.
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 245 seconds]
<omnitechnomancer> daveshah I wonder how much of the database fuzzing support stuff could be made more generic to allow an easier time spinning up new documentation projects, much of the trellis stuff has seemed rather generic or nearly so to me
yuriks has quit []
zng has quit [Ping timeout: 246 seconds]
<whitequark> tpw_rules: will look soonish, thank you!
Bike has quit [Quit: Lost terminal]
<whitequark> cr1901_modern: I still don't have an implementation I'm quite happy with, but most likely it won't change
<whitequark> certainly it won't change radically
OmniMancer has joined ##openfpga
zng has joined ##openfpga
gregdavill has quit [Ping timeout: 250 seconds]
____ has joined ##openfpga
gregdavill has joined ##openfpga
genii has quit [Quit: Time for beer and hockey.]
cyrozap has quit [Quit: Client quit]
cyrozap has joined ##openfpga
<____> I don't see any package drawings for NX anywhere in the datasheet or supplement docs. Is the SG72 a normal QFN, or one of those crazy double-row or triple-row BGA wannabees?
gregdavill has quit [Ping timeout: 250 seconds]
<whitequark> lattice has a separate dcument for package diagrams
<____> They do, but it's not listed in NX section. Either someone is being lazy, or it is not relevant yet.
<____> QFN72 listed in there is a normal one. And the dimensions fits. So it's rather relevant than not.
lopsided98 has quit [Ping timeout: 265 seconds]
lopsided98 has joined ##openfpga
finsternis has quit [Excess Flood]
finsternis has joined ##openfpga
<OmniMancer> I think I need a helper function to make RoutingGraph arcs from the various strings
parataxis has quit [Ping timeout: 245 seconds]
cr1901_modern has quit [Quit: Leaving.]
m_w_ has joined ##openfpga
sgstair_ has joined ##openfpga
zignig has quit [Ping timeout: 265 seconds]
zignig has joined ##openfpga
m_w has quit [Ping timeout: 265 seconds]
cr1901_modern has joined ##openfpga
sgstair has quit [Ping timeout: 265 seconds]
____ has quit [Ping timeout: 260 seconds]
lain has quit [Ping timeout: 240 seconds]
lain has joined ##openfpga
____ has joined ##openfpga
m_w_ has quit [Ping timeout: 250 seconds]
m_w_ has joined ##openfpga
m_w_ has quit [Read error: Connection reset by peer]
m4ssi has joined ##openfpga
Hamilton has joined ##openfpga
____ has quit [Remote host closed the connection]
____ has joined ##openfpga
Thorn has quit [Ping timeout: 265 seconds]
<omnitechnomancer> daveshah: so for deduplicating it would be better to produce the deduplicated db by construction?
<daveshah> Yes, that would be my suggestion
<omnitechnomancer> For things like IO which tend to have some "inter tile" fixed connections would you encode those relatively?
<omnitechnomancer> I have gotten to the point where I have a Routing Graph with the FFs and LUTs for the mslices in it, with extra pips for the carry chains and FF inputs
<omnitechnomancer> now trying to hack up trellis_import.py to dump something from that
Asu has joined ##openfpga
____ has quit [Remote host closed the connection]
<daveshah> Yes, they would be relative
dh73 has joined ##openfpga
genii has joined ##openfpga
awordnot has joined ##openfpga
<omnitechnomancer> I still need to add code to add arcs for the inter tile wires to the routing graph
Hamilton has quit [Remote host closed the connection]
Hamilton has joined ##openfpga
<omnitechnomancer> I can see why flat databases are a bad idea for larger FPGAs
Thorn has joined ##openfpga
<omnitechnomancer> Using all the memory makes for a very slow linux
<omnitechnomancer> though I think that is just kate being bad at moderately large files
azonenberg_work has quit [Ping timeout: 250 seconds]
OmniMancer has quit [Quit: Leaving.]
<eddyb> heh kate used to be my benchmark to compare web-based editors to
m4ssi has quit [Quit: Leaving]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` is now known as X-Scale
mumptai_ has quit [Remote host closed the connection]
parataxis has joined ##openfpga
Kekskruemel has joined ##openfpga
sgstair_ is now known as sgstair
<anticw> eddyb: few editors deal with really large files well, it's not common or useful enough to put a lot of effort into
azonenberg_work has joined ##openfpga
<anticw> omnitechnomancer: re: flat databases ... is it linear search time that's the problem or just the amount of memory required?
<daveshah> Search time is nominal O(1) once built
<daveshah> The performance issue from flat database is cache trashing
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
dh73 has quit [Quit: Leaving.]
knielsen has quit [Remote host closed the connection]
dh73 has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
knielsen has joined ##openfpga
<q3k> real 1m22.651s
<q3k> can i blame xc3sprog for this slowness
<q3k> or is programming a XC7K420T always going to be slow?
Dolu has quit [Ping timeout: 268 seconds]
Hamilton2 has joined ##openfpga
<daveshah> My zcu104 programs with Vivado in about 15s iirc and that should be a similar number of cells
azonenberg_work has quit [Ping timeout: 250 seconds]
Hamilton2 has quit [Client Quit]
Hamilton2 has joined ##openfpga
<daveshah> and compression should be able to improve that further too
Hamilton has quit [Ping timeout: 276 seconds]
Hamilton2 has quit [Remote host closed the connection]
<mwk> q3k: many jtag probes use shit freq by default, check if you can bump it
<omnitechnomancer> anticw well my issue was that Kate likes to consume gigabytes of memory to look at a 200ish Megabyte text file and the VM gets very slow once it starts swapping
azonenberg_work has joined ##openfpga
<q3k> mwk: apparently xc3sprog has no way to bump the frequency
<q3k> anywy, this is using a platform cable on linux with vivado from nmigen - maybe there's a better way to do something here than use xc3sprog
<Kekskruemel> Hey, i'm designing a little module with an ECP5 and some hyperram. Is there anything to watch out for, concerning the pin assignment? E.g. using edge clock pins or certain pin groups?
<tux3> If anyone is looking for Active-HDL 10.5 with ice40 support, I finally got the damn thing working under Linux with a few patches. Turns out you can use a valid Diamond/Radiant license with iCE40 once you perform the cursed magic to refreshes the vlibs...
<tux3> Gotta love proprietary toolchains.
<omnitechnomancer> daveshah I was thinking about deduplicated db with pips for the inter tile connections, but having trouble picturing how the inter tile wires would be represented since the pips have to reference non local wires in that case and I expect all such wires need to be the same in each tile to make finding them by ID fast?
<daveshah> I would need to think about this more, but I envisage something along an extra data structure for each "tile neighbourhood" combination that effectively binds tiles together
<mwk> q3k: hrm, try -J maybe?
<mwk> TFM says it's ftdi-only, but hopefully it lies?
<mwk> the platform cable definitely has an option in the protocol to set the frequency
<mwk> *sigh* nevermind the option is ignored
<mwk> why do all programmers suck
<mwk> specifically, their host software
<OK_b00m3r> :)
<OK_b00m3r> waaaaait WE ARE programmers
<OK_b00m3r> this is like the "you're not stuck in traffic. You ARE traffic"
<mwk> sooner or later I'm going to get pissed off enough and write my own driver for the platform cable / ftdi / digilent crap programmers / ...
sgstair has quit [Ping timeout: 240 seconds]
<mwk> q3k: you compiled your xc3sprog from source, right?
<q3k> straight from portage
<mwk> ah fuck
<q3k> or no
<mwk> anyway
<q3k> from source
<q3k> somewhere
<q3k> i guess
<mwk> take ioxpc.cpp
<mwk> there are several calls to xpcu_request_28 where 0x11 or 0x12 is written
<q3k> yeah, svn r795
<mwk> try changing them to write 0x10 instead
<q3k> let's see
<mwk> if http://diamondman.github.io/Adapt/cable_xilinx_PCU.html is to be believed, that should bump the speed from 6MHz or maybe 3MHz to 12MHz
<q3k> oh yeah
<q3k> that brought it down to 28s
<mwk> great
<mwk> the chip should be able to do much faster jtag, btw
<mwk> at least 33MHz
<mwk> but you probably need a better jtag probe for that
<mwk> (or a better RE effort if xpc does in fact support higher speeds)
<mwk> though the 12MHz is probably the USB crystal speed, so it might be a hw max
<q3k> well this is also an aliexpress special xpc
<q3k> so all bets are off
<q3k> but it did seem to work at 0x10 which iiuc is 12MHz
<q3k> i'd measure it but $effort
<mwk> it's an uncompressed bitstream, right?
<mwk> hmm
<mwk> according to my math, it should take 12.49s to program an xc7k420t with 12MHz JTAG, assuming uncompressed bitstream
<mwk> so maybe the "12MHz" means the actual TCK is only 6MHz
<mwk> I'd check, but I probably have the same chinese xpc as you do
<omnitechnomancer> The JTAG probe on the board I have been using is not great, there was a comment somewhere in docs that on Linux it might fail if used higher than 400kHz
<omnitechnomancer> Not xilinx though
Kekskruemel has quit [Quit: Leaving]
Dolu has joined ##openfpga
sgstair has joined ##openfpga
<GenTooMan> was their any explanation as to why? is it because of the board layout trace capacitance, trace inductance or it just has low drive output?
Asu has quit [Ping timeout: 265 seconds]
Asu has joined ##openfpga
Sellerie has quit [Read error: Connection reset by peer]
Sellerie has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
genii has quit [Remote host closed the connection]
zino has quit [Excess Flood]
zino has joined ##openfpga
implr has quit [Remote host closed the connection]
genii has joined ##openfpga
implr has joined ##openfpga
renze has joined ##openfpga
<omnitechnomancer> GenTooMan I expect the issue is on the USB side and the suboptimal way the adapter functions more than the JTAG end
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Asu has quit [Ping timeout: 252 seconds]
Asu` has joined ##openfpga
Bike has joined ##openfpga