| awygle | lkcl_: on a totally unrelated note, regarding the sdram controller referenced above, were you unable to find a libre-licensed controller for more advanced memory, or just decided sdram was the way to go? | 00:46 |
|---|---|---|
| lkcl_ | DDR3/4 needs a high-speed analog PHY which, due to the parallel data bus, actually needs impedance-match training *at both ends* | 01:12 |
| lkcl_ | this is extremely complex and costly analog design work that is tuned not only to the geometry but to the characteristics of the Foundry | 01:13 |
| lkcl_ | consequently it requires approximately 12 to 18 months of R&D for which USD 600,000 is not an unreasonable fee | 01:13 |
| lkcl_ | or | 01:13 |
| lkcl_ | you license a proprietary PHY which has been silicon proven, tested, and Certified by the designers to actually work | 01:14 |
| awygle | sure. i often will cap my designs at DDR2 even on devices with their own analog PHYs just because it's so much simpler. | 01:14 |
| lkcl_ | for which you pay typically USD $1m and receive it immediately | 01:15 |
| lkcl_ | if you happen to know a way to drive even DDR2 using digital-only signals that would be fantastic | 01:16 |
| lkcl_ | a hell of a lot better than 133 mhz SDRAM1 | 01:16 |
| lkcl_ | anyway. 1am here. more tomorrow | 01:17 |
| jn__ | a libre modern memory controller would be an interesting project in itself | 01:27 |
| awygle | hm depending on what exactly ou mean by "digital-only" i'm not sure there needs to be much if any analog in a ddr2 phy beyond just having a reasonably stable output impedance | 01:59 |
| awygle | although i'd want to double check the spec for what's actually mandatory before asserting that with confidence | 01:59 |
| lkcl_ | awygle: some (most if not all) FPGAs have fixed impedance outputs even for DDR3 PHYs | 12:26 |
| lkcl_ | this basically relies on two things: | 12:26 |
| lkcl_ | 1) for simple designs, certain DDR RAM ICs are "Certified" (or more like "tested until they find one that works...") for use with that FPGA | 12:27 |
| lkcl_ | 2) resistor banks are inserted into the data lines (address lines are more lenient, having a longer hold time) which can be manually replaced until it "works" | 12:28 |
| lkcl_ | then by more luck than good fortune the DRAM ICs can be "trained" to match the (fixed) impedance of the IC and it works... | 12:29 |
| lkcl_ | ... but only at low clock rates | 12:29 |
| lkcl_ | for the gigabit ethernet router IC that may well be "Good Enough" | 12:29 |
| lkcl_ | because it's only going to be maximum 300mhz anyway | 12:30 |
| lkcl_ | driving QFP pins beyond around 150 mhz is risky and eats power esp. at 1.8v | 12:31 |
| lkcl_ | cesar[m]2, | 14:12 |
| lkcl_ | + # remember whether this is a prefixed instruction, so | 14:12 |
| lkcl_ | + # the FSM can readily loop when VL==0 | 14:12 |
| lkcl_ | nice! | 14:12 |
| * lkcl_ just reviewing binutils gas source code | 16:45 | |
| lkcl_ | https://bugs.libre-soc.org/show_bug.cgi?id=615#c12 | 16:45 |
| lkcl_ | adding in svp64 support looks to be pretty damn straightforward | 16:45 |
| lkcl_ | if it was longer than 3 days i'd start to get concerned | 16:46 |
| lxo | if you think so, I say go for it. I've been stuck myself | 17:32 |
| lxo | it's very hard for me to deal with moving targets | 17:33 |
| lxo | I don't suppose my first steps would save much time, but if you wish, I can send it to you | 17:36 |
| lkcl_ | lxo: yes please. | 18:02 |
| lkcl_ | one thing i left out: generating a table which identifies EXTRA2/3, which matches... err... where is it... | 18:03 |
| lkcl_ | const struct powerpc_opcode powerpc_opcodes[] = { | 18:04 |
| lkcl_ | ...} | 18:04 |
| lkcl_ | that one's a bit of a pain, as a separate hash-table will be needed | 18:04 |
| lkcl_ | or | 18:04 |
| lkcl_ | extending struct powerpc_opcode | 18:05 |
| lkcl_ | which i'm reluctant to do because the patch would hit hundreds of lines | 18:05 |
| lkcl_ | holy shit *thousands* of lines | 18:05 |
| lkcl_ | four and a half *THOUSAND* opcodes, christ | 18:06 |
| programmerjake | hmm, if you add a field to powerpc_opcode, shouldn't a refactoring tool be able to make all the appropriate edits? though if you add the field at the end and have it be zero by default you can just leave it out of most of the struct initializers...right? | 18:23 |
| programmerjake | add `struct svp64_properties svp64;` as a new field | 18:25 |
| programmerjake | alternative...have a c or python build script that generates a c source or header file containing the definitions | 18:27 |
| programmerjake | depends on if binutils will accept python build scripts... | 18:27 |
| programmerjake | lkcl_ lxo ^ | 18:28 |
| programmerjake | or maybe a posix shell build script...but that'll be more of a pain | 18:29 |
| lxo | what is the project's reference timezone, UTC (no DST changes), NA (now in DST) or Europe (not yet in DST)? | 20:13 |
| programmerjake | generally UTC | 20:13 |
| programmerjake | though the meeting schedules may change due to DST, check with lkcl_ | 20:16 |
| lxo | heh, if there's any uncertainty as to whether it changes with DST, then there's just as much uncertainty as to whether UTC is the reference timezone | 20:54 |
| programmerjake | well, we have changed it in the past since some people would rather not meet at 1am or 7am... | 20:55 |
| lxo | I understand the rationales. but I have to adjust my calendar appointments | 20:57 |
| programmerjake | the google calendar meeting for tuesday is still at 22:00 utc so far | 20:59 |
| lxo | back when Brazil had DST, my US-centered appointments had to be changed 4 times a year, varying by up to two hours depending on the offsets between the two hemispheres | 20:59 |
| lxo | so I understand the rationales and the procedures, I pay attention to the dates (I've had colleagues in various European countries), I just don't know how this specific team deals with this | 21:00 |
| programmerjake | I'm personally hoping switching timezones twice a year goes away, it's a major pain and doesn't even have the marginal energy-saving it might have had 80 years ago... | 21:04 |
| programmerjake | from what I can tell anyway | 21:04 |
| programmerjake | tzdata is already a mess, simplifying it will definitely be nice! | 21:05 |
| lkcl_ | if they don't accept scripts then we just auto-generate it anyway | 21:52 |
| lkcl_ | yes the meetings are all in UTC | 21:52 |
| lkcl_ | we *may* have to shift the wednesday bi-weekly one forward an hour not because of DST but because AU goes back *two* hours, it's unreasonable for Paul, Mikey and Anton otherwise | 21:53 |
| lkcl_ | lxo: yeah that patch looks great, can you create a branch and push to https://git.libre-soc.org/?p=binutils-gdb.git;a=summary ? | 22:02 |
| lxo | auto-generated files without their corresponding sources in the source repo would be a violation of the GPL, wouldn't it? | 22:32 |
| lxo | I happen to have had a long conversation with rms about generated files not long ago, maybe as recently as a couple of weeks ago | 22:35 |
| lxo | the conclusion, in my own words, is that the sources are what you edit to develop the program. so if the idea is to have a one-shot generation of the file, and from then on edit the generated file, that is your source. but if you'd go back to the original inputs and modify them to regenerate the file, then the generated file is not source | 22:37 |
| lxo | also keep in mind that GNU requires copyright assignments to the FSF for binutils (and gcc) | 22:39 |
| lxo | ugh, why is git trying to push the world to the repo, when I've only modified a couple of files? | 22:52 |
| programmerjake | did you filter-branch? :) | 22:59 |
| lxo | heh, no | 23:06 |
| lxo | I even tried to push the base commit along with the patched one, which usually avoids this when testing patches based on trees that are a few days old, but that didn't help. weird. investigating | 23:08 |
| lxo | ok, gas changes are in heads/lxo/WIP-svp64-gas, gcc changes are in heads/lxo/WIP-svp64-gcc, in the respective repos | 23:17 |
| programmerjake | ah, I'd bet it was because the git repos on libre-soc are several weeks out-of-date | 23:25 |
| programmerjake | were* | 23:25 |
| lkcl_ | lxo: very interesting about the auto-generated source... in this particular case it would make the CSV files from the Libre-SOC website part of that "source" | 23:33 |
| lkcl_ | ah i meant a collaborative branch name that we can work together | 23:36 |
| lkcl_ | ok so i've pushed a branch libresoc-svp64-gas | 23:39 |
| lkcl_ | no problem with copyright assignment. | 23:44 |
| lxo | lkcl_, why stop at the CSV file? how about the sources of the web pages, from which the CSV file is generated IIRC? | 23:47 |
| lkcl_ | the web pages *are* from the CSV files because they're also auto-generated (from ikiwiki) | 23:51 |
| lkcl_ | ahh except actually those CSV files were taken part-verbatim from microwatt initially | 23:52 |
| lxo | ah, so the pages are generated from CSV, and I'd got it backwards? | 23:52 |
| lkcl_ | correct. | 23:54 |
| lxo | thanks | 23:54 |
| lkcl_ | it goes: | 23:54 |
| lkcl_ | * microwatt decode1.vhdl --> | 23:54 |
| lkcl_ | * minor_19.csv, minor_31.csv, major.csv etc. etc | 23:54 |
| lkcl_ | * sv_analysis.py reads *.csv | 23:55 |
| lkcl_ | * sv_analysis.py writes SV*.csv | 23:55 |
| lkcl_ | and microwatt_sv_decode.vhdl | 23:55 |
| lkcl_ | and now i'd like to add ppc_svp64_info_struct.h | 23:56 |
| lkcl_ | *hypothetically* speaking it *may* be possible to write a parser of decode1.vhdl | 23:57 |
| lkcl_ | which would be hilarious. | 23:57 |
| lkcl_ | sv_analysis.py would take decode1.vhdl as input | 23:57 |
| lkcl_ | (downloaded with wget) | 23:57 |
| lkcl_ | create the csv files as temporary output | 23:58 |
| lkcl_ | except i've made some modifications to the CR column. but that's just one column | 23:58 |
| lxo | that fits the case richard wanted to talk to me about | 23:59 |
| lkcl_ | that's funny | 23:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!