<cr1901_modern>
Well, I'm not gonna get 1GHz b/w anywhere that low cost. But can I actually take advantage of it (since your board only works for periodic signals)?
<cr1901_modern>
anywhere else*
m_w has quit [Quit: leaving]
<awygle>
i'm studying clifford's docs on the ice40 and i'm a little confused about the carry chain. there's a CarryEnable bit for each LC but also you can route lutff_(i-1)/cout to lutff_i/in3 at the tile routing level, which seems redundant. anybody here know what's up with that? should i ask in #yosys?
<awygle>
thinking maybe CarryEnable turns on a tri-state output driver from the carry logic...
<rqou>
unfortunately i don't think there is any documentation other than the notes that clifford wrote up
<rqou>
(no idea if this works) have you tried looking into icebox?
<awygle>
hmm that might be a good idea. might be hard to isolate specifically what i'm confused about, but then again maybe not
<awygle>
thanks for the suggestion rqou
<rqou>
er wait
<rqou>
awygle are you the gsoc person that's tasked with writing better documentation?
<awygle>
rqou: i am not :) bit old for gsoc
<awygle>
just expanding my horizons
<rqou>
fossi foundation (iirc) is actually sponsoring a gsoc project for this because the documentation was apparently confusing for everybody except clifford and cseed :P
<awygle>
oh cool. "high-level bitstream format"
<awygle>
yeah the docs are a little opaque. i wasn't sure how much of that was the docs, how much was me, and how much was lattice :P
<azonenberg>
that may be worth using as a baseline
<rqou>
yak stack: "generic" schematic symbols for kicad
<rqou>
or do you think this should block on eeschema-new?
<azonenberg>
yes it should
<azonenberg>
anyway skim my docc
<azonenberg>
it's incomplete, i re-rendered it hence today's date
<azonenberg>
but the original doc dates to a year or two ago
<azonenberg>
so missing all of our recent findings
<rqou>
is eeschema-new happening at all?
<rqou>
as in, is anybody working on it?
<azonenberg>
yes but probably not until version 6 from what i remember
<rqou>
yes, i know that part
<azonenberg>
pcbnew was the higher priority
<rqou>
when is that going to happen? "when it's ready?"
<rqou>
you mean pcbnewnew? :P
<azonenberg>
lolol
<rqou>
gotta love kicad
<rqou>
i should actually send them cleanup patches rather than complaining about it all the time
<azonenberg>
i've been doing that
<azonenberg>
but its now reaching the point that there arent many small yaks i'd want to shave
<azonenberg>
i use my own libraries so the stock ones arent really a concern
<rqou>
hmm i'm currently sick so doing something masochistic right now might not be too bad :P
<azonenberg>
the only stock ones i use are like "generic N-pin connector" and passives
<azonenberg>
All of the other small yaks are dealt with
<azonenberg>
the big ones, like stackup-aware impedance math and length matching, will be major projects
<rqou>
wait what
<rqou>
it doesn't have that?
<rqou>
i thought that should be easy?
<rqou>
i guess it's kicad :P
<azonenberg>
it has length matching
<azonenberg>
but it is not stackup aware
<azonenberg>
i.e. it wont compensate for via length
<azonenberg>
it also is *length*, rather than *delay* matching
<azonenberg>
so it also doesn't compensate for different propagation delays on different layers
<azonenberg>
If you are matching signals with the same layer setup its fine
<azonenberg>
but if you want to match an internal and external layer you have to tune them manually to different target lengths to compensate for the velocity skew
<rqou>
this doesn't seem like it should be particularly hard to add?
<rqou>
er, the math/approximations might be hard, but the implementation doesn't seem like it should be?
<azonenberg>
well first you have to add the 2D field solver to calculate propagation velocity etc better than the current closed-form approximations :p
<rqou>
oh you wanted to do it that way
<azonenberg>
there's a stackup editor under development now
<rqou>
the hard way
<rqou>
:P
<azonenberg>
but afaik it's not actually used for anything but the 3d renders
<rqou>
wait what
<rqou>
it didn't have one before?
<azonenberg>
It let you specify what layers were being used
<azonenberg>
but not thicknesses/spacing
<rqou>
even EAGLE had that
<rqou>
(although i don't think EAGLE did anything with it)
<azonenberg>
exactly :p
<azonenberg>
anyway, once we have the data the next step will be to make the length matcher add via barrels to the path length
<azonenberg>
then make the matching work in the time rather than space domain
<azonenberg>
and use a layer-dependent velocity
<azonenberg>
initially using closed-form approximations and eventually a field solver
<azonenberg>
also, right now the diff pair / trace width dimensions are global
<rqou>
btw is there even foss code that can calculate this stuff?
pie__ has joined ##openfpga
<azonenberg>
i'd rather specify a target impedance and then have it use layer dependent width/space
<rqou>
i know there's openEMS, but that's a) slow as shit b) complicated as shit and c) a 3d field solver, which is probably not necessary
<azonenberg>
not to my knowledge, no
<azonenberg>
lain was thinking of writing one
<azonenberg>
anyway my vision is you'd enter the stackups
<azonenberg>
specify target impedance
<azonenberg>
then you'd get an x/y plot of impedance vs width for each layer
<azonenberg>
sorry i meant, width vs spacing
<azonenberg>
to get the target impedance
<rqou>
doesn't "PCB calculator" already do that?
<azonenberg>
and you could specify where in that chart you wanted to be
scrts has quit [Ping timeout: 268 seconds]
<azonenberg>
it uses closed form approximations that seems to disagree badly with hyperlynx simulations of the same geometry
<azonenberg>
i want to go back and verify
<azonenberg>
but in any case, regardless of where the data comes from
<azonenberg>
right now all of the geometry is done in the space domain, not time
<rqou>
(PCB calculator is my favorite part of kicad to complain about because it's a calculator. calculator = pure functions. except kicad's code has all sorts of random UI shit mixed up with the math)
scrts has joined ##openfpga
<azonenberg>
i want to say, match these traces within 50 ps
<azonenberg>
and figure out propagation delay across the layers they cross
<azonenberg>
knowing that an extra 1mm of path is not the same delay on one layer vs another
<rqou>
so i remember using various random javascript impedance calculators to try to figure out what width a 50ohm trace should be on a 2-layer 1.6mm board and the answer was always something over 100mils
<rqou>
is that anywhere close to correct?
<azonenberg>
yes
<azonenberg>
2-layer boards are almost impossible to do sane impedances on
<azonenberg>
for such designs i normally do 4L and just use the layers on one side of the board
<azonenberg>
then use the other layers if i need to
<azonenberg>
but i mostly just want the thin spacing
azonenberg_work has joined ##openfpga
<awygle>
i have done super-thin boards (not recommended) and coplanar waveguide (better) to get around that
<rqou>
does a coplanar waveguide work if you're trying to do "super buget" serdes/memory bus stuff rather than "real" RF?
<awygle>
no idea *shrug* i was doing RF
wolfspraul has quit [Quit: leaving]
<rqou>
ham?
<awygle>
i do remember having to do the extra-thin thing for budget USB
wolfspraul has joined ##openfpga
pie__ has quit [Ping timeout: 246 seconds]
<awygle>
because seeed still charges 5$ for boards that are 0.8mm thick
<awygle>
rqou: curious, are you based in HK or just visiting?
<rqou>
i was just visiting; i'm actually back in the US now (and sick)
<awygle>
ooo bummer :( travel plague is the worst
<rqou>
actually we seem to now suspect it's the apartment in HK
<awygle>
did you enjoy your trip other than the attempt on your life? HK is next on my travel list
<rqou>
yeah, i finally for once actually did "normal tourist things" like taking an obnoxious selfie on Victoria Peak :P
<awygle>
lol nice
<awygle>
oh btw, go bears! just noticed on twitter
<rqou>
lol
<awygle>
i am class of 2013
<rqou>
oh nice
<rqou>
no trees here in ##openfpga :P :P
* UmbralRaptor
is confused, given just how many schools have bears as their mascot.
<rqou>
uc berkeley
<rqou>
(and trees = stanford, a rival)
<UmbralRaptor>
This leads to hilarity like one school's motto being "Bear up" (Missouri State University), while another's is "bear down" (University of Arizona) >_>
<awygle>
both my parents are UofA alums lol
<awygle>
i think the "stanford cardinal" is the worst though. "what's your mascot?" "literally a shade of red"
<rqou>
also worst marching band :P
<awygle>
haha throwing shade! were you in the cal band or something?
<rqou>
my sister was in marching band (not cal's)
<awygle>
ah
<awygle>
well thanks for the lattice help, i appreciate it
ZipCPU|Laptop has quit [Remote host closed the connection]
<azonenberg>
(11:28:47) azonenberg_work: is it full techmap-accurate (i.e. exact same RAM topologies, no register balancing, etc)?
<azonenberg>
this is what i sent last time, not sure if you saw it
<pervo>
nope, got dc'ed, sorry about that :)
<azonenberg>
So, that's the first step
<azonenberg>
As far as extracting contents, look at the CAPTURE feature of the STARTUPE2 primitive
<pervo>
so, take the simplest example of a simple counter. i have a simulation that gives me a dump of the counter value. the goal is to rewrite/update a bitstream so the initial value for the ff's corresponding to the counter have the designated value.
<azonenberg>
that will let you update the jtag readback bitstream to have a given state
<azonenberg>
as far as going the other way around, it's tricky - my experience with the xilinx LL files have been poor to say the least
<azonenberg>
in terms of reliability/accuracy
<pervo>
write_bitstream -logic_location_file seems to give a mapping to the bitstream frames, etc, but i don't know enough (or really anything) about the bitstream format to know if that's useful or not
<azonenberg>
Basically what you would need to do is RE most of the bitstream other than the routing and hard IP
<azonenberg>
I am extremely interested in doing this but it's a major project
<pervo>
yeah, that sounds painful :)
<pervo>
right now my proof of concept just generates initial blocks, but the turnaround from resynth and reimplement makes it less than ideal
<azonenberg>
Yeah makes sense
<azonenberg>
So, what primitives do you need to initialize?
<azonenberg>
FFs, RAM, shregs?
<rqou>
there was/is a tool that can change the init values of BRAMs, but i never understood how to use it
<azonenberg>
You may want to consider just adding reconfiguration logic in your design for the short term, that will reduce Fmax and add quite a bit of gate overhead
<azonenberg>
but be easy to implement
<rqou>
i don't know if it works on anything else
<azonenberg>
rqou: it does not
<azonenberg>
and i never got it to work either :p
<pervo>
yeah the reconfig logic is something i was planning on trying
<azonenberg>
This is one of the many use cases for a published bitstream doc
<azonenberg>
and library, etc
<azonenberg>
If you want to help us work on 7 series we're definitely interested
<azonenberg>
I was going to start on s3a just because it seemed like a simpler project to get basic familiarity with the xilinx uarches
<azonenberg>
then generalize to more modern stuff
<pervo>
i'm not sure how much i can yak shave on this right now, my pinging you was mostly to gauge how much of a stretch it would be, and it sounds like the answer is: a lot
<azonenberg>
Yes its a major project
<azonenberg>
Feel free to hang out in this chan and stay updated on our prorgess etc
<pervo>
will do, and thanks for the info
<rqou>
heh, "progress"
<rqou>
current progress: still sick
<azonenberg>
rqou: Lol fixing that is generally a prereq to getting work done
<azonenberg>
also i didnt hear bac kfrom you re the not-datasheet
<azonenberg>
was there any useful info in there?
<azonenberg>
section 2.4 needs to be updated with the bladerunner info
<rqou>
oh right
<rqou>
i did read it
<rqou>
it seems pretty good for the parts that are actually documented
<rqou>
it seems decently confused which parts are generic across sizes and which parts are 32A-specific though
<azonenberg>
yes b/c i didnt know anything about larger devices back in 2014 :p
<rqou>
or maybe that was only the ZIA section
<azonenberg>
2015*
<azonenberg>
It needs to be udpated
<azonenberg>
but i mean, would you like a doc similar to that that's current?
X-Scale has joined ##openfpga
pervo has quit [Ping timeout: 255 seconds]
<rqou>
that's probably good initially
<rqou>
we'll still point to xilinx appnotes i suppose?
lexano has joined ##openfpga
<rqou>
wow the xilinx datasheet itself has very little information
<rqou>
all the useful information is in appnotes
lexano has quit [Ping timeout: 246 seconds]
<azonenberg>
i would rather rewrite the info just in case xilinx removes anything
<azonenberg>
And so all the info is in one place
<azonenberg>
we can cite the original appnotes of course
<fouric1>
.
<fouric1>
huh, that's odd
<fouric1>
would anyone happen to know if ##embedded and ##electronics have some sort of IRC permissions thing that i'm not aware of?
<fouric1>
apparently, i'm banned on both of those channels, despite never having said anything
<azonenberg>
Yes, you have to be registered
<azonenberg>
with nickserv
mifune has quit [Ping timeout: 260 seconds]
<fouric1>
i am registered, but when trying to change my nick to "fouric" (my registered nick), i get "##electronics :Cannot change nickname while banned on channel"
<fouric1>
wait
<fouric1>
don't tell me i have to leave, register, and then come back
<azonenberg>
You might have to leave and re-identify... idk, i have my client set to auto-id
fouric1 is now known as fouric
<fouric>
still "##embedded: Cannot send to channel"
<fouric>
wait nvm
<azonenberg>
the op of ##embedded is coming over for a bbq in a few hours
<azonenberg>
so if you're still having trouble i'll bug him :p
lexano has joined ##openfpga
<fouric>
i just had a little glitch with identifying
<fouric>
tried again and it worked
<fouric>
thank you, azonenberg
<rqou>
wait wtf azonenberg how many people are coming to this bbq?
<rqou>
how do you know ALL THE PEOPLE?
<azonenberg>
rqou: me, error_404, obnauticus and his gf, lain, sgstair, $WIFE, and a non-freenode person from work
<jn__>
sounds like fun
<fouric>
rqou: you need to find more computer engineering people in your area
<fouric>
either that, or convert your neighbors
<rqou>
apparently i'm just not that good at meeting people