jjjaaaccckkk has joined ##openfpga
<jjjaaaccckkk> anyone have Mathias Lasser's full slide deck from his presentation at 34C3 about reverse engineering the xilinx series 7?
<jjjaaaccckkk> Or anyone know Mathias and can ask if he is open to sharing them?
solo1 has joined ##openfpga
QK_b00m3r is now known as OK_b00m3r
OmniMancer has joined ##openfpga
_whitelogger has joined ##openfpga
edmoore has quit [Ping timeout: 245 seconds]
daveshah has quit [Ping timeout: 245 seconds]
_florent_ has quit [Ping timeout: 245 seconds]
bubble_buster has quit [Ping timeout: 245 seconds]
daveshah has joined ##openfpga
bubble_buster has joined ##openfpga
grantsmith has quit [Ping timeout: 245 seconds]
edmoore has joined ##openfpga
grantsmith has joined ##openfpga
_florent_ has joined ##openfpga
_whitelogger has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Bike has quit [Quit: Lost terminal]
emeb_mac has quit [Quit: Leaving.]
* sensille tries to install yosys/nextpnr/trellis
_whitelogger has joined ##openfpga
* sensille has compiled an example bitstream
Bob_Dole has joined ##openfpga
Asu has joined ##openfpga
<sensille> hm. nextpnr doesn't have an option for 12k. if i use 25k, openocd complains about the device id (i guess)
<sensille> READ = 0x21111043 WANT = 0x41111043
<sensille> i can just change that in the svg file, but then it complians about the last line in the svg READ = 0xca00000 WANT = 0x0000100
<daveshah> You need to add --idcode 0x21111043 to ecppack
<daveshah> because the 12k is a fake device
<sensille> but it saves a few $$ :)
<sensille> ok, so the tdo check error at the end has a different source
<daveshah> No it has the same source
<daveshah> It is because the idcode in the bitstream is also wrong and is rejected by the chip
<sensille> but i regenerated it and get the same error
<daveshah> With --idcode?
<sensille> let me make clean all again, to make sure
<sensille> yes, pretty sure
<sensille> the new svf passes the initial check, but fails at the end. it also doesn't program anything
<sensille> anyway, will hunt this later
<daveshah> 0xca00000 means an ID error so something must be still wrong on that front
<rombik_su> So, with yosys/nextpnr/trellis and iCE40/ECP5 I can use any JTAG adapter supported by OpenOCD?
<daveshah> For ECP5, yes
<daveshah> iCE40 uses SPI, not JTAG. The icestorm iceprog tool is for FTDI interfaces - but there are some other projects for different interfaces too
<rombik_su> Oh, right, forgot about SPI. Thanks!
Asu has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
<ZirconiumX> My design takes up 10k ECP5 LUTs for the move generator alone. Christ.
<ZirconiumX> (I'm writing a chess program for FPGA)
<omnitechnomancer> troubling
<ZirconiumX> -nowidelut halves that number (which is pretty spectacular), but then delay goes up
<omnitechnomancer> more pipelining?
<ZirconiumX> The whole thing is very intentionally fully-combinational logic
<ZirconiumX> (it's partly a combinational-logic benchmark)
<omnitechnomancer> Well there's your problem :P
<ZirconiumX> Sure, but I'm reasonably confident that I can reduce the logic area needed here.
genii has joined ##openfpga
<ZirconiumX> https://pastebin.com/9TMr0pUM <-- it never ceases to amaze me how well ECP5 keeps up with the Cyclone V.
<omnitechnomancer> What is a LUT6 ECP5?
<ZirconiumX> I have two versions of an algorithm on the critical chain, one optimised for LUT4 (i.e. ECP5) and one optimised for LUT6 (i.e. Cyclone V)
<omnitechnomancer> ah okay
<ZirconiumX> The ECP5 can produce LUT6s through internal muxes though
<omnitechnomancer> yes
<omnitechnomancer> I suspect that approach is likely better in many circumstances since it reduces wasted resources
<ZirconiumX> Well, a Cyclone V ALM has overprovisioned inputs (8 instead of 6) and outputs (2 combinational, 4 registered), so you can fit two functions in an ALM
<omnitechnomancer> indeed
<ZirconiumX> It does surprise me that on ECP5 the LUT6 optimised version is slightly faster
<ZirconiumX> On the other hand in -nowidelut mode the LUT4 version is faster
<omnitechnomancer> interesting
<omnitechnomancer> I kinda wonder how the weird 4/5 hybrid anlogic arch stacks up
<ZirconiumX> I can send you the nMigen (or the Verilog) if you want
<omnitechnomancer> perhaps tomorrow, sleep must occur
<omnitechnomancer> also still need to finish the nmigen vendor support for it
<ZirconiumX> I'm not using a platform for this at present
<ZirconiumX> So it doesn't need it
<omnitechnomancer> hmmk
Bike has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
genii has quit [Quit: Hockey and beer time, not necessarily in that order..]
lutsabound has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
GenTooMan has quit [Ping timeout: 260 seconds]
Bob_Dole has quit [Ping timeout: 260 seconds]
<sensille> daveshah: i can't find another instance of the wrong device id. is the 0xca00000 the device status register?
<daveshah> the device status register value, yes
<daveshah> what ecppack command are you running to get the SVF file?
<sensille> ecppack --svf-rowsize 100000 --svf morse.svf --idcode 0x21111043 morse_out.config morse.bit
<sensille> 0x21111043 is also the id code lattice diamond shows me
<sensille> so the device status reports id_verify error and preamble error
<sensille> i could try to program the .bit file with lattice programmer
<daveshah> Can you post the bitstream here? I can have a look at it
<sensille> will do. tried to program .bit with vendor tool, it says file is targetting LFE5U-25F
<daveshah> That is just the header
<daveshah> the text header - only Diamond cares about that
<daveshah> the chip doesn't
<daveshah> So the IDCODE command in that is 0x21111043 which is fine
<daveshah> I don't know why the chip is rejecting it
<sensille> can i also program .bit files, or only .svf?
<daveshah> With OpenOCD, only .svf
<daveshah> Can you post the svf file too
<daveshah> IDCODE in that looks fine too
<daveshah> You should still be able to program the bit in Diamond programmer even if it complains about device ID (if not, change the "25F" text to "12F" in a hex editor)
<daveshah> that would be a good test to work out if it is the bitstream itself or not
<sensille> if i got that right the device complains about the id_verify command. can i send just that?
<daveshah> You could strip out all of the bitstream after the end of the device ID (0x21 0x11 0x10 0x43, with 0x43 being the last byte)
<daveshah> if you want to use that with openocd you can convert it to an svf with https://github.com/SymbiFlow/prjtrellis/blob/master/tools/bit_to_svf.py
<sensille> i can also just use a different tool, openocd was just the only one i've found. seen mentioned iceprog earlier today
<daveshah> iceprog doesn't do ECP5 jtag
<sensille> lattice: "Failed to Program DONE bit"
<daveshah> ujprog should work though https://github.com/f32c/tools/tree/master/ujprog
<daveshah> > lattice: "Failed to Program DONE bit"
<daveshah> is expected given it isn't a full bitstream
<daveshah> but means the ID check probably passed on its own
<sensille> i'm still at the previous test, changing 25F to 12F in the .bit file, sorry
<daveshah> ah, that seems odd
<daveshah> Diamond bitstreams work fine?
<sensille> yes
<daveshah> Out of curiosity, can you post one of the working Diamond bitstreams so I can compare it to one that Trellis generated
<sensille> i have an error on the board which seems to pull DONE always down, but that isn't a problem with the lattice tool
<sensille> ok, strange. after programming a good file with diamond the morse bitstream works with openocd
<sensille> also works directly after power up
<sensille> so. power up. program the wrong stream, gets rejected upfront. program the correct stream, fails at the end
<sensille> program the correct one right away after power up, works
<sensille> seems like diamond was able to handle that situation, though
<daveshah> I think the problem might be a missing REFRESH command on the JTAG
<daveshah> The odd thing is, I think that the SVF commands trellis sends are exactly the same as an SVF file generated by Diamond deployment tool
<daveshah> but Diamond programmer may well do a bit more magic
<sensille> anyway, good the confusion is cleared up
show1 has quit [Quit: WeeChat 2.6]
<whitequark> azonenberg: how would you deal with PCIe EIDLE when buffering it?
<whitequark> some sort of comparator on the input driving the buffer's enable signal?
GenTooMan has joined ##openfpga
X-Scale` has joined ##openfpga
Bob_Dole has joined ##openfpga
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 260 seconds]
<sensille> how do i use the PLLs in the ecp5?
<daveshah> The ecppll tool can generate a PLL moduke
<daveshah> *module
<sensille> works :)
<gruetzkopf> where do you want to buffer PCIe
<gruetzkopf> and how many lanes
<tnt> and why not use one of the buffers that handles that internally :)
<gruetzkopf> that was where i was going with my question
<whitequark> i want a fanout data buffer
<whitequark> they don't make ICs for that
<whitequark> i mean... i'm pretty sure they don't. that would be incredibly special purpose.
<tnt> Would a differential resistive splitter feeding two re-driver work ?
<whitequark> i don't know. maybe. maybe not. that's why i decided to use https://www.diodes.com/assets/Datasheets/PI6C5946002.pdf, which will definitely work
<whitequark> (other than for EIDLE)
<whitequark> tnt: in your case a redriver would still somehow need to detect EIDLE
<whitequark> do these redrivers exist?
<tnt> http://www.ti.com/interface/pcie-sas-sata/products.html#p1694=Redriver&p1389=PCI%20and%20PCIe;PCIe;PCIe1;PCIe2;PCIe3;PCIe4
<gruetzkopf> DS80PCI402 for 4-lane gen3
<gruetzkopf> it's like 0.5$ more expensiver than the gen2 version
<whitequark> hm
<gruetzkopf> (they claim 10m of cable - _really_ need to try that
<whitequark> I think what I want is https://www.ti.com/lit/ds/symlink/sn75lvpe801.pdf
<whitequark> basically
<whitequark> possibly with a separate clock buffer
GenTooMan has quit [Quit: Leaving]
<whitequark> I'm not sure how to make a differential splitter though
<tnt> That's USB3 but same difference
<whitequark> hrm
<whitequark> that's not enough
<whitequark> how do I choose component values? how do I lay it out?
<tnt> 1/3 of the single ended impedance
<whitequark> do you have some appnote describing how to do this?
<whitequark> I need to understand it before I use it
<adamgreig> is it just two single-ended wilkinson splitters?
<adamgreig> or just resistive, sure.. but how do you maintain differential impedance?
<tnt> adamgreig: yeah, I had another source I can't immediately find that said that basically that's what it was. And when I actually ran the numbers it worked. (i.e. impedance seens at each port matched, both single-ended and differential)
<adamgreig> totally makes sense that you'd end up with the power split correctly but i guess maintaining differential impedance isn't obvious to me
<adamgreig> whitequark: literature seems to have differential power splitters/dividers as a thing, though, for microwave frequencies, which this pretty well is
<adamgreig> dunno how much you want to design rf structures into your pcb though..
<whitequark> hrm
<whitequark> i mean it's already an rf structure (microstrip)
<adamgreig> i wonder if a balanced-to-balanced power divider is the same as a differential splitter
<adamgreig> seems a bit much
<tnt> Just redid the math and it works. If you see the received as a resistor of Zd between +/-, then each branch is basically 3 resistor in series (2 * R + Zd). Impedance seen by a single branch is 2 branches in //, so (R + Zd/2) and seen by the transceiver is (R + (R + Zd/2) + R) = 3R + Zd/2. So if R = Zd / 6, then the transmitter sees Zd.
<adamgreig> tnt: and you just use a lumped element model and ignore the geometry in the splitter?
<tnt> adamgreig: That's where the rubber meets the road I guess ...
<adamgreig> got a photo of what the pcb ended up looking like? just curious about the geometry
<adamgreig> none of these rf balanced dividers really start or end with microstrip differential pair...
<whitequark> ^
<tnt> adamgreig: nope, no pcb, never actually implemented it. That's why earlier above I asked if you'd think a divider followed by redriver would work ... I couldn't see a reason it wouldn't but ...
<adamgreig> i think the schematic is fine but i just wonder how much impedance mismatch you'd get when you do it in copper
<whitequark> ouch
<whitequark> no, i don't trust this thing
<whitequark> i might make one because i'll have a TDR soon, just to see how bad it gets
<whitequark> but i definitely don't trust it
<adamgreig> yes it would be fun to measure at least
<adamgreig> you could briefly convert to single ended, do a normal power splitter, than go back to differential :p
<whitequark> yeah see this is why i used a 1:2 fanout buffer IC
<adamgreig> yes that really seems the solution here
<rombik_su> whitequark: are you getting actual TDR head for the Tek or it'll be some fast-rising standalone pulse generator?
mumptai has joined ##openfpga
<whitequark> actual TDR head
<whitequark> they're around $500 on ebay, so not too crazy
<whitequark> I also wonder if perhaps all of the modules for Tek have a TDR inside
<whitequark> and it's just fused off in EEPROM
<whitequark> they certianly have the TDR *LED*, looking blind into an aluminium front plate
<whitequark> (I opened up one of the modules, which came damaged from the seller, to see if I can fix the buttons, and discovered that)
emeb_mac has joined ##openfpga
<rombik_su> SD-24 (TDR) and SD-26 (just sampling) should be almost identical. SD-26 have an unpopulated cavity in RF part: http://w140.com/tekwiki/wiki/File:SD-26.JPG http://w140.com/tekwiki/wiki/File:SD24_1.jpg
<rombik_su> whitequark: ^
<whitequark> oh I see, so *that's* the difference
<whitequark> did they design the TDR head first?
<rombik_su> Maybe; as noted somewhere in the scope user manual, sampling-only heads get used only in very specific custom measurement applications
<whitequark> ahh
<azonenberg> whitequark: good question. that could work
<whitequark> what of the above?
<ZirconiumX> Yet again bugpoint comes to the rescue (thank you whitequark)
<whitequark> :D
<ZirconiumX> ABC9 broke again
<whitequark> it's not even very good, I just wrote it while frustrated about flowmap
<whitequark> there are tons of things it could do better
<ZirconiumX> I'll admit it's been running for...about eight hours now?
<whitequark> are you using it on the entire synth flow?
<ZirconiumX> I do that as a first pass, then break up the synth flow to the bits that matter, run all but the breaking command and let bugpoint chew on it a bit more
<whitequark> yeah that's one thing I was thinking it should do better
<whitequark> LLVM's bugpoint first bisects the passes
<whitequark> or rather reduces
<whitequark> would need some infra in yosys but it's doable
<ZirconiumX> The first pass went from 28,761 lines of RTLIL to 5,598 lines of RTLIL
<ZirconiumX> And so far the second pass is at ~2850 lines (still running)
<ZirconiumX> I feel like it should also be somewhat `clean`-aware. If clean thinks a cell if unused, then it might as well just prune it
<ZirconiumX> Anyway, it does a pretty good job as-is
<whitequark> uh, it is clean-aware
<whitequark> see `help bugpoint`
<ZirconiumX> I'm calling it with -clean here and there are like 32 cells or so that clean is always removing
<whitequark> try -fast
<ZirconiumX> Next time, probably.
<ZirconiumX> As a side note, I've been writing a chess program in nMigen, and honestly I feel like Python really shines here
<ZirconiumX> Even if it only runs at 50MHz on an ECP5.
<whitequark> nice
<ZirconiumX> Mostly nextpnr seems to have issues routing it to be fast enough
<ZirconiumX> It's like 18.7ns critical chain of which 2.7ns is logic and 16ns is routing
<whitequark> interesting
<whitequark> seems like a good nextpnr stress test?
<whitequark> what about vendor tools? that's one switch away in nmigen
<ZirconiumX> Quite possibly
<ZirconiumX> I don't have the vendor tools downloaded
<ZirconiumX> Plus it's currently "out of context"
<daveshah> ECP5 does generally have more routing than logic delay
<ZirconiumX> As much as I'd like to dream for a chip with >1,500 GPIOs, I doubt it'll happen
<daveshah> This is partly because differences in LUT input delays count as routing and also because logic is faster than routing
<daveshah> What does the histogram look like?
<daveshah> this should more or less show whether it is one bad path or not
* ZirconiumX reruns nextpnr
<whitequark> why do you need 1500 IO?
<whitequark> I mean
<whitequark> Xilinx has FPGAs with like 3k IO
<ZirconiumX> 256-input, 1024-output combinational logic move generator.
<whitequark> that seems very cursed
<ZirconiumX> Yes, but when you get about 1 billion chess positions per second out of it, it's worth it
<daveshah> You can just put shift registers on the inputs and outputs
<ZirconiumX> I do
<daveshah> Then you should only need 5 IO or whatever
<whitequark> connect the shift registers to the SERDES so you can run it at 50 MHz anyways
<ZirconiumX> https://pastebin.com/QJpDgw8Q <-- nextpnr output
<whitequark> ok, it's not fast enough, but 10 MHz is probably sort of doable
<whitequark> incredibly cursed tho
<ZirconiumX> Pipelining is not very helpful here as such
<daveshah> So, doesn't really look like there is one rotten path or anything
<ZirconiumX> I might vaguely be able to do it, but it would still look like a 256-input, 1024-output logic function.
<ZirconiumX> I should point out for the record that these were the smallest representations I could think of
<tnt> Does anyone kno what PATh symplify searches for .hex files in Radiant ?!?
<ZirconiumX> Also it's less than 1024-output, but still > 800 by my math
Laksen has joined ##openfpga
_franck_ has joined ##openfpga
rombik_su has quit [Quit: Leaving]
Jybz has quit [Quit: Konversation terminated!]
Asu has quit [Quit: Konversation terminated!]
Laksen has quit [Quit: Leaving]
show1 has joined ##openfpga
mumptai has quit [Quit: Verlassend]
jjjaaaccckkk has quit [Ping timeout: 240 seconds]
GenTooMan has joined ##openfpga