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