<whitequark>
the gateware is mostly ready, i'm optimizing it but every feature should work as intended
<Flea86>
whitequark: Nice work. Definitely looks like a cross between AVR and MIPS
<whitequark>
Flea86: thanks
<whitequark>
there was 8051 there too.
<Flea86>
whitequark: Only two things worth taking from 8051 are the boolean processor and fast context switching tbh
<Flea86>
*bit-boolean
<whitequark>
yes, register windows
<Flea86>
Ah okay :)
<whitequark>
:P
<Flea86>
hehe
<Flea86>
whitequark: I made my own CPU design too https://github.com/Basman74/Sweet32-CPU That sits at ~900 LUT4 elements for a minimum 32-bit system, or 450 LUT4 elements for the cut-down 16-bit ALU variant
<whitequark>
oh, nice
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<whitequark>
I feel like by this point if I need a 32-bit one the decision to use an RV32 impl is obviousl
<whitequark>
*obvious
<whitequark>
but there are not many good 16-bit options
<Flea86>
Even modded an x86 c compiler backend to target it
<whitequark>
wtf
<whitequark>
i'm sorry you did what to target it
<whitequark>
that is cursed
<Flea86>
Yep. I used Smaller-C as the toolchain base... x86 works because Sweet32 is actually a highly optimized abstract of i386 ;)
<Flea86>
(and improved/extended)
<Flea86>
so the translation was relatively straightforward
<Flea86>
except for my use of skip opcodes, those are quite non-trivial to convert to relative jump tables
jevinskie has joined ##openfpga
<Flea86>
Alas, I never got around to resolving that issue, which limits the overall size of compiled routines for large sw projects
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
<swetland>
whitequark: I had not - interesting - I definitely don't like where I ended up with the 8reg/16bit more classic mips-y design
<whitequark>
swetland: let's merge forces?
<whitequark>
my design is very Migen-focused, intentionally, but maybe the ISA could use some more spread
<swetland>
maybe! let me take a closer look at where you're going. I was going to experiment with a more stack-based sorta thing, borrowing a bit from J1 / forth machine stuff
<whitequark>
swetland: one thing I haven't yet decided if I want to make is to reorganize the ISA a bit
<whitequark>
make all conditional jumps have a smaller bit width offset
<whitequark>
this frees up a bit of opcode space for shifts through carry
<swetland>
I think so far my conclusions in this spare are for medium-large parts risc-v rv32i feels like a pretty good fit with the benefit of heavy duty llvm/gcc support, but for smaller stuff there's room for something a bit more compact
<whitequark>
and add/sub with carry
<whitequark>
yes
<whitequark>
this is why i made boneless
<swetland>
I also really need to rename that cpu16 repo to gateware or something, as it's becoming more "assorted useful fpga tools"
_whitenotifier-6 has joined ##openfpga
<_whitenotifier-6>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fpxMn
<swetland>
better density than set conditional + jz/jnz
<swetland>
especially in a limited (active) register environment
<whitequark>
that too
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
<swetland>
ext vs mem is a separate io? address space?
Bob_Dole has quit [Remote host closed the connection]
<whitequark>
swetland: yes
<whitequark>
all the decisions are driven by absolute minimal BRAM and LUT count
<whitequark>
including for interfacing with peripherals
* swetland
nods. makes sense. so definitely multi-cycle and not pipelines
<swetland>
s/pipelines/pipelined/
<whitequark>
i actually might make it pipelined
<Flea86>
whitequark: Cool. What kind of LUT counts are you getting now?
<whitequark>
because toolchains seem to struggle with multicycle
<whitequark>
Flea86: about 500 LUT, but there are clear efficiency issues
<whitequark>
this is with yosys and yosys doesn't recognize the control FSM
<Flea86>
for the 32bit core?
<whitequark>
so it is *definitely* *much* worse than it should be
<whitequark>
no 16 bit
Bob_Dole has joined ##openfpga
<Flea86>
Ah ok
<whitequark>
swetland: so I'm thinking like this
<whitequark>
a pipeline that's constantly stalled is still useful
<whitequark>
because it lets me register the hell out of every signal
catplant has quit [Quit: WeeChat 2.2]
<whitequark>
swetland: i get like 25 MHz with Yosys and nextpnr on UP5K
<whitequark>
which is not bad at all but I want even faster
<whitequark>
i have already microoptimized the ALU and the ALU is optimal
<whitequark>
i.e. uses theoretical minimum LUT count
catplant has joined ##openfpga
* swetland
nods. I think contention for memory+registers and read vs write in the 1spram model is going to fight back hard. with a mipsy dual-read+write register file and separate I/D memory interfaces you get a bit less contention
<whitequark>
agreed
<whitequark>
i want to have three build variants:
<whitequark>
1) everything in a single SPRAM
<whitequark>
2) everything in a single BRAM
<whitequark>
(both are supported right now, though no advantage of true dual port nature is taken)
<whitequark>
3) memory is BRAM 1, register file is BRAM 2
<swetland>
only instruction set questions that come to mind are: 1. is there a jump <register> op? 2. does JAL really need a choice of link register (I'd consider trading more imm bits vs always using r7 or whatnot) 3. is there a mechanism present to shift the register window (may have missed it in my readthrough)
<whitequark>
but rather as a detail of the absolute minimal implementation
<swetland>
yeah that had crossed my mind as well (is it a possible optimization or a feature)
<swetland>
that explains lack of a "call" instruction that slides the window as a side effect
<whitequark>
swetland: hm, that said
<whitequark>
one of my possible designs for "combined ENTER/LEAVE" involves not having any CSRs
<whitequark>
and using LD/ST with immediate offset to load arguments
<whitequark>
and store return values
<whitequark>
that would not work with separate RF/mem
<whitequark>
so i might not want to go for that, *however*
<whitequark>
what i *might* want to go for, is two read port one write port RAM
<whitequark>
which really is just 2x BRAM count
<whitequark>
glad you like my arch :3
<swetland>
really depends on the size of your programs -- a single spram with 16k words is a nicely large workspace
<whitequark>
yeah SPRAMs are even cheaper
<whitequark>
we really ought to make yosys infer SB_SPRAM
jevinskie has joined ##openfpga
<swetland>
the idea being that it's pretty easy to write a toy language that compiles to that sort of thing
<swetland>
and yeah you get pretty compact code as a result
<whitequark>
nod
mumptai has quit [Quit: Verlassend]
<swetland>
give me a heads up when you declare your 1.0 or 0.9 or whatnot of the isa. I'm buried in other little projects at the moment, but definitely want to keep this on my radar
<_whitenotifier-6>
[Glasgow] whitequark created branch nmigen - https://git.io/fp4Wh
<_whitenotifier-6>
[whitequark/Glasgow] whitequark pushed 2 commits to nmigen [+0/-0/±48] https://git.io/fpxD6
<_whitenotifier-6>
[whitequark/Glasgow] whitequark e4c02c8 - Bulk port of all gateware to nMigen compatibility layer.
<_whitenotifier-6>
[whitequark/Glasgow] whitequark 50be78c - Bulk-migrate eeeeeverything to nMigen.
<whitequark>
swetland: will do!
<_whitenotifier-6>
[whitequark/Glasgow] whitequark pushed 1 commit to nmigen [+0/-0/±39] https://git.io/fpxDi
<_whitenotifier-6>
[whitequark/Glasgow] whitequark fc3f1f6 - Bulk port of all gateware to nMigen compatibility layer.
<cr1901_modern>
I think one of the missing insns should become a WAit for Interrupt
<whitequark>
swetland: mostly speed
<whitequark>
swetland: with UP5K I can saturate the USB but only barely
<whitequark>
and meeting timing on more complex applets is a struggle
<whitequark>
i imagine applet multiplexing would just not work well period
<whitequark>
cr1901_modern: boneless doesn't really have interrupts
<whitequark>
cr1901_modern: if i added that... there would be a single fixed address it jumps to at interrupt
<sorear>
I’m surprised by how little use we’ve gotten out of the SPRAM
<whitequark>
and it would shift a window in hardware
<whitequark>
sorear: yeah
<cr1901_modern>
whitequark: I'm saying that it should have interrupts, or failing that an insn that makes it wait for an external event (and might as well impl interrupts at that point).
<cr1901_modern>
sorear: SPRAM is used for micropython on ice40 when it exists
<whitequark>
cr1901_modern: my proposed design doesnt involve a WFI interrupt
<whitequark>
however, i think what will be necessary
<whitequark>
is a SEI/CLI instruction
<whitequark>
cr1901_modern: i think i can avoid having a need for a "return from interrupt" instruction by..
<whitequark>
making SEI have a 1 instruction latency
<whitequark>
or maybe 2
<whitequark>
so you do SEI; LEAVE; JR R7
<whitequark>
and this is guaranteed to not have an interrupt occur between the three instructions
<sorear>
Is R7 reserved for ISR use like k0/k1 in mips?
<whitequark>
sorear: no
<whitequark>
entering an interrupt will definitely push a window
<whitequark>
and then it'll put PC into... wherever, really
<whitequark>
so why not R7
<catplant>
R0-7 are fixed, R8-15 are windowed?
<sorear>
whitequark: does LEAVE also have a cycle delay?
<whitequark>
catplant: there are 8 registers
<whitequark>
(16 registers didn't really fit)
<catplant>
damn :(
<whitequark>
eh, i think it'll be fine
<whitequark>
x86 does with less
<sorear>
sparc usual approach is to put leave in the ret delay slot, which is bonkers
<whitequark>
sorear: the idea is that CLI/SEI have two DFFs
<whitequark>
between them and the actual I flag FF
<whitequark>
or maybe just SEI
<whitequark>
yeah, probably just SEI
<cr1901_modern>
What does "SEI; LEAVE; JR R7" idiom do?
<sorear>
Yes but after LEAVE won’t the JR see the caller’s R7?
<whitequark>
sorear: oh shit
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
...
<whitequark>
well fuck
<whitequark>
i don't really know how to do it lmao
<whitequark>
sorear: so yeah the idea with ENTER/LEAVE would be that it would have an Rd
<whitequark>
it would push a window and store the *old* window address to Rd
<whitequark>
in the *new* window
<whitequark>
then, per calling convention, you'd have e.g. R7 as LR
<whitequark>
(it is useful to have JAL have configurable Rd for certain kinds of PIC)
<sorear>
whitequark: sorry, what is a "window address"? is this an offset within the register file, (logically) outside of memory?
<sorear>
I assume you're using fixed size windows, do they overlap like SPARC?
<sorear>
I also don't follow the relevance of JAL's Rd for PIC - it's useful for IPRA/leaf functions if you've got a lot of registers, sure
<swetland>
whitequark: yeah my earlier cpu16 iterations had 16 registers but it chewed up way too much instruction space, and I ended up either having to ditch 3-reg ops or have limited destination register space, neither of which was very pretty
<whitequark>
sorear: fixed size window, register file is within memory
<whitequark>
fixed size and strictly aligned
<whitequark>
so they cannot overlap
<gruetzkopf>
ooh, supernes controller
<whitequark>
i think overlap of 4 instructions is not that useful, and it adds a lot of logic in critical path
<gruetzkopf>
i should make a 4*GC/N64 breakout
<whitequark>
sorear: re: JAL's Rd. JAL .+1 is basically GETPC.
<swetland>
dualshock
<gruetzkopf>
oh, right
<gruetzkopf>
joybus is a bit WTFNINTENDO
<gruetzkopf>
but fun
<whitequark>
swetland: yeah. i had to ditch some of the 3-reg ops anyway
<whitequark>
to make space for shifts
<swetland>
I just prefer the feel of sony controllers
<swetland>
whitequark: I approve of shifts. especially if you're doing word-only mem/io access you rapidly find yourself wanting them
<gruetzkopf>
i grew up on nintendo
<whitequark>
swetland: yep
<swetland>
in gradeschool it was C64 and NES. in college a housemate bought the N64 at launch and super mario destroyed productivity. but the first console I bought myself was PS2... then PS3... then PS4
<gruetzkopf>
i have n64(pika edition) and up
Bike has quit [Quit: Lost terminal]
pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
rohitksingh_work has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 268 seconds]
dj_pi has quit [Ping timeout: 250 seconds]
_whitelogger has joined ##openfpga
GuzTech has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azonenberg_work has quit [Read error: Connection reset by peer]
jevinskie has joined ##openfpga
azonenberg_work has joined ##openfpga
Bob_Dole has joined ##openfpga
GuzTech has quit [Ping timeout: 240 seconds]
Richard_Simmons has quit [Ping timeout: 264 seconds]
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 272 seconds]
GuzTech has joined ##openfpga
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 250 seconds]
tms_ has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 246 seconds]
rohitksingh_work has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 272 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
rohitksingh has joined ##openfpga
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
<_whitenotifier-6>
[whitequark/Glasgow] whitequark pushed 1 commit to nmigen [+0/-0/±39] https://git.io/fppae
<_whitenotifier-6>
[whitequark/Glasgow] whitequark 99ba3f8 - Bulk port of all gateware to nMigen compatibility layer.
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
Bob_Dole has quit [Remote host closed the connection]
Bob_Dole has joined ##openfpga
azonenberg_work has quit [Ping timeout: 272 seconds]
Miyu has joined ##openfpga
GuzTech has quit [Quit: Leaving]
pie__ has quit [Remote host closed the connection]
pie___ has joined ##openfpga
azonenberg_work has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
azonenberg_work has quit [Ping timeout: 250 seconds]
azonenberg_work has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
GuzTech has joined ##openfpga
jevinskie has joined ##openfpga
Flea86 has joined ##openfpga
Maya-sama has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
Maya-sama is now known as Miyu
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
GuzTech has quit [Remote host closed the connection]
jevinskie has joined ##openfpga
fseidel has quit [Quit: leaving]
fseidel has joined ##openfpga
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cpresser>
$friend has a board with a leaky NiCd Battery. There is corrosion with greensish crystals on some pads and pins. I cleaned it with IPA, but when soldering there is a black gooey stuff coming out of the board. any ideas that that is? how to fix?
<Flea86>
cpresser: What kind of board is it? PC mobo? Sounds like the dreaded 'battery cancer' (corrosion) has already damaged/penetrated your friend's board...
<cpresser>
its a X68000 computer board
<cpresser>
build in 1988 :)
<Flea86>
cpresser: Ok cool :) How much of the copper traces/pads have been visibly afflicted that you can see?
<Flea86>
Does it still fire up?
<davidc__>
Also, are you soldering at an appropriate temperature? (IE,leaded solder at leaded temps)
<davidc__>
(since pre-lead-free boards can decompose at lead-free temps)
<Flea86>
if any of the traces are eaten towards an open circuit, they need to be patched
<cpresser>
yep, i am below 300°C, with lead solder. but you are right, it might be the epoxy from the pcb
<whitequark>
lead solder is around 180 °C liquidus
<whitequark>
not 300 °C
<Flea86>
davidc__: Indeed, one can delaminate the substrate with too much heat
<cpresser>
oh, i thought it was 250°C... shit
<whitequark>
Sn63/Pb37 liquidus is 183 °C
<whitequark>
and the maximum assembly temp during reflow is 215 °C
<whitequark>
300 °C is way too much even for lead free!
<cpresser>
anyway, the PSU is also blow.. but its only 5V, 12V and -12V, we plan to just replace it
<Flea86>
300deg.C for an iron tip is Okay, depending on how well your iron recovers from an actual solder cycle
<davidc__>
and how long you are contacting the pad
<Flea86>
but you cannot leave it on your PCB for too long that's all
<whitequark>
Flea86: depends on the iron
<cpresser>
i have been contacting it for ~5sec. then the black soot appeared and i stopped
<whitequark>
e.g. "300 °C" with a regular ceramic heater iron and 300°C with a T12 cartridge iron
<whitequark>
is completely different
<whitequark>
the former could be basically anything
<Flea86>
whitequark: Bulk solder wire needs good heat transfer to melt it
<whitequark>
of course
<Flea86>
paste is another matter
<davidc__>
and tip size too
<Flea86>
hah yes size matters ;)
<cpresser>
heat transfer depends on so much factors