azonenberg_work has quit [Ping timeout: 240 seconds]
Miyu has quit [Ping timeout: 272 seconds]
unixb0y has joined ##openfpga
unixb0y_ has joined ##openfpga
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y_ has quit [Quit: ZNC 1.6.5+deb1 -]
<awygle> tfw YouTube recommends TinyFPGA
<tinyfpga> woohoo!
<tinyfpga> XD
<awygle> congrats :-)
digshadow has quit [Ping timeout: 244 seconds]
unixb0y has joined ##openfpga
s1dev has joined ##openfpga
s1dev has quit [Ping timeout: 244 seconds]
ym has quit [Quit: Leaving]
Bike has quit [Quit: Lost terminal]
m_w has quit [Quit: Leaving]
s1dev has joined ##openfpga
digshadow has joined ##openfpga
<cr1901_modern> > azonenberg_work: see my blog
<cr1901_modern> Could you point me to a link :)? Also, what's TDR?
azonenberg_work has joined ##openfpga
<lain> time-domain reflectometer
<cr1901_modern> Oh, that "find the fault" game you play if you have an oscilloscope, a T-connector, and a square wave generator?
<cr1901_modern> oh and coaxial cable*
<rqou> lol cr1901_modern is oldschool
<rqou> my father was telling me about how he used to do that
<shapr> but you can't find the fault if you ran your coax over the top of the fluorescent bulbs
<rqou> lol
<cr1901_modern> I mean, that's what we did in a lab once. We were given coaxial that deliberately had a fault, look at the oscilloscope to see when the square wave/pulse was reflected. Use telegrapher's equations to predict where it actually is
<awygle> that's a cool lab
<awygle> wish we did stuff like that
* cr1901_modern forgets how to actually find the speed of e-field prop using telegrapher's equations tho
<cr1901_modern> all that stuff I lost T_T
<azonenberg_work> seee, i look at the cable datasheet to get a propagation velocity
<azonenberg_work> Or estimate 2/3 * C in the absence of any information
<azonenberg_work> then hope for the best :p
<lain> ^
<azonenberg_work> Since realistically you probably do not know the Er or spacing *that* precisely
<azonenberg_work> there is going to be some tolerance anyway
<cr1901_modern> Er?
<azonenberg_work> dielectric constant
<cr1901_modern> Oh that
<sorear> what kinds of cable have a prop speed significantly different from 2/3c?
<cr1901_modern> azonenberg_work: I think we were given the characteristic impedance (incl. the imaginary part that lossy- aka real- cables have) for rg-58 as an assumption. Or maybe L and C per unit length
<cr1901_modern> But it's going on 8 years now that I did that lab lmao
<azonenberg_work> sorear: random data points from googling datasheets
<cr1901_modern> Being able to calculate it was kinda a requirement to pass that lab. I could use 2/3*C and prob be fine. It's the principle that I let myself forget how to do it, and reteaching myself has been... well, not going well
<sorear> I mean, "2/3 c" is the number I've always heard for copper-based technology
<azonenberg_work> RG-316 from various vendors 69.5%, 69%, 70%
<azonenberg_work> (times C)
<cr1901_modern> 10BASE5 mandates above 70%
<cr1901_modern> I think that's important to know in 2018
<sorear> is there anything I could plausibly encounter in my life that's <10%?
<azonenberg_work> RG174 66%, 66%
<cr1901_modern> analog delay lines as cables :P
<azonenberg_work> According to a chart on rfcafe it varies mostly by dielectric
<azonenberg_work> looks like foam polystyrene is a whopping 0.910C
<azonenberg_work> air space teflon 0.850 - 0.900
<azonenberg_work> But most solid (non-foamed) dielectrics are pretty solidly 0.65 - 0.7
<cr1901_modern> vaccum 1.000
<azonenberg_work> So yeah it does vary greatly by the cable tech but for almost anything but a weird exotic RF dielectric
<azonenberg_work> it will indeed be 65-70%
<azonenberg_work> iirc internal pcb traces have slightly faster velocity than external
<azonenberg_work> slower*
<cr1901_modern> why?
<azonenberg_work> Since theres partial air dielectric on the surface traces
<cr1901_modern> hmmm
<azonenberg_work> which makesthem faster
<sorear> i'm wondering if old-school submarine cables would be an example of exotic
<sorear> apparently they had hella dispersion but it's unclear what the propagation velocity was
taralx has joined ##openfpga
s1dev has quit [Ping timeout: 244 seconds]
fseidel has joined ##openfpga
<fseidel> this is a shot in the dark, but do any of you guys know of a tool for recovering equations from JEDEC for a Lattice M4LV-192/96 device?
<fseidel> or at the very least, what the heck the bitstream format is for this thing
taralx has quit [Quit: Connection closed for inactivity]
<jn__> fseidel: this is definitely the right place to ask
<jn__> (but i haven't seen Lattice Mach 4 being discussed here)
xdeller has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
ym has joined ##openfpga
GenTooMan has joined ##openfpga
p0nziph0ne has quit [Ping timeout: 260 seconds]
p0nziph0ne has joined ##openfpga
rohitksingh has joined ##openfpga
Wallbraker[m] has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<florolf> gonna try the readout-protection thing with those later
rohitksingh has joined ##openfpga
p0nziph0ne has quit [Ping timeout: 272 seconds]
X-Scale has quit [Ping timeout: 260 seconds]
<q3k> heh, gd32
<daveshah> I thought they just have an SPI flash in the package?
X-Scale has joined ##openfpga
X-Scale has quit [Excess Flood]
X-Scale has joined ##openfpga
Miyu has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<florolf> rqou: FWIW, same behavior: flash lockout only disengages on POR
<q3k> fseidel: hm
<q3k> fseidel: REing the bitstream format for 4000ZE was on my backlog
<q3k> fseidel: I don't think anyone else looked at lattice CPLDs at all
s1dev has joined ##openfpga
<fseidel> q3k: woah, cool
<fseidel> let me know if you manage to get to it
<q3k> fseidel: but yeah, i have so many stupid personal non-money-making projects on that list that it's gonna take a looong time :/
<q3k> but i'll certainly bump it up
<fseidel> don't sweat it, I'm not in any critical need
<q3k> i at least managed to get isplever to run on docker so I can start running fuzzing at some point or another
<fseidel> this only helps me avoid designing something myself :-P
<fseidel> (although maybe learning how to interface a 68060 to a 68000 bus and writing the verilog from scratch is a better use of time than trying to port to a modern CPLD)
<q3k> huh, yeah
<q3k> probably easier :)
<q3k> you could use a ice40 for that, too - low power and cheap enough
<fseidel> yeah, that's what I had in mind
<q3k> lp1k would probably do just fine, and they come in large enough packages
<fseidel> just need to figure out how the bus protocols actually differ. the 68060 docs have a lot of shit in them I don't care about (like multiprocessor snooping). need to figure out what's really necessary
<fseidel> anyway, thanks!
<gruetzkopf> where're you getting the 68060s :D
<cr1901_modern> Is this for some amiga accelerator?
<cr1901_modern> Only use case that comes to mind attaching a 680x0, x > 2 to a 68000 bus
<fseidel> my university's computer club has a few
<fseidel> close, sharp X68000
<cr1901_modern> I really want one of those (b/c 68k + YM2151 = <3), but I'm not prepared to shell out $700-$1000 for one
<fseidel> best option is to buy a dead one and attempt to refurb, you can get them broken for ~$200
<fseidel> shipping from japan is a pain though
<cr1901_modern> Historically if I take something apart that's already broken it doesn't end up working when I put it back together, so I guess I'll just save up the money
<fseidel> the issues tend to be bad caps and PSUs (I think the PSU may be made of tissue paper, it's the most fragile POS I've ever seen)
<fseidel> but yeah, given the cost, it's a risk if you aren't sure you can get it working
<cr1901_modern> So someone already made a 68060=>68k converter, and you want the equations/schematic?
<fseidel> yeah, some dude in Japan did a while ago, and someone I know has the card + the JEDEC file used to program the CPLD on the card
<fseidel> they're super rare and hard to find, so people want reproductions, but the CPLD is EOL. There's an easy to find replacement for it, but I think a new design would be a good thing to have
<fseidel> and it seems like a fun project, anyway
<cr1901_modern> This is cool; I've seen a number of these "class projects" fail thinking that "because it's 8/16-bit it's going to be easy"
<q3k> you could just grab a ECP5 and implement the 68060 on there as well
gnufan has quit [Ping timeout: 268 seconds]
<q3k> so you don't have to use super rare vintage chips
<sorear> How compatible are 68060 open cores
<fseidel> cr1901_modern: thanks! how did you find that?
<cr1901_modern> I just googled your handle lmao
<fseidel> BTW, it worked, there's a video here:
<fseidel> lol, that works
<fseidel> I've never seen an open 68060 core
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 272 seconds]
[X-Scale] is now known as X-Scale
<cr1901_modern> I _love_ 68k assembly, but the features I love about it come at a cost; the insn encoding is horrifying and there's stuff about internal state that we still don't know about it (i.e. it saves stuff on the stack on exception and last I checked we don't know exactly what that state is)
<cr1901_modern> 68060 sounds like even less fun
<fseidel> yeah, 68010 and up save A LOT of internal state for resuming after a fault
gnufan has joined ##openfpga
<fseidel> these guys clearly have an 060 core:
<fseidel> they just won't share it with anyone
<fseidel> 68K was actually my first ISA, it's probably the most programmer friendly ISA ever designed
<sorear> Aren’t the exception frames documented, and doesn’t 040+ have much simpler frames
<cr1901_modern> sorear: AFAIK, they aren't documented, not even in the patents
<cr1901_modern> sarayan might know something I don't tho
<cr1901_modern> s/might/prob/
<sorear> Better than VAX and S/360?
<fseidel> S/360 feels like a mess
<cr1901_modern> how many pnr systems does this make now?
<fseidel> VAX is pretty close, which makes sense given that 68K and VAX were both PDP-11 inspired
<Prf_Jakob> fseidel: The apollo core isn't a full 68060 not even a 020, since they stubbernly refuse to implement the standard MMU and FPU.
<fseidel> laaaame
<gruetzkopf> i've recently happened upon a VME 68EC030 machine
<fseidel> so it's just a faster 68K offering 060-like perf?
<gruetzkopf> if i get a QFP non-ec 030 i could throw it on
<fseidel> what machine is this?
<Prf_Jakob> I think they implement all of the 060 ins -FPU/MMU. And added their own AMMX instructions. Then do "emulation" via traps.
<Prf_Jakob> Well the 060 doesn't implement some 000 instructions even, which the implement.
<Prf_Jakob> they*
<Prf_Jakob> So they just call it 68080.
<Prf_Jakob> So they get around 060 perf and maybe more thanks to the DDR3 they have.
<sorear> dual issue?
<Prf_Jakob> Up to 4 I think
<fseidel> you could probably do pretty well doing the tried and true P6 CISC->RISC micro-op translation scheme
<fseidel> would make for a very speedy 68K core
s1dev has quit [Ping timeout: 240 seconds]
<Prf_Jakob> It is pretty speedy.
<gruetzkopf> the 030 processor card (and rest of the system) of a adept VME based industrial robot controller
<Prf_Jakob> Then again, it has DDR3 memory WS DRAM at like 50mhz.
<fseidel> I do wonder what the point is a running it so fast when Amiga games and demos will almost certainly keel over at that speed
<fseidel> I have enough issues getting Amiga demos to be happy with an 020
<fseidel> the OCS ones, anyway
<sorear> looks like an UltraSparc/A53-style slow 2-issue superscalar with limited fusing ability
<Prf_Jakob> They claim 4-issue
<fseidel> could be dual issue of two fusable instructions?
<sorear> when you dig down to cpu_{superscalar,fuse,bond} that's exactly what they're claiming
<sorear> "we fuse, also we have 2 pipelines, so it's 4 instructions"
<Prf_Jakob> Ah okay
<fseidel> ah, yeah 2 int, 2 address
<fseidel> so you can probably fuse a load and an add, or a lea and an add, etc.
<fseidel> interesting that it has its own 3-operand instructions
<fseidel> at a certain point, these accelerators seem a little silly. tacking an 010-060 on a 68000-based machine is one thing
<fseidel> but sticking a higher performance core than would have been even remotely possible during the lifetime of the machine sort of feels like running a super gameboy type addon
<fseidel> where the original machine isn't really doing any of the work
<gruetzkopf> heh, i once had a accelerator for a600 planned
<sorear> reminds me of a certain company that used to make 68040 computers and then switched to selling ppc boxes with a rom emulator
<gruetzkopf> plugged ontop of the PLCC 68000
<sorear> because, you have a software base
<Prf_Jakob> fseidel: Well just amiga you got a desktop, so with the new core you can actually do more on the desktop now.
<fseidel> so this is intended for the "still use an Amiga as a daily driver PC" market?
<Prf_Jakob> I guess, and funding developement for the core so they can sell it.
<Prf_Jakob> I think is the long term goal.
<gruetzkopf> mine was for the fun of it, basically
<cr1901_modern> 2 int, 2 address <-- I'm not sure how these can be used to convert 4 insns into 2, considering most 68k insns are going to have address calculation happening?
<fseidel> register->register math + memory should fit that
<Prf_Jakob> gruetzkopf: I have been "planning" one as well.
<gruetzkopf> had hardware issues, never did a respin
<cr1901_modern> yea, that sounds logical/fair. Though I'd expect a compiler to do that opt for you :P
<fseidel> rule #1: never trust the compiler to do anything for you :-P
<Prf_Jakob> fseidel: I think they mean four 16bit ins. Maybe, because sometimes they are bad at communicating.
<sorear> slightly tempted to hack a 68k frontend onto BOOM or something
<gruetzkopf> please do
<Prf_Jakob> ^ ditto
<gruetzkopf> what worked with my hardware was "boot off of sd card"
<Prf_Jakob> gruetzkopf: You think all that will fit on a Zynq?
<fseidel> sorear: funny, that was one of the ideas I had in mind before deciding to do an X68k accelerator
<fseidel> please do that, sounds fantastic
<gruetzkopf> why zynq
<gruetzkopf> and zynq is a fairly broad field
<Prf_Jakob> Mostly because the Z-turn board with a Zynq has enough IO to replace a MC68k
<Prf_Jakob> And is cheap enough
<cr1901_modern> >I think they mean four 16bit ins <-- Are there 16-bit insns that addr memory in 68k (otherwise how do you keep the addr units filled?)
<cr1901_modern> In any case, 68k decoding is not my idea of a fun time. It's a beautiful ISA with a horrific encoding :(.
<Prf_Jakob> Data 'op' *(Addr++)
<Prf_Jakob> Instructions I think excists.
<fseidel> seems easy enough to make a state machine to parse it
<fseidel> at least it's not x86...
<cr1901_modern> Early x86 is easier tha 68k IMO
<sorear> "state machine" is not an approach that scales to 4-wide decode
<fseidel> oh shit, right
<Prf_Jakob> sorear: Four state machines?
<sorear> that'd work OK with 4 threads
<fseidel> if you can extract the length in a pre-decode stage, you can use state machines to decode the actual ops
<sorear> not that much of a gap between "extract the length" and "decode"
<Prf_Jakob> Well you could have 2 or 3 different types of decoder blocks. So one set which would only work on say 16bit ones and only active when there are 4 16bit ops. Or something.
<fseidel> that's getting dangerously close to modern x86 decoding
<fseidel> 3 simple decoders and a complex one
<sorear> well yes
<sorear> the design space is pretty constrained, modern large processors all look kind of alike
<Prf_Jakob> They guy doing the apollo core is a former PPC designer, so I not suprpised if it is something like that.
<pie__> (hey peeps, whats ths topic?)
<Prf_Jakob> pie__: mc68k cores
<Prf_Jakob> And amiga stuff
<pie__> ah ok \o/
<sorear> mmh
<sorear> freescale or ibm?
<Prf_Jakob> Dunno maybe IBM
<sorear> so when do we get decimal fp
<Prf_Jakob> Haha :p
<cr1901_modern> what is insn bonding vs insn fusing?
<gruetzkopf> i'd love a s390x box
<cr1901_modern> I'd love a new arch that wasn't painful to write (read: more than load/store touches memory). It'll never happen of course.
<cr1901_modern> Maybe someone will make riscv extensions to play around w/ a so-called "orthogonal insn set", but I'm not holding my breath.
<whitequark> cr1901_modern: just use a macroassembler
<cr1901_modern> Like what :P? NASM is okay, but I find it's too easy to make mistakes w/ it's macro system. I've def batted around making my own before.
<whitequark> sure, write your own
<whitequark> add a register allocator while you're at it
<cr1901_modern> Yup, also have thought about that too :), in fact I have a crappy prototype somewhere.
<cr1901_modern> Something akin to an "optimizing assembler" lol
<whitequark> optimizing assembler is harder because if you want to do anything interesting you get UB
<whitequark> you could probably do a peephole optimizing assembler
<whitequark> and actually sdcc has it
<whitequark> it can optimize inline assembly in C code, even
<whitequark> and it's scriptable, too
<whitequark> but... it's sdcc
<sorear> cr1901_modern: "insn bonding" is the nonstandard name the apollo people are usin for
<cr1901_modern> peephole was what I had in mind. Like "let the peephole optimizer correct goofy insn combos I used when there was clearly a better choice".
<cr1901_modern> sorear: Thanks