<tpw_rules>
my fav electronics shop before we moved sold bare Z80s
<tpw_rules>
i never bought one because fuck z80 but
<whitequark>
yeah you could probably reproduce that experience
<whitequark>
not sure what to do about the 16-bit MAU
<sorear>
for the full 1970s experience you need to have not quite enough pins for the full bus without a painful multiplexing scheme
<whitequark>
of course
<tpw_rules>
dip64 babyyyyy
<whitequark>
largest LP384 has 37 pins
<whitequark>
lol
<whitequark>
you could maybe fit A, D, ~M/X, ~R/W, CLK
<whitequark>
like... barely
<whitequark>
oh there's *5* pins
<whitequark>
i guess then you could even have separate RD/WR strobes
<whitequark>
no JTAG though
<whitequark>
well it won't fit anyway
<whitequark>
LP1K is easy but boring
<whitequark>
though CM49 is one of those annoying fine pitch BGAs so ehhh
<whitequark>
i guess LP1K it is??
<whitequark>
then you could have JTAG too.
<tpw_rules>
add video out
<whitequark>
lol
<whitequark>
wait you're serious aren't you
<tpw_rules>
of course
<whitequark>
ok sure
<whitequark>
why the fuck not
<tpw_rules>
that could use up the extra logic and make it hard
<whitequark>
nah it's fine
<whitequark>
we have a 50% margin even right now
<Ultrasauce>
use flex pcbs to optimize for bonelessness
<whitequark>
lmao
<tpw_rules>
i'm gonna rewrite mem[W|Ra] to mem[W+Ra] and just keep that the low 3 bits have to be 0 when setting W
<whitequark>
ack
<tpw_rules>
then what's the point of not just defining W to be 13 bits
<whitequark>
oh?
<tpw_rules>
and getting rid of all the UNPREDICTABLE stuff
<whitequark>
to be 16 bits you mean?
<tpw_rules>
yeah
<tpw_rules>
no
<whitequark>
expensive?
<whitequark>
i don't understand
<whitequark>
the reason it's UNPREDICTABLE is so that the current impl (with 3 bits missing) and any impl that uses an actual adder for that are both in-spec
<tpw_rules>
like right now the game is that W doesn't have the lower three bits and you just concatenate it with Ra. i think it would be simpler documentation wise to either say that W is 13 bits and it's concatenated with Ra, or that W is 16 bits, it's added to Ra, but you can't make the lower 3 bits be nonzero
<whitequark>
yes
<whitequark>
well
<tpw_rules>
if you used an adder, then defining it as mem[W|Ra] with | as binary OR means you couldn't have nonzero low W anyway
<whitequark>
yes
<tpw_rules>
unless you wanted to like lock off some registers?
<whitequark>
i agree
<whitequark>
let's define W as 16 bits, and say that if you ever set them to not 0 the result is UNPREDICTABLE
<whitequark>
sounds sane?
<tpw_rules>
then it makes sense to pretend that W is added to Ra
<whitequark>
yes
<tpw_rules>
okay, cool
<tpw_rules>
mem[W|Ra] will become mem[W+Ra]
<whitequark>
the only thing i ever wanted to ensure here is to make sure that both current and future impl will both be in-spec
<tpw_rules>
yes
<tpw_rules>
also i assume Z is calculated on only the low 16 bits of the result
<tpw_rules>
the part that gets stored to the register
<whitequark>
yes
pie_ has quit [Ping timeout: 250 seconds]
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±5] https://git.io/fjAeC
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark 247380e - gateware.alsru: extract shift direction from operation word.
<whitequark>
saved 3 LUTs in decoder!
<tpw_rules>
can you do me a favor and add .DS_Store to the root .gitignore? it's mac's particular brand of garbage and it seems silly to do a pull request for
<tpw_rules>
also ._*
<tpw_rules>
eh nvm i just did it already
<tpw_rules>
if you do too it can get merged no probalo
<sorear>
fyi git has a per-user gitignore feature which works well for ignoring your editor of choice and file manager of choice’s detritus
<tpw_rules>
oh i did not know that
<whitequark>
^
<tpw_rules>
how do i set that up
<whitequark>
i have a bunch of stuff in ~/.gitignore
<tpw_rules>
oh just put it there? ok
<whitequark>
yes
<tpw_rules>
it's too late now it's been written into history. unless you want me to reset everything
<whitequark>
i rebase yes
<whitequark>
a lot
<whitequark>
git rebase is probably my most used command
<tpw_rules>
i don't know how to use git lol
<whitequark>
ah, crap
<whitequark>
i guess i can just fix it for you
<tpw_rules>
okay
<tpw_rules>
thank you
<whitequark>
git is ... aggravating
<whitequark>
i mean
<sorear>
Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead.
<whitequark>
if my options were svn i wouldn't use version control at all
<tpw_rules>
i've only made one other commit, would it be easier to just delete and start again
<whitequark>
oh
<whitequark>
oh yeah i forgot
<whitequark>
i set up that excludesfile
<whitequark>
thanks
<whitequark>
now it's neater :3
<tpw_rules>
can the immediate rotate and shift instructions have an extended encoding?
<whitequark>
yes
<tpw_rules>
okay
<whitequark>
i'd have to spend LUTs on prohibiting that
<whitequark>
the operation is UNPREDICTABLE if you specify any of the high bits tho
<whitequark>
i think they're currently just trimmed
<tpw_rules>
yeah. the docs are totally opaque on that though
<whitequark>
oh? i forgot to mention it?
<whitequark>
crap
<tpw_rules>
the operation says it can be done, but there is no encodig example and the UNPREDICTABLE is not mentioned
<tpw_rules>
i was going to fix it
<whitequark>
thanks
<tpw_rules>
also how is has_ext13 treated? i was going to put a bit after every if (has_ext13) that says has_ext13 <= 0, but i assume it's cleared after every non-exti instruction anyway? in which case i would put that info elsewhere
<whitequark>
the latter
<whitequark>
mhm
<tpw_rules>
cool
<whitequark>
really, either works
<whitequark>
it's more explicit to say it in Operation
<tpw_rules>
well i think the first implies that it's not cleared by an instruction that doesn't say it
<tpw_rules>
which would be fun
<tpw_rules>
cause you could have the exti be as far away from the instruction that uses it as you wanted
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/fjAJL
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark b058f93 - gateware.core: move PC address mux to arbiter. NFC.
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark efa9b43 - gateware.decoder: simplify SI handling.
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fjAJ3
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark d2e176e - gateware.decoder: simplify SI handling.
sunxi_fan has joined ##openfpga
<ZirconiumX>
whitequark: morning
<whitequark>
hi!
<ZirconiumX>
I mean I did just wake up, but I'm around
<ZirconiumX>
Presumably you want me to synthesize the changes you made to Boneless last night, whitequark?
<whitequark>
ZirconiumX: tbh i doubt it changes much
<whitequark>
I thought I had a good improvement but not really
<whitequark>
but yeah I guess
<ZirconiumX>
FWIW the synthesis scripts are open source
<ZirconiumX>
/usr/lib/python3.6/runpy.py:125: RuntimeWarning: 'boneless.gateware.core' found in sys.modules after import of package 'boneless.gateware', but prior to execution of 'boneless.gateware.core'; this may result in unpredictable behaviour
<whitequark>
ah i'll fix that
<ZirconiumX>
Overall: one cell larger
<whitequark>
yeah that's about what i expect. hrm
<whitequark>
i have an idea for a change but it'll reduce LUT count... but probably will raise 74xx count
<whitequark>
bit annoying
<ZirconiumX>
Little point you optimising for me specifically :P
<whitequark>
true
<ZirconiumX>
And I still have no idea about timing :P
<ZirconiumX>
I'll update Yosys; see if that makes any meaningful difference
<ZirconiumX>
It does not.
<whitequark>
i wonder if i stuff *two* decoders into the cpu instead of one, will i be able to make it smaller
<ZirconiumX>
It'd be nice to see where the complexity is for optimisation purposes
<whitequark>
can you elaborate?
<ZirconiumX>
One of the problems I've had when trying to find optimisations in this flow is that a) I don't know the Yosys passes all that well, and b) I don't have graphviz installed
<whitequark>
i see
<ZirconiumX>
So I have no idea how close to optimal this is
<ZirconiumX>
whitequark: re assembler directives, I think the most useful feature I've found is anonymous labels
<ZirconiumX>
For example 1: foo; jump 1b
<whitequark>
right, that's easy to add i guess
emeb_mac has quit [Ping timeout: 272 seconds]
<whitequark>
you know this is harder than it looks
<whitequark>
i don't want to compromise on the ISA *or* the LUT count
<emily>
do people do superoptimization type stuff for LUTs
<whitequark>
it's unlikely to help much
<ZirconiumX>
You mentioned you wanted to get this on an lp384, right?
<whitequark>
yes
<whitequark>
the toplevel is ~170 LUTs for no especially good reason
<whitequark>
i see where it could have like 64
<whitequark>
the rest is... complicated
Jybz has joined ##openfpga
<whitequark>
this shit is made worse by me stuffing the most heinously complicated addressing modes in
<whitequark>
LDR does two indirections and two additions
<whitequark>
and then it's running at 4 CPI
<ZirconiumX>
Ouch
<whitequark>
if I lower it to 5 CPI then I can get to 48 MHz on HX1K.
<ZirconiumX>
Mmm. I should see how it does on Cyclone
<whitequark>
it should be possible to get ahead 48 MHz I *think*
<whitequark>
by adding more registers
<whitequark>
lol on up5k it can do a whopping 18 MHz
<whitequark>
ugh
<whitequark>
i made a crappy cpu.
<whitequark>
and i'm not even sure how to improve it without a total redesign
<whitequark>
ok i guess i could add registers but beyond that...
Miyu is now known as hackkitten
sunxi_fan has quit [Quit: Leaving.]
<whitequark>
yeah it doesn't even run at 100 MHz on ECP5-5G
<whitequark>
runs at... 65 MHz
<daveshah>
That seems very odd
<daveshah>
minimal picorv32 is ~130MHz, Linux VexRiscv is 80-90MHz
<whitequark>
well like i said. it sucks
<daveshah>
But even Rocket can hit 65MHz on ECP5-5G with a good seed
<daveshah>
You are actually setting up the 5G part correctly? non 5G parts have slow BRAM that would probably hurt boneless
<whitequark>
yeah
<whitequark>
--um5g-45k
<whitequark>
actually, 68 MHz with nextpnr
<ZirconiumX>
whitequark: it's pretty small though, so you've got that going for you
<whitequark>
it's not as small as i want anyway.
<whitequark>
i could probably make shifts and complex jumps optional but that's meh
<whitequark>
do not like
Asu has joined ##openfpga
gnufan_home has joined ##openfpga
Stary has quit [Ping timeout: 250 seconds]
Asu has quit [Ping timeout: 258 seconds]
Asu has joined ##openfpga
<Flea86>
whitequark: I have an experimental 32-bit RISC core (Sweet32 v2.0) that runs at 87.5MHz on baseline (non serdes) ECP5 (True 1T core, including 32-bit immediate loads and all types of branch/skip ops :-)
<ZirconiumX>
whitequark: You were working on an opt_match pass for Yosys, right?
<whitequark>
ZirconiumX: yes
<whitequark>
i hit a minor snag and haven't been able to work much due to health recently, so that's delayed
mumptai has joined ##openfpga
<ZirconiumX>
I'm sorry to hear that; hope you feel better soon
Bike has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 244 seconds]
<tpw_rules>
so i'm thinking we need to formally define UNDEFINED and UNPREDICTABLE
<tpw_rules>
my idea was "The behavior of any instruction which reads an UNDEFINED register is UNPREDICTABLE." and then "The behavior of any instruction which encounters UNPREDICTABLE behavior is to set all output registers to UNDEFINED". that limits the poison effect, but i don't know if that's intended
<whitequark>
tpw_rules: UNDEFINED: any bit pattern. UNPREDICTABLE: any behavior is in-spec
<tpw_rules>
alright, cool
<whitequark>
if you execute an UNPREDICTABLE instruction, the thing can just hang.
<tpw_rules>
well my logic for that was that then PC would become UNDEFINED which would be a hang. but like if you shift > 15 it's probably not going to hang, just produce bogus output. but your definition sounds good
<whitequark>
tpw_rules: it might actually hang depending on the impl
<whitequark>
like if it only decrements the bottom 4 bits or something
<tpw_rules>
that would be a weird impl but point taken
<tpw_rules>
should an invalid imm3 be unpredictable or undefined
<tpw_rules>
like if it's 3 for an ADDI
<tpw_rules>
also should i be putting all the guide stuff in its own file? probably
pie_ has quit [Ping timeout: 250 seconds]
<tpw_rules>
whitequark: ^
pie_ has joined ##openfpga
<whitequark>
tpw_rules: it's not ... invalid
<whitequark>
it's just not assigned yet
<whitequark>
i'd need to run some sort of statistics or something to figure out what to plug there
<goran-mahovlic_>
Hi, can someone please help me with rebuilding litex for ULX3S for 85F and 64Mb SDRAM -- EMARD is also interested if we can add support for USB network device, but we are still struggling with litex basics like starting rebuild
Flea86 has quit [Read error: Connection reset by peer]
<tpw_rules>
can TopoR permute the pins
<ZirconiumX>
There appears to be a "pin swap" option, so
<goran-mahovlic_>
in README of linux-on-litex-vexriscv there is ./make.py --board=XXYY --build but there is not make in root folder - so I do not know where to to from that -- I do have opensource toolchain already installed
<goran-mahovlic_>
ok, will try now
<goran-mahovlic_>
and to run what after I change module
<goran-mahovlic_>
cool, it is sending image over serial
<daveshah>
There is a way to increase baud rate for faster serial downloads, but I can't remember it off the top of my head
<goran-mahovlic_>
daveshah I will try to look around to add network that would be better way :)
pie_ has joined ##openfpga
<goran-mahovlic_>
I actually need good memtest we have some problems in running Amiga on 85F
<goran-mahovlic_>
So just want to be sure SDRAM is good on linux
<goran-mahovlic_>
About 50% of 85F boards cannot run Amiga so we are just checking if we can find what is wrong and it is fixable or it is better to use 12F for that (at least for now)
<goran-mahovlic_>
Litex does not have SD card module?
<tpw_rules>
ok the manual is about where i imagined it now
<tpw_rules>
the remaining items on the PR are probably going to need additional tests and/or proving myself that they're really right
<tpw_rules>
there are some formatting glitches that i don't know how to fix
<tpw_rules>
but i think technically this document is the only thing necessary to implement a compatible boneless cpu
<tpw_rules>
i'm sure something is underconstrained
<goran-mahovlic_>
hmm it stops at this point
<goran-mahovlic_>
VexRiscv Machine Mode software built Jul 9 2019 11:58:09
<goran-mahovlic_>
--========== Booting Linux =============--
<ZirconiumX>
Bleh
emeb has joined ##openfpga
<ZirconiumX>
TopoR is beginning to annoy me
<tpw_rules>
does nmigen require a master version of yosys?
<tpw_rules>
i'm trying to make the new blinky example work on my icebreaker but yosys says top.il has a syntax error
<cr1901_modern>
yes
<cr1901_modern>
until yosys 0.9 comes out, which will pin to nmigen 0.1 AIUI
<goran-mahovlic_>
Hmm two 85F stops at Booting Linux -- do I need to connect to other serial to get linux prompt or it is done over first USB serial?
pie_ has joined ##openfpga
<daveshah>
Should be done all over the same serial
<goran-mahovlic_>
ok, then something else is wrong
<goran-mahovlic_>
I have tested on one board that has non working Amiga, and one that cannot load Amiga, but all other samples we tried works.. And for now we cannot pass Booting linux on those boards. Will send binaries to EMARD so he can recheck...
<goran-mahovlic_>
He has 64Mb version SDRAM on previews boards
<daveshah>
LiteX should run a memory test at startup
<daveshah>
is it printing anything about it on the serial (you might need to not use serialboot to see it?)
<tpw_rules>
:D i built yosys and friends from source and now my board is blinking away
<ZirconiumX>
Congrats, tpw_rules
<tpw_rules>
whoops already crashed the nextpnr gui
<daveshah>
it is possible that something is bad with the image for some reason, I haven't tried latest master personally (#litex might be a better channel)
<goran-mahovlic_>
Maybe I need to rebuild bin files? Or it does this when I build from start
<goran-mahovlic_>
ok
rohitksingh has joined ##openfpga
<ZirconiumX>
So, this design definitely seems like it would benefit from pin-swapping
<ZirconiumX>
Unfortunately there are kinds of pin-swapping possible that I can't express to TopoR
<ZirconiumX>
tpw_rules: I reject your reality and subtitute my own.
<tpw_rules>
i think it's neat. i've never seen 74 series logic in anything other than rectangular 14 pin packages. it's a refreshing change
<tpw_rules>
there are long bois though. are those the 4 bit ALU ones
<ZirconiumX>
They're also clipping through each other
<tpw_rules>
that's a depressing way to think about it
<tpw_rules>
it's like that game where you have to slide around cars in a parking lot
<tpw_rules>
how many layers is it
<ZirconiumX>
4
<sorear>
4 layers of ICs, you don’t want to know how many layers of traces
<tnt>
ZirconiumX: what's the 'efficiency' of usage ( like how many gates in the 7400 chips are unused )
<tpw_rules>
i think it's very high?
<ZirconiumX>
I don't actually know, but I can hack the script to find out
<ZirconiumX>
I'm expecting 90% or so
<tpw_rules>
i mean isn't it just the remainder of the last chip
<ZirconiumX>
Yep
<tnt>
And can your routing to 'gate swap' intra & interchip to find the best routing ?
<emily>
ZirconiumX: omg, that's beautiful
<ZirconiumX>
tnt: TopoR seems a bit limited in that respect, unfortunately
<ZirconiumX>
I can identify sets of pins that commute
<ZirconiumX>
But I can't tell it to do something like use a different gate on the chip
Asu has joined ##openfpga
<freemint>
Are there any OpenFPGA communities which are really succesful (by member number, by problems solved, or some other metric)?
Asu` has quit [Ping timeout: 245 seconds]
<freemint>
Or is everything "individuals pushing in their repo" with loose interaction and some tool reuse because people are to busy to rewrite them from scratch?
<emily>
seems like a loaded question :p
<emily>
nextpnr is pretty from-scratch, isn't it?
<ZirconiumX>
As is Yosys, I think
<ZirconiumX>
Though it does build on ABC
<freemint>
I am sorry i could not formulate it less loaeded
<freemint>
I want to figure out if development by "a community" is a approach that works for FPGA at all.
Asu has quit [Remote host closed the connection]
mumptai has quit [Remote host closed the connection]
Asu has joined ##openfpga
rohitksingh has quit [Ping timeout: 276 seconds]
<ZirconiumX>
freemint: Of course it does
<freemint>
That is good to hear. I was not really sure from the conversations in here.
emeb_mac has joined ##openfpga
Asu` has joined ##openfpga
<freemint>
Are there any OPENFpga communities/projects which are considered beginner friendly?
Asu has quit [Ping timeout: 272 seconds]
<daveshah>
freemint: I'm sure if you lurk around here, #yosys, #litex and #symbiflow you'll see some interesting stuff
<daveshah>
Are you more talking about using open source tools or developing them?
<freemint>
I am especially interest in communities around projects like "BitCoin miner", "CPU" with open VHDL/Verilog source with my questions
<freemint>
Tooling not so much
<daveshah>
idk if that many people here are looking at the former, but loads of people here are doing custom CPUs or experimenting with existing ones
<freemint>
I was curious whether these things are "one man projects" or if there is some community ofr projects of this sort
<azonenberg>
freemint: sounds like you are more interested in open FPGA development? yeah i dont think there is a particular channel for open HDL projects, just all of the FPGA-related ones in general
<azonenberg>
This channel is specifically about open tooling
<azonenberg>
not that we'll turn away users of such tools
<freemint>
Ooops
<azonenberg>
it's just not the main focus of the chan
<azonenberg>
Certainly if you are working on f/oss projects using our tools you're more than welcome
<freemint>
Nah the project i am looking at is VHDL and there is no good open source tooling for it from my impression
<azonenberg>
All of the tools we're working with here are verilog-2005, and the focus for front-end improvement is adding systemverilog support
<azonenberg>
there's not enough VHDL users among the devs to expect much progress