soylentyellow has quit [Ping timeout: 255 seconds]
ZipCPU|Laptop has joined ##openfpga
<awygle>
azonenberg_work: did you see my question over the weekend about the placement cost of different cells within a clb?
<azonenberg_work>
No
<azonenberg_work>
I was out training with SAR all weekend and AFK
<azonenberg_work>
then got home for all of an hour to shower then catch a plane to a client
<azonenberg_work>
i'm here all week
<azonenberg_work>
then home for sunday then off to germany for a week
<azonenberg_work>
then home for a few day,s then xmas
<azonenberg_work>
:p
soylentyellow has joined ##openfpga
<awygle>
Figured it was something like that lol
<cr1901_modern>
azonenberg_work: So basically what you're saying is you'll have plenty of time to work on openfpga :)?
<awygle>
I was sick for three days last week, I got a ton of work done :-D
<azonenberg_work>
cr1901_modern: lol
<azonenberg_work>
I'm at the hotel and probably going to hit the hay soon to adapt to the time change
<azonenberg_work>
with any luck i can get progress on something tomorrow, not sure what yet
<azonenberg_work>
may be my slides for germany
<azonenberg_work>
may be openfpga, may be antikernel
<balrog>
azonenberg_work: sounds like you're extra busy again :/
<awygle>
azonenberg_work: well if you have a second before you crash, my question was whether treating all cells within a logic block as equivalent for the purposes of placement sounded reasonable. That's what arachne does for ice40s, and it makes sense to me in that arch, but idk the other options well enough yet to generalize intelligently
<azonenberg_work>
For most but not all purposes, yes
<azonenberg_work>
There are some special cases where it matters, for example carry chains
<azonenberg_work>
To use a carry chain you must have the LSB at the lowest BEL in the slice and the MSB at the highest BEL
<azonenberg_work>
carrying up to the next slice in line
<azonenberg_work>
Additionally there are tiny differences in propagation delay between them, as well as even between lut inputs
<azonenberg_work>
insignificant for most purposes but sebastian actually made a time-to-digital converter by using iirc lut input skew
<azonenberg_work>
i.e. his resolution was basically the delta between (Tpd from in0 to out) and (Tpd from in1 to out)
<rqou>
ah, afaik there's some secret carry short-circuiting going on?
<awygle>
I'm not surprised there are differences, I'm just wondering how much we need to care at the level of placement. Carry chains is interesting because iirc they come out as their own cells from Yosys, have to double check what's going on there when I get home..
<azonenberg_work>
Yeah thats the main thing that matters
<azonenberg_work>
That, and FxMUXs
<azonenberg_work>
The F7AMUX has to take ALUT and BLUT as inputs
<azonenberg_work>
the F7BMUX has to take CLUT and DLUT as inputs
<azonenberg_work>
i.e. you cannot F7MUX ALUT and CLUT
<azonenberg_work>
or BLUT and DLUT
<azonenberg_work>
The F8MUX has to take the two F7MUX's as inputs
<awygle>
Hmm right
<azonenberg_work>
Honestly i would suggest you forget slices exist
<awygle>
OK, I think that answers the basic question
<azonenberg_work>
at the placement level
<azonenberg_work>
Place BELs to sites
<azonenberg_work>
you care about slices for routing
<azonenberg_work>
And maybe for optimizing placement
<rqou>
so i never got around to really understanding the ice40 architecture
<rqou>
does _every_ CLB have _both_ span4 and span12 wires?
<awygle>
That's basically what I was intending to do, but if it can end up with an _illegal_ placement then that's an issue probably
<awygle>
Oh wait I read that backwards
<awygle>
Yeah that's the other extreme. It has some complications of its own but might be the way to go. Another option is to pack to CLBs instead of slices
<awygle>
rqou: iirc yes but that's the kind of thing I usually double check
gruetzko- has joined ##openfpga
moho1 has quit [Ping timeout: 268 seconds]
moho1 has joined ##openfpga
gruetzkopf has quit [Ping timeout: 268 seconds]
m_w has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<pointfree>
Just got my Cypress Analog co-processor devkit in the mail today. It comes in a nifty box with a magnetic cover.
<pointfree>
The idea is to have logic even before that actual gpios.
<pointfree>
This is great for waking up a chip given some conditions.
<pointfree>
smartio logic can even run asynchronously/clocklessly
<pointfree>
The only other chip I have that does that is the GA144 from Greenarrays.
<qu1j0t3>
is this any relation to BeagleBone PRUs? (That I know almost nothing about)
<pointfree>
qu1j0t3: Well this is a Cypress chip so it's probably not related directly and the Beaglebone "Programmable Real-Time Units" are still clocked as far as I know.
* qu1j0t3
nods
* qu1j0t3
should look into it more sometime
* qu1j0t3
just bought the Freedom Kinetis KE06Z board
* cr1901_modern
watches qu1j0t3 use the /me command in succession
* pointfree
continues the conversation with /me
Bike has joined ##openfpga
* pointfree
looks forward to getting the analog coprocessor and smartio re'd.
ZipCPU|Laptop has quit [Ping timeout: 255 seconds]
* pointfree
almost doesn't want to use up flash writes on his new analog coprocessor devkit because it comes in such a nice box.
digshadow has quit [Ping timeout: 260 seconds]
wpwrak has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
pie_ has joined ##openfpga
nrossi has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<cyrozap>
pointfree: All the larger Cypress kits come in the magnetic boxes :P
<cyrozap>
Also, isn't the "Analog Coprocessor" just a PSoC 4 without any UDBs?
<cyrozap>
Ah, ok, so for analog applications it reduces external component count/complexity. That's pretty useful.
<cyrozap>
pointfree: Also, you have a GreenArrays chip? Is it actually useful for anything?
<pointfree>
cyrozap: It's in my desk drawer. The GA144 is not really big enough for me and is rather expensive. A friend of mine is building a smart watch with it ...a clockless smart watch.
<pointfree>
cyrozap: It would be interesting to compare the capacity for asynchronous logic between the ga144 and the smartios of a psoc4, analog coprocessor, and psoc6.
<pointfree>
(which has more space)
<pointfree>
At one point Chuck Moore and Co were swimming in money. The GA144 was only meant to be a prototype for a much larger greenarrays chip. Then they got sued by a patent troll. Greenarrays won, but now they no longer have the funds to tool up for a larger version of the chip.
<cr1901_modern>
From what I can tell, Chuck Moore is a freakin genius known to be able to get shit done. But Forth is not a language I would personally use.
<pointfree>
Chuck Moore wrote the EDA tools that were used to design the GA144 in forth from scratch (Okad II)
<pointfree>
I have a book with some eda software written by him: logic synthesis, techmapping, simulation -- one block/screenful of forth code ( 16 lines of code or so)
<cyrozap>
> a clockless smart watch
<cyrozap>
> clockless watch
<cyrozap>
What a time to be alive.
<cyrozap>
> clockless clock
<cyrozap>
I just can't even XD
<cyrozap>
But seriously, I don't really understand how that clockless stuff works. Is it just purely combinatorial logic? No flops?
<cyrozap>
<awygle> anyone know if the format of the .pcf files used by arachne-pnr is standardized somewhere?
<cyrozap>
awygle: tl;dr, the actual SDC format is just TCL with a library to support all the SDC functions.
<cyrozap>
awygle: But Yosys/arachne-pnr/IceStorm/et al. don't actually use TCL--or, at least, not to handle constraints--so they're parsing what amounts to be a subset of the standard.
<cyrozap>
Speaking of constraint files, anyone have any opinions on whether they should be Turing-complete or not? :P
<mtp>
i love forths
<cr1901_modern>
openfpga's format is a superset of the subset of synposys that arachne supports (phew!)
pie_ has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
pie_ has joined ##openfpga
fpgacraft1_ has joined ##openfpga
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1_ is now known as fpgacraft1
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has joined ##openfpga
moho1 has quit [Ping timeout: 248 seconds]
moho1 has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
<awygle>
cyrozap: thanks! That's exactly what I was looking for
xdeller has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
X-Scale has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
azonenberg_work has quit [Ping timeout: 248 seconds]
xdeller_ has joined ##openfpga
azonenberg_work has joined ##openfpga
soylentyellow has quit [Ping timeout: 255 seconds]
xdeller has quit [Ping timeout: 260 seconds]
<azonenberg_work>
qu1j0t3: beaglebone PRUs are (i havent used them but skimmed this part of the datasheet) basically hard realtime MCU cores that hang off the main ARM
<azonenberg_work>
so no OS jitter etc
<azonenberg_work>
they just run a little bit of code by themselves
<azonenberg_work>
they look like they're meant for things like motor control, offloading bitbang to a separate core, etc
<azonenberg_work>
IMO a little bit of FPGA would be far more useful for that
pie_ has quit [Ping timeout: 255 seconds]
promach__ has joined ##openfpga
promach__ has quit [Quit: Leaving]
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
m_w has joined ##openfpga
m_t has quit [Quit: Leaving]
fpgacraft2 has joined ##openfpga
* qu1j0t3
nods
m_t has joined ##openfpga
<awygle>
They're also decent for comm protocol stuff. You can bitbang like... Modbus or whatever.
<awygle>
FPGAs are better but lots of people don't understand them I guess
<azonenberg_work>
Yeah
<azonenberg_work>
honestly i think FPGAs are far superior for hard realtime and safety critical applications
<azonenberg_work>
it's so much easier to get cycle-accurate timing
<azonenberg_work>
and provable isolation
<balrog>
more difficult to program; more silicon real estate too?
<azonenberg_work>
i actually find verilog is a very clean way to describe state machines
<azonenberg_work>
more so than C
<balrog>
does TI do any FPGA work already (that could be integrated)?
<azonenberg_work>
i do not think they have an FPGA IP
<azonenberg_work>
Microchip has the "configurable logic cell
<azonenberg_work>
"
<azonenberg_work>
i actually wanted to explore that a bit more and see how plausible it would be to program that with HDL
<azonenberg_work>
i also wanted to explore generating pin mux data for the PICs with crossbars on the io
<azonenberg_work>
in verilog
<balrog>
btw the AM5728 which is on the beagleboard-xm has two tms320c66x series DSP cores
<azonenberg_work>
i.e. have a top level module declaration
<balrog>
(they're basically integrating everything they can)
<m_w>
beagleboard-x15
<azonenberg_work>
Basically what i wanted to do was
<azonenberg_work>
have an IP module for the processing system
<awygle>
Just that cypress is pretty solidly an Asic company and still does FPGAs, unless you argue that the psoc isn't one
<balrog>
the psoc is some weird hybrid
<pointfree>
I need to figure out if the psoc6's smartio logic, higher clock speed, etc makes up for having half as many UDB's.
<azonenberg_work>
In today's news
<azonenberg_work>
cypress figured out that FPGA uses a decent amount of die area :p
<balrog>
do we have a good psoc 5lp decap?
<balrog>
of the poly layer
<balrog>
I Don't think so
<balrog>
there are images from the PSoC 1
<balrog>
pointfree: is there an equivalent to the smart io in the psoc5?
<balrog>
it's available on the psoc4 though
<balrog>
4000*
<pointfree>
balrog: No, not really. Not as in logic before the gpios.
<balrog>
grr how DO you write a place and route algo for all this differing logic :D
<pointfree>
I'm tempted to check out the PSoC 6 even though I've hated on its reduced number of UDB's.
<pointfree>
The PSoC 6 uses Cortex-M4 which means proper support for coprocessors which means I think I could use the analog coprocessor as a coprocessor.
<awygle>
I've been thinking about it and I think packing to the CLB level (and other "regular" tiles, i.e. Things that fit on the grid) is the way to go
<awygle>
That logic is going to be very arch-specific I feel, and so a generic placer wants to be higher level
<pointfree>
The PSoC 6 Register TRM's are split over three pdfs because they are so humongous. Also, routing registers have different naming...
<azonenberg_work>
awygle: So you want to have a chip specific CLB packer
<azonenberg_work>
then a generic CLB-level par engine?
<awygle>
That's what I'm thinking yes
<awygle>
Seems too easy to end up with an illegal (not just inefficient) placement otherwise.
<qu1j0t3>
pointfree: I read 'analog coprocessor' and i got excited because i thought analog computing was back
<azonenberg_work>
awygle: Yeah that makes sense
<azonenberg_work>
how's your literature survey etc?
<awygle>
Some progress. Latency on standard Ethernet seems like a real issue
m_w has quit [Quit: leaving]
<awygle>
Trying to get some prototype stuff put together so I can have actual numbers
<azonenberg_work>
I think global placement will be the hardest part
<azonenberg_work>
Basically, my assumption is
<azonenberg_work>
we start with a random placement
<azonenberg_work>
then as you get closer and closer to optimal
<azonenberg_work>
the amount of communication will die down
<azonenberg_work>
right?
<azonenberg_work>
i.e. you have more and more % of the comms local to the node vs communicating
<azonenberg_work>
Because there will be less stuff jumping between nodes
<azonenberg_work>
You are definitely going to want to batch operations
<azonenberg_work>
Figure out a few hundred CLBs you want to shove into the adjacent node's territory
<azonenberg_work>
Then do them all at once
<azonenberg_work>
rather than a hundred separate send(2) calls
<azonenberg_work>
Like i said earlier definitely look at molecular dynamics stuff like LAMMPS
<azonenberg_work>
you don't need to actually use MPI but the communications patterns are important
<openfpga-github>
[openfpga] azonenberg opened issue #122: Create Vivado tcl import/export tool (kinda like XDL) https://git.io/vbZY5
<awygle>
I'm at work now so I can't dig in too deep on this but basically I see two algorithmic approaches, one based on solving the global problem and one based on spatial decomposition. The former are easier to write and potentially higher quality bit don't scale as well in the presence of latency. The latter scale nearly indefinitely but are more complex and possibly not as high quality. I want to ultimately explore both.
<azonenberg_work>
OK
<azonenberg_work>
awygle: I am more interested in the latter but agreed, both are worth looking at
<azonenberg_work>
We should discuss in more detail at our whiteboard etc session
<awygle>
Yes. And I'd like to have some numbers to bring to that lol
<azonenberg_work>
Fair enough
digshadow has joined ##openfpga
<azonenberg_work>
awygle: you should probably also update the wiki with that important insight
<azonenberg_work>
i.e. that we pack not only because it's faster
<azonenberg_work>
but because it allows the CLB-level placer to be more technology independent
<awygle>
azonenberg_work: good point, done
m_w has joined ##openfpga
digshadow has quit [Ping timeout: 250 seconds]
user10032 has joined ##openfpga
nrossi has quit [Quit: Connection closed for inactivity]
<rqou>
er, for prototyping i really want someone to just hack ice40 into vpr
<rqou>
sure, but i never considered that you could gerrymander together parts of _two different metropolitan areas_
<azonenberg_work>
Lol
<azonenberg_work>
i've seen some equally absurd ones
* azonenberg_work
thinks we should just pick well-defined locations (say centers of cities or neighborhoods or counties, depending on population density)
<azonenberg_work>
as seats of legislative districts
<azonenberg_work>
then do a voronoi tesselation
<azonenberg_work>
round to street boundaries
<azonenberg_work>
problem solved
<rqou>
i don't think that guarantees equal distribution of population across the districts though
<zino>
Gerremandering is an extremely small with sane propotional voting systems.
<zino>
small problem*
<azonenberg_work>
The easiest, i think, is to give each legislator votes proportional to their district size
<azonenberg_work>
i.e. if my district has 20% more people in it, i get 20% more votes
<azonenberg_work>
to balance out small changes in size
<azonenberg_work>
Then, when the size disparity gets more than 10-20% you'd either split a district in half or move the centroid of a district a bit (using a well defined energy minimization formula) to restore the tesselation to equal area
<azonenberg_work>
If you do this frequently enough (i.e. every election) you could simply remove the vote scaling entirely
<azonenberg_work>
and have each district be identical in size
<rqou>
or we can do what zino suggested and just switch to saner voting systems :P
<azonenberg_work>
But this might cause problems with stability where voters bounce between districts each election if they live on the edge
<azonenberg_work>
Scaling would allow some stability
pie_ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
<pie__>
awygle, i kind of wonder if another moon landing today wold really be as reliable as apollo 16
<rqou>
eh, just reboot the arduino when it hangs :P
<pie__>
wait im confused, we put manned missions on the moon MULTIPLE TIMES?
<azonenberg_work>
Yes
<azonenberg_work>
Apollo 1 was destroyed in a fire beofre takeoff, along with all crew
<azonenberg_work>
2-7 were unmanned test flights
<azonenberg_work>
8-10 were manned but didn't land on the moon
<pie__>
"The United States' Apollo 11 was the first manned mission to land on the Moon, on 20 July 1969. There have been six manned U.S. landings (between 1969 and 1972) " OH. WHAT THE FUCK. How did I not know this. Well i guess everyone only talks about /the one/ usually.
<azonenberg_work>
11-17, except 13, all landed on the moon
<azonenberg_work>
13 had a fuel tank explosion in flight and had to abort the mission before landing
<azonenberg_work>
but all crew survived
<pie__>
man that must have been disappointing for the astronauts :P
<azonenberg_work>
IIRC one of them later did land
<azonenberg_work>
on another flight?
<azonenberg_work>
i forget the specifics
<azonenberg_work>
i know one or more of them later flew on the shuttle
<pie__>
still jesus christ tho mind blown or something
<Bike>
i think the plan is pretty neat. they started with orbital then kinda moved out, then orbited the moon, then landed, then landed longer
<qu1j0t3>
yes
<qu1j0t3>
including landing the rovers
<Bike>
apollo 11 didn't have the buggy or nothing, they had to work up to that
<Bike>
yeah
<qu1j0t3>
Apollo is awe-inspiring, really
<awygle>
And eventually, golf clubs
* qu1j0t3
has long been a fan
<Bike>
big space fan
<pie__>
heavy metal fan
<pie__>
fan puns
<Bike>
apparently they were originally going to hang out in MEO for one, but it didn't work out
<pie__>
</>
<qu1j0t3>
well, i'm slightly overweight metal fan
<pie__>
Bike, incremental does make sense
<Bike>
also probably good to remember next time someone starts talking about a "moonshot"
<Bike>
incrementalism, i mean
<pie__>
yeah
<pie__>
nvm about marsshot even
<jn__>
pie__: i'm a linux fan^W^W^W^W wait, are there fans controlled by linux now? ;)
<Bike>
i'm glad the space capitalists have focused on something boring but useful like reusable rockets
<Bike>
rather than mars missions, i mean
<pie__>
theyr eprobably more qualified to know thats not a good idea yet
<Bike>
they want to make money, and they can do that doing cargo into orbit, and they'll make more money the cheaper they can do that
<Bike>
very tidy
<pie__>
good thing about the moon is you have a launch window every day i supose
<Bike>
do you?
<pie__>
or at least once a month maybe
<pie__>
PERIODically
<Bike>
i have no idea how launch windows work because kerbal kills my computer