<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>
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
<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
<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
<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?
<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