<kc8apf>
xc7-tool will dump all the packets in a bitstream. Need to port over configuration state machine next.
noobineer has joined ##openfpga
<rqou>
heh, i just discovered the best bug in xc2par
<rqou>
`assign pin = 1;` causes a panic
<rqou>
"the most trivial design possible"
digshadow has quit [Ping timeout: 245 seconds]
m_w has quit [Quit: Leaving]
steakpizza has quit [Remote host closed the connection]
esudyin has quit [Quit: -a- IRC for Android 2.1.40]
ZipCPU has quit [Read error: Connection reset by peer]
ZipCPU has joined ##openfpga
<sorear>
Run afl on it? :p
<rqou>
probably not directly effective
noobineer has quit [Ping timeout: 256 seconds]
<rqou>
should be easier to directly fuzz the frontend graph data structure
digshadow has joined ##openfpga
<sorear>
Formal? :p :p :p
<rqou>
formal would be neat
<rqou>
not sure what properties would be desirable to prove though
<rqou>
maybe "does not hit asserts"
<rqou>
in any case, I don't think rust formal tooling is mature enough yet
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 244 seconds]
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
balrog has quit [Ping timeout: 244 seconds]
balrog has joined ##openfpga
ZipCPU has quit [Ping timeout: 256 seconds]
ZipCPU has joined ##openfpga
<rqou>
ping awygle
MrSynAckster has joined ##openfpga
<MrSynAckster>
Evening
<MrSynAckster>
How's the open FPGA community doing tonight?
<rqou>
working on a new project
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 268 seconds]
<MrSynAckster>
what's that?
<rqou>
not quite ready to be announced yet
<rqou>
but if you grep the logs, azonenberg "leaked" it :P
<awygle>
rqou: pong. What's up
<rqou>
do you know how icefuzz actually works? :P
<rqou>
how does it fuzz routing?
<awygle>
It makes a bunch of verilog, place and routes it, then looks at the routed output. If you want more details you should check out the code (glbcheck.py, fuzzconfig.py, extract.py, etc) or ask daveshah
<rqou>
yeah, well, the code is kinda a giant mess
<awygle>
Start from the makefile. It's actually not that bad.
<MrSynAckster>
icefuzz?
<MrSynAckster>
That public? I'd like to take a look.
<awygle>
It runs each of the "make_whatever.py" scripts, each of which generate a verilog file and a makefile to P&R it
<awygle>
rqou: after it makes all the glb files it uses icepack to reverse them and checks for equivalence, iirc
<awygle>
I think extract.py does most of the actual analysis
<awygle>
yup. So there you go.
<awygle>
Also if you're looking to start a new thing, I'd look at what daveshah has been doing in trellis, maybe. It's a lot cleaner.
mumptai has joined ##openfpga
<awygle>
rqou: any further questions? If not I'm going to bed
<rqou>
not really
<awygle>
cool. good luck! glad to see somebody looking at That Other Company. don't get sued.
<daveshah>
Sounds like fun :P
<MrSynAckster>
are the fpga vendors really that sue happy?
<MrSynAckster>
that would be sad if it's true
<daveshah>
MrSynAckster: not really, but we are going down a fairly untrodden path
<MrSynAckster>
I imagine that some of them might even be amenable to discussing where their legal "red line" is
<daveshah>
I think fpga companies tend to regard bitstream stuff as secret, so they'd almost certainly say no despite there being no law actually protecting the bitstream information
<awygle>
no one has been sued yet to my knowledge but I'd put money on Intel/Altera as the most likely to do so (except maybe Microsemi and they're like the least interesting target currently)
<azonenberg>
daveshah: yeah the only protection is the EULA really
<azonenberg>
I dont know how well anti-RE clauses like this would hold up in court
<azonenberg>
i.e. targeting the bitstream rather than the software itself
<awygle>
even the eula is interesting given the specific exemption in the dmca for interoperability
<daveshah>
azonenberg: from what I've heard normally if you don't decompile then you will be OK
<awygle>
never been tested to my knowledge
<daveshah>
I think decompilation is sort of the red line
<awygle>
anyway. bed. night all.
<azonenberg>
Binary RE is normally legal unless there is a clause in the agreement (which there basically always is) prohibiting it
<azonenberg>
So the gray area is, if it's legal to contractually prohibit binary RE
<azonenberg>
Can they contractually prohibit bitstream RE?
<azonenberg>
And afaik this has never been tested in court
<sorear>
The red line if you study the history is “when it becomes a revenue threat”
<daveshah>
Well, Diamond's EULA only prohibits decompilation/reverse translation and doesn't discuss RE in general, so that should be safe
<azonenberg>
sorear: Yes
<azonenberg>
That's always true in anything
<azonenberg>
You don't sue someone if the cost of the suit exceeds the revenue you'd lose by not suing
<azonenberg>
Which is why i targeted coolrunner
<azonenberg>
as a dead-end product line that used a free-as-in-beer compiler
<azonenberg>
there was essentially zero threat to xilinx's bottom line
<azonenberg>
Thus i judged the risk of a suit to be close to nil
<sorear>
Does dead-end apply to all cplds or something more specific to xc2?
<azonenberg>
xc2 specifically
<azonenberg>
xc2c*
<azonenberg>
its important to say that because xc2 is a generation that includes xc2s and xc2v
<azonenberg>
Which are LUT based devices that are direct ancestors of the modern FPGAs
<azonenberg>
xc2c was xilinx's last product term CPLD family
<azonenberg>
it was originally codenamed BladeRunner, hence the data files being in "xbr" under the ISE install dir
<azonenberg>
It was to be succeeded by BladeRunner-II, which would have been 130-90 nm and launched alongside spartan3
<azonenberg>
fabbed at UMC
<azonenberg>
that was presumably a larger capacity die shrink but similar architecture
<azonenberg>
There was also the StarFighter architecture which never launched
<sorear>
I thought bladerunner was the product term but fpga-like routing one
<azonenberg>
Thats what i thought
<azonenberg>
Recent data suggests bladerunner was the in-development codename for coolrunner-2
<azonenberg>
Based on patent filings, I conjecture that the fpga-routing-of-PLAs was to be starfighter
<azonenberg>
But other than knowing they looked at this architecture and that they had a chip named starfighter that was supposed to parallel coolrunner/bladerunner
<azonenberg>
i have no evidence to link the arch to the name
<azonenberg>
Anyway, from xilinx's perspective product term CPLDs are dead
<azonenberg>
there have been no updates since coolrunner-2, nothing is supported by vivado,
<azonenberg>
they havent made a nonvolatile device at all since spartan3an
<azonenberg>
So it seemed like an obviously-abandoned line that was safe to target
Lord_Nightmare2 has joined ##openfpga
<sorear>
Are there non product term cplds?
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
<azonenberg>
There are "CPLD" devices that are actually nonvolatile FPGAs
<azonenberg>
i.e. LUT based
<azonenberg>
So the edges are a bit gray
<azonenberg>
personally, i prefer the taxonomy that a CPLD is product term and an FPGA is lut
<azonenberg>
makes a lot more sense than internal vs external config rom
<sorear>
Ah
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 244 seconds]
<azonenberg>
awygle: BTW when i was doing my testing the other day
<azonenberg>
I had good results on channels A/B/C
<azonenberg>
D seemed a bit funny, i suspect a loose solder joint
<azonenberg>
but want to re-test
<azonenberg>
i also want to probe the attenuators in more detail to see if i can figure out what's up with them
<azonenberg>
I'm confident we don't have a crosstalk issue at this point but i want to make sure we dont have any more pinout issues etc
<azonenberg>
And i still want to know whats up with the attenuators
<eduardo__>
rqou: max-V is dead end. Max-10 is totally different architecture.
Lord_Nightmare2 has joined ##openfpga
mumptai has quit [Remote host closed the connection]
indy has quit [Ping timeout: 260 seconds]
<azonenberg>
eduardo__: i tried to talk him into targeting 10
Lord_Nightmare has quit [Ping timeout: 276 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
<rqou>
fine, you guys can go do 10
<rqou>
not everything has to be the biggest and fastest
<rqou>
afaict there is still a use for v
<azonenberg>
well you're more interested in RE than tool dev it seems
<rqou>
i'm working on tool dev too
<azonenberg>
So older parts may be better since there's gonna be more bitstreams for them in shipped hardware :p
<rqou>
but remember the stuff we discussed privately?
<azonenberg>
i mean for this sub-project
<rqou>
no, i intend for this to be a complete toolchain as well
<azonenberg>
ah ok
<rqou>
i originally thought it would be RE only but the part turned out more useful than that
Lord_Nightmare2 has joined ##openfpga
<pie_>
rqou, congrats on graduating btw
<rqou>
thanks, weeks late :P
<pie_>
oh how time flies
<pie_>
me and my creaky joints :p
Lord_Nightmare has quit [Ping timeout: 276 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
<eduardo__>
the thing is. Just imagine we would want to write a next generation open source PnR tool. Then it would be useful to understand all the different architectures which are out there. We do have a good understanding of ECP5, ICE40, XilinxS7.
<pie_>
PNR:TNG
<eduardo__>
But we do noit have any understanding of any Microsemi or Altera parts.
<eduardo__>
Understanding EOL Altera parts gives us nothing for designing the database architecture for the PnR.
<azonenberg>
Yeah thats why i was interested in max10
<azonenberg>
i'm entirely a xilinx shop now but it seemed like a better re target for that reason
<rqou>
this part isn't EOL
<azonenberg>
iirc some microsemi stuff has "versa-tiles" that can be either a lut or dff but not both?
<rqou>
and the architecture does seem to have similarities
<azonenberg>
i havent looked too much at those parts because i couldnt get their toolchain to run on linux
<azonenberg>
so i gave up and went back to xilinx :p
<azonenberg>
The two chips i had got decapped (A3P030)
<eduardo__>
I am in contact with an Altera shop in Russia. They are very much interested in Altera RE.
<eduardo__>
Altera is definitely no priority for us now.
<rqou>
O_o wtf happened to the gimp splash screen
<azonenberg>
eduardo__: do you have any updates on the 7 series work? i havent seen much updated publicly, the database files on the prjxray github havent been updated since january
<rqou>
gimp got a massive facelift
<eduardo__>
S7 is mostly on hold from our side for now
<eduardo__>
What is missing now is a working PnR for S7
Lord_Nightmare2 has joined ##openfpga
<eduardo__>
There is no point in doing more work on S7 until we have a working PnR
Lord_Nightmare has quit [Ping timeout: 248 seconds]
<azonenberg>
also when i hear 's7" i think spartan7
Lord_Nightmare2 is now known as Lord_Nightmare
<azonenberg>
not 7 series in general
<eduardo__>
rqou: its gimp 2.10 the biggest update in the last 10 years
<azonenberg>
i'd refer to 7 series in general as xc7
<eduardo__>
ok
<azonenberg>
eduardo__: anyway, what's the status on par?
<rqou>
anyways, I'm currently trying to manually program a Coolrunner-II and only the first row programs correctly
<rqou>
but i can't figure out why
<rqou>
what I'm doing _should_ match the svf
kuldeep has joined ##openfpga
<azonenberg>
addressing is gray coded, did you miss that?>
<azonenberg>
or the padding of the address?
<rqou>
i got that
<azonenberg>
transfer bits?
<rqou>
i don't see any padding?
<azonenberg>
its 12 bits but only 6 are meaningful iir
<azonenberg>
iirc*
<azonenberg>
check my code
<rqou>
crbit explicitly has the transfer bits already
<azonenberg>
it works
<rqou>
the svf only shifts 266 bits
<azonenberg>
yeah that sounds right
<rqou>
your code is too difficult to understand
<azonenberg>
actually wait a sec
<azonenberg>
ok yeah so i shift nshort bits, which is GetShiftRegisterWidth() = 260, plus 12, minus padding size which is 6
<azonenberg>
So 266
<azonenberg>
Did you include the 10ms delay between rows?
<azonenberg>
And difficult to understand? i barely even have any OO in there
<rqou>
yes
<azonenberg>
its just straight function calls
<rqou>
your functions jump around all over the file with index juggling everywhere
<rqou>
and so many implicit jtag state changes
<azonenberg>
There's no implicit state changes
<azonenberg>
it's all very explicit
<azonenberg>
But its a layered API
<azonenberg>
From my perspective 99% of the time you dont care about the jtag state machine at all
<rqou>
your functions magically know how to cycle through run-test/idle
<azonenberg>
you just want to shove stuff in IR or DR
<azonenberg>
And what happens under the hood doesnt matter
<azonenberg>
This is how layering works :p
<rqou>
except when you do care
<rqou>
e.g. the init pulse that requires a specific route through the DR states
<azonenberg>
Which init pulse?
<rqou>
after programming is finished, to reload the SRAM
<azonenberg>
In jtaghal you are always assumed to be in RTI except durign a SetIR() or ScanDR() call
<rqou>
also the 64a requiring cycling through exit2
<azonenberg>
If you see the comment in line 617
<azonenberg>
as far as i can see, the SVF does not agree with the programming spec
<azonenberg>
But i implemented the algorithm in the spec, which does work
<azonenberg>
Speaking more generally if you want to have layering violations it is possible to call the low level jtaghal functions to do EnterShift1IR() etc
<azonenberg>
But this is not recommended
<azonenberg>
And there's almost always a better way to do it
<rqou>
the svf also takes quite a few detours through the pause states but neither the spec nor your code does
<rqou>
i hope this isn't the problem
<azonenberg>
I dont know why the SVF does this but i implemented the algorithm in the spec which works
<rqou>
i implemented that and it doesn't work :P
<rqou>
trying to figure out why
<rqou>
i see the correct data coming out of DR while programming but when reading back only the first row got programmed
<rqou>
on a different topic: azonenberg: what do you think about awygle's comment that "this other fpga company" may be sue-happy?
<rqou>
i don't see any evidence for this?
<daveshah>
rqou: they complained to a uni who did bitstream re back around 03/04 iirc
<daveshah>
Not actual legal trouble, but they stopped that project
<rqou>
wtf?
<rqou>
but they also have extremely open documentation
<rqou>
including QUIP
<daveshah>
Can't find the link now, but it was posted a while back
<daveshah>
Things may have changed in the mean time anyway
<rqou>
i wonder how they would feel about "bypassing defeatures"
<rqou>
these parts appear to be very significantly software-defeatured
<azonenberg>
i would say that is probably the single most likely thing to get you sued
<azonenberg>
More so than even bitstream re
Bike_ is now known as Bike
MrSynAckster has quit [Ping timeout: 240 seconds]
<azonenberg>
Because it clearly and directly hurts their profits
<rqou>
but you end up being able to do that automatically if you do bitstream RE
<azonenberg>
and a script made to patch (say) a 7a100t bitstream to run on a 7a75t can be run by anyone
<rqou>
I'm not even sure patching is needed here
<azonenberg>
You just patch the idcode and either remove or recompute the CRC
<azonenberg>
in the case of a xilinx part
<azonenberg>
it's semi-widely known how to do it
<rqou>
i think you can directly cross-flash, but i don't have hardware to test right now
<azonenberg>
But nobody's released a tool
<azonenberg>
And i certainly wouldn't attempt it
<rqou>
but we've done it for ice40
<azonenberg>
they're not Big X or Big A
<rqou>
how about a flag `--oversize-please-sue-me` :P
<azonenberg>
basically once a capability reaches the "metasploit level" its a lot more likely to get noticed
<rqou>
like i said, i think you can already just directly cross-flash these parts
<rqou>
since as we discussed the other day they have the same idcode
<azonenberg>
oh yeah
m_t has quit [Quit: Leaving]
kuldeep has quit [Ping timeout: 260 seconds]
<daveshah>
rqou: note that for the iCE40, although we mention it when people ask nowhere on the icestorm docs do we actually explicitly refer to it
<daveshah>
That's how we stayed out of trouble, and probably how I'll approach it with the ecp5
<daveshah>
I'm not sure how much anyone actually cares about it, given how unlikely the customers they care about are likely to use such a feature
<rqou>
ecp5 is limited like this too?
<daveshah>
The 12k and 25k are the same die with a resource limit
<daveshah>
The SERDES is present on all parts, but I suspect may be borked on the non SERDES parts
<azonenberg>
or just not bonded out?
<daveshah>
It clearly is, if you look at the pinout file they provide
<azonenberg>
ah ok
<daveshah>
They actually still mention it in a way, and it looks like the pinout file is autogenerated
<daveshah>
I've heard SERDES tend to have yield issues, so it's not something I'd rely on
<daveshah>
The price difference isn't that much anyway
<rqou>
but that's still like a 1/2 defeature, right?
<rqou>
try like 1/6
<rqou>
:P
<rqou>
inb4 sue
<daveshah>
That's kind of interesting
<daveshah>
I've heard rumours of this for cyclone parts too
<daveshah>
Cyclone IV E I think, although can't remember details
<rqou>
it makes sense if you think about it
<rqou>
max v is 10 logic elements per tile
<azonenberg>
well the way i see it is, there is market demand for a low gate conut part
<azonenberg>
so they have to provide one
<rqou>
the smallest part is "40" logic elements
<azonenberg>
Think about the engineering and mask cost to make a new chip with only 4 tiles
<rqou>
but that's only 4 tiles
<azonenberg>
vs how much money they waste making a 24-tile part and only using 4 of them
<azonenberg>
wafer space is cheap
<azonenberg>
and a small CPLD probably has good yield
<rqou>
also think about how io-bound a 4 tile part would be
<azonenberg>
if, over the lifetime of the part, the NRE would exceed the wafer cost, you should fuse a bigger part
<rqou>
especially given that it still contains ~32 pins
kuldeep has joined ##openfpga
<rqou>
anyways, it wasn't quite done running when i last checked it this morning, but afaict you can use every LE site
<rqou>
which means no fusing
bitd has quit [Remote host closed the connection]
Bike has quit [Ping timeout: 260 seconds]
GenTooMan has joined ##openfpga
<rqou>
azonenberg: ok, my readback is definitely hosed somehow
<rqou>
so that's one problem
noobineer has joined ##openfpga
<kc8apf>
azonenberg: reading up on Device DNA. UG470 says up to 32 devices can have the same DNA (57-bit value) but FUSE_DNA (64-bit value) is always unique.
<kc8apf>
sounds like a serial number
mumptai has quit [Remote host closed the connection]
<rqou>
azonenberg: not sure if bug in my software still or not, but mis-programming the done/security row seems to cause interesting effects
<sorear>
aside, that is an impressively bad name for a feature
<gruetzkopf>
it's a programmable logic vendor, what did you expect
noobineer has quit [Ping timeout: 260 seconds]
<sorear>
a slightly more relevant acronym
<pie_>
rqou, are you going to get a rediculously overpaid job now? :D
<pie_>
get rich, retire, do cool shit
<lain>
speaking of device DNA in xilinx, I noticed there's a limit on the number of times Device DNA can be /read/ (does it become corrupt after that?)
<pie_>
lain, that sounds...wut
<lain>
it's in the datasheet
<pie_>
not that i dont believe you, i mean idk anything about fpga i just shitpost in here, you know
<lain>
hehe
<lain>
I mean, I know flash memory will wear out eventually from reads (or just from random electrons tunneling out of the floating gate)...
<pie_>
i....did not know that
<pie_>
unless you mean it just needs refresh
<lain>
pro tip: don't use SSDs for archival. they lose data on a relatively short timescale (years) when unpowered
<lain>
yeah it needs refresh
<pie_>
limited as in corruption or limited as in broken
<pie_>
ahhh
<lain>
well xilinx don't specify but I assume they mean corruption
<pie_>
hm thanks for the reminder i probably need to go plug the spare ssd in
<pie_>
(^never thought id say that, woohoo ebay surplus ssds)
<lain>
modern SSDs are terrifyingly close to the physical limitations lol
<lain>
see also the samsung evo 840 issues
<pie_>
pretty sure i have evo 840s kek
<pie_>
my laptop is an 850...it was expensive...it BETTER last 10 years :P
<lain>
they had a bug where the read performance of data that hadn't been written in a long time would gradually get worse and worse. they released a fix, which didn't fix it. then they released another fix which mostly fixed it.
<lain>
as best I could tell, they pushed their process too far (I think they retired that process after the 840 evo line?) and then in the patch they again mischaracterized the failure mode, hence the second patch...
<lain>
iirc it was like: accessing adjacent regions caused some carrier injection? or otherwise disturbed the floating gates. the read perf drop was due to the drive having to do more and more ECC to bring the data back :P
<lain>
but a bug prevented the drive from refreshing the data correctly, so the problem would only become worse
<lain>
I wonder how close they came to the recovery limits of their ECC
<lain>
there have been a few studies on read disturb effects since then, it's basically rowhammer for SSDs
<lain>
read a bunch over here, corrupt a bit over there
<pie_>
iranian nuclear plants for ssds
<rqou>
ok, i finally got this to work
<rqou>
apparently i forgot that crbit is already mirrored
<rqou>
so fb2 is on the left
<rqou>
also, most/all of the bitstream physical layout is symmetrical
<rqou>
(other than global signals)
<rqou>
azonenberg: what do you know about sram-only programming?
<rqou>
azonenberg: it appears sram programming doesn't work with a completely blank flash?
<rqou>
even when you try to program the done row
steakpizza has joined ##openfpga
steakpizza has quit [Ping timeout: 256 seconds]
<rqou>
azonenberg: btw, it is not possible to program the unused cells in the middle of the zia on XC2C32A
<rqou>
oh wtfwtf
<rqou>
I've totally confused myself
<rqou>
because azonenberg's schematic symbol is weird
<rqou>
oh and now I've extra confused myself
<rqou>
because i forgot to erase first
<pie_>
time to delete the repo and clone again
<pie_>
ever gotten so confused you just bought an entirely new machine
<pie_>
HARDER RESET
<jn__>
:D
<lain>
I've been trying to root-cause a graphical glitch on my little GPD Pocket device lately and it has been quite a journey. the latest segment has me reading xorg-server source code
<lain>
I've found instances of what seems to be the exact same bug going back to 2011, and some possibly related ones going back to 2008, but it's apparently stupidly rare to hit this bug so nobody has ever *fixed* it
DrLuke__ is now known as DrLuke
<lain>
wheeeeeeeeeeeeeeeeeeeeee
<jn__>
that's one of these stories at the end of which you become the sole maintainer of a large piece of software
<gruetzkopf>
you do not want that.
Bike has joined ##openfpga
<lain>
hahahahaha
<lain>
it's such a weird bug
genii has quit [Read error: Connection reset by peer]