<promach3>
lambda: someone told me : `Spec does not say that. It just says that at any point of time more than 8 refreshed cannot be posted.
<promach3>
So if you do 4 together and 4 next time will might have a performance hit since now you have to precharge all 2 times along with tRP.`
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
tokomak has joined ##openfpga
aquijoule_ has quit [Ping timeout: 240 seconds]
richbridger has joined ##openfpga
freemint has joined ##openfpga
<freemint>
I am in contact with a company that wants to make an programmable analog computer on a chip (also called fpaa). I would like to encourage them to have an open source toolchain. Are there any components in the open fpga world that would be adaptable for this and could be reused?
<freemint>
If you are wondering what such a circuit might look like, i made an illustration yesterday: tinyurl.com/hvat4s52
<freemint>
To give some more details the fpaa will be probably a bunch of analog standard cells, D/A, A/D connected via a crossbar switch. Since the analog signals are not of high bandwidth and the integrators not that fast signal travel time should be no objective (maybe a contraint).
<Lofty>
freemint: Unfortunately the only tooling we have would be Yosys, which is pretty strictly digital
<Lofty>
But maybe you could get nextpnr to perform routing
<freemint>
I considered that too. I'm currently reading up on Nextpnr adn watch some talks.
<sorear>
there's an old project around here to support cypress psocs which might be relevant, although i never looked deeply into it
<freemint>
What are psocs?
<freemint>
Wait i google
specing_ has joined ##openfpga
specing has quit [Ping timeout: 252 seconds]
specing_ is now known as specing
<freemint>
cypress psoc is fascinating but it looks like it is meant to enable a digital processor to interact with the analog without on pcb component. This is different from routing mostly analog signals
<sorear>
yeah, it's different but "might be relevant"
<sorear>
I thought psoc had on-chip mixed-signal routing, which would pose some of the same problems you have
<sorear>
looks like pointfree's thing https://github.com/lowfatcomputing/forth-psoc-utils but they haven't been on IRC in two weeks; if the mixed-signal routing is similar enough to what you're doing it could make sense to email
<freemint>
Now that you explained your reasoning more i agree with you.
<sorear>
I should clarify I'm making assumptions based on things I've heard secondhand and never actually read the PSoC documentation - it might not work the way I think it does
sgstair has quit [Ping timeout: 240 seconds]
emeb has joined ##openfpga
sgstair has joined ##openfpga
<freemint>
Does nextpnr support distributed computing?
<pie_>
noob question: if you want programmable low bandwidth analog stuff, wouldnt you want to use an ADC-logic-DAC configuration? is the tradeoff cost and latency? im guessing the digital solution is also easier for noise resistance?
<freemint>
pie_, not a noob question.
<freemint>
Logic is not that good at integrating (solving ODEs) as analog components. The hope is that those chips give faster, more energy efficient solutions to ODEs. You don't need much bandwidth to simulate a process at 100-1000x real time speed at roughly half floating point precision.
<freemint>
For many control applications that would be good enough. It might also be super interesting for climate simulation.
<freemint>
https://arxiv.org/pdf/2102.07268.pdf is a publication by people from the company i am in contact with where they kinda justify why they think that it is interesting.
<pie_>
aha
<q3k>
freemint | Does nextpnr support distributed computing?
<q3k>
not last time i checked
<q3k>
i'm not even sure any of the algorithms involved parallelize well
<q3k>
(cc gatecat ^)
<q3k>
ah, at least the router is multithreaded now, it seems.
<freemint>
router2 seems to be a big improvment
<gatecat>
it works well for some things but not others, there might be another router in the pipeline
<q3k>
anyway, i don't know about the internals of placer1/placer_heap/router2 to tell you more about the feasability of shoving this into a map/reduce or mpi or something
<gatecat>
but yeah, anything like distributed computing would be a long way off and realistically only practical for very big (ie 500k LUT+) devices where you can partition into decent chunks
<gatecat>
unless you want distributed computing in the sense of just trying different seeds on different machines and seeing which one wins
<freemint>
I was just curious it isnot relevant for my application as the analog computers on a chip will probably start out with <2k elements.
tokomak has quit [Ping timeout: 245 seconds]
<freemint>
Could nextpnr be used with an architecture that is not tile based, for example 3d or irregular shaped? Could it deal with an FPGA with no routing, just local connections between neighboring hexagons?
<gatecat>
irregular shaped should be OK - quite a few FPGAs with hard processors, etc, have cut outs in their shape already
<gatecat>
3D would be a problem
<mwk>
3d would be a major pain in the ass
<mwk>
irregular... well everything can be made into tiles with a hammer
<mwk>
and as for "no routing", well if you really had no routing you'd have no need for a router
<mwk>
but really what happens in such things usually is that you use cells in some kind of bypass mode as routing
<mwk>
and that's supported
<mwk>
if you really truly can only support direct cell-to-cell connections... well then you have a problem
<freemint>
thanks for your comments it helps me get a better grasp on nextpnr capabilities.
<freemint>
Would it be considered an gross missuse if nextpnr is used to place&route breadboards with a given amount of available components?
<mwk>
that... doesn't sound like a good tool for the job
<freemint>
how so?
<mwk>
breadboards don't really map to the "there are the following logic blocks available at the following coordinates" model
<mwk>
it's more like "place any kind of thing anywhere as long as it doesn't physically collide"
<gatecat>
yeah, if you are going to abuse anything for this starting from an ASIC placer would make more sense
<freemint>
Is nextpnr appropiate if you have a switchboard of fixed function elements and you can plug wires between arbitrary ports but you are limited what physical wires you have?
<gatecat>
it's more intended if you have configurable connections between wires than can actually move the wires around...
<freemint>
I think i got a better grasp of nextpnr now.
<mwk>
nextpnr is a fairly complex and hard to use (as a person doing the porting to a target) tool optimized for a particular purpose, which is finding its way around FPGA routing fabric
<mwk>
if you have a different use case, all the optimizations that minimize FPGA routing delays are simply not worth the price of the complex tool
<freemint>
So if delays are not relevant for my usecase nextpnr might be a bad choice?
<mwk>
and the nature of FPGA is that you have fixed point-to-point routing channels with fixed muxes
<mwk>
if delays don't matter, that already means you have a much simpler problem
<mwk>
but the real reason it's a bad choise is that routing channels are not fixed in that case
<freemint>
With an analog computer on a chip (interconnected by fixed muxes) the delays are irrelavant so i am not looking for an delay optimal satisfiable solution but just an satisfiable solution (maybe minimzing cross channel signal polution). Would nextpnr be a sensible target then or should i write my own pnr?
<mwk>
okay, that's fairly close to the nextpnr model
<gatecat>
the only problem is that the placer assumes it can route anywhere-to-anywhere
<mwk>
it would still be modelling the wrong thing (delay instead of whatever analog signal integrity metrics are), but it sounds like it would be able to spit out a solution
<gatecat>
while you can kind of fudge it with the various legality and cluster APIs it gives you, it's unlikely to give very good performance that way
<freemint>
by performance you mean time to route or poor objective in routing?
<gatecat>
if you use the validity APIs to force connected things to be adjacent, the placer may well end up pathologically slow, because it's not designed for such a case
<gatecat>
if you have route-throughs so things don't actually need to be adjacent, then it will probably be a much closer fit to what nextpnr expects
<freemint>
How heavily is the "must clock high" objective backed in to the simulated annealing?
<freemint>
*baked
<gatecat>
it won't be baked in at all, if you don't give it timing data (and I'm not sure if analog stuff has a critical path, so the cell timing wouldn't make sense anyway)
<freemint>
The analog components i'm dealing with doesn
<freemint>
't have a critical path.
<gatecat>
so if you don't give it any timing data, because it won't have a critical path to optimise, both HeAP (the analytical placer) and SA will be purely wirelength-driven
<freemint>
My bad. I thought wirelength equivalent timing data.
<gatecat>
so the metric nextpnr tends to use is basically (wirelength + delay*criticality^n)
<gatecat>
where criticality is a value between 0 and 1 of how close an arc is to the critical path, and n is an exponent between about 2 and 7
<freemint>
So i could swap out the simulated annealing objective function and get good solutions for analog signal integrity using SA for small chips?
<gatecat>
probably, given a bit of retuning (I suspect you could add a similar heuristic to the matrix being solved in HeAP, too)
<freemint>
Would you recommend using nextpnr to pnr some problemset you want to be able to implement to search the space of architecture configurations, interconnect options and layouts when designing an architecture for an analog computing on a chip?
<freemint>
As in design your architecture such that nextpnr can route the problems you care about?
<freemint>
(on hardware you make)
<gatecat>
that seems like a reasonable enough approach
<gatecat>
it's certainly a good idea to have a go at PnRing some stuff to see if it's practical or not before taping out
<gatecat>
ideally you would have some way of doing full system simulations with the resulting "bitstream" too
<freemint>
Maybe throwing it into LTSpice or something could work
<freemint>
Ok, i am confident enough that in my conversation with the acoac company i'm going to pitch them developing against nextpnr and make nextpnr part of their toolchain.
<gatecat>
awesome! feel free to post here or on github if you hit any issues
<freemint>
(With analog computers you need some different front end languages and special kinds of reasoning there but once they produced some netlist nextpnr could eat that and match it against chip capabilities.
<freemint>
I don't get paid by them so i don't get paid enough to write pythom or C++ ;-)
<freemint>
I heard in a talk that the architecture can return conflicts caused by some assigment to the nextpnr loop such that bad past assignments can be undone or something. Is that correct?
<gatecat>
yeah, nextpnr allows architectures to tell the placer/router if things they have done are valid or not
<gatecat>
this is used to deal with things like shared flipflop control signals in FPGA tiles, for example
<gatecat>
incidentally, if you don't mind me asking, is this Mythic by any chance? a friend sent me an article about them the other day, by coincidence
<freemint>
Nope it's a german company called Anabrid
<gatecat>
interesting
<freemint>
Can i get nextpnr to return some conflicts to the thing that generated the thing i feed into nextnpr. As in "you asked me to route an design with 10 times function block B but this target has only 8 such blocks, either you send me another thing to route matching that constraint or you go and fail,"
<gatecat>
that's a placement issue not a routing one, but atm that could only be done by parsing the error output of nextpnr
<freemint>
meh ...
<gatecat>
indeed
<freemint>
Is that something you would consider adding somewhere in the middle of your infinite list of "that's an good idea"?
<freemint>
;-) I don't expect you to implement it but it might good for some workflows.
<gatecat>
yeah, particularly if you can come up with a good spec for creating this data it seems reasonable
<freemint>
This is something i will be thinking a bit about when i'm bored.
<freemint>
This company made an 80s style analog computer as a test bed they sell commercially and opensourced the firmware so i am guessed they would be receptive towards open sourcing stuff.
<freemint>
If you want to look at a few pictures of switch boards or an get impression what degree of VLSI analog computer still have ahead of them here is a manual with some pictures: http://analogparadigm.com/downloads/handbook.pdf
<freemint>
gatecat, are you the david who gave all the nextpnr talks over the last years?
<gatecat>
to some extent or other, yes
<freemint>
Thank you for the talks, they enabled to ask less stupid questions here.
<gatecat>
glad they were useful!
<freemint>
are non sat-based pnr tools capable of proving that a certain request is unsatisfiable?
<freemint>
Also if you are considering routing with sat solvers, you might also want to consider pseudo boolean formulations instead as the make cardinality reasoning, pidgeon hole reasoning a lot quicker due to a stronger system of reasoning: https://gitlab.com/miao_research/roundingsat is one pb solver
tokomak has joined ##openfpga
<freemint>
There won't be any literature on it but if you find it hard to put the constraints into cnf pseudo boolean might be easier to deal with,
<gatecat>
no, nextpnr as it stands will either fail or simply run indefinitely if its heuristics fail to find a solution
<gatecat>
I still need to think about SAT stuff, but SAT really struggles to scale to typical FPGA problems unless used for a small window
<gatecat>
I'll have a look at pseudo boolean though as cardinality would definitely be important for any FPGA SAT stuff...
<freemint>
Jakob Nordström gave a series of great recorded talks earlier this year at the simons institute. I don't quiet know which talk would the best one to get started but there is an 2 hour long without a number (overview of all talks) or the number 1 talk might be an good introduction.
<freemint>
the number 1 talk is only 23 minutes so i would stat with that.