knielsen has quit [Read error: Connection reset by peer]
knielsen has joined ##openfpga
azonenberg_work has quit [Ping timeout: 245 seconds]
emeb has left ##openfpga [##openfpga]
knielsen has quit [Ping timeout: 272 seconds]
knielsen has joined ##openfpga
knielsen has quit [Ping timeout: 250 seconds]
lovepon has quit [Ping timeout: 260 seconds]
wpwrak has quit [Ping timeout: 268 seconds]
wpwrak has joined ##openfpga
unixb0y has quit [Ping timeout: 252 seconds]
unixb0y has joined ##openfpga
SpaceCoaster_ has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
SpaceCoaster has joined ##openfpga
_whitelogger has joined ##openfpga
knielsen has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
azonenberg_work has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
lovepon has joined ##openfpga
knielsen has quit [Ping timeout: 244 seconds]
knielsen has joined ##openfpga
knielsen has quit [Ping timeout: 252 seconds]
knielsen has joined ##openfpga
rohitksingh_work has joined ##openfpga
Bike has quit [Quit: Lost terminal]
knielsen has quit [Ping timeout: 246 seconds]
knielsen has joined ##openfpga
knielsen has quit [Ping timeout: 268 seconds]
SolraBizna has joined ##openfpga
<Bob_Dole>
Welcome
<SolraBizna>
maybe!
<Bob_Dole>
for random crap people in this channel also talk about: ##whitequark seems to be it.
<SolraBizna>
so... say I have an iCE40LP, and say I have no alternative but to configure it in SPI slave mode
<SolraBizna>
and say I have to bitbang that
<SolraBizna>
and say the absolute fastest I could flip SCLK on and off and do nothing else (including send data) was exactly 1MHz
<SolraBizna>
the datasheet says 1MHz is the minimum allowed speed for writing
<SolraBizna>
is that actually true?
<SolraBizna>
(I can't actually test this myself, as contrary to what I just said, I don't actually have an iCE40LP yet...)
<Bob_Dole>
we're designing a board, but there's some things we're pretty firm on: 65816 based MCU MRAM/SRAM that will be ECC'd via the ice40.
<Bob_Dole>
by "we're" I mean him. I'm soldering and sourcing parts
<SolraBizna>
I have an irrational hatred for flash memory, which is why we aren't going the (normal, sane) "use an SPI flash" route
<SolraBizna>
and the SPI MRAMs don't support Fast Read
<SolraBizna>
(the ones I could find, anyway)
<Bob_Dole>
I wonder.. if SPI FRAM exists with that feature?
<SolraBizna>
FRAM is destructive-read
<SolraBizna>
Badly timed reset or power failure during readout and *blam*
<Bob_Dole>
Oh. Well hell
<SolraBizna>
I didn't actually check whether any of the SPI FRAMs have protection against that particular problem...
<sorear>
nobody's figured out how to make FRAM with enough capacitance to finish a write and sell it as a feature, huh
futarisIRCcloud has joined ##openfpga
<Bob_Dole>
oh yeah. EEPROM exists.
<SolraBizna>
isn't EEPROM synonymous with flash these days?
<Bob_Dole>
you can still get real eeproms I believe
<sorear>
you two know each other ?
<Bob_Dole>
Yes
<SolraBizna>
(for the record, the very first SPI FRAM I checked *does* support Fast Read)
<sorear>
the last time I talked to somebody about FRAM, I recall it being said that read endurance was a theoretical issue but only that because it's in the trillions of cycles?
<whitequark>
trillions of cycles?
<SolraBizna>
this datasheet says one trillion cycles per bit
<rqou>
Bob_Dole: i would suggest not immediately recommending ##whitequark to people
<SolraBizna>
that's a lot of bootups
<rqou>
gotta appear superficially normal first
<whitequark>
so like, one thousand writes at 1 GHz?
<whitequark>
you could kill it in less than an hour with a modern CPU
<Bob_Dole>
SolraBizna and me are very.. not normal.
<Bob_Dole>
and interested in all the topics in there already.
<SolraBizna>
but all I'm doing is configuring an FPGA on bootup, and occasionally reprogramming it because I made a mistake in my Verilog somewhere
<rqou>
ah ok, you already know them
<SolraBizna>
anybody got a spare iCE40 and random MCU and an appetite for tedium?
genii has joined ##openfpga
<sorear>
whitequark: this is a SPI part, it's not going to operate at 1 GHz, but yes
knielsen has joined ##openfpga
<cr1901_modern>
>65816 based MCU MRAM/SRAM
<cr1901_modern>
Interesting choice in part
<SolraBizna>
I think there was a missing comma
<cr1901_modern>
Are you using the microcontroller variant that WDC sells? (I forget the part number)
<SolraBizna>
W65C265S
<cr1901_modern>
Yes, that
<SolraBizna>
yup
<cr1901_modern>
Inb4 someone asks "why don't you use an ARM, they're 32-bit and cost less and use less power"
<SolraBizna>
lol
<sorear>
does the WDC chip have embedded MRAM and SRAM?
<SolraBizna>
the MRAM/SRAM are on the board, external
<cr1901_modern>
65816 assembly language is nice, but I wouldn't try compiling C for it. You can do _a lot_ of shitty things that make assembly programming easier, but high level langs absolutely hate
<cr1901_modern>
Biggest one being "you can move the DP reg"
<SolraBizna>
I'm writing an LLVM backend for the 65816, so that I can compile Rust and C to terrible (but runnable) 65816 code
<whitequark>
sorear: well ok, 10 hours at 100 MHz...
<SolraBizna>
Bob_Dole tricked me into fitting an entire MMU into the iCE40LP that he tricked me into using, so this might end up turning into yet another "Linux runs on the X (but is so slow nobody cares)" stories
<cr1901_modern>
I have no idea how you would deal with aliasing, unless you can prove DP is known to point somewhere at the beginning of each function
<cr1901_modern>
ditto with the A/X flags
<sorear>
whitequark: more like ~2 weeks once you factor in the clocks required to read an addressed bit once
<SolraBizna>
Well, one method of avoiding banking problems is murdering performance and code size by never using the zero page or absolute addressing modes
<sorear>
the DP thing sounds like an ABI consideration not an aliasing one
<SolraBizna>
keeping track of the A/X flags would be an ABI thing too
<sorear>
very similar to the mips/riscv gp-relative data
<SolraBizna>
I'm worrying about software a little later, once we've figured out enough of the hardware end that I don't have too bad of a moving target
<sorear>
what's sizeof(void*) and CHAR_BIT on your target?
<cr1901_modern>
IMO it's range is too small to be useful as a global pointer. And moving it when you exceed a 256 boundary carries the risk of "thrasing", if you need to access data in close proximity to a 256 byte boundary
<SolraBizna>
4 and 8, probably
<cr1901_modern>
for instance, queue head is at DP + 255, queu tail is at DP + 256... uh oh! Need to increment DP by 256 and access queue tail by DP + 0
<SolraBizna>
Right now, I'm more worried about making it so that the iCE40 can load its program from somewhere that will still be working when I am an old person
<sorear>
cr1901_modern: i thought you could increment DP by 128 and have hysteresis
<cr1901_modern>
I don't understand what you mean
<cr1901_modern>
oh, DP isn't signed
<SolraBizna>
Direct Page lets you anchor the zero page addressing mode anywhere in the low 64K, with byte resolution
<cr1901_modern>
err, the offset in DP-rel addr modes isn't signed*
<sorear>
doesn't matter
<cr1901_modern>
SolraBizna: The problem w/ using byte resolution is not having it on a 256 byte boundary has a penalty
<sorear>
it's a 256 byte window either way
<azonenberg_work>
SolraBizna: Does anyone make an IoT linux-powered toaster yet?
<azonenberg_work>
:p
<SolraBizna>
argh, penalty cycles
<Bob_Dole>
you know what they say, all toasters toast smurfs
<sorear>
i suspect that this can be made non-awful with sizeof(void*)=4, sizeof(ptrdiff_t)=2
<sorear>
but now is not the time &
* azonenberg_work
does not want his smurf tube going in a toaster
<cr1901_modern>
If I were making a 65xx calling convention, all regs would be caller saved :P
<azonenberg_work>
melting pvc smells awful
* sorear
wonders if PTRDIFF_MAX=128 is compatible with C
<whitequark>
azonenberg_work: i think so
<cr1901_modern>
There's a netbsd toaster. it uses some weird ARM based pc-104 board I think
<SolraBizna>
if I really can't bitbang a program onto an iCE40 below 1MHz, I can still do what I need by basically using an SPI SRAM as a very, very large shift register
<SolraBizna>
but I kinda don't want to do that
<SolraBizna>
I already have a few more components on this board than I want, and I haven't even started trying to figure out how to provide nine different voltages in a precise sequence yet
<Bob_Dole>
how're greenpaks?
<SolraBizna>
plus, using external memory on an MCU to program the memory controller that the MCU uses to access external memory is *already* silly
<sorear>
nine *different* voltages?
<Bob_Dole>
eInk.
<SolraBizna>
when I finally pried a datasheet from E Ink about the display I was looking at, I found out it needs -20V, -15V, -4V, 15V, 16.5V, and 25V (on top of the 3.3V and 0V I already have)
<Bob_Dole>
also 1.8V?
<SolraBizna>
the iCE40 wants another voltage, I forget if it's 1.8 or 1.6 volts
<SolraBizna>
and then we're also using *another* MCU in the "IO board" that wants whichever one of 1.8/1.6 that the FPGA doesn't want
<SolraBizna>
with the FPGA and the second MCU, I at least don't need to worry about sequencing... with the display, if I don't do it in the right order, broken English promises that permanent damage to the display will ensue
<zkms>
is there a pre-existing power supply sequencing IC that you can use
<zkms>
i havent looked at the set of available parts ;;
<whitequark>
there are some but not for like 8 voltages
<SolraBizna>
I'm sure there is, I just haven't gotten deep enough to find it yet
<whitequark>
glasgow uses such an ic
<whitequark>
i think once you get to 8 you use a cpld
<zkms>
is it possible to daisy chain them
<whitequark>
yes
<SolraBizna>
I found a really nice one that supports daisy chaining... and only supports voltages in the -6 - +6 range
<azonenberg_work>
zkms: greenpak is designed to make custom PMICs
<azonenberg_work>
the greenpak4 family has up to six comparators with internal references
<azonenberg_work>
plus a bunch of counters, luts, and ffs
<azonenberg_work>
so you can do sequencing state machines etc
<SolraBizna>
I broke the design into two boards partly so that I wouldn't have to worry about that part yet
indy has joined ##openfpga
<SolraBizna>
I guess there's nothing for me to do but expend an iCE40 on a test board
<TD-Linux>
also you can always just add an external pullup. seems easier than replacing the one on the board
<whitequark>
yeah
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has quit [Ping timeout: 252 seconds]
rohitksingh_work has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 272 seconds]
lovepon has quit [Ping timeout: 276 seconds]
genii has quit [Remote host closed the connection]
Bob_Dole has quit [Ping timeout: 276 seconds]
Bob_Dole has joined ##openfpga
<openfpga-github>
[Glasgow] hardkrash commented on issue #67: i thought about a DAC + current mirror, but didn't think of how to overcome compliance voltages with single supply 5V, unless this is not a concern with pulls.... https://github.com/whitequark/Glasgow/issues/67#issuecomment-429784413