| lkcl | i got a demo running of how to remap the triple loop of matrix multiply into 3 linear array "generators" https://twitter.com/lkcl/status/1410734426204512258 | 00:04 |
|---|---|---|
| lkcl | the idea is to drop that onto the "normally linear Vector operations" | 00:05 |
| lkcl | and if done on top of FMAC it does an arbitrary-sized Matrix Multiply *in-place*, up to a total of 64 FMACs | 00:06 |
| lkcl | the generators however i am really struggling to get the ordering right | 00:07 |
| lkcl | i mean, they're right _now_ because i went through dozens of permutations of arguments until the right sequence(s) were printed | 00:07 |
| lkcl | a review would be helpful | 00:08 |
| Shell | /part/ | 08:18 |
| *** Shell <Shell!~shell@user/shell> has left #libre-soc | 08:18 | |
| sasi8985 | Hi all, I am trying to build Libresoc on ubuntu;i tried on mintos 20.x it worked but for ubuntu i am getting this error | 10:43 |
| sasi8985 | Traceback (most recent call last): | 10:43 |
| sasi8985 | File "src/soc/simple/issuer_verilog.py", line 117, in <module> | 10:43 |
| sasi8985 | vl = verilog.convert(dut, ports=dut.external_ports(), name="test_issuer") | 10:43 |
| sasi8985 | File "/tmp/soc/nmigen/nmigen/back/verilog.py", line 61, in convert | 10:43 |
| sasi8985 | return _convert_rtlil_text(rtlil_text, strip_internal_attrs=strip_internal_attrs) | 10:43 |
| sasi8985 | File "/tmp/soc/nmigen/nmigen/back/verilog.py", line 47, in _convert_rtlil_text | 10:43 |
| sasi8985 | return yosys.run(["-q", "-"], "\n".join(script), | 10:43 |
| sasi8985 | File "/tmp/soc/nmigen/nmigen/_toolchain/yosys.py", line 145, in run | 10:43 |
| sasi8985 | return cls._process_result(popen.returncode, stdout, stderr, ignore_warnings, src_loc_at) | 10:43 |
| sasi8985 | File "/tmp/soc/nmigen/nmigen/_toolchain/yosys.py", line 108, in _process_result | 10:43 |
| sasi8985 | raise YosysError(stderr.strip()) | 10:43 |
| sasi8985 | nmigen._toolchain.yosys.YosysError: thread '<unnamed>' panicked at 'assertion failed: res.eax == 0', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/raw-cpuid-7.0.3/src/lib.rs:295:13 | 10:43 |
| sasi8985 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace | 10:43 |
| sasi8985 | fatal runtime error: failed to initiate panic, error 5 | 10:43 |
| lkcl | hi sasi8985 welcome | 10:44 |
| lkcl | ok, first thing, we only support debian/10 | 10:44 |
| sasi8985 | okay | 10:45 |
| openpowerbot | [mattermost] <lkcl> for this exact reason | 11:01 |
| lkcl | however there is slightly more to it | 11:02 |
| lkcl | when doing ASICs you *absolutely cannot have* any possible differences in library routines or versions of software | 11:02 |
| lkcl | or versions of hardware | 11:04 |
| lkcl | producing subtle differences in the Tape-out (layout) | 11:04 |
| lkcl | strictly speaking, two people should be able to run the exact same automated script | 11:04 |
| lkcl | and compare the *bare metal hard drive contents* after running the Tape-out for 36 hours | 11:04 |
| lkcl | and the contents of the *bare metal* drives should be exactly the same | 11:05 |
| lkcl | then you can safely and confidently know that the TEN MILLION DOLLARS you are going to spend on Foundry Masks are ok | 11:05 |
| lkcl | so please follow the instructions and use debian schroots | 11:05 |
| lkcl | sasi8985: here https://git.libre-soc.org/?p=dev-env-setup.git;a=summary | 11:05 |
| lkcl | there's some instructions here that you can follow step-by-step: | 11:06 |
| lkcl | https://libre-soc.org/HDL_workflow/devscripts/ | 11:06 |
| lkcl | basically, if it doesn't work on a particular OS, not being funny, it's your problem to fix | 11:06 |
| lkcl | if however you use the standard development environment that we chose for the project in order for everyone to be able to produce the exact same output | 11:06 |
| lkcl | (which is an Industry-standard practice for ASIC development to do that) | 11:06 |
| lkcl | *then* we will kick into high gear and help get it sorted | 11:06 |
| lkcl | so please can you use the standard dev scripts (install a debian chroot) and let us know ok? | 11:06 |
| lkcl | sasi8985: make sense? | 11:07 |
| lkcl | btw you pasted a bit too much into the IRC client (generally this is not good practice) | 11:07 |
| lkcl | you were lucky it did not "kick" or "ban" you, automatically :0 | 11:07 |
| lkcl | instead of pasting dozens of lines, it's best to either send to the mailing list (as text, not images) | 11:07 |
| lkcl | or to raise a bugreport (bugs.libre-soc.org) | 11:08 |
| lkcl | or use a pastebin somewhere (debian run one, ubuntu run one, there are plenty around) | 11:08 |
| lkcl | these will do perfectly fine - https://paste.debian.net https://pastebin.ubuntu.com/ | 11:08 |
| lkcl | but, really, the bugtracker is the place to report bugs. | 11:09 |
| sasi8985 | lkcl: yes got it.. i will try those scripts and get back to you if there are issues | 11:09 |
| lkcl | brilliant | 11:09 |
| lkcl | sasi8985: how much memory on your laptop btw? | 11:10 |
| sasi8985 | 4 gb ram :-( | 11:10 |
| lkcl | i have *64* GB of RAM (!!) i was veeery lucky to have it donated | 11:10 |
| lkcl | eek! | 11:10 |
| lkcl | ok well if you can review the Charter and you can send me an ssh public key i can probably give you a remote shell login to the Raptor Engineering sponsored TALOS-II workstation | 11:11 |
| sasi8985 | lkcl: i saw your youtube video of building soc where you got read and write speeds of 30 and 40 mbps...but i am getting 1 and 0.7 mbps...is the ram reason | 11:11 |
| lkcl | that and if it's a slower processor, yes. i have an NVMe SSD, it is 2500 mbytes/sec read speed (!!) | 11:12 |
| lkcl | i actually have diff | 11:12 |
| lkcl | iculty getting my head round how fast it is :) | 11:12 |
| lkcl | http://libre-soc.org/charter/discussion | 11:13 |
| lkcl | if you're happy to abide by the charter, i'm happy to let you use the TALOS-II workstation, remotely. | 11:13 |
| lkcl | also... you might also be able to get a remote login to Oregon State University computers. | 11:13 |
| lkcl | you can ask Ganesan about that | 11:13 |
| lkcl | the FPGAs OSU have, woooow | 11:14 |
| sasi8985 | lkcl: yes...i have used those computers but same speed | 11:14 |
| lkcl | interesting. | 11:14 |
| lkcl | well, the Raptor TALOS-II is almost no other users and has ridiculous amounts of RAM and cores | 11:14 |
| sasi8985 | lkcl: okay..may be ganesan should comment regarding this | 11:15 |
| lkcl | i run the Libre-SOC project, so i can give you permission to log in to our sponsored TALOS-II machine, as long as you review and are happy with our Charter | 11:16 |
| lkcl | OSU you have to speak with them, and Ganesan, yes. | 11:16 |
| sasi8985 | lkcl:yeah... i just now saw a sim.vcd file in one of the directories maybe near sim.v....is the instruction level signal vcd file | 11:18 |
| lkcl | sasi8985: oh btw what were those other questions you had? | 11:18 |
| lkcl | yes. | 11:18 |
| lkcl | ./sim.py --trace (something like that) | 11:18 |
| lkcl | you should be able to run ./sim.py --help | 11:18 |
| lkcl | the only thing is: the VCD file produced by litex is "damaged", subtly | 11:19 |
| lkcl | it's not litex's fault, it's verilator | 11:19 |
| lkcl | so depending on the version of verilator you are using it *might* be fixed, now. | 11:19 |
| lkcl | if not, then use this: | 11:19 |
| lkcl | vcd2fst sim.vcd sim.fst | 11:20 |
| lkcl | fst2vcd sim.fst sim_no_longer_borked.vcd | 11:20 |
| lkcl | and | 11:20 |
| lkcl | sigh | 11:20 |
| lkcl | you will find, magically, that gtkwave can now properly show you the trace signals :) | 11:20 |
| lkcl | the "borked" symptoms you're looking for are that you display a trace signal in gtkwave and it looks completely blank. | 11:21 |
| lkcl | *including* sys_clk. which is clearly and obviously false, esp. if you inspect the VCD file manually | 11:21 |
| sasi8985 | yes i will try that too....i want to use microwatt with system c as it has some inbuilt libraries of interconnects.,fifo's etc can i do that? i think library is matchlib | 11:23 |
| lkcl | for that, there's the #microwatt channel. | 11:24 |
| lkcl | which toshywoshy has just successfully got the bridge to OPF mattermost up and running again | 11:24 |
| sasi8985 | okay | 11:24 |
| lkcl | or, you can log in here | 11:24 |
| lkcl | https://chat.openpower.foundation/opf/channels/microwatt | 11:24 |
| lkcl | SystemC is proprietary: Libre-SOC absolutely cannot use it. | 11:25 |
| lkcl | we are under "Audit" conditions (NLnet Privacy and Enhanced Trust) | 11:25 |
| lkcl | plus, the company, RED Semiconductor, is seeking VC Funding based on full transparency, for security reasons. | 11:26 |
| sasi8985 | One more question is there any chance of developing system verilog testbench for this soc. | 11:26 |
| sasi8985 | lkcl: okay got it...i can't use. | 11:26 |
| lkcl | oh, you can use it for microwatt, no problem. they don't have such limitations | 11:27 |
| lkcl | sure you can develop a SV testbench if you like | 11:27 |
| lkcl | System Verilog is now supported by yosys i believe | 11:27 |
| sasi8985 | lkcl: yes there are almost done | 11:27 |
| lkcl | http://www.clifford.at/yosys/cmd_read_verilog.html | 11:27 |
| lkcl | "a small subset is supported" | 11:28 |
| lkcl | but ahh, interesting | 11:28 |
| lkcl | remember though, that we have literally thousands of testbenches already | 11:28 |
| lkcl | in the case of the IEEE754 FPU it's *hundreds* of thousands of testbenchs. | 11:29 |
| lkcl | really not kidding, it takes a week to run them all | 11:29 |
| lkcl | they're all automated behind python unit tests | 11:29 |
| sasi8985 | okay..got it..for me it will take months then | 11:30 |
| lkcl | :) | 11:30 |
| lkcl | yeahh you don't want to run those :) or, you can on the TALOS-II workstation, no problem | 11:30 |
| lkcl | 24 cores (!!) | 11:30 |
| lkcl | htop is very funny, it reports 72 processes :) | 11:30 |
| lkcl | but the non-IEEE754 ones, you should at least try running some of them | 11:31 |
| lkcl | 1 sec | 11:31 |
| * lkcl just finding some... | 11:31 | |
| lkcl | ok any of these: | 11:32 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD | 11:32 |
| lkcl | test_caller_fp.py will be quite short | 11:32 |
| lkcl | that tests the *simulator* | 11:33 |
| sasi8985 | yeah sure i will try them | 11:33 |
| lkcl | we use it for bootstrap | 11:33 |
| lkcl | when we know the simulator is correct, then we can compare against the HDL. | 11:34 |
| lkcl | single-step mode | 11:34 |
| lkcl | extract the register file (and some memory) and compare them | 11:34 |
| lkcl | use "nohup" btw. or output the console garbage to a file, ok? :) | 11:35 |
| lkcl | a loooot of debug output is printed | 11:35 |
| lkcl | for co-simulating the hardware-vs-simulator, this is quite short: | 11:36 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/test/test_issuer_svp64.py;hb=HEAD | 11:36 |
| sasi8985 | i will have to try all these only then it makes sense | 11:36 |
| lkcl | yehyeh, no exactly. | 11:37 |
| lkcl | learning-is-doing. wait.... doing-is-learning :) | 11:37 |
| lkcl | here's the actual unit tests, divided by pipeline | 11:38 |
| lkcl | (similar to the way v3.0B PDF spec is organised) | 11:38 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/test;hb=HEAD | 11:38 |
| * lkcl lunch for me, now :) | 11:39 | |
| sasi8985 | okay :) | 11:44 |
| sasi8985 | Thanks for all the help and guidance...i am learning a lot from these | 11:44 |
| openpowerbot | [irc] <vpandya> Is there any example which show SVP64 textual assembly ? | 13:15 |
| lkcl | vpandya: yes | 13:39 |
| lkcl | 1 sec | 13:40 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=HEAD | 13:40 |
| openpowerbot | [irc] <lkcl> vpandya: there's some actual functional examples for MP3 | 13:41 |
| openpowerbot | [irc] <lkcl> i need to choose a better "separator" than the exact same one as comment ("#") | 13:41 |
| openpowerbot | [irc] <lkcl> here: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/audio/mp3/mp3_0_apply_window_float_basicsv.s;hb=HEAD | 13:42 |
| openpowerbot | [irc] <lkcl> there's actual functional Makefiles in there https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=media/audio/mp3;hb=HEAD | 13:43 |
| openpowerbot | [irc] <lkcl> but use this one to "wget" the data: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/Makefile;hb=HEAD | 13:43 |
| openpowerbot | [irc] <lkcl> if you need more examples give me a shout. | 13:46 |
| programmerjake | sasl8985 did you get that error running in a VM? that particular error is caused by the x86 cpuid instruction reporting it supports getting some extended state, but not returning that extended state when asked again -- symptoms of a broken VM implementation. try using different virtualization software | 13:55 |
| sasi8985 | programmerjake: Hi programmerjake. No i got that error from University of oregon system(Jupiter). some yosys assertion failure | 14:03 |
| lkcl | ahh you'll be on a Virtual Machine, that's why | 14:04 |
| lkcl | that needs to be reported to OSU, then | 14:04 |
| sasi8985 | Sure i will tell Ganesan | 14:06 |
| sasi8985 | lkcl: I have tried that unix "pipe" thing to issue commands through jtag "https://pastebin.ubuntu.com/p/CBXrwgfff6/" | 14:10 |
| lkcl | great! | 14:11 |
| lkcl | it worked! | 14:11 |
| lkcl | yes, that command simply runs JTAG "idcode" | 14:11 |
| programmerjake | sasi8985 after a little more research turns out your cpu/vm is just fine, the cpuid crate just made an incorrect assumption which is violated by recent intel cpus that support avx512_bf16 | 14:11 |
| programmerjake | https://github.com/gz/rust-cpuid/issues/45#issuecomment-872984806 | 14:11 |
| lkcl | TDO (000018ff) | 14:11 |
| lkcl | that's the JTAG idcode | 14:12 |
| lkcl | so the next thing to try, if you like, is the *python*-based version of openocd "remotejtag" | 14:12 |
| lkcl | which... 1 sec... | 14:12 |
| sasi8985 | yes!!! | 14:12 |
| sasi8985 | programmerjake: it is an open issue maybe i will just report it and try with working system | 14:13 |
| programmerjake | sasi8985 can you comment on that github issue with your /proc/cpuinfo? or you can email it to me and I can post it. | 14:15 |
| programmerjake | this issue: https://github.com/gz/rust-cpuid/issues/45#issuecomment-872984806 | 14:15 |
| sasi8985 | programmerjake: yeah sure...shouild i send a log file of that | 14:16 |
| lkcl | programmerjake: thx. it's the oregon state university server | 14:16 |
| programmerjake | nah, it's cuz they have a recent intel cpu and the cpuid crate made an incorrect assumption about how the cpuid instruction works | 14:17 |
| lkcl | what am i doing... oh yes, trying to find the jtagremote.py test | 14:17 |
| lkcl | sasi8985: here you go https://git.libre-soc.org/?p=soc.git;a=tree;f=src/soc/debug/test;hb=HEAD | 14:18 |
| lkcl | and there's this as well: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/debug/firmware_upload.py;hb=HEAD | 14:18 |
| lkcl | bear in mind, those are hoooorrribly slow | 14:18 |
| lkcl | like... 50-100 JTAG bits per second, something mad like that | 14:19 |
| lkcl | also: annoyingly, the JTAG "reset" command, when sent to verilator, goes and trashes the memory, resetting it back to running the BIOS. | 14:19 |
| lkcl | sigh. | 14:19 |
| sasi8985 | lkcl: Okay...i will leave this system on for 4 hours and see atleast one command is passed | 14:20 |
| lkcl | but, at least you can show the JTAG wishbone read/write is working. and JTAG stop/start | 14:20 |
| lkcl | sasi8985: it shouldn't take anywhere near that long | 14:20 |
| lkcl | like... 3-4 minutes | 14:20 |
| lkcl | just not "3-4 seconds" like you'd normally expect | 14:20 |
| programmerjake | sasi8985 send your /proc/cpuinfo, only the assertion failed line is relevant to the cpuid crate | 14:21 |
| sasi8985 | okay :) | 14:21 |
| sasi8985 | programmerjake: thread '<unnamed>' panicked at 'assertion failed: res.eax == 0', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/raw-cpuid-7.0.3/src/lib.rs:295:13 | 14:22 |
| lkcl | sasi8985, run "cat /proc/cpuinfo > {some_file}" or "cp /proc/cpuinfo {some_file}" on jupiter. | 14:24 |
| lkcl | and drop it into pastebin | 14:24 |
| sasi8985 | lkcl: https://pastebin.ubuntu.com/p/g9NkyVjbQG/ | 14:26 |
| lkcl | programmerjake: ^ | 14:28 |
| programmerjake | thx, I'll post that to the github issue | 14:28 |
| * lkcl ok, cool. off out for a walk. sitting down all day, getting antsy :) | 14:28 | |
| programmerjake | sasi8985 posted to github: https://github.com/gz/rust-cpuid/issues/45#issuecomment-873001709 | 14:33 |
| sasi8985 | programmerjake: Thanks. | 14:34 |
| programmerjake | yw | 14:34 |
| programmerjake | you'll just have to run it on a cpu that doesn't support avx512_bf16 for now, or figure out how to patch that cpuid crate (sounds like a pain) | 14:37 |
| sasi8985 | programmerjake: yes...i will run it on other system | 14:48 |
| programmerjake | sasi8985 I also opened bug reports https://github.com/YoWASP/yosys/issues/22 and https://github.com/bytecodealliance/wasmtime/issues/3053 | 15:25 |
| sasi8985 | great, thank you :) | 15:27 |
| programmerjake | :) | 15:27 |
| sasi8985_ | Regarding python based opencod i am getting "https://pastebin.ubuntu.com/p/kdCh6mx9CC/" i installed this "https://pastebin.ubuntu.com/p/CW3bp8Qc3H/" but no luck. | 15:47 |
| programmerjake | you need python 3.7 or later: https://docs.python.org/3/library/socket.html#socket.close | 15:50 |
| sasi8985_ | okay Thanks | 15:53 |
| lkcl | sasi8985_, please don't put quotes around the pastebin, it stops irc clients from being able to open the link, because they think the " at the end is part of the URL | 15:59 |
| lkcl | yep, the default version of python from the chroot scripts comes out as python 3.7 | 15:59 |
| sasi8985_ | Okay i will take care. | 16:00 |
| lkcl | star | 16:00 |
| lkcl | ezcellent, the FFT "REMAP" triple generators work | 16:07 |
| lkcl | https://twitter.com/lkcl/status/1410973407890624512 | 16:07 |
| lkcl | (sasi8985_ for context there, we're aiming to do the loops of Matrix Multiply, FFT and DCT, with a *single* instruction) | 16:15 |
| lkcl | plus some context setup, but hey :) | 16:15 |
| sasi8985_ | great..is this for power isa also or only riscv | 16:17 |
| programmerjake | not for riscv, we're working on only openpower for >1yr | 16:18 |
| programmerjake | though I wouldn't object to their using our design :) | 16:18 |
| sasi8985_ | okay..i thought for riscv as its there in riscv directory | 16:20 |
| programmerjake | ?? where? | 16:20 |
| sasi8985_ | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/remapfft.py;h=458c839c237d707234ad933cdfd9744a7b7a43ab;hb=HEAD#l74 | 16:21 |
| programmerjake | ah, we never got around to renaming the git repo. it is in the openpower directory in that git repo though | 16:22 |
| lkcl | yes it's a bit of a pain, renaming that repository is a bit awkward | 16:22 |
| lkcl | i have to symlink it to stop older links from breaking | 16:23 |
| lkcl | and redo the ikiwiki configuration, and... ur.... | 16:23 |
| lkcl | this is what FFT looks like in x86 assembler | 16:25 |
| lkcl | https://github.com/lu-zero/ffmpeg/blob/master/libavcodec/x86/fft_mmx.asm | 16:25 |
| lkcl | 666 lines! | 16:26 |
| lkcl | altivec isn't much better - that's a *macro* there | 16:26 |
| lkcl | https://github.com/lu-zero/ffmpeg/blob/master/libavcodec/ppc/fft_altivec_s.S | 16:26 |
| lkcl | slightly horrified to see that assembly macro might actually be recursive | 16:27 |
| lkcl | with the SVP64 FFT-REMAP schedule i think we'll be down to about 20-25 lines of assembler | 16:28 |
| lkcl | for *variable* length power-of-two FFT | 16:28 |
| programmerjake | getting visions of turing complete macros using continuation-passing-style... :P | 16:28 |
| sasi8985_ | is theer anything wrong with systems https://pastebin.ubuntu.com/p/BbwxKgzMgW/ | 16:42 |
| lkcl | sasi8985_, don't use python 3.8 either | 17:16 |
| lkcl | *only* use python 3.7 | 17:16 |
| lkcl | programmerjake: yeahno :) | 17:17 |
| lkcl | it'd be hilarious, having a mini CPU inside a CPU | 17:17 |
| lkcl | in all seriousness we have to be really careful about gate latency for REMAP | 17:17 |
| lkcl | only using adds and MUXes | 17:18 |
| lkcl | the FSM's going to be a bit of a pig to be honest | 17:19 |
| sasi8985_ | lkcl: https://paste.ubuntu.com/p/Qvt7yDF6nV/ jtag sim stopped but some different bios is loaded this time as it has some different crc than previous one | 18:36 |
| sasi8985_ | also if i want to run python codes on libresoc should i need to connect to fpga? | 18:48 |
| lkcl | sasi8985_, yes, every single time that you run ./sim.py, the entire BIOS source code is recompiled. | 18:59 |
| lkcl | a date and time stamp is inserted into the source code automatically. | 18:59 |
| lkcl | therefore you will never, under any circumstances, get the exact same CRC. | 19:00 |
| sasi8985_ | lkcl: i think there is a deine for time and date | 19:00 |
| lkcl | unless you modify the BIOS source code to remove the insertion of time/date | 19:00 |
| lkcl | this is "Not_Our_Problem(tm)" :) | 19:00 |
| lkcl | it merely explains the anomalous, unexpected, behaviour | 19:00 |
| lkcl | by "running some python codes", do you mean, "do you want to run micropython"? | 19:01 |
| lkcl | "some python codes" makes no sense | 19:01 |
| lkcl | (there is no such thing as "python codes") | 19:01 |
| sasi8985_ | i meant like a helloworld program in python | 19:02 |
| lkcl | then you'll need to run micropython. | 19:03 |
| lkcl | which can be done by using the binary from the tests directory in microwatt | 19:03 |
| lkcl | and modifying sim.py (by hand) at this line: | 19:03 |
| lkcl | https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=sim.py;hb=HEAD#l54 | 19:03 |
| lkcl | obviously, take out the line "ram_name=None" that comes after it | 19:03 |
| lkcl | i haven't run any of the microwatt binaries in a while | 19:04 |
| * lkcl trying one now | 19:04 | |
| sasi8985_ | okay i will try to run that hello world.bin | 19:04 |
| lkcl | ok sim.py runs the BIOS... | 19:05 |
| lkcl | just bear in mind that the microwatt binaries assume a 16550 UART | 19:06 |
| lkcl | litex uart is *NOT* a 16550 UART. | 19:06 |
| lkcl | hey, the hello_world.bin works. | 19:06 |
| lkcl | so you won't be able to interact with micropython over the console | 19:07 |
| lkcl | because although it will print at the console (the "write" of litex UART happens to coincide with 16550 UART write addresses) | 19:08 |
| lkcl | the reading (typing) does NOT | 19:08 |
| lkcl | you'd have to update the micropython source code in microwatt to use litex's way of doing UART. | 19:09 |
| lkcl | *then* it will work, ok | 19:09 |
| lkcl | ? | 19:09 |
| sasi8985_ | yeah i am getting it | 19:09 |
| lkcl | at least this works | 19:09 |
| lkcl | MicroPython v1.12-571-g16d6cb7f7-dirty on 2020-06-23; bare-metal with POWERPC | 19:09 |
| lkcl | Type "help()" for more information. | 19:09 |
| lkcl | >>> | 19:09 |
| lkcl | basically you have to develop three things, all at the same time: | 19:10 |
| lkcl | 1) the software | 19:10 |
| lkcl | 2) the peripherals | 19:10 |
| lkcl | 3) the main core | 19:10 |
| lkcl | *all three absolutely have to match* | 19:10 |
| lkcl | https://github.com/antonblanchard/microwatt/tree/master/micropython | 19:10 |
| lkcl | errr i have no idea where that binary came from. | 19:10 |
| lkcl | you'll have to ask on the #microwatt channel | 19:11 |
| lkcl | or on here | 19:11 |
| lkcl | https://chat.openpower.foundation/opf/channels/microwatt | 19:11 |
| sasi8985_ | okay. | 19:11 |
| lkcl | hmm looks like it was built externally and only the binary added | 19:12 |
| lkcl | https://github.com/antonblanchard/microwatt/commit/434962bc34d605f3049ff904e847f0db53110426 | 19:12 |
| sasi8985_ | for fpga also can i can make some changes in https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=versa_ecp5.py;h=18aca0eedf6f9f8ab3ecffa5fd6e98d305e92376;hb=HEAD and generate bitstream | 19:13 |
| lkcl | yes. | 19:13 |
| lkcl | if you happen to have access to an Arty A7-100 that would be _great_ | 19:14 |
| lkcl | bear in mind that versa_ecp5.py although it says VERSA_ECP5 it also has a class for the Radeona ULX3S | 19:14 |
| lkcl | which is a great board, very low cost | 19:14 |
| lkcl | note in that file, there is JTAG btw? | 19:15 |
| lkcl | to test that, you need to get some sort of FT232 USB dongle | 19:15 |
| sasi8985_ | OSU has xilinx zynq-7 mpsoc+ fpga i guess | 19:16 |
| lkcl | and then (ta-daaa) you can connect it to the FPGA board and run the exact same firmware_upload.py as you did earlier against the simulation | 19:16 |
| lkcl | well, then, nmigen will have to be modified to support whatever-it-is. | 19:16 |
| sasi8985_ | Okay..so i think we should buy some low cost board and test it. | 19:18 |
| lkcl | or, you export to verilog and you're on your own from that point onwards | 19:18 |
| lkcl | basically... yes. | 19:18 |
| sasi8985_ | libresoc.v? | 19:18 |
| lkcl | Ganesan is talking with Tim Pearson to get some of the ModBMC boards connected to Raptor TALOS-II workstations for you | 19:19 |
| lkcl | yes libresoc.v | 19:19 |
| lkcl | however you also need to set up peripherals etc. etc. etc. etc. | 19:19 |
| lkcl | a core is just a core | 19:19 |
| lkcl | it's no good if it has no memory, or anything else to connect to the outside world, is it? | 19:20 |
| sasi8985_ | yes...i want to run programms from sdram and send the transactions through pcie | 19:20 |
| lkcl | ok then you need to investigate what type of internal Bus Architecure the zync-7 has | 19:21 |
| lkcl | (which is probably AXI-4 - we have everything set up to do wishbone because it's not patented and is a lot simpler) | 19:21 |
| sasi8985_ | For this i thought i will write some basic assembly program and initialize main_ram of core with this program and generate some .vcd files | 19:21 |
| lkcl | microwatt likewise uses wishbone | 19:22 |
| lkcl | DDR RAM requires "training" initialisation. | 19:22 |
| lkcl | before it can even *become* DDR RAM. | 19:22 |
| sasi8985_ | cant we write like OUT a2 address | 19:23 |
| lkcl | nnope. not until you've run the "DDR training". | 19:23 |
| lkcl | this is a whooole area you need to investigate and learn about | 19:23 |
| sasi8985_ | yes..i should | 19:24 |
| lkcl | ULX3S uses SDRAM (133mhz) precisely for this reason | 19:24 |
| lkcl | a couple of other boards use HyperRAM | 19:24 |
| lkcl | the reason is because DDR runs so fast, you get impedance mis-match | 19:25 |
| lkcl | and the A0-12 and D0-D31 signals *bounce back* and destroy the signals | 19:25 |
| lkcl | to "fix" that, both the DRAM PHY *and the DDR IC* have built-in tunable RC circuits | 19:26 |
| lkcl | yes, really | 19:26 |
| lkcl | and the "training" basically goes through all possible permutations of the settings | 19:26 |
| lkcl | "does this work with controller RC-circuit timing = 0.1ps phase delay yes no" | 19:27 |
| lkcl | ok? ok try 0.2ps | 19:27 |
| lkcl | no? ok try 0.3ps delay | 19:27 |
| lkcl | ... | 19:27 |
| lkcl | ... | 19:27 |
| lkcl | ... | 19:27 |
| lkcl | it's completely insane but that's how you can get 800mhz, 1300 mhz, 2400 mhz, 3200 mhz etc. etc. etc. | 19:27 |
| sasi8985_ | i dont know about these kind of circuits | 19:27 |
| lkcl | RC: resistor-capacitor | 19:28 |
| lkcl | no, and normally you wouldn't have to. | 19:28 |
| lkcl | welcome to low-level hardware | 19:28 |
| sasi8985_ | :) | 19:28 |
| lkcl | all of these circuits are *built-in* to the FPGAs and into DRAM ICs | 19:28 |
| lkcl | so you don't have to "know" about them, but you *do* have to run some assembly code which initialises the interface. | 19:29 |
| sasi8985_ | okay discharge and charge are the pulse widths? for speed | 19:29 |
| lkcl | etc. etc. | 19:29 |
| lkcl | and some other timings N-N-N whatever those are | 19:29 |
| lkcl | a good BIOS will have support for these, already. | 19:30 |
| sasi8985_ | okay i got it there is a gap for in interaction between ram and cpu | 19:32 |
| sasi8985_ | i thought it like if we give clock to ddr ram controller it will automatically start transactions | 19:32 |
| lkcl | nnope. | 19:38 |
| lkcl | SDRAM, yes. | 19:38 |
| lkcl | DDR2, DDR3, DDR4, no | 19:38 |
| lkcl | because SDRAM is only 100, 133 or 166mhz | 19:38 |
| lkcl | so there is no signal-bounce at that kind of speed | 19:38 |
| lkcl | or, there is... | 19:38 |
| lkcl | ... but it quickly dies down and doesn't interfere with the next signal | 19:38 |
| lkcl | DDR2: 400mhz clock rate | 19:38 |
| lkcl | DDR3: 800mhz clock rate | 19:39 |
| lkcl | DDR4: 1.6 ghz | 19:39 |
| lkcl | the speed of light is 3x10^8 | 19:39 |
| sasi8985_ | :-) | 19:39 |
| lkcl | so 3 ghz is only... err... 10 cm? | 19:39 |
| lkcl | so the signals start bouncing back and interfering with the next clock | 19:40 |
| lkcl | simple physics | 19:40 |
| lkcl | ever played with a slinky? :) | 19:40 |
| lkcl | and had it "bounce" a wave back and forth? | 19:40 |
| sasi8985_ | no | 19:40 |
| lkcl | https://www.youtube.com/watch?v=SCtf-z4t9L8 | 19:41 |
| lkcl | here | 19:42 |
| lkcl | https://youtu.be/SCtf-z4t9L8?t=205 | 19:42 |
| lkcl | watch the signal "bounce back" | 19:42 |
| lkcl | that's *exactly* what happens on DDR signals... | 19:42 |
| lkcl | *unless*.... | 19:42 |
| lkcl | you have an "absorber" at the other end | 19:42 |
| lkcl | perfectly matched to the "friction", to the length, to the weight of the slinky, to the speed of the waves | 19:43 |
| lkcl | etc. etc. etc. etc. | 19:43 |
| sasi8985_ | got it.. | 19:45 |
| sasi8985_ | For sdram speed is less and the signal bounce doesn't start or if starts ends quickly is this? | 19:46 |
| sasi8985_ | its enough for me today. Good night. | 19:53 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!