<cyrozap>
The Titan chips are for Google's internal servers and hardware--this is for Chromebooks.
<rqou>
hmm ok
<rqou>
btw, there is a block of 20 bits in the bottom left of the bitstream that i have no idea what it can possibly be controlling
<rqou>
but it changes all the time
<rqou>
anybody want to hazard a guess as to what that's for?
<awygle>
checksum
<rqou>
wut
<awygle>
idk I guessed
<rqou>
i guess that's possible
<cyrozap>
rqou: It's possible they might share the same crypto hard IP, but I'm just speculating :/
<rqou>
if that's the case then pwning it should still lead to much lulz
<rqou>
awygle: so, want to guess for the "mystery stripe bits?"
<rqou>
awygle: alternatively want to help guess wtf is up with coordinates?
<rqou>
awygle: or otherwise have suggestions/hints for what to do next?
<kc8apf>
that person really assumes malicious intent for including cr50.
<rqou>
i mean, it's not too unfounded
<rqou>
given the things that companies have done with "tivoization"
<kc8apf>
meh.
<kc8apf>
developer mode has existed in ChromeOS since the beginning
<kc8apf>
that's an explicit anti-tivoization capability
<rqou>
does it disable widevine?
<rqou>
does chromeos even have widevine?
<rqou>
hmm, i guess it doesn't disable widevine on android
<rqou>
why the **** does an io cell have so many local interconnect wires?
<awygle>
that person is Very Angry in general
<awygle>
rqou: uh buffers, column or row as makes sense
<awygle>
that's my guess
* awygle
zzz
<rqou>
so column/row IOs have local tracks too
<rqou>
but it has at least 14
<rqou>
(in a right-hand row IO)
<rqou>
which seems like far more than you would need
Hamilton has joined ##openfpga
<rqou>
so, 18 local tracks in right-hand io tiles
<cyrozap>
kc8apf: Yeah, when you look at its actual capabilities, if it's backdoored the worst it could do is replace the SoC boot flash, record keystrokes on a couple keyboard columns, and maybe attack the host's USB stack. It's far more limited than the Intel ME, which has both DMA and network access in addition to flash access.
<kc8apf>
almost as if it is designed to hold the system in reset until it can attest to the firmware being properly signed.....
<cyrozap>
lol exactly
<rqou>
hmm, i wonder if it's vulnerable to a TOCTOU?
<rqou>
which would make it significantly less useful for DRM
<daveshah>
rqou: could the high number of local tracks be a legacy from the Cyclone/Stratix devices with IO registers
<sorear>
what kind of adversary can replace the boot firmware but can't remove a chip
<cyrozap>
kc8apf: I'm more annoyed that it's one more chip that I can't replace the firmware on and mess around with it.
<rqou>
daveshah: actually no, i mixed something up
<rqou>
right-hand (and probably left-hand?) io cells have up to 7 IOBs
<rqou>
the smaller parts only have 5, but idk if they use the same structure or not
<kc8apf>
sorear: replacing boot firmware has often been done remotely
<rqou>
anyways, that already requires 14 wires
<cyrozap>
sorear: I think it's less about the ability to replace the chip, but more the ability to reprogram the chip without doing any chip replacement at all.
<rqou>
so 18 is not unreasonable
<rqou>
i had confused myself because the top/bottom io cells only have 4 IOBs
<daveshah>
rqou: makes sense
<daveshah>
The iCE40 has slightly more local tracks than inputs in its io tiles too, fwiw
<rqou>
daveshah: right now i'm still getting totally wrecked by the coordinate system and the fact that every mux seems to be slightly different(??)
<rqou>
so if you could help with that that would be really nice :P
<daveshah>
rqou: sure, what is going on with these coordinates?
<rqou>
well, i don't know :P
<rqou>
that's the problem
<rqou>
e.g. i can observe a certain mux in a certain physical location of the die, and i can correlate its bits with the quartus routing graph
<rqou>
but in one column, this mux will have index e.g. 4
<rqou>
but one column over, the mux in the corresponding physical location will have a totally different index in the quartus routing graph
<rqou>
and when i was decoding the interconnect->LAB muxes
<daveshah>
I wonder how close this is to VPR
<rqou>
one bit pattern comes from a wire that is locally called I0 for every Y coordinate i try
<rqou>
but it corresponds to a different physical mux in different rows
<daveshah>
The indexing thing may be an artefact of VPR
<daveshah>
The I0 thing is stranger
<rqou>
but why does the muxes in the die match up with the _logical_ index?
<daveshah>
Wait, I thought you said it had a different index?
<daveshah>
Or was that something else
<rqou>
that was something else
<rqou>
sorry, it doesn't make too much sense unless you play around with the "cfm2png" scripts
<rqou>
(and have the data files that i haven't published)
<daveshah>
yeah, feel I'd have to poke around a bit to understand these different indexes and naming systems
<daveshah>
particularly having never touched that side of Quartus/Altera before
<rqou>
anyways, i'm finding that "png" is currently a really amazing debugging tool
<daveshah>
Yep, Clifford did similar during the ice40 stuff and I've done the HTML stuff for the ecp5
<daveshah>
Definitely being able to view stuff is a lot more useful than just a text file
numarkaee has quit [Ping timeout: 240 seconds]
<rqou>
huh io bits are a giant mess
<rqou>
i think i'm going to skip fuzzing them in detail
<rqou>
just their connections to the interconnect for now
numarkaee has joined ##openfpga
<daveshah>
For the ECP5 I currently khave a stupid big look up table of IO standard and directionality vs IO bits
<daveshah>
It's really ugly, but it's enough to get something off the ground
<rqou>
i also don't care about this at this point
<daveshah>
Yeah, can just copy and paste those from a working bitstream anyway
<rqou>
i'm trying to just mark more interconnect bits so that i can figure out wtf is going on with coordinates and muxes
<rqou>
anyways, 2A is low if you're planning on using a large fpga at very high fmax
<comietek>
let’s say Spartan 6 or later
<comietek>
i have multiple 5V lines of input available
<comietek>
i was thinking i could use a number of these and then merge the outputs
<comietek>
does that make sense to you? i’m new to electronics
<rqou>
that usually doesn't work
<comietek>
why?
<rqou>
if you're new to electronics, an fpga board usually isn't the best first project
<rqou>
both voltage regulators have independent control loops that will both try and regulate the voltage at their output terminals
<rqou>
unless they're designed to do this, this can cause weird things to happen
<rqou>
if you're new to electronics and want to design your own board, i would suggest that you start with an 8-bit microcontroller (PIC, AVR) or a small 32-bit ARM
<comietek>
thanks, but that’s not very interesting to me
<comietek>
i’d rather struggle with something interesting
<comietek>
we can consider voltage conversion as a separate problem, right?
<daveshah>
It's a pretty big part of a modern FPGA board
<comietek>
are there any other options for voltage conversion apart from linear converters and switching DC/DC regulators?
<daveshah>
Yes, but they tend to be for niche applications
<rqou>
not really
<rqou>
anything else would be extremely exotic and almost certainly not what you want
<comietek>
would linear converters be more suitable for having their outputs merged?
<daveshah>
Not really
<daveshah>
I'm not convinced this is needed anyway, depending on the size of the FPGA and the power input
<rqou>
the search keyword for (the common type of) "merge-able" voltage converters is "multi-phase switching regulator"
<comietek>
thank you
<rqou>
but you probably don't need that unless you're planning to consume like 100W
<daveshah>
Yeah, I can't think of any need for a multi-phase regulator for any new FPGA costing less than a decent secondhand car
<comietek>
i’m not clear on how much power a Spartan 6 can actually use
<rqou>
azonenberg: ?
<daveshah>
It will depend on how big and fast your design is
<comietek>
yeah
<azonenberg>
comietek: xilinx has an excel spreadsheet you can download
<azonenberg>
and plug stuff into
<comietek>
thanks
<azonenberg>
they will want to know (to a first order estimate)
<azonenberg>
which chip and speed grade/package you're using
<rqou>
based on absolutely nothing, i would budget 50W
<azonenberg>
Number of LUTs/FFs/RAMs in use, at what speed
<azonenberg>
number of fast io interfaces at what speed
<azonenberg>
etc
<comietek>
the purpose of the FPGA is a simple 2D graphics card
<azonenberg>
7 series is the way to go for a modern design, ISE is basically EOL
<comietek>
frame buffer controller, color lookup table controller
<azonenberg>
s6 is going the way of the dinosaur
<daveshah>
rqou: well, that would depend on the spartan6
<comietek>
digital video output
<daveshah>
clearly a S6 9k in the QFP is going to catch fire at 50W
<azonenberg>
I've done small s6 boards that ran off USB power
<rqou>
yeah, i was thinking the huge ones
<comietek>
azonenberg: hobby project. i have some S6 boards that are good enough
<azonenberg>
i have an a7 board sitting near me that pulls about 350 mA at 12V but that includes a bunch of analog stuff, the FPGA isnt using that much
<comietek>
i can get 1080p@60Hz HDMI output out of a Pipistrello with a S6LX45 powered over USB
<rqou>
alright, based on these new numbers i would probably budget 15W on the power supply
<comietek>
the thing is, i can’t use USB to power the final project
<comietek>
i have to convert 5V or 12V lines
<daveshah>
well, from a power point of view USB==5V
<daveshah>
but it depends what current those lines can supply
<comietek>
one moment
<daveshah>
if this is your first board, I'd suggest going for 5V just because explosions will be less likely (even though 12V may be better from a strict engineering perspective)
<rqou>
awygle: so, you were wrong about the mystery bits in the corner
<rqou>
they're the USERCODE
<rqou>
and the altera docs lied
<mietek>
oh? can you explain why 12V could be better?
<mietek>
looking up the power limits now
<azonenberg>
mietek: Lower current for the same power
<azonenberg>
so less losses in the supply cable
<rqou>
anyways, apparently quartus sets USERCODE to a random value
<azonenberg>
rqou: timestamp?
<rqou>
even though the datasheet/manual claims FFFFFFFF by default
<azonenberg>
generally beyond about 5W estimated power consumption i go to 12V
<rqou>
azonenberg: no 48V for you yet? :P
<azonenberg>
rqou: that is something i would feed to a rackmount appliance
<azonenberg>
then have a 48-12 converter
<azonenberg>
and feed 12 to each blade
<azonenberg>
LATENTRED is going to take 12V from either 48 DC or 120 AC, TBD, and regulate the FPGA core power off that directly
<azonenberg>
then step to 5V as an intermediate rail for the backplane
<azonenberg>
and go from that to the PHY voltages at point of load on the line card
<azonenberg>
You can look at it from two viewpoints
<azonenberg>
One is, in the frequency domain, you want power and ground to be DC current
<azonenberg>
i.e. no AC voltage between them, ever - just a fixed DC bias
<azonenberg>
So by putting lots of caps between them you create a near-short circuit at AC
<rqou>
hmm, i see 10 local tracks in column io cells
<azonenberg>
By mixing small and large caps, you can get low impedance between them across a wide frequency band
<azonenberg>
Thinking about it in the time domain, your PCB power distribution (and the SMPS/LDO driving it) has inductive and resistive components
<azonenberg>
When a clock edge comes and the chip suddenly pulls a lot of current, the inductance will fight that dI/dt
<azonenberg>
And cause a voltage drop
<azonenberg>
So to compensate, you want a reservoir of voltage near the chip (with minimal inductance between you and it)
<mietek>
thanks. I called the reservoir “a buffer”
<mietek>
the frequency domain viewpoint is unclear to me.
<azonenberg>
But you can't use a huge capacitor, because the cap has inductance too
<mietek>
I expect I have to do a lot more reading.
<azonenberg>
And a bigger cap has more L
numarkaee has quit [Ping timeout: 260 seconds]
<azonenberg>
and thus you don't gain much at high frequency
<azonenberg>
If you use a small cap, there's not enough charge stored to power the IC for any length of time
<azonenberg>
so typically you use a network of caps with small ones very close to the IC then larger ones further away
brizzo has quit [Ping timeout: 265 seconds]
<azonenberg>
My general "rule of thumb" which agrees nicely with xilinx appnotes is 0.47 uF 0402 as the standard "right by the chip" cap. then 4.7 uF 0603 as the midrange one and then something in the tens to hundreds of uF further away depending on application requirements
<azonenberg>
You can see some of that in my schematic
<azonenberg>
Going back to the frequency domain, if you want two points to be at the same DC voltage you put a wire between them, right?
<mietek>
sure. I understand that we want a fixed DC bias.
<mietek>
the bit about AC flew over my head
<mietek>
it’s not clear to me why there would be any AC, unless we don’t trust out power supply
<azonenberg>
Well, if you want two points to be at the same AC voltage
<azonenberg>
You can connect them with a capacitor
brizzo has joined ##openfpga
<azonenberg>
Which will conduct AC but block DC (thinking in general terms)
<azonenberg>
This allows a fixed DC bias while passing any variations in voltage from one point to the other
<azonenberg>
If the AC is freely moving from power to ground, there's no AC voltage between the two
<azonenberg>
And thus they should just have the DC offset
<azonenberg>
make sense?
<mietek>
oh, I think I’m beginning to see what you mean.
<azonenberg>
in practice you cant use just one cap because the power plane isn't an ideal conductor at the frequencies FPGAs operate at
<azonenberg>
It's a 2D network of resistors and inductors
<azonenberg>
and to tie ALL those points together you need many caps
<azonenberg>
Across a wide range of frequencies
<mietek>
thanks again. much appreciated.
<azonenberg>
There's a lot of bad advice out there about decoupling, its not as well understood/taught as it should be
<azonenberg>
Some older sources teach using a range of caps in the same size, say 0402, but 0.1 and 0.01 uF or something like that
<azonenberg>
This may have been good advice years ago when caps were built differently
<azonenberg>
But modern caps tend to have a fairly fixed mounting inductance for a given package size, then higher capacitance just gives you more energy storage
<azonenberg>
So there's little downside to a larger C in a given size, up to the point that you start having problems with too-thin dielectric (C/V curves are fun)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rqou>
so azonenberg overall really interesting thing in max v
<rqou>
all tiles have "local lines" on both the left and the right
<rqou>
that's how it manages to interact with two columns
<rqou>
but of course it's asymmetrical
<rqou>
so one column is "favored"
<azonenberg>
lol
<rqou>
oh wtf
<rqou>
there are up-going wires at the very top of the array?!
<azonenberg>
To the IOBs?
<rqou>
yeah
<mietek>
azonenberg: so in your schematic, you are combining four LTC3374s for the FPGA 1V supply?
<azonenberg>
No
<azonenberg>
Four channels of one chip
<azonenberg>
Out of eight total
<mietek>
aha
<mietek>
right
<azonenberg>
I just have multiple symbols so I cna make the layout easier to understand
<mietek>
thanks
DocScrutinizer05 has quit [Quit: EEEEEEK]
<rqou>
ok wait wtf
<rqou>
azonenberg: no switch seems to control the "Y5" wire
<rqou>
now i'm not sure what's going on
<rqou>
also, afaict the left/right IOs have _their own_ wires
<rqou>
but can _also_ feed the neighboring LAB's wires
<rqou>
azonenberg: is it possible quartus is somehow creating "virtual" wires?
<azonenberg>
maybe?
Hamilton2 has joined ##openfpga
Hamilton2 has quit [Remote host closed the connection]
Hamilton has quit [Ping timeout: 255 seconds]
<rqou>
azonenberg: no i'm an idiot
<rqou>
i forgot to run quartus_asm :P
<rqou>
(analogous to bitgen)
<azonenberg>
lol
<rqou>
so there are indeed wires going up into the io cell
<rqou>
azonenberg: so for some reason the C4 wire coordinates seem to be one tile higher than their control bits
<azonenberg>
Hmm
<azonenberg>
is it possibly y=0 is the IOBs or something?
<azonenberg>
or they control start vs end of the wire?
<azonenberg>
or something liek that
<rqou>
y=0 is definitely an IOB
<rqou>
wires are supposed to go "up" from the tile mentioned in the coordinates
kuldeep has quit [Ping timeout: 256 seconds]
kuldeep has joined ##openfpga
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
DocScrutinizer05 has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
pie_ has joined ##openfpga
unixb0y has joined ##openfpga
<pie_>
azonenberg, are you getting fire resistant doors or howver that works? :p
<pie_>
might as well go all-out and build a bunker
eightdot has quit [Ping timeout: 268 seconds]
kuldeep has quit [Ping timeout: 276 seconds]
eightdot has joined ##openfpga
kuldeep has joined ##openfpga
gnufan1 has joined ##openfpga
gnufan has quit [Ping timeout: 260 seconds]
Bike has joined ##openfpga
shadowdancer has joined ##openfpga
pie_ has quit [Ping timeout: 264 seconds]
genii has joined ##openfpga
pie_ has joined ##openfpga
shadow_dancer has joined ##openfpga
shadowdancer has quit [Ping timeout: 256 seconds]
shadow_dancer has quit [Ping timeout: 240 seconds]
shadow_dancer has joined ##openfpga
<awygle>
rqou: I win, checksum
<cr1901_modern>
What do you win?
m_w has joined ##openfpga
shadow_dancer has quit [Ping timeout: 276 seconds]
shadow_dancer has joined ##openfpga
<awygle>
My question exactly
shadow_dancer has quit [Ping timeout: 248 seconds]
gnufan has joined ##openfpga
gnufan1 has quit [Ping timeout: 276 seconds]
pointfree1 has quit [Remote host closed the connection]
AlexDaniel` has quit [Read error: Connection reset by peer]
indefini has quit [Read error: Connection reset by peer]
sielicki has quit [Remote host closed the connection]
anuejn has quit [Read error: Connection reset by peer]
hl has quit [Read error: Connection reset by peer]
nrossi has quit [Remote host closed the connection]
jfng has quit [Remote host closed the connection]
<mithro>
Morning!
<mithro>
blinky pnr's with vpr for the ice40!
<m_w>
nice
massi has quit [Remote host closed the connection]
pointfree1 has joined ##openfpga
<mithro>
anyone good at Verilog want a task? :-P
<m_w>
mithro, what are you needing?
<mithro>
m_w: Many things -- but I'm after a verilog simulation model of the XC2064/XC2018 CLB - it's pretty simple, a lut, ff and some muxes
<cr1901_modern>
Yes, that's for adding a platform to migen/litex
<cr1901_modern>
I assumed you already did that?
<m_w>
nope
<m_w>
I am a total newb when it comes to migen and litex
<cr1901_modern>
Ahh, then the migen post will help you then :). It all applies to litex except for package structure
<cr1901_modern>
migen is the core Python language for creating FPGA designs. misoc is a framework for SoCs written in migen. litex is migen+misoc plus experimental stuff
<cr1901_modern>
platforms in migen can be used in litex, but if you're spending a lot of time in litex, you prob want to port to both
<m_w>
you think there would value to adding beaglewire support
<m_w>
remember it is memory mapped to a BBB
<m_w>
plenty of SoC down there
<cr1901_modern>
I don't know enough about beaglewire
<cr1901_modern>
But I'd say yes. Adding a platform is low-burden code addition
<cr1901_modern>
(in general)
Miyu is now known as hackkitten
pointfree1 has quit [Remote host closed the connection]