<omnitechnomancer>
Oh one other comment about the rust, is there a reason you don't use &patterns when iterating over the u32s? Eg 'for &input in &self.inputs {' so that you don't have to deref everywhere?
<Lofty>
Force of habit I guess
<omnitechnomancer>
Ah
FabM has joined #apicula
<omnitechnomancer>
Hmmm, so my hacked up serving seems to take 203 chips with the 74ac.lib cell library
<omnitechnomancer>
Do the octal DFFs have a reset line?
FabM has quit [Ping timeout: 265 seconds]
FabM has joined #apicula
<pepijndevos_>
gahhhhhh, python packaging
<omnitechnomancer>
Lofty: did your number of cells for serv_top go down with 74LVC1G99 based cells?
<omnitechnomancer>
Trying to get python to link to things pepijndevos_ ?
<Lofty>
I recall it's something like 550 chips with the 1G99 library, but because they're single chips, it's so much easier to place and route
<Lofty>
omnitechnomancer: Do the octal DFFs have a reset line? <--- '377 has a clock enable line, '273 has a reset line
<Lofty>
But your mention of flops gives me a slightly crazy idea
<omnitechnomancer>
and the 374?
<omnitechnomancer>
ah just tristate outputs
<omnitechnomancer>
Yea the packing for multi gate parts is probably not fun
<omnitechnomancer>
I tried hacking up a little library with some of the gates the 1G99 can do and got a serving hacked to put the RAM signals out to ports to 959 cells
<omnitechnomancer>
What manner of dubious idea are you having?
<Lofty>
I *swear* I found a 16-bit flip flop chip
<Lofty>
Which you could probably build register files out of
<Lofty>
Holy shit I found it
<Lofty>
The 74__16374
<pepijndevos_>
omnitechnomancer, no, just trying to package apicula so it's easier to use and install, but there are a million outdated and conflicting packaging solutions
<omnitechnomancer>
Ah, most annoying
<omnitechnomancer>
PyPI?
<pepijndevos_>
Yea, but like... just when I got over the whole setuptools distutils thing, turns out there is now a setup.cfg option and a Manifest.in and what not
<omnitechnomancer>
I wonder how much optimisation you lose out on by synthing parts of the design separately
<omnitechnomancer>
For example for CSRs it would be neat to be able to have a design that is synthed with them but works if you just never populate those parts (perhaps with some appropriate pull up/downs somewhere)
<pepijndevos_>
hoshteoshteonhst (sorry my keyboard mash looks weird, it's my keyboard layout)
<pepijndevos_>
I forgot how to makefile
<pepijndevos_>
What do you call those %@< bits that refer to parts of the rules?
<omnitechnomancer>
So with no CSRs I go down about 89 non FF cells
<omnitechnomancer>
Is the area particularly important when all the cells represent the same chip?
<pepijndevos_>
blegh
<pepijndevos_>
%.pickle: %_stage2.pickle
<pepijndevos_>
cp $*_stage2.pickle $*.pickle
<pepijndevos_>
does not work...
<omnitechnomancer>
Why not 'cp $< $@' ?
<omnitechnomancer>
and in what way does it not work?
<pepijndevos_>
make: *** No rule to make target 'GW1N-1.pickle', needed by 'all'. Stop.
<pepijndevos_>
because I'm an idiot
<omnitechnomancer>
run with -d
<omnitechnomancer>
no rule for makign the stage2 pickles?
<pepijndevos_>
ahhh -d I was trying --verbose and what not hehe
<pepijndevos_>
no problem was I moved some files around, so it depended on a source file that was moved.
<omnitechnomancer>
ah, that would not help
<omnitechnomancer>
-d helps to explain why it wont use your rule you think it should
<pepijndevos_>
yea... I was very actively looking for that option
<pepijndevos_>
I knew I'd used it before
<pepijndevos_>
Turns out there is a *reason* Apicula didn't have any sort of build system or packaging for the longest time... Hopefully today will just be one day of concentrated misery that will make everything easier in the future.
<pepijndevos_>
After like a decade of Python, import rules are still a mystery to me. I moved all my files into a package with a __init__.py and changed all the imports to "from apycula import foo" like a good boy, but that only works if I run with "python -m apycula.foo" if I just pass the path it can't find the apycula package... for reasons...
<omnitechnomancer>
I had to find it a bit ago to find out why the kicad dir makefile in 74xx-liberty wasnt working
<omnitechnomancer>
Python imports are somewhat a mystery to me too
<omnitechnomancer>
time to RIIR /s :P
<pepijndevos_>
Nexus is actually largely written in rust... but the fuzzers are still python
<pepijndevos_>
(had to google riir)
<omnitechnomancer>
Yea I know
<omnitechnomancer>
Is there any spec for how the mtime mtimecmp RISC-V timer works with respect to what happens when the irq happens? Is the counter supposed to reset? Is it supposed to start at any particular value?
<omnitechnomancer>
And I was being facetious
<rvalles>
Are the dual-port memory blocks working? I'll be soldering headers to tang nano later today, and attempt to get things working.
<pepijndevos_>
rvalles, in synth_gowin, yes. Apicula, no.
<rvalles>
Hopefully I can then get synth_gowin to make me some RAM out of LUTs instead?
<rvalles>
I only need a few bytes, ultimately.
<rvalles>
(can probably make things work with 16)
<rvalles>
If I can't, it's no big deal either. I'll play with the functionality that works, and hang around to see where apicula goes.
<rvalles>
Did cost less than $10 shipped after all, and I have other FPGAs to play with :)
<pepijndevos_>
rvalles, so synth_gowin has a threshold for when it will use block ram, so even that will probably use lutram or straight up luts
<pepijndevos_>
bug yea, if you just need a few bytes, you can actually just use Apicula with nextnpr-generic and it will just synth to luts.
<rvalles>
It's for a FIFO... one of the sides is an async protocol, so I can always stall that when it's near full.
<rvalles>
So I'll likely get it working no prob, unless something else screws me up.
<rvalles>
(e.g. I need two tristate pins)
<rvalles>
(which is likely to be working, but I can't count on it)
<pepijndevos_>
Meanwhile I'm writing a setup.py for Apicula, and wondering if I should make it call make or let make call setup.py or neither
<pepijndevos_>
kbeckmann, would it make sense to add another gh action that pulls the artifact of the chipdb one, and publishes the python package to pypi?
<kbeckmann>
sure, or integrate it as a final task in the job that builds the artifact. not sure what's the best approach.
<pepijndevos_>
me neither...
<pepijndevos_>
I think a separate step might be better, in case one step fails or something. Don't really know.
<kbeckmann>
i guess one should be careful to not do too much in the same action so it doesn't hit a timeout. i'd assume there is some limit.
<kbeckmann>
nice
<pepijndevos_>
So now I just have to figure out how to run setup.py, and how to pick up the artefacts from another action
<pepijndevos_>
I guess that answers the other question: setup.py should not run make
<kbeckmann>
oh i just noticed that the jobs take over 1h now. didn't expect the free GH jobs to support that without complaining.
<kbeckmann>
all the more reason to make the artifacts more accessible :)
<kbeckmann>
but yeah let's do it as a separate step that depends on the chidb builder step. i have not done this before, neither done pypi publishing nor a more complex workflow with dependencies like this.
<kbeckmann>
so can't help you immediately. will have to do some trial and error i guess.
<kbeckmann>
i'll be afk for a while, but ttyl.
<pepijndevos_>
if it helps we could split fuzzing for different FPGAs into their own step, and somehow cache the docker image between them.
<kbeckmann>
there might be an easier way but this worked for me
<kbeckmann>
i have this set up so it builds all of my aur packages every day so i get a notification when something breaks
<kbeckmann>
oh the urls should be swapped... but you get the idea
<pepijndevos_>
ohhh, you have infra set up to build aur packages? Recently noticed libftd2xx is orphaned and was broken, so if you feel like adopting it... haha
<trabucayre>
pepijndevos_: libftdi not libftd2xx :)
<pepijndevos_>
do you have to configure GITHUB_TOKEN etc. or these are given automatically?
<trabucayre>
libftd2xx is the proprietary blog from ftdi
<pepijndevos_>
huh... I have that one installed
<trabucayre>
it's possible to have both libraries
<pepijndevos_>
maybe that was for the python lib... I forgot...
<kbeckmann>
my memory is a bit hazy but i think i didn't have to setup any tokens, it's all github magic
<pepijndevos_>
oh okay... I was reading about the new thing that supersedes the other docker thing and they mentioned having to set up a special token...
<kbeckmann>
i don't see any secrets in the repo->settings->secrets view at least.