<pie__>
i really hate it when things get closed on SO for being too broad or whatever
<pie__>
but reference requests are like some of the most damn useful parts
<pie__>
and they seem to get closed a lot heh
<pie__>
but not always before getting good results
<pie__>
not sure if the SO i probably got that off of (closed it already) was closed, im just ranting i guess
unixb0y has quit [Ping timeout: 252 seconds]
TavyCats has joined ##openfpga
unixb0y has joined ##openfpga
<Flea86>
pie__: Nice one. What? No "we're in life flynn" or "What a bobby dazzler" comments in that doc? xD
<pie__>
lol
futarisIRCcloud has joined ##openfpga
luvpon has joined ##openfpga
TavyCats has quit [Ping timeout: 268 seconds]
TavyCats has joined ##openfpga
TavyCats has quit [Ping timeout: 250 seconds]
emily has quit [Quit: Reconnecting]
emily has joined ##openfpga
TavyCats has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
<pie__>
is all engineering like this
<pie__>
Now that you understand what a thou is, we’ll throw another spanner in the works with the term “mil” (or “mils”). 1
<pie__>
“mil” is the same as 1 thou, and is NOT to be confused with the millimeter (mm), which is often spoken the
<pie__>
same as “mil”. The term “mil” comes from 1 thou being equal to 1 mili inch. As a general rule avoid the use of
<pie__>
“mil” and stick to “thou”, it’s less confusing when trying to explain PCB dimensions to those metricated non-PCB
<pie__>
people.
<pie__>
hate is a strong word
<Flea86>
good old imperial vs metric.. only answer is to recognize and be conversant in both
<pie__>
sigh...being reasonable can be horrible :P
<Flea86>
sometimes
<TavyCats>
caoeuchaeosuch
moho1 has quit [Ping timeout: 250 seconds]
<TavyCats>
gods i hate that the thou unit is a thing
<gruetzkopf>
metric only works quite well
moho1 has joined ##openfpga
<TavyCats>
yes
azonenberg_work has joined ##openfpga
<Flea86>
gruetzkopf: oh yeah, metric is preferable.. seeing 0.064" in connector drawings hurts my eyes...
<sensille>
2.54mm spacing is better?
<Flea86>
Not better, just familiar
<Flea86>
Soviet pin spacing on their ICs was 2.5mm :)
<azonenberg_work>
eeeew
<Flea86>
lol
<azonenberg_work>
that's like 1.25mm
<azonenberg_work>
so close to english units but not quite
<azonenberg_work>
1mm or 2mm are sane
<Flea86>
azonenberg_work: Right. I was referring to DIP ICs (relative to 2.54mm)
<azonenberg_work>
yeah but what i mean is, use a round number in english or metric units
<Flea86>
Yeah, 2mm DIP pins is definitely doable.
<Flea86>
*is/are
<azonenberg_work>
more importantly 2mm is visibly different from 2.54
<azonenberg_work>
vs 2.5 and 2.54 are so close you cant tell by looking :p
<Flea86>
eh, it's only a few misaligned/bent pins... it's still good ;)
<sensille>
press fit
TavyCats is now known as catplant
<TD-Linux>
whitequark, btw I assembled another glasgow board today, and it's much better than the last hand soldered one
<TD-Linux>
however it still fails the voltage readback test, I think it's likely there's either a pcb or software error related to that on revb
<TD-Linux>
p.s. I can mail you this one if you like
<RaYmAn>
works for me™ :P
<RaYmAn>
just the obvious: Did you connect VIO to VSENSE for the test?
<tnt>
TD-Linux: you're shorting the two pins right ?
pie__ has quit [Ping timeout: 268 seconds]
<TD-Linux>
oh uh
<TD-Linux>
no :)
<tnt>
lol
<TD-Linux>
cool. now it very nearly passes. just out of tolerance on port b
<TD-Linux>
likely swapped resistors
<TD-Linux>
alright ordering parts to populate the other 12 boards now
<tnt>
Ahah. I still have 5 PCBs left (and matching stencil) if anyone is interested.
<sensille>
for what?
<Ultrasauce>
i'll take one
<sensille>
ah, glasgow
<tnt>
shoot me an email at 246tnt@gmail.com
GuzTech has joined ##openfpga
luvpon has quit [Ping timeout: 260 seconds]
Flux42 has quit [Quit: Paaaaatch]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Flux42 has joined ##openfpga
<swetland>
oh boo lattice, boo. one pmod connector and you routed the primary SPI interface to it so I can't use a pmod and keep talking to the part over the on-board FTDI
<daveshah>
Lattice never fail to disappoint with their dev boards
<daveshah>
Like picking an FT2232H and throwing away the second interface instead of providing a uart
<swetland>
yeah that blew my mind
* swetland
is looking forward to icebreaker becoming available at some point
<swetland>
random nextpnr observation of the evening: reporting an error would probably be preferable to assert()ing when you try to assign two different signals to one net
<daveshah>
yes
<daveshah>
imo Yosys should not be producing these netlists in the first place
<swetland>
that's fair, but I'd still argue error reporting on bogus input beats crashing
<swetland>
hmm. per the manual one is supposed to wait 100uS before enabling either the HFOSC or LFOSC -- is it not possible to run a ICE40 without an external crystal or clock? (obv the +/-10% on the HFOSC would limit the applications, but still)
<tnt>
swetland: one of the connector is almost a pmod, I just had to bring a solid ground at the right place and bring an IO to a normally n/c pin.
<tnt>
swetland: well if you insist on that delay you could have a external rc charging tokeep the hf disabled ... but I've never had issue with having HFOSC enabled directly.
<tnt>
maybe its a bit unstable at the beginning ? I guess you could have a reset counter that wait a certain number of clock cycle before releasing your reset to make sure hfosc is 'booted' properly.
<tnt>
(then you would only have that one counter clocked by a potentially out-of-spec osc)
<swetland>
well the device does enable the hfosc in order to load its configuration
<swetland>
so I suspect if the config doesn't conflict there's no interruption
<swetland>
and/or the amount of glitching the lfosc could do is probably pretty minimal so perhaps driving a little POR startup timer/fsm from that makes sense
* swetland
shall do some experiments
<tnt>
I also wanted to play with the "trim" input of the hfosc ...
<swetland>
none of the docs seem to mention that
<tnt>
I know :)
<tnt>
exactly why I want to try it.
<tnt>
but it has a 10 bit TRIM port.
<tnt>
(like the PLL has dynamic reconfic as well which isn't mentionned. Would be useful for things like dynamic video mode and stuff like that)
* swetland
nods
<daveshah>
I did test this a while ago
<daveshah>
I think arachne supports trimming but not nextpnr
<daveshah>
It's neither linear nor monotonic. Range is over an octave so step size is pretty coarse - a few hundred kHz iirc
<daveshah>
You can build a sort of crude DPLL with it if you want to lock to another source and have used the proper PLL already...
<tnt>
Some recent uC can do USB without external xtal. They dynamically trim their internal oscillators by measuring the interval between SoF packets on the USB bus as a timing reference. And I tought something like that might be doable.
<tnt>
at least nextpnr adds the ports : "for (int i = 0; i < 10; i++) add_port(ctx, new_cell.get(), "TRIM" + std::to_string(i), PORT_IN);"
<daveshah>
I think there's a config bit that needs to be set to enable trimming
Miyu has joined ##openfpga
<swetland>
I'm having fun with my little cpu working in simulation (verilator direct from source verilog) but misbehaving on the metal. same misbehaviour with both lattice and nextpnr, so I strongly suspect it's my bug. I should rig up simulation using the outputs from nextpnr and lattice's tools to compare that.
<swetland>
but first because hey I'm not using the SPRAM, I'm building a little 64ch x 16Ksample logic analyzer to capture internal cpu state and slurp it out a serial port
<tnt>
daveshah: yeah, there seem to be a cbit controlled by the "TRIM_EN" parameter.
<daveshah>
That's the one
<tnt>
in arachne it was a different primitive SB_HFOSC_TRIM but in nextpnr, it's the same primitive with a parameter.
Miyu has quit [Ping timeout: 240 seconds]
<tnt>
ah well no ... that param is never transferred from SB_HFOSC to ICESTORM_HFOSC
futarisIRCcloud has joined ##openfpga
m_w has quit [Ping timeout: 250 seconds]
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
catplant has quit [Quit: WeeChat 2.2]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has quit [Read error: Connection reset by peer]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Miyu has joined ##openfpga
genii has joined ##openfpga
jevinskie has joined ##openfpga
rohitksingh has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
egg|zzz|egg has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Ping timeout: 268 seconds]
oeuf has joined ##openfpga
rohitksingh has joined ##openfpga
GuzTech has quit [Quit: Leaving]
pie_ has joined ##openfpga
<pie_>
so in kicad im running the ERC and it gives me unconnected pin errors for these: https://a.uguu.se/B6c713JpERrk_Selection_008.png and i dont get it, because it should error for all of them if theres a problem with the net?
<pie_>
see top left, and right
<whitequark>
pie_: you need to place the power unit for those
<whitequark>
i think
<pie_>
what do you mean
m_w has joined ##openfpga
<pie_>
oh
<pie_>
i..think it only had the two units...
* pie_
looks
<pie_>
yeah they only have unit A and unit B
<whitequark>
no idea then
<pie_>
ah wait
<pie_>
probably user error
<pie_>
why cant i copy out the error messages from kicad -_-
<pie_>
basically it says pin connected to some other pins but no pin to drive it
<whitequark>
no idea
<pie_>
(which is to say i was saying the wrong error)
azonenberg_work has joined ##openfpga
<pie_>
ok i think the problem is all the power pins on the mcu are labeled as inputs
<pie_>
(sidenote: there probably shouldnt be a vcc on VIN)
Xark has quit [Ping timeout: 240 seconds]
Xark has joined ##openfpga
<adamgreig>
pie_: you need a PWR_FLAG
<adamgreig>
to tell kicad that net is 'powered'
<adamgreig>
i.e. you have a lot of types of 'power input' but no 'power output' on that net
<adamgreig>
usually your voltage regulator's output would be a 'power output'
<adamgreig>
but if it's actually just a connector, or it goes through an inductor, it won't be
<adamgreig>
in the power lib there's PWR_FLAG or something which you can just place on nets that are powered to tell kicad
TavyCats has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 244 seconds]
[X-Scale] is now known as X-Scale
rohitksingh has quit [Ping timeout: 250 seconds]
ym has quit [Remote host closed the connection]
<whitequark>
daveshah: I am hitting the issue where nextpnr does a global promotion of some signal on critical path that causes the design to fail timing *again*.
<whitequark>
this is very aggravating.
<whitequark>
(I hit it in arachne before.)
<daveshah>
I didn't want to promote logic globals at all tbh
<whitequark>
fully 1/4 of the critical path is spent in SB_GB...
<whitequark>
do you think you can add a switch?
<daveshah>
sure
<whitequark>
thanks!
<balrog>
whitequark: USB-C connector would be nice.
<balrog>
I find microUSB to be crap, mechanically :(
<daveshah>
I'm going to make logic promotion default off, I think packing CE/LSR/CLK is more useful in most cases anyway
<daveshah>
because it also makes FF packing easier
<whitequark>
yep
<daveshah>
s/packin/promoting in message before last
<whitequark>
currently trying to get a 33.33 MHz design to work on UP5K...
<tnt>
Ah, adding a switch for that was on my todo, I guess I can cross it off :p
rohitksingh has joined ##openfpga
edmund20[m] has quit [Remote host closed the connection]
indefini[m] has quit [Remote host closed the connection]
Wallbraker[m] has quit [Remote host closed the connection]
thehurley3[m] has quit [Read error: Connection reset by peer]
pointfree[m] has quit [Read error: Connection reset by peer]
nrossi has quit [Remote host closed the connection]
galv[m] has quit [Remote host closed the connection]
AlexDaniel-old[m has quit [Read error: Connection reset by peer]
jfng has quit [Remote host closed the connection]
m_w has quit [Quit: Leaving]
<pie_>
adamgreig: yeah i saw stuff about that. I wasnt sure if I should do that or ?fix? the MCU footprint
<adamgreig>
the mcu footprint is fine - those pins should be power inputs
<adamgreig>
either your voltage regulator should have a power output pin, or you need to label a net as an output using the flags
<adamgreig>
(the flag is just a dummy component with a single power-output pin, basically)
<adamgreig>
you might consider putting your gnd pins below the positive power pins, but it doesn't matter to kicad :p
<pie_>
i had an arduino micro handed to me so i figured it just use the micro usb for power and serial to a raspi or somesuch
<pie_>
which doesnt show up on my schematic, so i guess i can just use the power flag
<whitequark>
daveshah: thanks!
<adamgreig>
pie_: I suppose you might consider your 5V and 3V3 lines as power outputs _from_ the arduino, then..
<adamgreig>
I was thinking of powering chips but it sounds more like you're drawing power from the arduino to power other things?
<pie_>
adamgreig: yeah. but in the case of the 5v, which is what im using, i think it just goes straight to the usb power?
<adamgreig>
yep it does
<adamgreig>
but that's ok, if you had the usb connector on your schematic you could flag the usb 5v line as a power output instead
<daveshah>
whitequark: As the nextpnr state is hopefully quite contained to Context, I would like some kind of embarrassingly-parallel portfolio method type approach to difficult designs
<daveshah>
Just run 8 threads and this could well be a 10-15% boost
AlexDaniel-old[m has joined ##openfpga
<pie_>
adamgreig: something is still screwy. so what i did is i just hooked up a +5V flag to my global vcc label, is that wrong?
<pie_>
still gives the same errors
<adamgreig>
the +5V power symbol just lets you connect all the 5V nets together
<adamgreig>
but it's not itself a 'power output' (since you'll have lots of them on the same net)
<adamgreig>
you need the one called 'FLAG' or 'PWR_FLAG', it's a filled diamond
<pie_>
oh. ok. it had "power flag" as a tag so i figured it would be ok
<adamgreig>
(usually have that in addition to a +5V arrow)
<tnt>
whitequark: btw, you can also look at the yosys PR I have if you want to help timing a bit.
<daveshah>
I've just pinged clifford again about that
<pie_>
adamgreig: i have the same problem with ground i think but adding a pwr_flag didnt help
<adamgreig>
you should be able to add a pwr_flag to gnd the same way, is it definitely on the same net?
<adamgreig>
https://imgur.com/a/X8gWU5O has an example with a power input that needs a flag, gnd has a flag, 3v3 has a flag (since it's from an inductor), but 1v2 doesn't need a flag because the VOUT pin on IC3 is a "power output"
<adamgreig>
the power flag thing is pretty weird. I guess a lot of people just ignore erc errors though.
<adamgreig>
kicad is just trying to help!
<cr1901_modern>
It has gotten a _lot_ better, but the fact remains that when I use it, unrelated problems tend to cascade
rohitksingh has quit [Ping timeout: 268 seconds]
<pie_>
umm ok actually strangely enough it does seem to be ok i think? but my number of erc warnings seems to be the same
<adamgreig>
you might just have other warnings :p
<pie_>
yep :P
mumptai has joined ##openfpga
Wallbraker[m] has joined ##openfpga
pointfree[m] has joined ##openfpga
nrossi has joined ##openfpga
indefini[m] has joined ##openfpga
thehurley3[m] has joined ##openfpga
jfng has joined ##openfpga
galv[m] has joined ##openfpga
edmund20[m] has joined ##openfpga
<pie_>
yup ok looks good
<pie_>
if only i could mark specific warnings to be ignored, with a rationale
rohitksingh has joined ##openfpga
<pie_>
(unconnected mcu legs will use an internal pull-up in input mode instead of floating)
<daveshah>
Put a "no connect" flag (q key iirc) on the unused pins
<pie_>
hm ok
<pie_>
ahh, yep found the tool
<TavyCats>
does anyone have good kicad bindings for dvorak?
<TavyCats>
the qwerty binds are nice because they can be done mostly on one hand and mouse in other
<pie_>
TavyCats: arent the current bindings largely based on the words...oh
<pie_>
daveshah: will this still create pcb pads?
<TavyCats>
yes
<pie_>
ok
<pie_>
im actually not sure if the information would even transfer to the next level tool
<pie_>
i.e. would footprints even know about this
<daveshah>
I don't think it's used for anything other than display and erc
<adamgreig>
yea, the pcb editor doesn't care about no-connects
<adamgreig>
the netlist that's exported just won't have that pin
<pie_>
aaand now i have to do the part i dont feel like doing which is actually picking components :p
<adamgreig>
ugh yes that's the worst
jfng has quit [Remote host closed the connection]
Wallbraker[m] has quit [Remote host closed the connection]
AlexDaniel-old[m has quit [Remote host closed the connection]
edmund20[m] has quit [Remote host closed the connection]
thehurley3[m] has quit [Remote host closed the connection]
nrossi has quit [Remote host closed the connection]
indefini[m] has quit [Read error: Connection reset by peer]
pointfree[m] has quit [Read error: Connection reset by peer]
galv[m] has quit [Remote host closed the connection]
<pie_>
does it really matter what esd IC thing i get
<adamgreig>
no but pick wisely because you'll copy-paste the same one for the next five years, if I'm anything to go by :p
<pie_>
they have different ?breakdown? voltages? or is that operating voltages
<adamgreig>
you want them to start conducting ESD spikes at some voltage above where you'll be nominally operating
<adamgreig>
so if your logic is all 3v3 (like usb or 3v3 spi or whatever) then a 6v breakdown would be fine, but if you're doing +12V RS232 it would be bad
<pie_>
right
<pie_>
i actually forgot about that
<pie_>
im probably at 5v, i was thinking abot this 15 / 30 kV stuff
<adamgreig>
that's the maximum voltage spike it's rated to handle; bigger is just better but probably unnecessary
<pie_>
i dont know how many volts i do when i shock something >_>
AlexDaniel-old[m has joined ##openfpga
<whitequark>
pie_: HBM is like 5 kV I think?
<whitequark>
ah, there are classes
rohitksingh has quit [Remote host closed the connection]
<tnt>
Currently nextpnr doesn't seem to always load asc fully easier and not all 'connections' are drwn on the GUI.
<swetland>
will definitely check that out
<tnt>
s/easier/either/
Wallbraker[m] has joined ##openfpga
jfng has joined ##openfpga
pointfree[m] has joined ##openfpga
nrossi has joined ##openfpga
galv[m] has joined ##openfpga
indefini[m] has joined ##openfpga
thehurley3[m] has joined ##openfpga
edmund20[m] has joined ##openfpga
flaviusb has quit [Quit: Leaving.]
flaviusb has joined ##openfpga
pie__ has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 252 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
<tnt>
daveshah: something has been bugging me when writing code in nextpnr ... should I be using id_XXXXX or ctx->idx("XXXX") ?
<daveshah>
You should be using id_XXXX if it is in constids.inc
<daveshah>
I know this isn't always followed for legacy reasons
<daveshah>
There's no need to add stuff to constids.inc to use id_XXXX unless it's a hot path
<tnt>
Ok, I'll try to stick to that then :)
TavyCats is now known as catplant
Adluc has quit [Ping timeout: 252 seconds]
Adluc has joined ##openfpga
<tnt>
daveshah: When LUTCascade is used, is the normal output still usable as well ? (i.e. to drive non-cascaded logic)
<daveshah>
tnt: yes
<daveshah>
You can still have a flip flop in there too
<daveshah>
The cascade output comes from before the FF
<tnt>
Oh, that's pretty nice actually.
<daveshah>
Be aware that FFs can't always be packed together though
<tnt>
(tricky to automap correctly, but nice)
<daveshah>
Also, it's useful to bear in mind that LUT inputs are permutable
<tnt>
because of the control set you mean ? or other reason ?
<daveshah>
Control set or config
<tnt>
yeah, for lut inputs, I thought about that.
<tnt>
Also .. .interaction with carry chains ...
<daveshah>
I don't think the two should be used together
<daveshah>
I understand the vendor tools never combine the too
<tnt>
make sense. Would be pretty tricky ...
<tnt>
whitequark: btw, did disabling global promotion improve your timing ?
* tnt
still working on #141 ... turns out it's far from easy to check all conditions and provide good error message for every cases.
<whitequark>
tnt: yes. just enough to pass constraints.
<whitequark>
daveshah: thanks!
<daveshah>
\o/
pie_ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
<whitequark>
daveshah:
<whitequark>
Info: Max frequency for clock 'sys_clk': 37.00 MHz (PASS at 30.00 MHz)
<whitequark>
Info: Max frequency for clock 'lpcmonitorapplet_lclk_i_$glb_clk': 36.15 MHz (PASS at 33.33 MHz)
<whitequark>
with some slack even
<daveshah>
sweet
mumptai has quit [Quit: Verlassend]
<kbeckmann>
daveshah: I'm curious, how come the 12k lut variant of ecp5 isn't supported in trellis? is the bitstream too different or isn't there enough interest/reason to reverse it?
<daveshah>
lool
<daveshah>
wot 12k
<daveshah>
It's actually the same die as the 25k
<kbeckmann>
ohhh
<kbeckmann>
i had no idea.
<daveshah>
You can use it with Trellis with the idcode override function of ecppack
<kbeckmann>
wow that's awesome
<daveshah>
But I'm trying not to make a big show of this right now
<kbeckmann>
i see why that would be controversial.
<daveshah>
Indeed
<daveshah>
Lattice never complained for icestorm with the 4k/8k
<daveshah>
But we didn't make it a headline feature there either
<swetland>
I wonder if they make that decision (lg/sm part) before or after packaging. one would imagine it wouldn't be hard to fuse it to reject the larger bitstream early on, but probably a pain if they fully package and make a late binding decision what silkscreen to use
<daveshah>
The only thing the change is the JTAG ID
<daveshah>
I am pretty sure this is in OTP
<daveshah>
That you could access via JTAG via some unknown sequence
<swetland>
and/or I suspect most vendors will make no promises about using a part above capacity (maybe it was binned because the other quadrant failed test, maybe it was binned for market segmentation, who can say) and most commerical customers wouldn't want to make the chance
<daveshah>
Indeed
<daveshah>
The vendor tools seem to implement a resource limit, rather than a region based lock out
<daveshah>
So a partially functioning device is pretty much ruled out
<swetland>
oh *that*'s fascinating
<daveshah>
What they do almost certainly bin on is SERDES
<daveshah>
The 12k is only available without a serdes
<daveshah>
So it's a good way of dumping parts with out of spec serdes
<daveshah>
In addition to the 25k variant without a serdes
<swetland>
also kind of impressive in that even with a resource limit having more room to arrange things, conceivably designs just-near-capacity in the artificially smaller parts have a better chance of placing...
<RaYmAn>
so the non-serdes version might still have some serdes, even if it could be slower?
<daveshah>
swetland: I understand this is a well observed issue in the Xilinx world
<daveshah>
People using the resource locked Artixes expect to be able to run fpgas at 100% and are surprised when moving to devices without fake capacity
<daveshah>
RaYmAn: I'd guess so
<daveshah>
I'm pretty sure it's bonded
<daveshah>
But who knows how out of spec it might be
<swetland>
whee. my cheesy on-chip logic analyzer is capturing traces of weird things happening
<sorear>
i'm going to point out that if you look at the ecp3 datasheets, the ecp3-12 and ecp3-25 have different bitstream lengths
<sorear>
so the ecp3-12 was probably a real part
<daveshah>
Yeah
<daveshah>
Occasionally bitstream lengths can be slightly different for fake parts because of ebr init
<daveshah>
If the fake ones have some ebr locked out of use
<SolraBizna>
swetland: that happens to me every time I try to get clever with my clocks
<sorear>
re. SiC and VEXAG, I've turned up one secondary source for NRAM retaining data at 800C, can't find a primary source yet
<SolraBizna>
when I think about the resource utilization issue, I start thinking about trying to "do FPGA" by hand
<SolraBizna>
I need to remind myself that it takes a lot of practice and perseverence to get as good as simulated annealing, even at the iCE40 scale... and then you've sacrificed flexibility and "compile time" for your trouble
<Bob_Dole>
just looked up NRAM.. ok that looks interesting.
<SolraBizna>
that's the neatest mechanical memory I've seen
<SolraBizna>
though does it really still count as "mechanical" when Van Der Walls forces are some of the strongest in your system? :P