<azonenberg>
cr1901_modern: both are named after the Greek personification of death
<azonenberg>
I name any machine of mine that hosts internet-facing services after a god of death or the underworld to symbolize it's assumed pwned and not to be trusted
<azonenberg>
at one point or another I've used Charon, Pluto, Hades, Thanatos, and Camazotz
<azonenberg>
oh and Anubis
<azonenberg>
Charon is an ancient NTP server i've never had time to properly decommission, Thanatos is my old VPS that is going down after I copy anything worth keeping off it
<azonenberg>
the rest are all offline already except Camazotz, which is a 1U blade system with four raspberry pi 3's in it
<azonenberg>
that will host my public DNS and web presence
<azonenberg>
a pi may not be fast but it beats an el cheapo openvz box (thanatos)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
when do we get a server that wipes out all life?
dj_pi has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
futarisIRCcloud has joined ##openfpga
Bob_Dole has joined ##openfpga
soylentyellow__ has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 250 seconds]
soylentyellow_ has quit [Ping timeout: 250 seconds]
Flea86 has joined ##openfpga
Miyu has quit [Ping timeout: 246 seconds]
m_w has quit [Ping timeout: 246 seconds]
pie__ has quit [Ping timeout: 244 seconds]
m_w has joined ##openfpga
m_w has quit [Client Quit]
<ym>
There are blade servers.
mumptai_ has joined ##openfpga
Richard_Simmons has joined ##openfpga
mumptai has quit [Ping timeout: 250 seconds]
Bob_Dole has quit [Ping timeout: 250 seconds]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
demonplant is now known as catplant
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
jcreus has joined ##openfpga
_whitelogger has joined ##openfpga
<jcreus>
@someone who's been reverse engineering the 7-series, what does the floorplan look like? I'm only finding marketing about their novel(TM) scalable(TM) columns
<jcreus>
in particular, I'm interested in how the non-LUT elements are distributed (say DSPs and RAMs)
<jcreus>
because I want to make sure that whatever constraint system or iterative placer I come up with can handle them
<jcreus>
because, say, having the DSPs be on opposite sides of the die (like the iCE40s, if memory serves me right) is harder than having them uniformly around (because in the latter case you can, like LUTs, pretend they're a continuous density in xy)
<kc8apf>
it's not very clear from that document so here's the overview:
<kc8apf>
devices are split into two halves based on the location of the global clock buffers. See Figure 1-1.
<kc8apf>
the line that split the upper and lower BUFGs is called the horizontal center
<kc8apf>
rows are added growing outward from the horizontal center. a device need not be symmetric around the horizontal center.
<kc8apf>
in each row, the BUFGs form a "spine" that is called the clocking center. This logically splits the row into two halves. Again, symmetry is not required around the clocking center.
<kc8apf>
with all that in mind, I/O is on the left and right edge of each row. Working inward from the I/O, next few columns are CMTs.
<kc8apf>
After that, you have mostly a repeating pattern of LUT columns mixed with BRAMs and/or DSPs.
<kc8apf>
Each row can have a unique configuration of column types though
<jcreus>
I see yeah, thanks kc8apf!
<kc8apf>
so rows with GT banks will have those at the end and I/O gets shifted it
<kc8apf>
in
<kc8apf>
some rows will omit BRAMs because the device didn't need them.
<kc8apf>
In practice, I've seen most regularity at the "half-row" level. That is, the column configuration from the clocking center to the edge of a row is reused as a building block rather than the whole row.
<kc8apf>
larger virtex7 devices include another layer to the hierarchy called SLRs that are mostly how multiple dies are interconnected
<kc8apf>
I really need to get this all put together into blog posts. I've been sidetracked on other projects and haven't gotten to part 4
<jcreus>
and I assume each of those layers has worse locality?
<kc8apf>
SLRs?
<jcreus>
yeah
<kc8apf>
think of it as dies stacked on top of one another. SLRs define a vertical interconnect through the stack. Not how it really works but close enough in concept.
<sorear>
wait, it's 3D?
<kc8apf>
sorear: not really. They use an interposer that the dies are mounted on
<sorear>
what I assumed prior to your comment was that the US+ die was a 2-layer structure, consisting of a continuous interposer covered with N tiled, not overlapping SLR dice
<kc8apf>
my understanding is that connections between the dies are not solely at the edges of the dies though
<kc8apf>
sorear: physically, yes. that's exactly what it is.
<kc8apf>
but how signals are interconnected between the die seems to be more intricate than just wiring up I/Os between the die
<kc8apf>
azonenberg will know a lot more about SLRs than I do
* azonenberg
appears in a puff of smoke
<sorear>
if the number of metal wires per micron on the interposer is greater than the number of pads per micron on the SLR pad ring, then it would make sense to grab signals from deeper in
<azonenberg>
sorear: That's where the "laguna" blocks come in
<azonenberg>
they have launch points from interposer to/from the fabric at the left and right side of each edge of each SLR
<azonenberg>
iirc a laguna is the same logical size as a CLB and has... 4? nets each way
<kc8apf>
jcreus: see last paragraph on UG472 pg 20 regarding composition of rows
<sorear>
how do you define up/down/left/right
<azonenberg>
vivado floorplan gui perspective
<azonenberg>
a vu9p is three slrs stacked top to bottom
<jcreus>
kc8apf: got it thanks
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fhkpj
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark 244d439 - XCHG pseudo with both operands being the same is illegal.
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark 8ec21cd - Add comments back to design doc.
<kc8apf>
huh. ug475 tells you what rows are used in each individual die and which I/Os are bonded out per package
<kc8apf>
hmm. ug475 figure 1-26 shows a xc7vx1140t as SLRs with the interposer connecting additional rows
<kc8apf>
spanning the global clocking backbone and CMT backbone between dies rather than 3d stacking
rohitksingh_ has quit [Ping timeout: 245 seconds]
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhkh6
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark ea0e966 - doc: improve design of SWPW/ADJW.
rohitksingh has joined ##openfpga
<tnt>
tfw you realize two of the cute tricks you used in your design interact in bad ways.
<cpresser>
'cute'?
<cpresser>
or ugly hacks?
<tnt>
I love my hacks unconditionally, they're all cute to me :P
<whitequark>
ha
<tnt>
Wait what ... mithro just said we can't access the lattice bram until 40 clock cycles after power up ?!?
<tnt>
Seriously ?
<whitequark>
yes
<tnt>
Is that documented anywhere in the lattic docs ?
<whitequark>
yes
<tnt>
Huh. Must have missed that :/
<whitequark>
it says that you need to give it at least 42 (i htink? around that number) SPI cycles after all bitstream is read
<sorear>
this is the first I've heard it's documented; it's been described several times around here otherwise
<tnt>
Yeah, ok, that I'm not too surprised, but I would have exepected the 'global reset' to still be asserted ...
<whitequark>
hmmmm
<whitequark>
until 40 *which* cycles?
<sorear>
TN-02001 has "The PIO pins activate according to their configured function after 49 configuration clock cycles." but does not mention BRAM
<whitequark>
sorear: so
<whitequark>
both icecube and yosys do not use RE/WE
<whitequark>
instead they use RCLKE and WCLKE
<whitequark>
so this cannot be BRAM CLK, I think?
<daveshah>
This is configuration clock, I think
<daveshah>
probably the internal config oscillator
<whitequark>
oh hm
<daveshah>
which is unrelated to the user internal oscillators, btw
<tnt>
I'm wondering if the SPRAMs have gotchas like that ...
<sorear>
leaves a few related ones open like "if I'm writing the same address from two clocks, how many ps do I need between them"
<whitequark>
sorear: i think that's just always undefined
<sorear>
so if I have a RAM with two write clock domains, they need to write non-overlapping address sets over the length of time the device is on?
<tnt>
I would hope you at least get the guarantee that one or the other write is going to work ...
<daveshah>
I don't think that's true, based on the sim models I've seen
<tnt>
Well the ice40 only has 1 write port anyway btw :p
<daveshah>
I'm pretty sure the required period is more or less ~1/Fmax
<daveshah>
conflicting writes sooner than that will make the entire addressed location Xs
<sorear>
I assume that the word line is held high for an entire half-clock or clock and if one domain is slow, the other domain needs to avoid the line being written for a potentially long time
<noopwafel>
symbiflow talk went well :)
<sorear>
hard enough to find detailed timing info on memory compilers, and I'm pretty sure BRAMs don't use those
<daveshah>
the ice40 SPRAM definitely uses one
<daveshah>
Synposys DesignWare to be precise
<daveshah>
*synopsys
<sorear>
what makes that a "definitely"?
<daveshah>
the sim model is mem compiler output ;)
<daveshah>
and the user guide for the SPRAM gives the names of some internal signals for some reason
<sorear>
POWEROFF, that's a fun one
<marex-cloud>
rqou: hey, any progress on the altera stuff?
<marex-cloud>
rqou: in fact, are you at 35c3?
<rqou>
max ii/v for the 240 LE part is completely done
<rqou>
others need work on figuring out the interconnect
<rqou>
yes, I'm at 35c3
<rohitksingh>
rqou: you were mentioned in the mithro's talk :p
<rqou>
you can call me on eventphone 8838
<sorear>
if someone decapped one, how much effort would it be?
<tnt>
lol "your 7 segment decoder shouldn't take 150k gates"
<tnt>
(clifford during his talk)
<whitequark>
what
<whitequark>
how
<whitequark>
how did that happen
<sorear>
someone not used to thinking about hardware did a bad for-loop
<tnt>
No, that was an hyperbole. Clifford was explaining that he likes the ice40 for workshops because it is small. if you use large devices to teach people, they can do really stupid stuff and things still work ...
<whitequark>
ahhh
<GuzTech>
He's right. 100k gates should be more than enough...
<GuzTech>
:P
<marex-cloud>
rqou: nice
<daveshah>
I understand clifford actually saw this at a uni
<daveshah>
Somehow someone had a for loop that checked for all 1000 possible values
catplant has quit [Ping timeout: 240 seconds]
<sorear>
yosyshq/nextpnr@xc7 …
<tnt>
daveshah: lol
<GuzTech>
When you let a software guy "write" hardware...
mumptai has quit [Remote host closed the connection]
<marex-cloud>
rqou: just arrived
<jcreus>
does anyone have an intuition for how many "paths" there are in a fpga routing that have the potential to be critical (that is, ignoring all the subpaths, and only picking the longest ones that go to the leaves)
<jcreus>
I haven't thought about it too deeply, and while initial intution says it should blow up exponentially, idk if real designs have more limited interactions that make it tractably bigger than the number of edges
<jcreus>
reason I ask is that the focus on minimizing total wirelength seems a bit misguided if all that matters is the critical path (if only optimizing for timing that is)
<daveshah>
Minimising total wirelength also makes sure that the design will actually route
<jcreus>
if it blows up, it presumably can still be handled iteratively, by simply adding constraints for the paths that are critical or close to tcritical
<jcreus>
ahh, dangit
<daveshah>
I use a criticality metric in my new placer branch
<daveshah>
This is basically a number [0, 1] "how close an arc is to being on the critical path"
<SolraBizna>
GuzTech: and then another 3 hours to install, and at least 24 hours per startup
catplant has quit [Ping timeout: 252 seconds]
<GuzTech>
SolraBizna: And nvme drive helps significantly, but since I'm used to QuestaSim, I'm actually OK with the startup and usage speed.
<GuzTech>
QuestaSim is horrendously slow
<GuzTech>
Then something else that really sucks (and mithro will not like to hear this :P): Python under Arch Linux
<GuzTech>
I've been trying to get project X-Ray setup, and the virtual environment could not be setup properly.
<GuzTech>
Turns out that the pyjson5 library imports a function with an incorrect signature. The author actually has a fix for this in a PR, but didn't apply it and didn't release it.
<GuzTech>
So I had to do it by hand.
<GuzTech>
Not a big deal right? But every time I need to setup something with Python and pip and setuptools, something will always go wrong.
<GuzTech>
Maybe I'm cursed :(
<qu1j0t3>
GuzTech: no, it's not just you
<qu1j0t3>
GuzTech: i go into that jungle without optimism and with many bandages from past encounters
<GuzTech>
The only language that I've used that has a decent library management system is Rust.
<GuzTech>
Haskell with stack works ok-ish but you have 500 package updates everyday.
<GuzTech>
C/C++...
<GuzTech>
And I don't use Python much, but this is a pain point.
jevinskie has quit [Ping timeout: 264 seconds]
catplant has joined ##openfpga
jevinskie has joined ##openfpga
catplant has quit [Ping timeout: 245 seconds]
emily has quit [Quit: leaving]
Atlantic778 has quit [Ping timeout: 246 seconds]
m_w has joined ##openfpga
Atlantic778 has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 252 seconds]
Atlantic778 has quit [Ping timeout: 240 seconds]
<tnt>
Has anyone tried to use gtkwave transaction filter process to run sigrok decoders ?
<azonenberg>
interesting idea but why not just use pulseview? does it lack vcd import?
<azonenberg>
that might be easier to add
<azonenberg>
i use my own waveform viewer because pulseview isn't really meant for analog or mixed signal stuff, or real-time control
<tnt>
azonenberg: pulseview decompresses vcd internally and only supports up to 64 signals.
<azonenberg>
only 64 signals? that sounds pretty useless
<azonenberg>
yet another reason i dont use it :p
<tnt>
yeah, it works fine when I work with real-captures from a usb logic analyzer or from my scope but for simulation data, not so much.
<azonenberg>
yeah, my goal for glscopeclient is to work with anything
<azonenberg>
real time, thousands of waveforms per second, hundreds of signals
<azonenberg>
mix of analog and digital
<azonenberg>
with realtime protocol decodes on top of everything
<azonenberg>
it's going to be a complete rewrite of my old scopeclient UI to improve scalability and performanec
<azonenberg>
of course it also doesn't exist yet...
<azonenberg>
at least not in any usable form
<tnt>
The sigrok guys are actually starting now a complete rewrite of the core to deal with all those historic issues ... just had a talk with them.
<azonenberg>
Interesting, but the whole GPL thing is still a dealbreaker for me
<tnt>
but ... that's future stuff, so I was wondering if I could have a stop-gap with transaction filters in the mean time to get the benefits of all existing decoders.
<azonenberg>
(my tool will be permissively licensed to encourage wide adoption)
rohitksingh has quit [Ping timeout: 245 seconds]
catplant has joined ##openfpga
Atlantic778 has joined ##openfpga
Atlantic778 has quit [Ping timeout: 245 seconds]
<swetland>
I'm okay with GPL for standalone tools, but yeah, prefer BSD/MIT/Apache and use one of them for my own stuff
<swetland>
would be nice to have something less clunky than gtkwave. only so many hours in the day, sadly
<azonenberg>
swetland: well by the time i build that 10 Gsps real-time DSo
<azonenberg>
DSO*
<azonenberg>
i will *need* something decent because none of the existing f/oss tools can keep up with that kind of bandwidth
<azonenberg>
or even close
catplant has quit [Ping timeout: 268 seconds]
* swetland
nods
<swetland>
It'd be nice to see some decent open scope / logic analyzer tech -- including ui/ux that's not awful
<swetland>
I really like solid benchtop tools, but they sadly tend to be expensive and needlessly limited
<azonenberg>
yeah i have a chain of like 5 projects in the pipe before i get there
<azonenberg>
My target for most of my future high-end test equipment is 1U rackmount
<azonenberg>
with a DC power jack and SFP+ on the back, and four SMA connectors on the front
<azonenberg>
or similar
Richard_Simmons has quit [Ping timeout: 264 seconds]
Bob_Dole has joined ##openfpga
catplant has joined ##openfpga
<tnt>
swetland: I really don't mind gtkwave for most stuff ...
<tnt>
not saying it's perfect or you can't do better, but I find it perfectly usable and does the job for me without major pains most of the time
<cr1901_modern>
This matches my experience too
<tnt>
(for the purpose it's meant for ... i.e viewing files ... not controlling hw or live input or anystuff like that)
<cr1901_modern>
I do have to say- PulseView has gotten _a lot_ better since I first used it nearly 4 years ago.
<cr1901_modern>
It couldn't do anything I needed it to do before then