<azonenberg_work> lol
wbraun_ has joined ##openfpga
wbraun has quit [Read error: Connection reset by peer]
wbraun_ is now known as wbraun
* whitequark sobs
<whitequark> mov eax,1; retn
<G33KatWork> I only run vivado in docker
<G33KatWork> containers are about 20-30 GiB in size. Depends on the version
<etrig> why does vivado take screenshots of the user's desktop?
<etrig> is it something webtalk related?
<whitequark> etrig: wtf
<etrig> whitequark: I was getting lots of segfaults from libawt_xawt.so at Java_sun_awt_X11_XRobotPeer_getRGBPixelsImpl
<etrig> because old jvm cannot into wayland
<G33KatWork> Wasn't this related to icon rendering?
<G33KatWork> I ran into that as well once
wbraun has quit [Quit: wbraun]
<G33KatWork> ah, no. popups with drop shadows
<G33KatWork> that also explains why AWT reads screen content
<G33KatWork> I always got segfaults when a little tooltip popped up when hovering over some buttons with the mouse
<etrig> oh that makes sense- it seemed like it always happened during synthesis or routing and I wasn't otherwise interacting with the ui
<whitequark> ugh, just HOW MANY copies of flexlm code does it have?!
<sorear> more or less than the number of independent javascript engines in a vivado download?
<whitequark> at least six
<zkms> cursed
<whitequark> sorry, at least nine
<whitequark> jesus
<gruetzkopf> what does he have to do with this?
<TD-Linux> how many years has it been since X has had argb visuals?
* TD-Linux does remember kde 3 doing a similar hack
<sorear> grammatically that sentence implies X no longer has argb visuals
<sorear> i recall it becoming a thing at the same time as XComposite
<TD-Linux> if you're not american you can't critique my grammar
<sorear> server-side alpha composition was never a thing
<TD-Linux> yeah. well it's not very compatible with drawing directly to the front buffer
<TD-Linux> I wonder how windows xp transparenc yworked
<lain> the earlier discussion of lattice licensing stuff reminds me of my adventure with solidworks... solidworks licenses always phone home when activating, and they count licenses on their end. the idea is you deactivate a license on a machine you're decommissioning, and that frees up an install slot for your new machine. they allowed like 3 concurrent active licenses.
<lain> thing is, deactivation never /worked/
<lain> so eventually, through OS reloading churn or new hardware, I'd wind up hitting the 3 install limit, despite always deactivating
<lain> it used to be largely automated to reset the counter, you'd just email your license info in a standard form to some address and within 24 hours you'd have it reset
<marshallh> do they even allow de-activations anymore
<lain> IMHO 24 hours of downtime for their own bug is absolute madness after they've extracted all the other fees from me, but that's beside the point
<marshallh> something was change da few months ago
<lain> yeah so recently they changed it
<lain> now they don't allow deactivation OR resetting EXCEPT VIA PHONE CALL to your distributor
<lain> NOT solidworks corp - they don't talk to customers anymore, ever
<marshallh> yeah
<marshallh> at least DASI seemed pretty good when i bought from them
<marshallh> solidworks can go eat shit in this regard
<lain> yes
<lain> so turns out there's a lot of DLLs with debug symbols
<lain> one of them may have a function, something like bool IsDebugModeEnabled() { return false; }
<marshallh> you should poke around and see where they open up and scan through your mozilla thunderbird databases for company info
<lain> and the license check has something like if(IsDebugModeEnabled()) { return FULLY_LICENSED; }
<lain> marshallh: WHAT lol
<marshallh> i'm sure they do it for outlook and every other local email client htey can
<marshallh> it's part of the erm, "compliance" program
<whitequark> what.
<lain> if you were going to crack any software like that I'd definitely use windows firewall rules to eliminate all in/outbound traffic for all EXEs it installs, or better yet just use it in a VM with no networking
<lain> but jesus
<lain> that's worse than I could've expected lol
<marshallh> yeah they are very aggressive about it
<marshallh> i would blow away the entire OS after installing "solidworks" if doing that
<lain> yeah jeez
<whitequark> ok let's try the pcie demo finally
<lain> I don't recall seeing any of that when I looked around their code, but it wouldn't surprise me. it's not like I spent any time on it.
<lain> marshallh: what version was that seen in?
<lain> mine is ancient, 2012.
<whitequark> ... it's a .EXE?!
<whitequark> the fuck
<marshallh> 2017
<marshallh> make sure you firewall up the wazoo lol
<lain> lol yeah
<lain> I basically just don't use it anymore because it's been such a PITA with the licensing
<whitequark> WHY DOES THE PCIE DEMO HAVE A COPY OF JRE INSIDE
<sorear> unzip -l ? :p
<gruetzkopf> :D
<gruetzkopf> everything has a jre
<lain> if I need it again, well, that's what VMs without network interfaces are for >_>
<gruetzkopf> ^
<lain> I wish there was like, a legal exception for unlocking software like that when you're only unlocking features you actually have perpetual license to use
<whitequark> ... huh, lattice's softcore is not encrypted?
<lain> because legally that's still not okay, but it fucking SHOULD be
<whitequark> it's just 2k lines of verilog
<whitequark> kind of decent, too
<sorear> what.
<whitequark> yes
<sorear> the serdes model is, but the pcie isn't
<whitequark> ~/.wine/drive_c/Lattice_DevKits/DK-ECP5-PCIE-200/Hardware/PCIe_x1/Versa_PCIeBasic/Clarity/ecp5um5G-45-Versa/pcie2_core/pcie2_core/pcie2_x1/pcie2_x1_pcs/pcie2_x1_pcs_softlogic.v
<whitequark> what is this?
<marshallh> a very long path
<sorear> probably part of the core?
<whitequark> oh hm
<gruetzkopf> coding layer?
<whitequark> yeah the phy is definitely open-source
<whitequark> >/pcie2_x1/pcie_eval/models/ecp5um/pcie2_x1_phy.v
<whitequark> i mean
<whitequark> "ships with the source"
<whitequark> oh isee
<whitequark> The generated PCI Express IP core package includes <user_name>.v and black box files <user_name>_core_bb.v and <user_name>_phy.v.
<whitequark> looks like the phy is in the source form but there's *also* a black box
<whitequark> which implements everything above the phy?
<whitequark> interesting
<sorear> everything except the link training seems fairly straightforward
<whitequark> yes
<whitequark> which is why this is really weird
* whitequark shrugs
<sorear> although I'm rather amused by the boneless-TCP-ness of the data link layer
<whitequark> daveshah: ok, i found the bitstream and jed file for ispclock
<whitequark> any idea how to flash it?
<gruetzkopf> yeah DLLP stuff is funny
<sorear> does gen3/gen4 have any kind of FEC
<sorear> *gen4/gen5
<gruetzkopf> gen4 doesn't iirc
<whitequark> ok i flashed it
<whitequark> lets plug it
<gruetzkopf> looked around a bit, apparently they're actually doing 16GT/s without FEC into up to 28dB of insertion loss
<azonenberg_work> is pcie 5 going to be pam4 yet?
<azonenberg_work> or is that not until 6
<azonenberg_work> whitequark: my guess is that the black box is an IP they licensed from say synopsys
<azonenberg_work> the phy was specific to their design, and less carefully debugged, so they made it an rtl blob they could reconfigure if they found bugs
<gruetzkopf> afaik still nrz
<azonenberg_work> the pipe layer is probably a hard macro to save die area
<gruetzkopf> PIPE isn't big if you have serdes
<gruetzkopf> afaict STILL without FEC
<azonenberg_work> yeah i dont think we will see fec in pcie until they move to pam4
<azonenberg_work> pam4 pretty much mandates fec because you lose another ~3 dB of noise margin
<azonenberg_work> just from the modulation
<gruetzkopf> "As such, PCIe 5.0 is intended as a straightforward speed bump to the PCIe 4.0
<gruetzkopf> required to enable the PCIe standard to support 32 GT/s in as short a time as feasible."
<gruetzkopf> For example, PCIe 5.0 does not support PAM4 signaling and only includes new capabilities
<gruetzkopf> standard without any other significant new features.
<gruetzkopf> "owever, after passing through the proposed -36 dB channel, any resemblance to an open eye is missing."
<azonenberg_work> gruetzkopf: ah ok so pcie 6 is probably where they are going to start adding the other fun stuff
<gruetzkopf> "The minimum expectation for eye height for a PCIe 5.0 signal is 10 mV (post-equalization)."
<gruetzkopf> yes
<azonenberg_work> 10 mV *post* equalization
<azonenberg_work> post
<gruetzkopf> YES
<gruetzkopf> also i found a keysight document
<gruetzkopf> showing the cursed pcie->"usb" adapters
<zkms> nice
<azonenberg_work> ??
<sorear> azonenberg_work: reasonably efficient modern FEC requires fairly large blocks, which is a problem for PCIe because the ACK timeout is tens of bytes
<zkms> can you link?
<azonenberg_work> sorear: i think they are going to have to start tolerating slightly higher latency
<azonenberg_work> because something like hamming(72,64) is way too big
<azonenberg_work> they're going to have to do acks at the TLP level or something
<gruetzkopf> DLLP ack timeout can be increased
<gruetzkopf> TLP timeouts are far longer anyways
<gruetzkopf> like 2OOM longer at least?
<sorear> > However, after passing through the proposed -36 dB channel, any resemblance to an open eye is missing.
<azonenberg_work> gruetzkopf: aaand you know what?
<sorear> i like the way they put this
<azonenberg_work> once they start tolerating slightly higher latency and having acks and stuff work at the packet level?
<azonenberg_work> it's starting to look an awwwwwful lot like ethernet :p
<gruetzkopf> hehe
<sorear> azonenberg_work: pcie has both packet level and data link acks, always has
<azonenberg_work> sorear: that may have to change down the road if they add fec
<azonenberg_work> gruetzkopf: 1Tbase-KX16 anyone?
<gruetzkopf> no matter what they do
<gruetzkopf> still more sane than usb
<azonenberg_work> gruetzkopf: 16 lanes of 64 GT/s PAM4
<gruetzkopf> hmm
<azonenberg_work> moving "pcie tlp in 802.3 frames"
<SolraBizna> can I have a FireWire GPU instead?
<gruetzkopf> SolraBizna: been there, done that
<gruetzkopf> with *extremely* crude hacks
<sorear> 802.3 addresses and ethertypes would add about 100% overhead
<whitequark> 06:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation Device ec30
<azonenberg_work> sorear: not if it was around a whole TLP
<gruetzkopf> sorear: there are people commercially providing it
<sorear> i guess you could consolidate multiple TLPs into a single ethernet frame
<azonenberg_work> or several ,yes
<gruetzkopf> expether (driven by nec)
<azonenberg_work> gruetzkopf: there would be passive adapters available to break the x16 socket out to four QSFP56's
<SolraBizna> I played UT2004 over GLX over IP over FireWire once
<sorear> azonenberg_work: a basic read TLP is 12 bytes
<gruetzkopf> SolraBizna: IOMMU page fault handlers.
<azonenberg_work> four 200G ethernet interfaces (downgradeable to 100Gbase-SR4 or 40Gbase-SR4) per pcie 6.0 x16 interface
<SolraBizna> well, played is a strong word
<azonenberg_work> that would be awesome :p
<gruetzkopf> that's as much as i'm willing to admit
<sorear> the CRC is needed regardless, but the 14 bytes of addresses and ethertype are dead weight and >100% overhead
<gruetzkopf> azonenberg_work: dualrow-QSFP56
<gruetzkopf> with 8 lanes to per cage
<azonenberg_work> gruetzkopf: well a pcie 6.0 x16 interface would only have 16 transceivers
<gruetzkopf> let's support the often forgotten x32 link mode
<azonenberg_work> so my thought was four qsfp cages, each cage with four pam4 serdes lanes
<sorear> hmm, is x32 not common?
<gruetzkopf> barely used
<gruetzkopf> from what public markets show
<gruetzkopf> i mean, not even bplus has stuff with it
<kosborne__> most stuff I've seen about x32 is just bifurcation boards
<sorear> if I buy a random computer will it probably only have x16 slots?
<kosborne__> to turn it into 2 x16 slots
<SolraBizna> I've never actually seen an x32 slot or card
<azonenberg_work> sorear: generally there's a few x16 for gpus
<azonenberg_work> (often one of them is only wired to x8)
<azonenberg_work> then some x4's for misc expansoin stuff and a few x1's for low speed
kosborne__ is now known as Bob_Dole
<sorear> is "10mV eye height" as bad as it sounds
<Bob_Dole> whoopsy
<gruetzkopf> sorear: it's far worse
wbraun has joined ##openfpga
<azonenberg_work> yeah that would be one heck of a rx to decode that
<sorear> > high-bandwidth oscilloscope (63 GHz or more)
<sorear> oh, the article is from a scope company
<zkms> high speed serial interfaces are just a plot by keysight and lecroy to sell super expensive oscilloscopes
<sorear> i see this now
<SolraBizna> lol
<sorear> 63 GHz is "wtf" and "wait, at what point does the waveform become too quantum for plotting it to make sense?"
unixb0y_ has joined ##openfpga
unixb0y has quit [Ping timeout: 272 seconds]
prpplague has left ##openfpga ["Leaving"]
<SolraBizna> can I have an asynchronous SR latch in an iCE40?
<sorear> probably
<sorear> the tools won't support it though
* SolraBizna adds that to the list of "things I miss about discrete logic"
<SolraBizna> (it is, so far, a short list)
<sorear> discrete logic ~ structural verilog
<SolraBizna> ?
<sorear> i'm 80% sure that if you instantiated two SB_LUT4 as NAND gates pointing at each other, synthesis wouldn't give you trouble
<sorear> structural verilog uses modules to describe the exact graph structure of a circuit
<SolraBizna> ah
<azonenberg_work> sorear: wellll
<azonenberg_work> the issue is that, at least in general, fpga luts are not guaranteed to be glitch free
<sorear> behavioral verilog, using always blocks, is going to work poorly for anything involving latches
<azonenberg_work> you'd be better off configuring the dff's as latches, if the fpga supports it
<sorear> that's the 20% above
<azonenberg_work> pretty sure xilinx can do that
<sorear> ice40 definitely can't
<azonenberg_work> idk about lattice uarch
<SolraBizna> what I want it for is an interrupt signal and the logic to trigger/acknowledge it
<azonenberg_work> SolraBizna: the correct option imo for that is to have the pulse be at least 1 clock cycle long, synchronize it into a clocked logic domain
<azonenberg_work> then do synchronous logic
<SolraBizna> a little bit more thinking and I can just fit it into the clocked paradigm
<sorear> latches are an advanced topic with few good uses
<azonenberg_work> sorear: yeah exactly
<azonenberg_work> SolraBizna: i've been doing fpga stuff for... about eight years now?
<azonenberg_work> i have not once needed a latch in one of my designs
<SolraBizna> my first FPGA literally arrived three hours ago, and I never touched Verilog before a month or so ago
<azonenberg_work> my point is, if a latch is the solution
<SolraBizna> but I've done discrete logic for... forever
<azonenberg_work> you probably misunderstood the problem :p
<SolraBizna> doing this the "without a latch" way was pretty easy once I actually started thinking of how to do it
Bike has quit [Quit: Lost terminal]
<SolraBizna> since everything else in this module was already clocked, and the module that will be doing the acknowledgement is using the same clock
<SolraBizna> (in other words, a latch was indeed not the best solution)
<azonenberg_work> Point made :)
<sorear> I've seen ASIC people use latches for register files when they don't have the eng budget for a SRAM
<sorear> I'm actually struggling to come up with another use
<sorear> sometimes a flip-flop will be decomposed into complementary latches so that other logic can be retimed between them, but that's operationally transparent
<sorear> if you meet a bunch of conditions *handwaving intensifies* and are OK with having a minimum clock, a latch can just be a pair of pass transistors
<azonenberg_work> you mean a dram cell? :p
<sorear> almost every detail differs but the principle is the same
<sorear> rely on the capacitance of the downstream gates to maintain a logic value until the next clock cycle
<sorear> technically dynamic logic (does not work at 0 Hz) but unlike dynamo it doesn't kill your dynamic power for low-activity nets
<sorear> s/dynamo/domino/
Miyu has quit [Ping timeout: 268 seconds]
eightdot has quit [Ping timeout: 244 seconds]
eightdot has joined ##openfpga
lovepon has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
<whitequark> fucking hell synopsys
<whitequark> why do you have a zillion scirpts with #!/bin/sh that assume bash
<SolraBizna> well, for a decade or so, that assumption held on most Linuxes
<SolraBizna> they've only had like ten years to get their act together
<SolraBizna> that's not even enough time to make a decent filesystem~
<whitequark> Copyright (c) 1991-1994 by NeoCAD Inc. All rights reserved.
<whitequark> Copyright (c) 2001 Agere Systems All rights reserved.
<whitequark> Copyright (c) 1995 AT&T Corp. All rights reserved.
<whitequark> Copyright (c) 1995-2001 Lucent Technologies Inc. All rights reserved.
<whitequark> Copyright (c) 2002-2017 Lattice Semiconductor Corporation, All rights reserved.
<whitequark> wow
<whitequark> that's a lot of history
<SolraBizna> o_o
<whitequark> Saving bit stream in "top_implementation.bit".
<whitequark> Wrong # arg -task
<whitequark> Jedecgen is not a valid task name.
<whitequark> wtf
<whitequark> aaaaa
<SolraBizna> what's the easy way to initialize BRAMs?
<sorear> an initial block
<sorear> ice40 fpgas can load BRAM contents as part of the configuration process, the tools will turn some verilog initial blocks into data for that process
<SolraBizna> ah... I didn't think I could use initial blocks outside simulation
<SolraBizna> is there a reference / rule of thumb for what kind of thing I can put into such an initial block?
<SolraBizna> $readmemh is probably a thing I can use, but what of things like $fopen/$fseek?
<SolraBizna> yosys manual says I can't even use readmemh...
<sorear> like everything else it depends on your tools
<sorear> IEEE 1364.1-2002 is a reasonable place to start, but it hasn't been updated in quite a while
<zkms> i-i've used readmemh with yosys with an actual irl ice40 ;;
<SolraBizna> the manual lies!?
<SolraBizna> next you'll tell me a WDC datasheet has an error
<SolraBizna> zkms: was that with an inferred BRAM or an explicit one?
<zkms> reg [1:0] memory[0:2047];
<zkms> initial $readmemh("modea.hex", memory);
<SolraBizna> drat
<zkms> it inferred fine iirc
<SolraBizna> I had no luck previously getting BRAMs to infer, *but*... this is a read-only usage so it should be easier
<zkms> maek sure they're the right size
<zkms> and
<zkms> make sure you dedicate a clock for the acces
<zkms> s
<zkms> iirc you want a clock to generate the address, a clock to access the BRAM, and a clock to do whatever else with the BRAM
<zkms> thats what i did and all my BRAMs infer fine all the time
<SolraBizna> getting yosys to recognize the way I've clocked this system seems like less work than writing a tool to autogenerate all this
<SolraBizna> *more work
<whitequark> daveshah: can you confirm that PCIE_PERSTN on versa5g does nowhere?
<whitequark> I can't find it anywhere else on the schematic
<zkms> is this a good ecp5 dev board? i'm considering getting it http://www.latticesemi.com/ecp5-evaluation
<azonenberg_work> zkms: lol
<azonenberg_work> looking at that makes me think of a xilinx board somebody cheaped out on
<azonenberg_work> with all the unpopulated sma footprints etc
<azonenberg_work> i get why they did it, 18 good SMAs would probably have added $50+ to the cost of the pcb
<azonenberg_work> but still
<zkms> is it decent though or are there any contraindications
<zkms> i'm considering it because it's the biggest ecp5 part
<zkms> it has *
<whitequark> zkms likes big ecp5s and cannot lie
<zkms> n-not wrong!
jevinski_ has joined ##openfpga
lovepon has quit [Ping timeout: 260 seconds]
jevinskie has quit [Ping timeout: 250 seconds]
m4ssi has joined ##openfpga
<daveshah> zkms: yes, that's very good board
<daveshah> Loads of IO unlike a lot of boards
<daveshah> Only one qualm is a lack of memory onboard
* zkms nods
<zkms> I don't think i need external DDR memory for what i'm doing
<zkms> but ty for pointing that out
<zkms> i hadn't realised that the versa boards also had memory and this one didnt
<daveshah> I did design a board which adds 64MB of SDRAM to the hat connector
* zkms nods
<zkms> i'm more interested in those DSP blocks ;;
<daveshah> Have only tested with the Versa so far (because the FOSS tools don't support ddr3 yet)
<daveshah> But should work on this board too
<daveshah> whitequark: I can find PCIE_PERSTN on the schematic
<daveshah> Seems that by default it isn't connected to the card edge though
<daveshah> Because R178 is DNP
<whitequark> daveshah: where?
<whitequark> which sheet
<whitequark> the schematic isn't searchable...
<daveshah> Pages 21 and 27
<daveshah> It's searchable for me??
<whitequark> hm
<whitequark> 21, yes, I see
<whitequark> OH
<whitequark> thanks
<daveshah> If you want to experiment with Diamond further, the unencrypted part of the PCIe core is more or less the output from Lattice's PCS wizard
<whitequark> i don't want to look at diamond's code
<whitequark> first, it's not fun
<daveshah> You can access this from Clarity Designer in Diamond
<whitequark> second, it contaminates mine
<whitequark> anyway, i got 50 mhz out of the fpga from the default oscillator
<whitequark> let me see if i can coerce ispclock into routing pcie clock where i need it
<whitequark> you're syaing that only fabric works, right
<daveshah> Yes, but that should be fixed asao
<daveshah> *asap
<whitequark> hmmmm
<daveshah> Hopefully today if I have any time
<whitequark> I guess I want to play with PLL anyway?
<whitequark> not sure
<whitequark> ispclock seems mildly annoying to program
<daveshah> I think ispclock should route refclk x2 into the serdes refclk
<daveshah> That is a good long term solution
<daveshah> x2 is needed for 5Gbps because the serdes can only multiply by a max of 25x
<whitequark> mhm ok
<whitequark> how do you program the ispclock anyway?
<whitequark> does it have some gui tool to configure it?..
<whitequark> ah, "pac-designer"...
<daveshah> afraid so
<daveshah> I'm not sure if the default config would be good enough once the extref pins can be used
<whitequark> sure
<whitequark> i reflashed it anyway
<whitequark> to the pcie sample dedsign
<whitequark> idk what it does
<daveshah> seems dubious why that is different tbh
<daveshah> maybe that is the factory one
<daveshah> they just wanted to make sure you really did use that one
<whitequark> ok
<whitequark> yeahhhhhh this doesnt work under wine at all
<daveshah> ispclock bitstream re time lol?
<whitequark> wow
<whitequark> green schematics on black background
<whitequark> so retro
<whitequark> daveshah: hm?
<whitequark> the pac designer thing
<whitequark> doesnt run under wine well
<whitequark> wtf
<whitequark> it doesn't open JED files
<whitequark> only "PJC" files...
<whitequark> AAAAA THE PROGRAMMER DOESN'T WORK ON WINDOWS 10
<whitequark> this hting is precisely as fucked as i expected
<daveshah> Diamond should do programming once you've got a jed
<whitequark> no, I want to look at *their* jed
<whitequark> see how it's configured
<whitequark> lattice can only read a .jed
<whitequark> if you try to load a .jed into pac designer it segfaults
<whitequark> nice
<whitequark> oh
<whitequark> it's one of example ispclock designs
<whitequark> ok
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
<whitequark> ... I clicked "save" and overwrote the example design
<whitequark> this tool is extremely ghetto
<azonenberg_work> whitequark: your experiences are making me very glad i did not play with ecp5 yet, lol
* azonenberg_work sits back and watches other people suffer until the RE is complete :p
<daveshah> azonenberg_work: this isn't an ECP5 per se
<azonenberg_work> ?
<azonenberg_work> with xilinx the proprietary toolchain sucks but i can at least tolerate using it
<daveshah> It's an ispclock programmable pll and clock routing chip
<daveshah> That Lattice put on the Versa board
<azonenberg_work> oh, i thought this was to program the fpga
<daveshah> Diamond isn't great but isn't that bad either
<azonenberg_work> i looked at ispclock briefly, saw they were all tqfp, and stopped looking
<azonenberg_work> :p
<daveshah> Yeah I'd defo go for one of the Silabs parts or something
<azonenberg_work> as a general rule these days i only use bga/qfn parts
<azonenberg_work> unless i have a very good reason not to
<azonenberg_work> my new favorite clock synthesizer is the lmk04806
<azonenberg_work> it may be overkill for most purposes
<azonenberg_work> ~100fs rms jitter
<daveshah> As far as I know all this chip is doing is a clock switch on PCIe presence and a x2 multiply
<azonenberg_work> 14 outputs, 220 kHz to 2.6 GHz output
<azonenberg_work> CML, LVDS, LVCMOS, LVPECL, etc io buffers
<daveshah> I think that is quite overkill for this lol
<azonenberg_work> in a 64-QFN
<azonenberg_work> oh, and fine phase shift down to 25 ps steps
<daveshah> Sounds good for crazy adc stuff
<azonenberg_work> i did a design with one a while ago for 40 Gsps equivalent time sampling
<azonenberg_work> tweaking waveform to sampling phase by 25 ps per acquisition
<azonenberg_work> i think we oversampled at 400 different phases
<daveshah> nice
<daveshah> Ecp5 serdes testing makes me want a fancy scope
<daveshah> I've only looked at them with an SDR so far
<daveshah> But ENOMONEY
<azonenberg_work> i've been drooling over the wavesurfer 510 for a while
<azonenberg_work> it
<azonenberg_work> it
<azonenberg_work> gaah i keep aiming for shift and missing
<azonenberg_work> it's "only" 1 GHz b/w 10 Gsps
<azonenberg_work> But costs a bit more than the blue book value of my wife's car
<azonenberg_work> so i don't expect i will be getting faster any time soon
<azonenberg_work> and even that is a bit of a reach for the moment
<azonenberg_work> The fastest i've actually managed to acquire data myself is 10 Gsps equivalent time
<azonenberg_work> i want to try an interpolated render of this on my new opengl scope ui, i bet it'd look a lot better
<azonenberg_work> this is 250 MHz real time acquisition stepping phase in 100ps steps
<azonenberg_work> so 10 Gsps equivalent rate
<whitequark> azonenberg_work: this siclockis a qfn
<azonenberg_work> with 16-bit vertical resolution
<azonenberg_work> daveshah: ... in a $50 pmod :D
<azonenberg_work> i think i can push it to 40-50 Gsps with an external PLL but that will be more work and right now i dont need it
<azonenberg_work> the big problem is that it relies on your tx and rx being phase locked so it's great for plotting eyes through a backplane or something
<azonenberg_work> or a buffer
<azonenberg_work> not so good for a serdes you dont have full control of
<daveshah> azonenberg_work: mmm, that sounds fun
<azonenberg_work> although i am wondering about maybe using a crazy-fast comparator and some dirty tricks to build my own discrete cdr
<azonenberg_work> and then doing a DLL off that
<azonenberg_work> Basically, analog trigger on a zero crossing
<azonenberg_work> delay by one UI then sample
<azonenberg_work> change delay to 1.001 UI, sample again
<azonenberg_work> you dont want to use zero delay as this means you only will trigger on a rising edge
jhol has quit [Read error: Connection reset by peer]
<whitequark> daveshah: i've got refclk in fabric \o/
<whitequark> so the ispclock config work
<whitequark> 200 mhz
<whitequark> actually, what i get is more like um
<azonenberg_work> but if you start by delaying one UI, then you can sample a rising or falling edge
<azonenberg_work> daveshah: sound plausible?
<whitequark> 199.6016 MHz
<whitequark> which is weird as hell
<whitequark> maybe my scope lies?
<azonenberg_work> whitequark: when was it last cal'd?
<daveshah> is this from PCIe
<whitequark> azonenberg_work: never
<azonenberg_work> alternatively, how cheap is the osc on the pcb?
<daveshah> I'm not sure how exact motherboards are
<whitequark> azonenberg_work: havent disassembled it but its a rigol
<azonenberg_work> 2000 PPM off seems like a lot
<whitequark> it seems very *exactly* off
<whitequark> like
<whitequark> the scope shows my clk/4 as 49.9004
<whitequark> very stable, too
<whitequark> i swear this is an off by one *somewhere
<azonenberg_work> yeah sounds like one of your oscillators (dut or scope) is out of spec
<azonenberg_work> or that
<whitequark> daveshah: this isnt a mobo
<whitequark> its a thunderbolt pcie box
<whitequark> doubly cursed
<daveshah> that could be it
<whitequark> oh and the versa is connected to it via a floppy drive cable basically
<daveshah> Have you scoped the input clock?
<whitequark> one of the cheaper bplus.com.tw extenders
<whitequark> my scope cant do 200 mhz
<whitequark> oh hm
<whitequark> thats 100 mhz
<whitequark> sec
<whitequark> gimme a moment
<whitequark> ugh let me just bypass pll this is very inconvenient to probe
<whitequark> i need toget to the other side of the board on this cursed setup
<whitequark> and none of it fits very well on my desk
<whitequark> probably because of like four kilo of floppies on it
<whitequark> the fuck i need that for anyway
jhol has joined ##openfpga
jhol has quit [Read error: Connection reset by peer]
<whitequark> daveshah: ok, programmed PLL for bypass
<whitequark> i get... 12.4751 mhz on the scope
<whitequark> exactly 1/4 of 49.9004 mhz
<whitequark> so it seems like the pll works
rofl_ has quit [Read error: Connection reset by peer]
rofl_ has joined ##openfpga
<daveshah> seems just something is screwed up with the thunderbolt adapter then
<daveshah> maybe some crazy emi reduction scheme
rofl_ has quit [Write error: Connection reset by peer]
rofl_ has joined ##openfpga
<whitequark> hmmmm possible
<whitequark> lemme ughhhhh
<whitequark> try
<whitequark> oh
<whitequark> i can just disconnect it for probing
<whitequark> i.... what
<whitequark> daveshah: i disconnected the versa
<whitequark> and the freq is... 93.2 MHz
<whitequark> i'm wondering if it doesn't like being unloaded
<whitequark> precisely
<whitequark> it's approximately 99.6 MHz
<whitequark> and I think my scope sucks and can't measure very well near 100 MHz
<whitequark> because there's a ton of jitter in what it measures
<whitequark> but anyway
<whitequark> the pll seems fine
<whitequark> ... of course the lattice utility doesn't have undo either...
<whitequark> ok, my scope *definitely* lies because after "redriving" through the FPGA via the 3V3 bank it shows 99.8009 MHz exactly
<whitequark> seems like the frq counter is fucked on low amplitude signals?
<whitequark> i guess i'm *finally* bumping into limits of my rigol
<whitequark> can't complain, it has served me extremely well all this time
<whitequark> *thinks*
<whitequark> i'm going to need to use the SERDES now i guess
<daveshah> yeah sounds like things are ready to go
<daveshah> The config I linked previously was generic 2.5Gbps 8b10b tx/rx with a 100MHz ref
<daveshah> That used a 8 bit 250MHz fabric side interface
<daveshah> 125MHz 16 bit is probably more practical in terms of timing though
<whitequark> hmmmm
<whitequark> okay
pie__ has quit [Ping timeout: 252 seconds]
<whitequark> daveshah: does diamond or trellis implement default parameters?
<whitequark> also, is it "trellis" or "prjtrellis"?
<whitequark> i.e. what should migen use as the "toolchain" option
<daveshah> IMO trellis
<daveshah> Same as icestorm could be called project icestorm
<daveshah> Both do implement default parameters. Trellis defaults to zero and I believe Diamond does too
GuzTech has joined ##openfpga
<whitequark> ah cool
<whitequark> daveshah: so you're just using one half of the differential clock pair?
<whitequark> any particular reason?
<whitequark> no need for noise immunity?
<daveshah> You mean for the clock input?
<daveshah> For ecp5 you only specify one half of an lvds input
<daveshah> The other half is automatic
<daveshah> I know this is different to Vivado
<whitequark> hm, so I need to set IO_TYPE LVDS, right?
<daveshah> Yeah
<whitequark> huh
<whitequark> ERROR - ngdbuild: DCUA block 'DCUA' has no 'LOC' property.?
<whitequark> oh
<whitequark> HDINP
<whitequark> interesting, it still doesn't like it...
jhol has joined ##openfpga
<whitequark> daveshah: 1 = Internal high speed bit clock is 25x (for REFCLK =
<whitequark> 100 MHz only)
<whitequark> 0 = see REFCK_MODE
<whitequark> looks like it's not enough to use 100 MHz refclk
<whitequark> er, 200
vup has quit [Quit: The Lounge - https://thelounge.github.io]
vup has joined ##openfpga
<daveshah> whitequark: that's interesting
<daveshah> Anything above 200MHz will have to use the external ref primitive, not fabric, I'd say
cr1901_modern has quit [*.net *.split]
grantsmith has quit [*.net *.split]
hackkitten has quit [*.net *.split]
ym has quit [*.net *.split]
Sellerie has quit [*.net *.split]
mwk has quit [*.net *.split]
WilhelmVonWeiner has quit [*.net *.split]
flaviusb has quit [*.net *.split]
jn__ has quit [*.net *.split]
CoffeeFlux has quit [*.net *.split]
gnufan has quit [*.net *.split]
CoffeeFlux has joined ##openfpga
Sellerie has joined ##openfpga
CoffeeFlux has quit [Changing host]
CoffeeFlux has joined ##openfpga
cr1901_modern has joined ##openfpga
hackkitten has joined ##openfpga
WilhelmVonWeiner has joined ##openfpga
grantsmith has joined ##openfpga
flaviusb has joined ##openfpga
WilhelmVonWeiner is now known as Guest66115
ym has joined ##openfpga
mwk has joined ##openfpga
jn__ has joined ##openfpga
ym has quit [Remote host closed the connection]
Guest66115 has quit [Quit: leaving]
WilhelmV1nWeiner has joined ##openfpga
WilhelmV1nWeiner has quit [Client Quit]
WilhelmV1nWeiner has joined ##openfpga
WilhelmV1nWeiner has left ##openfpga [##openfpga]
<whitequark> ah, right
WilhelmVonWeiner has joined ##openfpga
WilhelmVonWeiner is now known as Guest12370
Guest12370 has left ##openfpga [##openfpga]
<daveshah> I would definitely start with 2.5Gbps though
<daveshah> I suspect 5Gbps might need some tuning of the equalisation, etc, parameters particularly if you have an extender cable in there
<whitequark> sure
<whitequark> I'm not going to start with 5g lol
<whitequark> or with links >x1...
<whitequark> given that i've never used a SERDES before
<whitequark> i have hubris but not *that* much hubris
<whitequark> right now my hubris consists of starting with a blank DCUA instance and adding parameters one by one
<whitequark> while understanding what they do
<daveshah> sure
<daveshah> this is very useful
<daveshah> thanks
<whitequark> so, i'm looking at this
<whitequark> p_D_MACROPDB="0b1", #?
<whitequark> i_D_FFC_MACROPDB=1, #?
<daveshah> these are powerdown bits I think
<whitequark> no, i get that
<whitequark> question is about another thing
<whitequark> looks like for quite a bunch of inputs there is both a parameter and fabric input
<whitequark> p (defparam but in migen) and i (input)
<whitequark> i wonder how do they work?
<whitequark> i *think* they are OR'd together
<whitequark> because that would explain why it uses active-low power down bits
<daveshah> I was guessing that they are AND'd
<whitequark> hm
<daveshah> logically anded
<daveshah> physically ored
<daveshah> if that makes any sense
<whitequark> that's just for powerdown ones, right?
<daveshah> ie both need to be high for it to power on
<daveshah> yeah
<whitequark> hmmmm
<whitequark> let's check
<whitequark> meanwhile i've read the entire serdes technote
<whitequark> they are actually not very scary
<whitequark> just kind of flexible and very underdocumented on primitive level
<daveshah> yes - luckily some of the nastier electrical parameters should correlate to the documented SCI registers
<daveshah> the names are a bit different, but usually can be worked out
<whitequark> yeah the naming is... uh...
<whitequark> i think there is a SERDES group inside and the fabric group inside and they don't talk to each other
<daveshah> Lattice is generally like that
<daveshah> The inconsistency is a big pain from Trellis's point of view more generally
<whitequark> that makes it all the more impressive that they actually manage to produce pretty good hardware
<daveshah> yeaj
<daveshah> *yeah
<whitequark> like they are clearly doing *something* right
<daveshah> They do manage to get some good customers too
<whitequark> probably *more* right than the others because it offsets the general silo'ing
<whitequark> i wonder why
<whitequark> i mean what
<daveshah> They fill a niche which is not that well occupied
* whitequark waves in the general direction of intel
<daveshah> "general purpose" FPGAs in small packages at low cost
<whitequark> yeah but that doesnt mean you make good hardware
<whitequark> in fact if you fill a rare niche you can produce shit and survive
<daveshah> The ECP5 is a lot nicer architecturally than 7-series in many ways
<daveshah> Much simpler SLICEs yet almost as capable
<daveshah> no SLICEL/SLICEM divisioning
<whitequark> i remember sb0 complaining for many months about the, uh, "ultratrash" serdeses
<whitequark> and the xilinx primitives are extremely gnarly
<daveshah> Yeah, I would guess they are worse and with even less primitive documentation
<whitequark> there is none and they are buggy as hell
<whitequark> in one case i believe artiq still repeatedly resets the entire serdes in order to get it to sync in the right phase or something like that
<whitequark> sometimes for like, seconds
<whitequark> because none of the features xilinx has for that actually work
<daveshah> was literally just having lunch with someone who had worked on RapidSmith before
<daveshah> it all very much sounds like this
<daveshah> just the routing in the logic slices can get quite crazy
<whitequark> also, i am imprssed how fast diamond is
<whitequark> it is almost on the nextpnr level
<daveshah> yes
<daveshah> makes fuzzing very nice
<whitequark> lol
<whitequark> ultratrash is *absurdly* slow
<whitequark> want to blink a led? wait like ten fucking minutes on the overclocked build machine we have
<daveshah> I dare say that this is an advantage to sticking with a 90's backend
<whitequark> like, i literally bought a gaming motherboard and overclocked a cpu to 5ghz just to get fpga synthesis/par times to half a hour
<daveshah> It's running on hardware 10-100x more capable than it was really designed for
<whitequark> and our designs arent even that complex
<whitequark> the only real complaint i have about diamond is the programmer
<whitequark> the ftd2xx piece of shit
<whitequark> that cant even unbind the kernel driver
<daveshah> yup
<whitequark> and it is a) very slow b) very crashy
<daveshah> I've had all kinds of udev shit to get it to work
<whitequark> i just blacklisted ftdi_sio
<whitequark> [finger pointing at temple] dont need to unbind kernel driver if there isnt any
<daveshah> lol
<daveshah> it gets particularly icky if you want to keep ftdi_sio bound to the second interface of the versa
<daveshah> for comms
<whitequark> yes
<whitequark> i anticipate that
<whitequark> that sounds disgusting
<whitequark> can i convert a .bit to .svf with free tools yet?
<daveshah> yes
<whitequark> oh
<whitequark> how?
<daveshah> it's a bit hacky
<daveshah> I will make this part of ecppack in the future
<whitequark> >ULX3S WiFi interface
<whitequark> the... what?
<daveshah> yes seriously
<daveshah> the ULX3S can be programmed via an ESP32 over WiFi
<daveshah> it's super dodgy
<daveshah> but they wanted a demo with trellis
<whitequark> ok that board seems kind of neat
<daveshah> the only other programming interface on that board is a new shitty ftdi (not x232h) that you have to bitbang jtag
<whitequark> it *sounds* ....
<whitequark> yes
<daveshah> with a patched openocd
<q3k> but it's surprisingly fast
<whitequark> that is precisely what it sounds to me
<whitequark> academic thingy with some kinda shitty chips on it
<q3k> although yeah, support for it sucks
<daveshah> there are also three versions circulating with different pin maps
<daveshah> so you can't even have one constraint file for your design
<whitequark> wtf
<q3k> don't care for different pinmaps, it would be nice if the version of the pinmap was silkscreened on the PCB (I don't think it is)
<whitequark> uhhhhh
<whitequark> does that point at capacitors for probing voltages?
<whitequark> that is
<whitequark> very ghetto
<whitequark> one slip of the probe and you shorted 2V5 to 3V3. good job
<whitequark> ok i'm just going to close that page now and never look at it again
<q3k> they're pretty far away
<q3k> what would fix this?
<q3k> same issue with test pads
<daveshah> it's the best non-Lattice ecp5 board out there atm
<q3k> unless you place test pads somewhat far away from eachother
<whitequark> q3k: test pads with holes
<whitequark> so the probe centers
<q3k> but the point of these testpoints is also, AFAIU, measure voltage as close to the BGA as possible
<whitequark> i mean, i am kind of a perfectionist safety wise, i guess
<q3k> IIRC the 'D' test strips are the official point to measure voltage/current
<whitequark> ah ok
WilhelmVonWeiner has joined ##openfpga
<q3k> also the caps are fairly far away. for scale: https://photos.app.goo.gl/Q9y5LnrXh3ESTPwPA
<q3k> i can't imagine how you would short 3v3 and 2v5 together
<whitequark> mhm
<whitequark> ok, fair
<q3k> i need to finish testing my unit at some point
<q3k> haven't actually tried anything apart from the stock bitstreams
<daveshah> The ULX3S was quite useful for the Linux demo as it had nice simple SDRAM
<daveshah> Overall, I'm most excited about the upcoming mystorm BlackEdge ECP5 board
<daveshah> That should have a nice feature set (but no SERDES stuff, it's more of an educational type board)
<q3k> bwhat's that?
<q3k> *what's that
<daveshah> It's the ECP5 successor to the BlackIce
<q3k> ah
<daveshah> Going to have 12k/45k ECP5, 128Mbit/1Gbit DDR2, depending on model
<daveshah> HDMI in/out, USB with ULPI PHY, MIPI in/out on both
<q3k> i'm thinking of making a simple serdes board for experimenting
<q3k> bring everything out on SATA (or SFF or PCIe edge)
<q3k> and have daughterboards for actual real interfaces
<daveshah> That sounds like a nice idea
<q3k> and maybe some SDRAM and that's it
<whitequark> ok, using openocd is MUCH nicer
<daveshah> What is the timeframe for the board? If it is 2019, go for DDR2/3
<whitequark> q3k: can you slap an fx3 on it so i can do glasgow revE bringup? :P
<q3k> likely 2019
<daveshah> support in trellis should be done by then
<daveshah> I mean all the primitives are fuzzed
<daveshah> It's just getting them & the routing and packing into nextpnr
<q3k> whitequark: i was going to say no and then I chuckled at 'slap' so I guess okay then
<whitequark> cool thanks
<q3k> glasgow has fx2, right?
<whitequark> yes
<q3k> fx3 is parallel lvds?
<daveshah> I'd like to see loads of regular IO on 1.27mm headers
<daveshah> if you have room
<q3k> yeah, just won't bother to keep length on the traces probably
<whitequark> q3k: just a parallel bus
<whitequark> 32 bit plus control
<q3k> doable
<q3k> anyway, don't hold your breath
<q3k> got a lot of other things on my backlog now :/
<whitequark> if you really dont want 32 bit i'll be fine with 16 bit or even 8
<whitequark> sure
<whitequark> just it's that i'll need to bring up revE at some point
<whitequark> and it's either this or a versa plugin specifically for bringup
<whitequark> which is kind of meh
<daveshah> The Versa is IO limited too
<whitequark> yeah it doesnt have enough io for full fx3
<q3k> yeah, it barely has 32
<q3k> iirc
<daveshah> The ECP5 breakout board might be better
<whitequark> versa has rgmii so i guess i can debug that at least
<whitequark> but im more interested in fx3
<daveshah> yeah
<whitequark> since fx3 is the bmc
<whitequark> essentially
<whitequark> it keeps the board alive if the fpga locks up or whateevr
<whitequark> thats actually its primary function, alongside with vreg stuff and such
<whitequark> being able to do usb is a nice addn
<daveshah> With the GPIF, you could do super-fast slave parallel reconfig, at least in theory
<whitequark> i thought about using gpif to reconfig with fx2 glasgow
<whitequark> but it bitbangs at 6 mh
<whitequark> mhz
<whitequark> with my optimized 8051 assembly lol
<whitequark> thats well fast enough
<whitequark> daveshah: the idea was, use the TI PHY that can be reconfigured to do WOL on any sequence
<whitequark> connect WOL to BMC
<whitequark> have BMC reload a known good bitstream that just forwards RGMII to parallel interface
<whitequark> use that to run smoltcp and handle management packets
<whitequark> so if the board dies? you kick it via the WoL feature
<whitequark> it reboots, loads that bitstream, and answers to management packets for sure
<daveshah> sounds like a good plan
<whitequark> should probably even add a bootloader to FX3 thats unflashable via Ethernet
<whitequark> for 100% unbrickability
<daveshah> serial using wol lol?
<whitequark> serial?
<whitequark> no i mean
<whitequark> split the fx3 firmware into two parts, bootloader that can only load/flash the rest of fx3 firmware (or continue booting)
<daveshah> sure
<whitequark> and the part upgradable via ethernet
<whitequark> or do you mean embed serial in wol packet?
<whitequark> yeah that's the idea
<daveshah> something along those lines
<whitequark> make it so that a right UDP packet even can kick it
<whitequark> the PHY can do it
<whitequark> it doesnt care where exactly the sequence lives
<daveshah> would you support fpga reconfig over ethernet?
<whitequark> definitely
<daveshah> this would need ~2MB of RAM somewhere
<whitequark> why?
<daveshah> that they FX3 could access (or whatever is configuring the fpga)
<whitequark> i'm just not going to buffer it
<whitequark> fx2 doesnt have 128k of ram either
<daveshah> I'm not 100% sure an ECP5 can keep running while being reconfigured
<whitequark> ohhh.
<whitequark> th-that's
<whitequark> thanks
<daveshah> It's a bit confusing because other Lattice parts with built in flash can
<whitequark> yeeah that will need to be verified
<daveshah> and they use the same naming for feature
<whitequark> wait, ecp5 has built in flash?
<daveshah> no
<whitequark> ah
<daveshah> as in they have documents referring to parts with and without flash without clearly explaining what needs internal flash
<daveshah> pretty sure once you start configuring an ecp5 you shift stuff into the config memory and break your running design
<daveshah> I know they have TransFR, but that's an awful hack that uses boundary scan to keep IO constant during reconfig
<whitequark> does... SPI RAM exist?
<daveshah> yes
<whitequark> wait really
<daveshah> but SPI RAM big enough to hold an ECP5 bitstream is quite rare
<daveshah> it has to be PSRAM
<daveshah> but the ECP5 should even be able to boot off it
<Prf_Jakob> Heh, add another FPGA that translates between SPI and HyperRAM? :p
<whitequark> what the hell
<daveshah> 64Mbit of QSPI PSRAM
<whitequark> how come i've n ever heard of this before?
<daveshah> it's pretty new
<whitequark> oh
<daveshah> there have been 128kByte parts forever
<daveshah> but the large ones are new
<daveshah> I don't even think the bigger distributors have the larger PSRAM ones yet
<whitequark> huh, it's actually compatible with 25C series
<daveshah> yeap
<whitequark> niiice
<daveshah> I understand it was made popular by the ESP32 which supports it
<whitequark> oh
<whitequark> huh
<daveshah> a few more MCUs are starting to support it now for IoT reasons
<whitequark> yeah that's perfect for revE
<whitequark> I could hang it off the same port as NVM
<daveshah> yeah
<whitequark> thanks, this will help a lot
<whitequark> daveshah: can you explain rx_pclk and rxi_clk?
<whitequark> i understand that...
<whitequark> rx_pclk is the recovered clock, or in other words, the clock at which words are shifted into FIFO
<daveshah> yes
<whitequark> and rxi_clk is the clock at which words are shifted out of FIFO
<daveshah> not so sure about that
<daveshah> I think this is where the clock divider comes in
<whitequark> hm
<daveshah> for 8-bit/10-bit output mode, they are the same
<whitequark> so, you loop back rx_pclk to rxi_clk
<daveshah> yes
<daveshah> it seems this also works in 16-bit mode
<daveshah> I'm not sure when you don't loop back then
<daveshah> looping back does mean there is the "global network" in the middle, anyway
<daveshah> this way your output data has the same clock phase as your fabric
<whitequark> hm, ok
<whitequark> so right now i have this serdes config: https://hastebin.com/cipurilej.py
<whitequark> it shows LOS and LOL as high
<daveshah> link doesn't work?
<whitequark> well i'd be surprised if it worked
<whitequark> given that i have configured nothing else
<daveshah> link as in URL
<whitequark> oh
<daveshah> is this with nextpnr or diamond?
<whitequark> diamond
<daveshah> just checking - nextpnr doesn't support loc or chan yet (but will soon), you have to constrain with bel
<daveshah> I think it needs way more parameters set than that unfortunately
<whitequark> yep
<daveshah> the PLLs need to be powered on and configured
<daveshah> the low and high marks for the fifos need to be set
<daveshah> termination and equalisation quite possibly
<whitequark> first i'm going to try and get it to get LOS down
<whitequark> since i understand this involves the least amount of parameters
<daveshah> definitely the first thing is to make sure the PLLs are running
<whitequark> hmm okay
<daveshah> check that the output clock is toggling
<whitequark> let me take a look at pclk
<whitequark> nnnope
<whitequark> nothing on pclk
<daveshah> not suprising given the PLLs aren't even turned on
<whitequark> "oops"
<daveshah> unfortunately, configuring the PLLs without diamond is ~impossible
<daveshah> in the end a lookup table approach will probably be needed
<daveshah> I think the "D_CMUSET" parameters all affect it
<whitequark> so, here's what i don't understand
<whitequark> txpll doesn't affect rx part of the serdes, does it?
<whitequark> not according to the block diagram
<whitequark> i'm currently only trying to bring up rx serdes
<daveshah> ah, I see
<whitequark> so... i need to configure the CDR, right?
<daveshah> yes
<whitequark> do you know which parameters affect CDR?
<whitequark> wait
<whitequark> nevermind, I had a silly bug, but still no rx pclk
<daveshah> I think all the DCO ones, for a start
<daveshah> anything with CALIB in too, I think
<daveshah> there are also some parameters related to LOS detection
<daveshah> holy f**k
<daveshah> while searching for dcu stuff I found the lost ecp4 datasheet
<daveshah> it was going to be up to 241k LCs
<daveshah> i waaaaaant one
<whitequark> huh
<whitequark> I have signal
<daveshah> interesting
<whitequark> by uh.... copying the parameters from your example until LOS went down :^)
<daveshah> awesome
<whitequark> rx_rlos_ceq fields in the technote are all "TBD" ol
<whitequark> lol
<whitequark> and level too
<whitequark> ok so first off i need to enable los detector
<daveshah> lattice like their TBDs
<whitequark> or it wont work
<daveshah> sure
<whitequark> probably configure termination too, would be stupid to expect it to work otherwise
<whitequark> let me look up the right values for pcie...
<whitequark> what is "CMFB"?
<daveshah> idk
<daveshah> it doesn't even seem to be an option in diamond
<whitequark> RXIN_CM
<whitequark> is the option
<whitequark> oh
<whitequark> but your code has CMFB selected.
<daveshah> thats what the wizard generated
<daveshah> but it's not an option in the wizard
<whitequark> ok
<daveshah> so I guess Lattice fix it at cmfb
<whitequark> hmm, rxterm_cm...
<daveshah> I doubt it matters much with AC coupling
<whitequark> yeah
<daveshah> seems it defaults to 11
<whitequark> um
<whitequark> lattice set RTERM_RX to a reserved value
<whitequark> 10110
<whitequark> because of course it did
<whitequark> I need 50 ohm pretty sure
<daveshah> that is 50 ohm, the wizard default
<whitequark> 01011 = 60
<whitequark> 10011 = 50
<whitequark> 11001 = 46
<whitequark> is what the datasheet says
<daveshah> yeah, what I mean is setting 50 ohm in the wizard sets rterm_rx to 22
<whitequark> yes
<daveshah> which seems to be almost 50 ohm based on the datasheet
<whitequark> i understood
<whitequark> why that value?..
<whitequark> is it "TBD" again
<daveshah> probably
<daveshah> lol
<whitequark> also, it rejects 0b values there
<whitequark> only takes 0d
<whitequark> very user friendly
<whitequark> thanks for making me calculate.
<daveshah> heh, nextpnr allows any base for all the dcu parameters
<daveshah> I did that because I was trying to be nice and compatible with lattice
<daveshah> seems I over-tried
<whitequark> does it let me specify them as proper numbers?
<whitequark> or just these weird ass string things?
<whitequark> why the fuck does it take strings anyway?
<daveshah> atm just weird ass strings
<whitequark> did someone like javascript too much?
<daveshah> can add proper numbers though
<whitequark> please do
<whitequark> i got really confused because diamond just *ignores* numbers there
<daveshah> Lattice tend to prefer weird ass strings
<whitequark> pretends the parameter is not even passed
<daveshah> except for some settings which are numbers
<daveshah> like LUT init
<daveshah> got to go afk now for a german lecture at uni I'm afraid
<whitequark> sure
<daveshah> be back in a couple of hours
rk[ghost] has joined ##openfpga
<whitequark> daveshah: AHAHAHA
<whitequark> so
<whitequark> nothing worked because
<whitequark> there is an undocumented power down pin
<whitequark> p_D_IB_PWDNB
<whitequark> I assume this means "input buffer power down"
<whitequark> YEP
Miyu has joined ##openfpga
<daveshah> oh
<daveshah> That explains things
<daveshah> lol
<whitequark> ok I have LOS working
<whitequark> it even tries to lock onto something
<whitequark> and fails badly
<gruetzkopf> okay, i want ECP4 too
<daveshah> Set up an eBay saved search lol
<daveshah> I think they did ship a few samples
<gruetzkopf> i mean as a production part :P
<daveshah> Go buy the masks then
m4ssi has quit [Remote host closed the connection]
rk[ghost] has quit [Ping timeout: 268 seconds]
rk[ghost] has joined ##openfpga
<whitequark> daveshah: hm
<whitequark> I can't seem to get it to lock
<whitequark> using all the Clarity parameters
<whitequark> wonder if the fabric routing might not be good enough?..
<daveshah> Yes, could be
<daveshah> It locked fine for me with fabric though
<daveshah> Could just need tuning in some way
GuzTech has quit [Remote host closed the connection]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 252 seconds]
wbraun has quit [Quit: wbraun]
<mithro> Has anyone played with RAM4K initialization options on the ice40 before?
<SolraBizna> I'm "playing" with them now
<SolraBizna> or I will be if I ever fully wake up
<mithro> SolraBizna: Oh?
<mithro> SolraBizna: You willing to do some ice40 NVCM programming? :-P
* SolraBizna runs away screaming
<Bob_Dole> I thought nvcm on a small ice40 as a system-bringup chip would be good, to deal with limitations of the spi config memories. but that is a consideration for a later date.
<mithro> Bob_Dole: I'm pondering having something like TinyFPGA's TinyUSB bootloader as a failsafe thing in the NVCM for when you screw up the SPI configuration
<tinyfpga> mithro: that would be awesome
<tinyfpga> mithro: but I’m
<Bob_Dole> can you reprogram it after the nvcm is in place?
<mithro> Bob_Dole: I believe you get about 2-3 programs before it stops being programmable....
<tinyfpga> mithro: but I’m not sure that the FPGA will boot from SPI flash if the NVCM has been programmed
<mithro> tinyfpga: Working on that :-)
<Bob_Dole> that's what I meant, ^
<mithro> You /can/ program the SRAM using an external micro even after NVCM is set....
<SolraBizna> someone here was theorizing that it can no longer boot in SPI master mode, but it can still be booted in slave mode
<SolraBizna> nobody wanted to brick their iCE40 to test >_>
<mithro> SolraBizna: It 100% can be booted in slave mode
<SolraBizna> well, there ya go
<mithro> SolraBizna: Now I am just trying to confirm if SPI master mode can be made to work by using SB_WARMBOOT
<daveshah> mithro: the NVCM is one time programmable only
<daveshah> It is mtp in MachXO3 devices, this is a hack using bitstream compression afaik
<daveshah> The iCE40 is officially spi slave only after NVCM is programmed
<daveshah> No idea what warmboot would do though
mumptai has joined ##openfpga
<mithro> daveshah: The NVCM is actually multi-time programmable, but the chance of failure increases dramatically every attempt -- the problem is that after first program the ability to change a bit from 1 to 0 is not reliable
<daveshah> Ah, I see
kristianpaul has quit [Quit: Reconnecting]
<mithro> daveshah: The cell has like 4-5 bit flips possible apparently -- some cells maybe only 1 or 2....
kristianpaul has joined ##openfpga
<daveshah> Yes, I think there's a good reason lattice don't guarantee more than one program
<daveshah> The MachXO3 claim up to 9 but I'm fairly sure bitstream compression is involved in that
<daveshah> I do wonder if controlling programming voltage and temperature might get more cycles out of it
<daveshah> Don't know if this got posted here yet. But the ORConf videos are online now
<daveshah> mithro's on SymbiFlow: https://www.youtube.com/watch?v=CI1lpbt2Hz8
<daveshah> Clifford's on nextpnr: https://www.youtube.com/watch?v=XbwrOff59ck
<SolraBizna> I'm gonna have to watch that last one...
wbraun has joined ##openfpga
<mithro> daveshah: I couldn't find yours when I was tweeting
dingbat has quit [Quit: Connection closed for inactivity]
<daveshah> mithro: pretty sure it was one of the earlier ones they posted
<mithro> daveshah: Maybe I was just blind
<daveshah> I tweeted it yesterday anyway
<mithro> daveshah: I wonder how I missed that...
<mithro> Maybe I need more sleep...
<daveshah> Perhaps I tweeted a bit early for you (3pm uk time)
<mithro> Twitter is a pretty lossy format
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
SpaceCoaster has joined ##openfpga
dingbat has joined ##openfpga
<mithro> kc8apf: Have you seen CoreIR? -> https://github.com/rdaly525/coreir -- seems like something you might enjoy
<mithro> kc8apf: "An LLVM-style hardware compiler"
<kc8apf> neat
<kc8apf> similar in spirit to Gaffe
m_w has joined ##openfpga
mumptai has quit [Quit: Verlassend]
m4ssi has joined ##openfpga
futarisIRCcloud has joined ##openfpga
wbraun has quit [Quit: wbraun]
Bike has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
<q3k> anyone against me registering an Open FPGA assembly at 35c3? who coordinated that last year?
<q3k> and how many seats should we get?