<azonenberg>
yeah the ultrascale zynqs have a lot more fluff (dedicated PS-GTR transceivers, much bigger CPUs, GPU, etc)
<azonenberg>
AFAIK all of the zynq-7s are dual core
<azonenberg>
My understanding is that they have one core locked out in bootrom or similar but they're just software limited
<azonenberg>
and have gate count capped in vivado
<azonenberg>
same as the 7a35t etc
<azonenberg>
i think a 7z007s is just a crippled 7z010, etc
Thorn has quit [Ping timeout: 258 seconds]
<GenTooMan>
or defective IE part of it doesn't pass test.
sgstair has quit [Read error: Connection reset by peer]
<azonenberg>
GenTooMan: the FPGAs are software limited
<azonenberg>
we know this because they do not impose any restrictions on placement
<azonenberg>
any single lut, bram, etc anywhere in the fabric can be used
<azonenberg>
It doesn't fuse off one out of every four columns of CLBs like i initially hypothesized when they announced the smaller parts
<azonenberg>
(a la SRAM bad-block remapping)
sgstair has joined ##openfpga
<azonenberg>
it is possible the disabled CPUs are actually bad, but this seems like a stretch given the percentage of die area occupied by CPU vs FPGA
<hackerfoo>
But there's no guarantee that the disabled parts will work correctly, so it would be dangerous to rely on this for a product.
<azonenberg>
hackerfoo: it'
<hackerfoo>
Like overclocking a CPU.
<azonenberg>
It's known and confirmed that the extra FPGA space on a 7a35t etc can be reliably and safely used because, as mentioned before, it doesn't actually disable any particular resources in the fpga
<azonenberg>
it just aborts P&R when you get above a certain % utilization
<azonenberg>
you can see all the sites in the floorplanner and use them
<azonenberg>
So if you make a bitstream for a 7a50 and patch the right bits, it'll run on a 35
<azonenberg>
it's strictly market segmentation, there's no doubt about it
<azonenberg>
while i would love to see someone figure out a way of improving FPGA die yield by fusing off individual columns of logic, this is not how it's currently being done
<azonenberg>
I strongly suspect bad-cell/row/col remapping in block RAM is already being done, but dont have any data to confirm this
<azonenberg>
If i decap a 7 series chip and count rows/cols in the BRAM we can figure it out though
<azonenberg>
if there's a few extra we'll know
<hackerfoo>
I guess most of what you pay for is NRE, even in hardware.
<azonenberg>
Silicon NRE is massive, in the $1M range for a 28nm tapeout iirc
<azonenberg>
maybe more
<azonenberg>
NRE in silicon >> almost anywhere else
<hackerfoo>
That doesn't include design.
<azonenberg>
Correct
<azonenberg>
That's completed design -> ready to start manufacturing first wafer
<azonenberg>
just to make the masks
<azonenberg>
and god help you if you find a bug after the first chips come back
<hackerfoo>
I'd estimate tens of millions, depending on the complexity of course.
<hackerfoo>
Yeah.
emeb_mac has joined ##openfpga
<swetland>
azonenberg: the *wackiest* thing about their decision to cap resources like that it means (or would seem to) that the "smaller" parts have better odds of you being able to fully utilize the capacity you paid for
<azonenberg>
They do
<azonenberg>
you can fill a crippled chip to 100% without significant worries about routing congestion
<azonenberg>
because you can space stuff out and use routing resources of the surrounding CLBs, just not the luts
* swetland
nods. what a world
<daveshah>
I wonder if it even lets you use the extra LUTs as route throughs
<daveshah>
Interestingly, I've seen Lattice stuff occasionally have config bits referred to as "spare" internally that seemingly do nothing
<daveshah>
I don't think these are for per device remapping though
<daveshah>
instead so small bug fixes just need a new metal layer not a whole new mask set
ZombieChicken has joined ##openfpga
Bob_Dole has quit [Ping timeout: 260 seconds]
solo1 has joined ##openfpga
<mwk>
daveshah: not just Lattice...
<mwk>
I think it's a difference between a nonexistent config memory cell and a memory cell that just happens to not be hooked anywhere?
<mwk>
I should at some point try uploading an all-1 bitstream to some xilinx devices and reading it back
<daveshah>
Curiously one LIFCL primitive (the config one iirc) actually exposes them as parameters too
<mwk>
huh.
<mwk>
also there are some bits called "spare" that actually have functions
<mwk>
or, at least, are set to some values by bitgen
Bob_Dole has joined ##openfpga
<mwk>
so perhaps they do actually get used sometimes for respins
<daveshah>
This is spare gates not bits, but similar
<mwk>
amusingly, every single one is in IO tile...
<mwk>
for every single family
<daveshah>
Maybe it's just IO tuning thwn
<daveshah>
*then
<mwk>
seems more like late feature additions
<azonenberg>
mwk: an all 1 bitstream sounds like it would trip lots of one-hot stuff and short all over the place
<azonenberg>
do it with something you dont care too much about :p
<mwk>
azonenberg: that's true
<azonenberg>
i know for a fact that an all-1 bitstream on a coolrunner will kill it in about an hour
<mwk>
but most of that should be avoided by not actually activating the config array
<azonenberg>
maybe a bit less
<azonenberg>
ok it wasnt quite all 1s, it was carefully crafted with 100% knowledge of the bitstream layout for worst case internal bus fights
<azonenberg>
but still :p
<mwk>
ie. never sending the LFRM/DGHIGH command, not activating the startup sequence, etc
<azonenberg>
i had a chip that was supposed to use like 5 mA at Fmax on VCCINT, instead pulling >100 mA
<daveshah>
I wouldn't be surprised if on most FPGA boards it just caused the power supply to brown out and reset the chip
<mwk>
azonenberg: haha nice
<azonenberg>
And this was a deliberate attempt at self-destructing the chip
<azonenberg>
i wanted to know if it would brick the chip by browning out the internal vccint routing and putting you in a boot loop you couldn't jtag out of
<azonenberg>
(since it had internal nvm)
<mwk>
I'm surprised it lastet that long
<azonenberg>
yeah i dont remember how long it took but it was not an instakill
<azonenberg>
i tried a few different bitstreams to see what got the highest power consumption
<azonenberg>
then the power started flickering a bit, like it was arcing over an almost-broken joint
<azonenberg>
then it dropped to zero and went unresponsive
<daveshah>
I've been informed that it's easy enough to overheat plenty of FPGAs just by filling them with ring oscillators
<daveshah>
No bitstream hackery even needed
<azonenberg>
i decapped it and popped it in the fib but was unsuccessful at finding the exact failure
<azonenberg>
daveshah: yeah but overheating isnt the same as actually cutting wires in the chip via electromigration
<azonenberg>
which is i think what happened here
<mwk>
anyway... yes, I'm not going to try it on a chip I actually care about :p
<azonenberg>
Lol
<mwk>
I'm reasonably sure the routing is actually safe if you never DGHIGH
<mwk>
so should be the output buffers if you never deassert GTS
<azonenberg>
in coolrunner, at least the routes connected to IBUFs can busfight combinatorially even if OGATE (my internal name for their signal analogous to DGHIGH, it's not mentioned in docs since it's self timed during the boot process) is not enabled
<azonenberg>
as can the vdd and vss ties
<azonenberg>
so you can have 3-4 IBUFs busfighting vdd and vss
<azonenberg>
the routes from macrocells might still be busfight capable if you have registers on the output with init values
<azonenberg>
i think
<mwk>
huh.
<azonenberg>
i'd have to go and look at the layout
<azonenberg>
i could be wrong
<mwk>
either way... the things I'd be worried about are analog stuff like PLLs and transceivers
<mwk>
who knows what may be happening in *those* if you light all the bits :p
<mwk>
also there are many weird internal test options wired to conf cells
<mwk>
these could perhaps straightforwardly blow shit up
<azonenberg>
That was the nice bit about decapping coolrunner
<azonenberg>
i had gate/cell level visibility into what shorted :p
<azonenberg>
at least in the portions of the chip that i fully RE'd
<mwk>
hm
<mwk>
actually, now that I have a working bitgen program, I should start looking at various strange bits and blackbox-reversing them
<azonenberg>
What architecture are you working on again?
* mwk
would really like the s6 IO cells to actually start making some sense
<azonenberg>
oh s6
<mwk>
azonenberg: s3e and s6
<mwk>
s3e was kind of boring
<azonenberg>
How similar is 3a to 3e?
<mwk>
very
<azonenberg>
how hard would adding 3a support be? almost no hard IP other than the MULT and DCM
<mwk>
new IO cells (halfway between 3e and 6), slight upgrades to blockram
<azonenberg>
would be nice to breathe some new life into my old devkits lol
<mwk>
not very
<mwk>
like, a few days of work
<azonenberg>
Do you have a P&R or what?
<mwk>
no
<azonenberg>
or just bitstream right now
<mwk>
I have a tool that takes XDL netlist and spits out a bitstream
<azonenberg>
ah ok
<mwk>
and I have a very old experimental nextpnr version that could barely place & route LUTs and FFs on s6, but not much more
<azonenberg>
what about synth support? none of that either
<azonenberg>
ah ok
<mwk>
as for synth, s6 has first class support in yosys
<mwk>
s3e... has not, but that's also on my shortlist
<mwk>
it's reasonably easy to get going
<azonenberg>
Nice. the big thing holding me back from reusing some of these old boards is the lack of vivado support
<azonenberg>
or more precisely, lack of systemverilog support
<azonenberg>
which yosys seems to be slowly catching up on
<swetland>
all I want for christmas is enums, typedefs, structs, and interfaces ^^
<sorear>
azonenberg: do you know enough about dummy bitlines to reliably ignore then
<sorear>
them
<mwk>
dummy bitlines?
<azonenberg>
sorear: i'd be counting actual sram bitcells in the array after HF stripping all metal and poly
<azonenberg>
so metal fill shouldnt matter
<sorear>
you can't use the outside ring or two of bitcells in a SRAM because they have the wrong differential capacitance and don't work with sense amplifiers, because edge effects
<sorear>
so there's one or two rings of "actual sram bitcells" that aren't included in the logical capacity
<sorear>
idk I don't understand this _that_ well but it's going to confound
<mwk>
sorear: huh? is that a thing for SRAMs in general?
<sorear>
maybe
<mwk>
I'm not sure it applies to configuration memory though
<mwk>
because you don't actually read config memory in the usual way
<sorear>
sure, but we were discussing BRAMs
<mwk>
ohhh
<sorear>
which are also weird, having configurable port widths and clock edges, but they're closer to a normal 2RW SRAM
<mwk>
yes, that makes much more sense
<mwk>
about programmable clock edges: I think that's just an issue for the interface logic, not for the mem array
<mwk>
as in, Xilinx basically has a XOR gate with one input wired to conf memory cell
<mwk>
and the other to the clock
<mwk>
which is part of the interconnect tile, not of the blockram tile [ie. applies to CLBs and DSPs as well, not just blockrams]
<ktemkin>
daveshah: is there anything I should be doing to help get support for that 'emulated differential output' inverter into Trellis?
<ktemkin>
adding cases to the fuzzer to get it to generate the necessary PIO{T,B}{0,1} F11B0 values seems trivial
<ktemkin>
er, *PIC{T,B}
<ktemkin>
(I added some cases when I was manually searching for that bit earlier, but I'm away from my build server and so the fuzzers for that case are still running)
_whitelogger has joined ##openfpga
<omnitechnomancer>
Are fifos with different input and output widths possible?
Thorn has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<azonenberg>
omnitechnomancer: yes, although it takes a bit more work especially if they don't have common factors
<azonenberg>
e.g. 17 bit input, 13 bit output
<omnitechnomancer>
32 bit input 8 bit output?
<azonenberg>
So for that basically you'd have two blocks in your fifo
<azonenberg>
the first is a standard fifo with 32 bit word size
<azonenberg>
the second is a mux that outputs 8 bits at a time of the 32 bit word
<azonenberg>
and only pops the full fifo every 4 pops
<azonenberg>
one way this can be implemented is by having a 2-bit larger address counter on the pop side
<azonenberg>
use the high N-2 bits as the sram address and the low 2 bits as the mux selector
<azonenberg>
then a bit of twiddling of bits so that empty/full flags correctly handle the possibility of a half-popped word in the output buffer
<omnitechnomancer>
Ah, yea I thought it might be something like that
____ has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
Bob_Dole has quit [Read error: Connection reset by peer]
<daveshah>
ktemkin: I reckon I can repeat the patch easy enough, I'll do this and update the db. There might be a nextpnr patch needed too, I'll try and get that done today
OmniMancer has joined ##openfpga
<azonenberg>
o/ ktemkin. Didn't know you hung out in here
<ktemkin>
daveshah: awesome; thanks ^^
<ktemkin>
azonenberg: hi ^^; and yeah, I lurk :)
<azonenberg>
Do we have a comprehensive list of open FPGA projects somewhere?
<azonenberg>
We should change the topic to point to more than just my greenpak tools
<azonenberg>
this channel really has taken off in the past few years
<azonenberg>
every time i hop back in here i see someone talking about REing a new chip i didn't know anyone was working on. lol
<pie_[bnc]>
:D <3
Asu has joined ##openfpga
indy has quit [Ping timeout: 272 seconds]
<daveshah>
ktemkin: can you try https://github.com/YosysHQ/nextpnr/pull/382 with latest prjtrellis (inc db submodule) on your hardware? it at least builds now but I haven't tested on hardware
<pie_[bnc]>
hm. https://mntre.com/media/reform_md/2019-05-20-reintroducing-reform.html "We are doing experiments to find out if the values can be found once per board and shipped with each PCB so that you wouldn't have to run this firmware yourself. As of December 2019, this is a theoretical approach."
<pie_[bnc]>
why are propreitary firmwares for SoCs even a thing?
<pie_[bnc]>
i really have no idea
<pie_[bnc]>
lock-in?
<daveshah>
Not wanting to support people who modify it
<daveshah>
third party IP under NDA
<daveshah>
general strange ideas about security
<pie_[bnc]>
hm
<omnitechnomancer>
DDR training
<mwk>
right, I meant to ask
<mwk>
what the fuck is the deal with DDR training?
* shapr
dances faster
<omnitechnomancer>
no idea but its annoying
<mwk>
like, why is it so secret that everybody pushes blobs for it?
<daveshah>
because everyone buys in proprietary controller IP
<mwk>
yeah, but... Intel?
<pie_[bnc]>
AI controlled RAM
<shapr>
pie_[bnc]: I trust AI
<pie_[bnc]>
beats human controlled ram eh?
<pie_[bnc]>
but what if humans control the AI
<pie_[bnc]>
turns out MIRI was wrong all along
<shapr>
When did DDR training become a thing?
<shapr>
this is the first I've heard of it.
<mwk>
when DDR3 happened, I think?
<pie_[bnc]>
I cant read that as anything except dance dance revolution