emeb has quit [Quit: Leaving.]
Asuu has quit [Remote host closed the connection]
q3k has quit [Ping timeout: 240 seconds]
q3k has joined ##openfpga
smkz has quit [Quit: smkz]
smkz has joined ##openfpga
OmniMancer has joined ##openfpga
Degi has quit [Ping timeout: 240 seconds]
Degi has joined ##openfpga
Bob_Dole has quit [Ping timeout: 260 seconds]
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined ##openfpga
Bob_Dole has joined ##openfpga
lopsided98_ has quit [Ping timeout: 260 seconds]
jeanthom has quit [Ping timeout: 258 seconds]
jeanthom has joined ##openfpga
mkru has joined ##openfpga
jeanthom has quit [Ping timeout: 260 seconds]
mkru has quit [Quit: Leaving]
<omnitechnomancer> The 74x8836, 74x8837 and, 74x8847 seem a little out of place in 74 series chips
<daveshah> Wow
<daveshah> Doubt they are easy to find though...
<daveshah> Good way to troll the '74 series CPU' concept though...
<omnitechnomancer> Yea, here is my 74 series CPU with one chip that is just the ALU :P
<omnitechnomancer> Only thing more trolly would be if they released a '74 series CPU chip :P
<omnitechnomancer> I have been trying to figure out how one would render a SERV based CPU into a reasonable 74 series circuit via Lofty's 74xx-liberty stuff, but the register file interface is a bit confusing and all the existing socs for it assume FPGA like dual port memory (separate read and write ports)
azonenberg has quit [Ping timeout: 256 seconds]
<sorear> hear me out here: Williams tube
* omnitechnomancer googles.
<omnitechnomancer> Sounds more delicate than desirable :P
<omnitechnomancer> Could probably make the register file out of some horrible combination of shift registers and muxes
lopsided98 has joined ##openfpga
<tnt> there are dual port sram :p
<omnitechnomancer> they are expensive :(
<omnitechnomancer> I should see how horrible it would be to run a memory interface at twice the clock speed and do the write on even cycles and reads on odd cycles or something
azonenberg has joined ##openfpga
azonenberg has quit [Remote host closed the connection]
azonenberg has joined ##openfpga
azonenberg has quit [Remote host closed the connection]
azonenberg has joined ##openfpga
<sorear> that's also a very traditional approach
<Lofty> omnitechnomancer: how brave are you feeling?
<omnitechnomancer> Why do you ask?
<omnitechnomancer> Lofty: somewhat but not too much?
<Lofty> omnitechnomancer: the IDT7142 is a dual-port RAM. But it's also asynchronous, so have fun with timing.
<Lofty> *IDT7132
<omnitechnomancer> sounds like it would be just as annoying as just fudging it into one port by running the clock at half rate for the CPU
<omnitechnomancer> I am not sure what kind of clock speed one could achieve anyway
<sorear> the apple ii did that
<omnitechnomancer> The address collision stuff kind of also makes async dual port ram weird
Asu has joined ##openfpga
<Lofty> omnitechnomancer: ignoring the register file, I could push SERV to 24MHz
<omnitechnomancer> the core by itself is a relatively small number of 74 series devices too
<omnitechnomancer> Does RISC-V do okay as full harvard?
<Lofty> It's single address space
<Lofty> But it's also SERV, so I don't think the von Neumann bottleneck is much of a problem
<omnitechnomancer> Yea but SERV has separate I bus and D bus so you could make an actual harvard implementation by having them be entirely separate memories
<Lofty> I guess?
<omnitechnomancer> probably would not work very well with RISC-V software though
<Lofty> You'd have to make sure the I and D address spaces don't overlap
<Lofty> And it also means you'd probably got to program an EEPROM every time you want to run something
<sorear> there's nothing in the user ISA which prevents you from having rw- address regions and --x address regions, and you can even configure the mmu that way
<sorear> and it's pretty good at keeping rodata out of .text
<sorear> [the gnu toolchain]
<omnitechnomancer> Lofty: You just have your second 74series SERV attached to the I space RAM for programming :P
<Lofty> sorear: what's an MMU? Can you eat it?
<Lofty> /s
<Lofty> Yeah, I'm pretty sure we can't afford memory protection
<Lofty> In possibly the most literal sense of "afford"
<omnitechnomancer> TLB walker in 74 series logic? :P
<omnitechnomancer> well page-table walker
<sorear> i didn't say _you_ had to have a mmu
<sorear> also i don't recommend nomming 68851
<Lofty> More likely a MIPS-style software TLB
<omnitechnomancer> Yea though the TLB is still probably pretty big
<omnitechnomancer> can one make a bit serial TLB 🤔
<sorear> note that I wasn't the one to propose making a TLB, you were
azonenberg has quit [Ping timeout: 260 seconds]
<omnitechnomancer> Or go the: Here is the 74series CPU, and here is the FPGA in the middle for the MMU route
<zyp> sorear, it's not emitting constant pools at the end of functions?
<sorear> https://gcc.godbolt.org/z/h97Mvz note ".section srodata"
<sorear> riscv has no useful constant load with a range of less than 2 GiB so putting them at the end of functions doesn't buy you much
<zyp> ah, right
<zyp> I mostly do cortex-m, and cortex-m code is full of constant pools
<Lofty> sorear: I guess it might if you have the C extension
<sorear> every C instruction corresponds 1:1 with a base instruction
<Lofty> Correct, but being closer to the instruction means you can use C loads instead of I loads
<sorear> that's only applicable once you have the PC in a GPR, and when you get the PC into a GPR you always add a high constant to it
<Lofty> If you're using AUIPC, sure.
<Lofty> Nothing's restricting us to position-independent code here though
<sorear> if you're not using AUIPC there is no reason to have the literals _anywhere_ near the text
azonenberg has joined ##openfpga
<sorear> you'll probably use gp for this
<sorear> or, uh, address relative to zero if you have less than 32kbit total memory
<omnitechnomancer> Lofty: how do you determine the 24MHz for a SERV?
<Lofty> omnitechnomancer: I wrote black box cells and gave them specify blocks with timings according to the manufacturer datasheets
<Lofty> And then used sta to calculate the critical path
<omnitechnomancer> Ah, cool
<Lofty> What cell library are you using?
<omnitechnomancer> hmm?
<omnitechnomancer> the 74ac one?
<Lofty> I built some 74lvc1g58/74lvc1g99 libraries :P
<omnitechnomancer> ah
<omnitechnomancer> I am not sure how to answer your question since I'm using what's in the repository, was not aware there were multiple choices :/
<Lofty> Each `.lib` file is a Liberty cell library
<Lofty> I'll have to upload the 1g99 library
<omnitechnomancer> ah yes, so I was using the 74ac one
<Lofty> The problem is that cell duplication gets a bit of a nightmare
<omnitechnomancer> what is different about the lvc1g99?
<Lofty> The lvc1g99 is basically a MUX2 connected to a XOR connected to a 3-state buffer
<Lofty> Naturally, I abuse the shit out of this
<omnitechnomancer> ah
<Lofty> Since you can do things like three-input NOR
<Lofty> But since you're buying one chip, the price brackets help a lot
<omnitechnomancer> and it comes in helpful tiny SMD package for smaller boards
<omnitechnomancer> so this is kind of a universal gate?
<omnitechnomancer> I suppose there isn't a multiple in one package variant anywhere?
<Lofty> No, there isn't
<Lofty> The 58 has a 2G variant
<Lofty> But it's more limited
<omnitechnomancer> ah
<omnitechnomancer> well they come in tiny packages so size wise not too bad but lots of fiddly soldering :P
<omnitechnomancer> They are about 30 bucks for 100 of them for me it seems, so not prohibitively expensive
Bike has joined ##openfpga
emeb has joined ##openfpga
<Lofty> I wrote an article on LUT mapping.
OmniMancer has quit [Quit: Leaving.]
Asu has quit [Quit: Konversation terminated!]
mumptai has joined ##openfpga
mkru has joined ##openfpga
jeanthom has joined ##openfpga
<keesj> cool / fun idea to use issues as blog engine
<Lofty> I mean, they are issues
<Lofty> As in, magazine issues
<Lofty> :P
<keesj> I see
<Lofty> Okay but really I got the idea from lukego
<Lofty> It works surprisingly well
mkru has quit [Quit: Leaving]
jeanthom has quit [Ping timeout: 258 seconds]
Asu has joined ##openfpga
mumptai has quit [Remote host closed the connection]
mumptai has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
jeanthom has joined ##openfpga
mkru has joined ##openfpga
mkru has quit [Quit: Leaving]
peepsalot has quit [Ping timeout: 240 seconds]
peeps[zen] has joined ##openfpga
emeb_mac has joined ##openfpga
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
lambda has quit [*.net *.split]
ktemkin has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
jhol has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
jhol has joined ##openfpga
RaYmAn has joined ##openfpga
ktemkin has joined ##openfpga
TD-Linux has joined ##openfpga
lambda has joined ##openfpga
<omnitechnomancer> Lofty: one thing I was curious about is what size you get for a serving but with the ram removed and replaced with ports (but all the translation into a ram interface intact), I'll hack up the verilog for this tonight
indy has joined ##openfpga
stefanct has quit [Excess Flood]
stefanct has joined ##openfpga
tlwoerner has quit [Quit: Leaving]
Asu has quit [Ping timeout: 246 seconds]
tlwoerner has joined ##openfpga
mumptai has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]