lkcl | awygle, a thought: some time in the next... 3-5 months would you be happy with a commission to implement and validate RGM-II, USB-ULPI and USB3-PIPE in nmigen? | 13:24 |
---|---|---|
lkcl | agg did a basic M-II implementation in nmigen, really well | 13:25 |
lkcl | cesar[m]1, first integer-based predication test passes in ISACaller :) | 15:23 |
programmerjake | yay! predication! | 15:44 |
lkcl | :) | 20:11 |
lkcl | CRs next | 20:11 |
lkcl | done, pretty easy. | 20:50 |
lkcl | (with the int predication already in place) | 20:51 |
lkcl | twin-predication next but have to add srcstep-dststep first | 20:51 |
lkcl | irrelevant for when there's no predicate masks because | 20:55 |
lkcl | srcstep==dststep | 20:55 |
lkcl | but obviously for twin-predication it matters | 20:55 |
programmerjake | lkcl: first step: remove all 0b prefixes: | 21:00 |
programmerjake | nmigen.hdl.dsl.SyntaxError: Case pattern '0b010-' must consist of 0, 1, and - (don't care) bits, and may include whitespace | 21:00 |
lkcl | programmerjake: yes... ahhh i remember why i didn't do this | 21:01 |
lkcl | it's because power_decoder.py needs to be adjusted to match | 21:01 |
programmerjake | do we need the 0b somewhere? | 21:01 |
lkcl | you have to change the "opint=True" argument to Subdecoder in power_decoder.py | 21:01 |
lkcl | and the code is sufficiently complex that i went, "argh not doing it" at the time | 21:02 |
lkcl | changing opint=True to opint=False - which is what says "is this an integer or is it a pattern with "-"s in it" | 21:02 |
lkcl | changes the behaviour of Subdecoder subtly | 21:03 |
programmerjake | how about I just change it to remove the 0b prefix when there are any - characters? | 21:03 |
lkcl | give it a shot | 21:03 |
programmerjake | that way we don't need opint at all | 21:03 |
lkcl | maaaybee.... | 21:04 |
lkcl | line 320 | 21:04 |
lkcl | it's been a year since i looked at this so you'll have to experiment | 21:04 |
lkcl | if d.opint and '-' not in opcode: | 21:04 |
lkcl | opcode = int(opcode, 0) | 21:04 |
programmerjake | since we really should have all the csv files use the same format, and not pass in extra arguments in the parser code | 21:04 |
lkcl | it's just not that simple, jacob | 21:04 |
programmerjake | if a csv file needs info specific to itself, it should include the info in the csv file | 21:05 |
programmerjake | if csv isn't sufficient, we can switch to json or something | 21:05 |
lkcl | the additional requirement is to not deviate from what microwatt does, significantly | 21:06 |
lkcl | it's bad enough that RS has moved field and that the "CR in" field is no longer a 0/1 | 21:06 |
programmerjake | yup, so...we have the current csv columns be a list of dicts in a json (or better yet, a toml file) and the top-level dict has that list as one field and the Subdecoder.pattern as another field | 21:08 |
programmerjake | and all the other fields of Subdecoder too | 21:08 |
lkcl | making that chance has a large cascade effect because so much depends on those CSV files | 21:09 |
lkcl | including the wiki | 21:09 |
programmerjake | having it be json instead of csv doesn't inherently change the underlying data... | 21:09 |
lkcl | it's adding unnecessary work that we don't have time for | 21:09 |
lkcl | there are much higher priority tasks | 21:09 |
programmerjake | if we use use toml, I'd consider the text form readable enough that we could just put that directly on the wiki | 21:09 |
lkcl | and then the sv_analysis.py needs updating | 21:11 |
lkcl | and the power_decoder.py | 21:11 |
lkcl | and the microwatt writing code | 21:11 |
lkcl | and the SV reading codce | 21:12 |
lkcl | and | 21:12 |
lkcl | and | 21:12 |
lkcl | and | 21:12 |
lkcl | and | 21:12 |
lkcl | and | 21:12 |
lkcl | so... no. | 21:12 |
lkcl | i've said it already: too much is critically dependent on those CSV files | 21:12 |
lkcl | and we have *higher priority tasks* | 21:12 |
programmerjake | basically the only code that should need to read write csv is the .py on the wiki that generates the SVP64 csvs and the power_decoder.py. all other code should be using the power_decoder.py file so they don't see any change | 21:12 |
programmerjake | note the should be using power_decoder.py | 21:13 |
programmerjake | if they're not -- seems like bad design | 21:13 |
lkcl | again: | 21:14 |
lkcl | i repeat | 21:14 |
lkcl | again | 21:14 |
lkcl | there are *higher priority tasks* | 21:14 |
programmerjake | yeah, I get that...just complaining. I'll add a workaround to the decoder and see if that works | 21:14 |
programmerjake | summary: oh well, our code's an awful mess, we'll fix it later | 21:15 |
lkcl | be *very* careful with it, and for goodness sake make sure to run all unit tests before committing | 21:16 |
lkcl | i really mean all | 21:16 |
lkcl | decoder/isa/test_caller*.py | 21:16 |
lkcl | and simple/test/test_issuer_svp64.py as well as test_issuer.py | 21:17 |
programmerjake | isn't that just the full integration test and not the unit tests? | 21:17 |
lkcl | yes those are the full integration tests, which *use* the unit tests | 21:17 |
lkcl | the single-pipeline (FU) tests use only a subset decoder | 21:18 |
programmerjake | ??? I thought unit tests should be independent of eachother | 21:18 |
lkcl | they are | 21:18 |
programmerjake | you just said they weren't... | 21:18 |
lkcl | the independent unit tests fu/alu/test_pipe_caller.py | 21:18 |
lkcl | are each called *three separate times* | 21:18 |
lkcl | once for FU pipeline only | 21:18 |
lkcl | once when the pipeline is wrapped with a CompUnit | 21:19 |
lkcl | and once from test_issuer.py which throws all of those independent unit tests at a TestIssuer | 21:19 |
programmerjake | ah, k | 21:19 |
lkcl | there used to be test_core.py as well but it served its purpose | 21:19 |
programmerjake | this is making me think I should just add a workaround to simplev-cpp and save myself the headache... | 21:20 |
lkcl | TestIssuer now has a "main" PowerDecoder and there are multiple "satellite" decoder subsets (filtered) | 21:20 |
lkcl | it's got... very comprehensive | 21:20 |
lkcl | "small" seeming changes now have very large knock-on implications | 21:21 |
programmerjake | well, before making any changes: python src/soc/decoder/isa/test_caller.py | 21:25 |
* programmerjake < https://matrix.org/_matrix/media/r0/download/matrix.org/xCMnJVEBQehuoRVXYsDguTPK/message.txt > | 21:26 | |
lkcl | that's a HTTP link | 21:26 |
lkcl | programmerjake < https://matrix.org/_matrix/media/r0/download/matrix.org/xCMnJVEBQehuoRVXYsDguTPK/message.txt > | 21:27 |
lkcl | yes, known problem, the answer's correct, the unit test isn't :) | 21:27 |
lkcl | i just haven't got round to updating it | 21:27 |
lkcl | because there's so much to do | 21:27 |
programmerjake | so, I should expect that failure | 21:28 |
lkcl | yes | 21:28 |
lkcl | more accurately: you should expect that test to incorrectly *report* failre | 21:28 |
programmerjake | well, running the other tests you specified... | 21:29 |
* programmerjake < https://matrix.org/_matrix/media/r0/download/matrix.org/YRBgXxKOLduljHZgNCGLtrAa/message.txt > | 21:30 | |
lkcl | i still can't see those messages in irc | 21:30 |
lkcl | they come up as "a link has been sent" | 21:30 |
lkcl | (to an offsite non-audited website) | 21:30 |
lkcl | ah you need to install that | 21:31 |
lkcl | https://git.libre-soc.org/?p=c4m-jtag.git;a=summary | 21:31 |
lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=hdl-dev-repos;hb=HEAD | 21:31 |
programmerjake | missing from setup.py? | 21:31 |
lkcl | no, missing on your system | 21:31 |
lkcl | we're not using pip3 because it's such a f*****g nuisance | 21:32 |
programmerjake | well, I just ran make develop before...if it's missing it should complain. | 21:32 |
lkcl | causes no end of "ohh i fink i will install wotever s***" | 21:32 |
programmerjake | even if it doesn't install it for you, it should at least tell you you need it... | 21:33 |
lkcl | the morons running the python foundation now think it's a great idea to automatically go hunting through some random unsigned website if you happen to list the dependencies in the setup.py file | 21:33 |
lkcl | without actually asking the user if it's ok to do that | 21:33 |
lkcl | it's already caused enough problems for us with nmigen, nmigen-soc and other packages downloading random arbitrary versions of dependencies | 21:34 |
lkcl | just install it manually but *don't* install staf's version | 21:35 |
lkcl | use our version which has the pip3 crap-for-brains removed and also has DMI capability added | 21:35 |
programmerjake | well, I like cargo better since you can use git and path dependencies where it automatically uses the specified git repo or uses the specified local path. pip just doesn't support that apparently... | 21:36 |
lkcl | apparently it's possible | 21:38 |
lkcl | https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/ | 21:38 |
lkcl | which probably means that it's possible to specify in the setup.py file as well | 21:38 |
lkcl | which... yeah. no. :) | 21:38 |
programmerjake | no it's not supported in setup.py? or no you don't like it? | 21:39 |
lkcl | i suspect it is | 21:40 |
lkcl | if it can be done from the commandline | 21:40 |
lkcl | and correct: with so much else to do, most newcomers we would point at the dev-setup scripts | 21:40 |
programmerjake | c4m-jtag/setup.py | 21:41 |
programmerjake | packaging.version.InvalidVersion: Invalid version: '24jan2020' | 21:41 |
programmerjake | when running: python setup.py develop | 21:41 |
lkcl | *sigh* | 21:41 |
programmerjake | it's using setuptools_scm 6.0.1 if that helps... | 21:42 |
lkcl | 1 sec let me check | 21:42 |
lkcl | interestingly i don't have setuptools-scm installed | 21:43 |
lkcl | unless (argh) pip3 went and f*****g well downloaded it randomly | 21:43 |
lkcl | see why i intensely dislike pip3? | 21:43 |
lkcl | you have *no idea* what the hell it downloaded | 21:43 |
programmerjake | I'm on commit c71b674a067a52a26e96242c148c09999f237826 if that helps | 21:44 |
lkcl | commit c71b674a067a52a26e96242c148c09999f237826 (HEAD -> master, tag: ls180-24jan2020, origin/master, origin/HEAD) | 21:45 |
lkcl | Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> | 21:45 |
lkcl | Date: Sun Oct 25 11:26:26 2020 +0000 | 21:45 |
lkcl | resolve issue in coriolis2 with passing nmigen expressions rather | 21:45 |
lkcl | than signals to a submodule | 21:45 |
lkcl | yep | 21:45 |
lkcl | same | 21:45 |
programmerjake | setup_requires=["setuptools_scm"], | 21:45 |
lkcl | right. | 21:45 |
lkcl | try to find where the hell pip3 installed setuptools_scm without your consent and authorisation and remove it | 21:45 |
lkcl | then "apt-get install python3-setuptools-scm" | 21:46 |
programmerjake | sorry, apt-get won't help ... I'm in a virtualenv | 21:46 |
lkcl | i'll add that to the dev-setup-scripts | 21:46 |
programmerjake | which version do you have? | 21:46 |
lkcl | the version i had at the time was 3.4.3 (or thereabouts) | 21:47 |
lkcl | /home/chroot/coriolis-buster/home/lkcl/nmigen/.eggs/setuptools_scm-3.4.3-py3.7.egg/EGG-INFO/top_level.txt | 21:47 |
lkcl | it _should_ be possible to put "=N.N" after setuptools_scm | 21:48 |
* lkcl just updating python3-setuptools as well | 21:49 | |
lkcl | i got the same warning on running develop | 21:49 |
lkcl | it was however a warning not an error | 21:49 |
lkcl | still got a warning | 21:49 |
programmerjake | ah, bet it's the tag name | 21:50 |
lkcl | Please see PEP 440 for more details. | 21:50 |
lkcl | apparently | 21:50 |
programmerjake | the git tag is not a valid version string | 21:50 |
lkcl | Finished processing dependencies for c4m-jtag===24jan2020 | 21:50 |
lkcl | ahh yeah | 21:50 |
lkcl | git tag --list | 21:51 |
lkcl | ls180-24jan2020 | 21:51 |
programmerjake | I'll let you make a different tag that's a proper version string | 21:51 |
lkcl | setup( | 21:52 |
lkcl | name="c4m_jtag", | 21:52 |
lkcl | - use_scm_version=scm_version(), | 21:52 |
lkcl | + #use_scm_version=scm_version(), | 21:52 |
lkcl | goodbye problem | 21:52 |
programmerjake | lemme know when you pushed the fix | 21:52 |
lkcl | edit that out and it'll work | 21:53 |
lkcl | i'm not too keen on deviating from what Staf's done | 21:53 |
programmerjake | so...should I also change the git tag? otherwise anyone using the tagged code will run into this issue | 21:53 |
lkcl | tell you what, i'll just comment out that line. | 21:54 |
lkcl | too much else to focus on | 21:55 |
programmerjake | change tag? | 21:57 |
lkcl | git pull, try it | 21:57 |
programmerjake | apparently works! | 21:58 |
lkcl | goood :) | 21:58 |
programmerjake | so, just re-point tag at latest commit? | 21:59 |
lkcl | mmm that'd probably do the trick | 21:59 |
* lkcl no idea if you can delete tags - you're not suppposed to be able to | 22:00 | |
programmerjake | you can...but git doesn't automatically sync tags...you have to explicitly ask it to | 22:01 |
lkcl | dang i think twin-predication with masks is working | 22:02 |
programmerjake | how about I just create a tag ls180-24jan2020-fixed | 22:02 |
lkcl | sure that's a good idea | 22:02 |
programmerjake | commit 8241c4fdf5d89c710b073c3a6544f7cc7c944e02 (HEAD -> master, tag: ls180-24jan2020-fixed, origin/master, origin/HEAD) | 22:03 |
programmerjake | works! | 22:05 |
lkcl | exccellent | 22:05 |
programmerjake | well, food time...will work on testing soc later | 22:05 |
lkcl | ok :) | 22:06 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!