<openfpga-github>
yosys/master 27a626c Andrew Zonenberg: greenpak4: Added POUT to GP_COUNTx cells
Bike has quit [Quit: fear god]
<lain>
happy new year!
mifune has joined ##openfpga
<clifford>
azonenberg, looks like nobody has made iCE40 die photos so far. process node is similar to spartan 6 and that one is on siliconpr0n. how big of a project would it be to make die photos of iCE40 HX1K and/or HX8K?
<nats`>
pretty small for someone already having the microscope and the decapping acid
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
<whitequark>
mmhm, let me check the local shops
mifune has quit [Ping timeout: 260 seconds]
Ardeshir has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
mifune has quit [Ping timeout: 260 seconds]
<azonenberg>
clifford: Top metal only or all layers?
<azonenberg>
Top metal overview is pretty easy
<azonenberg>
you can do that optically
<azonenberg>
all layers SEM is a much bigger project
<azonenberg>
clifford: On modern deep-submicron processes, the top metal layer generally doesn't have a ton to see
<azonenberg>
clifford: it's all power distribution routing
<azonenberg>
So you can image it optically, largest features are several microns across
<azonenberg>
sometimes even tens of microns
<azonenberg>
But all of the interesting bits are further down
<azonenberg>
Personally, the image that I find most useful for showcasing the chip as well as floorplan analysis of major blocks is the bare silicon after etching off all metal and poly
<azonenberg>
That is also fairly easy to image, you won't see all of the detail but it's probably going to be possible to see the config memory, LUT/slice boundaries, etc a lot easier
<azonenberg>
if you want full netlist extraction like i did for parts of coolrunner that's a very involved process
<azonenberg>
as you're talking thousands of photos and polishing to every intermediate metal layer (probably about 8 of them at that node)
<clifford>
azonenberg, the motivation would be floorplan analysis and figuring out which resource takes up what amount of area, not creating a silicon netlist.
<clifford>
top metal would probably ok, but I agree that poly looks much much nicer.
<azonenberg>
Well, i dont have a photo handy
<azonenberg>
Poly is hard to do because it requires a planar delayert
<azonenberg>
delayer*
<azonenberg>
but bare silicon can be done with a HF etch
<azonenberg>
and at optical magnification is generally pretty indistinguishable from poly
<azonenberg>
I'll poke digshadow, he has this more automated than i do
<azonenberg>
clifford: If you supply a couple of chips (say 2 of each density) we can probably make this happen
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 258 seconds]
pie_ has joined ##openfpga
pie___ has quit [Ping timeout: 268 seconds]
pie_ has quit [Ping timeout: 248 seconds]
mifune has joined ##openfpga
<azonenberg>
So clifford, lain, and anybody else who's awake
<azonenberg>
I have a fun problem with the greenpak4 DAC input routing
<azonenberg>
in particular, each DAC can take its digital input from an 8-bit bitstream-defined constant (already implemented)
<azonenberg>
or the negative input of DCMP1
<azonenberg>
Which is a mux
<azonenberg>
If there are no DCMPs used, this is easy
<azonenberg>
infer a hidden one, ignore output, just use the input
<azonenberg>
but if DCMPs are used i'm trying to think how best to implement this constraint
<azonenberg>
Do i create a hidden "DCMP input mux" object and route that separately?
<azonenberg>
b/c then i could have the user's input signal drive a DCMPInputMux object, have that output drive both a GP_DCMP and the two GP_DAC objects
<lain>
ehhh I dunno
<lain>
I'm neck-deep in llvm target code :P
<azonenberg>
and if not, how do i describe the routing constraint
<azonenberg>
that DCMP1 must have the same input as this dac?
<azonenberg>
seems like creating a node to be PAR'd is the natural solution
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMqva
<openfpga-github>
openfpga/master 4184719 Andrew Zonenberg: doc: Added documentation for POUT output of GP_COUNTx
<azonenberg>
openfpga-bb: force build
<openfpga-bb>
you must provide a Builder, try 'force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] <WHICH> <REASON>'
<azonenberg>
openfpga-bb: force build Forgot to plug in the dev board :(
<azonenberg>
ok that looks better but still failing on the oscillator tests for who knows what reason
mifune has quit [Ping timeout: 260 seconds]
<lain>
whitequark: do you know off the top of your head how to represent shadow registers in the RegisterInfo.td file? having trouble finding info on it
<lain>
ah nvm
Bike has joined ##openfpga
pie_ has joined ##openfpga
<digshadow>
clifford: get me ice40 die(s) and I'll take some pictures
m_t has joined ##openfpga
<azonenberg>
digshadow: he said he was sending them to me but i can forward to you, or if he didn't send them yet we can change the dest address
<azonenberg>
my plan was to decap and quickly inspect then send you bare dies for imaging
<digshadow>
works for me
<digshadow>
would definitely simplify things on my end
<digshadow>
how much are these things
<digshadow>
aren't they like $1
<digshadow>
or is that just the greenpak
<azonenberg>
greenpak is $0.50 single unit and $0.35 volume
<azonenberg>
ice40 is substantially larger
<azonenberg>
up to ~8000 LUT4s
<azonenberg>
so close to the smallest artixes
<lain>
is that enough to implement a gameboy? :P
<azonenberg>
i fit an 8-bit RISC CPU (custom ISA), UART, and 32 PWMs in 1408 LUT4s
<azonenberg>
less, the chip had 1408 and i had a small handful free
<lain>
:D
<azonenberg>
Was also my first fpga project
<azonenberg>
so i prboably did lots of dumb thigns
<lain>
aha
<digshadow>
lain: a few people have expressed interest in doing polygon capture on the gameboy die images
<digshadow>
but no serious takers yet I think
Ardeshir has joined ##openfpga
<cr1901_modern>
azonenberg: A good metric I've heard is that ice40hx8k is approx a Spartan 6 LX5
<cr1901_modern>
if such a thing existed
<cr1901_modern>
I thought the smallest artix was quite larger than the smallest Spartan 6, tbh
<azonenberg>
cr1901_modern: smallest spartan6 is a lx4
<azonenberg>
smallest artix available now is the 15k
<azonenberg>
but there are 9 and 6 announced
<azonenberg>
not yet available
<azonenberg>
or maybe those are only spartan7
<azonenberg>
i know there's some new low-density 7 series in the works
<lain>
those are s7 yeah
<cr1901_modern>
Are the LUT archs the same between artix 7 and spartan 6?
<cr1901_modern>
or approx the same?*
<azonenberg>
Similar
<lain>
I dunno if slices are same, but I think both are 6-LUT?
<azonenberg>
7 series removed the stupid slices with no carry chains or wide muxes
<lain>
lol
<azonenberg>
everything has muxes and carry afaik
<azonenberg>
in s6 that really limited utilization for things like crypto
<cr1901_modern>
I did a calculation some time ago and calculated that spartan 3 4-LUT 200k is approx 4/9ths the size of a LX9
<azonenberg>
its not even directly comparable b/c of hard ip, block ram, different lut architectures
<azonenberg>
it totally depends on your design
<azonenberg>
like, having more DSP slices / wider multipliers wont help a non-DSP application at all
<azonenberg>
wider luts may make 50% less utilization for some designs or make no difference for others
<cr1901_modern>
I didn't add a factor accounting for wider LUTs, tbh. Just raw usage of slices
<cr1901_modern>
I don't think it's a *bad* rule-of-thumb when getting size comparisons between FPGA families in the first place is convoluted
<azonenberg>
xilinx's marketing numbers say a lut6 + two FFs = 1.6 logic cells
<azonenberg>
where a logic cell is a lut4 + ff
<cr1901_modern>
Based on a wide variety of real world tests conducted, and totally not a number pulled out of their asses :D
<azonenberg>
lol
<azonenberg>
in other news, i'm going to try and get a yosys-smtbmc verification flow working with splash v0.2 over the next few days
<azonenberg>
rather than the old sat solver i was using, smt should be faster
<cr1901_modern>
I need to get yosys-smtbmc working on Windoze
<cr1901_modern>
well, z3 works AFAICT, but of course yosys-smtbmc uses the "Unixism" of "calling select() without calling WSAStartup() first :D"
<azonenberg>
Lol
<cr1901_modern>
^That is a joke btw
<azonenberg>
As i port all of my old antikernel code over and clean it up
<azonenberg>
I'm going to try and make formal tests for as much of the core system as i can
digshadow1 has joined ##openfpga
<cr1901_modern>
I have a crappy SPI core I wrote on Christmas Day (motivation to write it must've been a Christmas Present from the Deity itself). Have a few invariants that I assume that I want to formally verify
digshadow has quit [Ping timeout: 252 seconds]
<azonenberg>
Yeah in my case what i want to do is get a lot better at formal stuff
<azonenberg>
rewrite a bunch of my modules with parameterizable size
<azonenberg>
Prove correctness at least for a reduced-size version that generalizes to the full data width
* azonenberg
waits for z3 to compile
digshadow has joined ##openfpga
digshadow1 has quit [Ping timeout: 258 seconds]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 258 seconds]
<azonenberg>
clifford: Does yosys SMT not support initialized/zero-filled memory?
<azonenberg>
had some trouble tinkering with it earlier