| programmerjake | found this interesting paper on generating a frequency comb all the way up to around 4GHz from a driving frequency around 200MHz by using ferromagnetics: https://scholar.archive.org/work/loeq4sye4jahrdxxydmngjt3wu/access/wayback/https://assets.researchsquare.com/files/rs-577652/v1_covered.pdf | 03:32 |
|---|---|---|
| programmerjake | assuming that can be shrunk and put on a cmos chip and have the output converted back to the electric domain and filtered, it could be a good replacement for multi-gigahertz PLLs with maybe better energy efficiency! | 03:34 |
| programmerjake | the diamonds and femtosecond lasers were just used as magnetic sensors so would not be needed on a cmos-integrated version | 03:36 |
| programmerjake | afaict | 03:36 |
| sadoon_albader[m | Morning all, starting the gentoo stuff right now! | 05:31 |
| sadoon_albader[m | Might need a bigger SSD for the VMs though | 05:31 |
| sadoon_albader[m | Thankfully the prices are still sane, I'm thinking of buying before some changes happen | 05:32 |
| sadoon_albader[m | For starters I plan to build enough software to have a desktop environment and a simple browser (probably webkit2gtk for now) | 05:33 |
| sadoon_albader[m | Once that works on pure ppc64le I will start to disable features like vsx and such and rebuild everything | 05:33 |
| sadoon_albader[m | Will report back if anything happens | 05:33 |
| programmerjake | thanks for working on that! | 05:38 |
| sadoon_albader[m | no problem :) | 05:41 |
| lkcl | sadoon_albader[m, star | 09:50 |
| sadoon_albader[m | As in the celestial explosions? | 09:53 |
| lkcl | yes. big thing that constantly goes bang. | 09:53 |
| sadoon_albader[m | :p | 09:53 |
| lkcl | https://dictionary.cambridge.org/dictionary/english/you-re-a-star | 09:54 |
| sadoon_albader[m | Ah I guess urban dictionary was the wrong place | 09:54 |
| sadoon_albader[m | Thank you :) | 09:54 |
| lkcl | https://www.urbandictionary.com/define.php?term=you%27re%20a%20star | 09:54 |
| lkcl | same thing | 09:54 |
| sadoon_albader[m | I just looked for "star" | 09:55 |
| lkcl | urr just adding a batch of AsyncFIFOs to the DRAM controller | 14:55 |
| lkcl | should allow the GRAM DDR3 controller to run at say 100 mhz | 14:56 |
| lkcl | whilst CPUs can run at anything-they-like. | 14:56 |
| tplaten | I'm trying to get microwatt working on the orangecrab, I flashed the bitstring, but I don't get any output on the uart. | 16:04 |
| lkcl | tplaten, correct. there isn't an actual UART on the USB pins | 16:24 |
| lkcl | you have to wire up an external USB-UART onto the pins shown in the orangecrab-0.2.lpf (constraints) file | 16:24 |
| tplaten | I did wire an external uart and still don't get any output | 16:25 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/master/constraints/orange-crab-0.2.lpf | 16:25 |
| lkcl | 1 sec | 16:25 |
| lkcl | to which pins? | 16:25 |
| lkcl | actually there's nothing in that constraints file which says uart_tx and uart_rx verilog signals should be connected to anything!! | 16:26 |
| lkcl | which explains why you get nothing :) | 16:26 |
| lkcl | which pins did you wire up the external uart to? | 16:26 |
| lkcl | e.g. if you look at this https://github.com/antonblanchard/microwatt/blob/f01f3d233ae4de595fa29beb305d00ce960f041e/constraints/ecp5-evn.lpf#L7 | 16:26 |
| lkcl | you see how that defines what uart0_txd / uart0_rxd must be connected to? | 16:27 |
| lkcl | P3 and P4 respectively | 16:27 |
| lkcl | you must do exactly the same thing | 16:27 |
| lkcl | find out the ECP5 BGA IOpad name from the orangecrab schematics | 16:27 |
| tplaten | I connected OC IO 0 (OC TX) to UART RX, UART TX is unconnected, as described in https://codeconstruct.com.au/docs/microwatt-orangecrab/ | 17:02 |
| tplaten | I had a look at constraints/orange-crab-0.2.lpf there is LOCATE COMP "pin_gpio_0" SITE "N17"; // tx | 17:04 |
| lkcl | tplaten fantastic | 18:11 |
| lkcl | programmerjake, can you mention the "proper" fix, give full context (post the contents of the email i sent you)? | 18:23 |
| lkcl | https://github.com/gatecat/nextpnr-xilinx/issues/34 | 18:23 |
| lkcl | otherwise people will flounder around here and it won't get properly fixed | 18:23 |
| lkcl | the proper fix is in the synth_xilinx arithmetic techmap to split at batches of 26 of CARRY4s | 18:24 |
| lkcl | the reason is that the "tiles" are subdivided by big routing trunks (acomodi explained all this to me a few weeks back) | 18:25 |
| lkcl | there's only room to put about 23-26 CARRY4s together in a chain before you have to "cross over" one of those routing trunks | 18:25 |
| lkcl | to do that you have to put the carry-out from one of the CARRY4s into a Signal | 18:26 |
| lkcl | let that "cross over" | 18:26 |
| lkcl | and accept it as Carry-in on another batch-of-CARRY4s-in-another-tile | 18:26 |
| tplaten | Now, I'll test merge-3d-game | 18:27 |
| lkcl | neither VPR nor nextpnr-xilinx can cope, therefore the "best" place to "fix" this is in the yosys techmap | 18:27 |
| lkcl | otherwise, VPR has to put in a workaround | 18:40 |
| lkcl | oh and then nextpnr-xilinx has to put in a workaround | 18:40 |
| programmerjake | imho vpr and nextpnr-xilinx are where that would be handled since they know the details of how many carry4 blocks are available and should be able to insert the necessary routing between them. imho yosys is the wrong place to try to fix that. | 20:04 |
| programmerjake | lkcl: https://github.com/gatecat/nextpnr-xilinx/issues/34#issuecomment-1065472075 | 20:08 |
| programmerjake | vpr: https://github.com/SymbiFlow/f4pga-arch-defs/issues/2463#issuecomment-1065474154 | 20:11 |
| lkcl | ok, it's complicated | 20:48 |
| lkcl | the yosys synth_xilinx alu techmap just creates a bunch of chained CARRY4 blocks together. nothing fancy, nothing clever about it, at all. | 20:48 |
| lkcl | symbiflow goes "yarg that's dreadful, let's shuffle those about to create some properly-efficient carry-propagation chains" which work in parallel. it's an extremely elegant algorithm | 20:49 |
| lkcl | BUT | 20:49 |
| lkcl | it's done as one of the most awful hacks i've seen in what is otherwise a pretty well-designed chain of open source software in a long time :) | 20:50 |
| lkcl | what it does is: *after* you have run yosys and done some ABC9 parsing, the file is exported to JSON | 20:50 |
| lkcl | ... then imported by a special-hatchet-job-python-script... | 20:51 |
| lkcl | which does AST-node-walking... | 20:51 |
| lkcl | which then outputs the JSON file after all of the carry-propagation-chains have been done... | 20:51 |
| lkcl | which yosys then picks up with "read_json" | 20:51 |
| lkcl | now, if you throw the output from yosys (with the naive chain-of-CARRY4s) at the proprietary xilinx tools, obviously it does a "proper dash professional" job of working out the blocks etc. | 20:52 |
| programmerjake | like it should... | 20:53 |
| lkcl | that hack-job verilog-to-json-to-a-python-script-to-json-and-back-out-again is just such a waste | 20:53 |
| lkcl | it should have been done in yosys techmaps, where *all* the different xilinx toolchains could benefit from it | 20:53 |
| lkcl | now nextpnr-xilinx has to implement that algorithm | 20:54 |
| lkcl | as well | 20:54 |
| lkcl | this is futilility at its best, forcing people to waste their time duplicating effort that compensates - *multiple times* in different tools - for yosys having a "naive" algorithm | 20:54 |
| lkcl | i forgot: we're *assuming* that xilinx proprietary tools do a decent job. | 20:55 |
| lkcl | they obviously fix the "breaking-down-into-blocks-of-23/26" problem | 20:56 |
| lkcl | but we have no idea if they perform a half-decent resource-utilisation job of using carry-propagation etc. | 20:56 |
| programmerjake | imho high-level optimizations like parallelizing carry chains should be done in yosys, low-level stuff like inserting wires in carry chains that are too long should be done by vpr or nextpnr -- they shouldn't try to redo the carry algorithm by parallelizing it tho | 20:56 |
| programmerjake | well...xilinx proprietary tools do at least a better job than vpr or nextpnr here...they work | 20:57 |
| lkcl | i made an attempt to modify the botch-program (in python), it was so complex i couldn't do it. | 20:57 |
| lkcl | because by the time the botch-job-program got to the NETLIST, it had already turned a very simple "add" operation into an extremely complex batch of CARRY4s plus CARRY-in, CARRY-out, and other blocks that are resource-specific | 20:58 |
| lkcl | that you simply cannot just decide "i'll wire this to that and it'll be all luvey" because they're hard-wired blocks that *only* take inputs from certain other blocks | 20:59 |
| lkcl | a bit like trying to change a programmer's high-level language mistakes by botch-patching the binary. | 21:00 |
| lkcl | and finding out that you've violated the function ABI in the process | 21:01 |
| programmerjake | vpr nextpnr should be where carry chain splitting occurs since you might want 2 different adders in your block of 23, only nextpnr and vpr know that those both need to be short enough to fit and should be able to figure out where to chop carry chains to make them fit | 21:02 |
| lkcl | btw can you please edit and the comment so that it say "is best fixed" not "should be fixed". | 21:03 |
| lkcl | "should be fixed" is a demand to the developers | 21:04 |
| lkcl | "is best fixed" is a neutral opinion | 21:04 |
| programmerjake | changed in both the nextpnr and vpr comments | 21:06 |
| programmerjake | added the email contents and link to this conversation on irclog: https://github.com/gatecat/nextpnr-xilinx/issues/34#issuecomment-1065472075 | 21:15 |
| programmerjake | lkcl, you'd be happy, Rust's project-portable-simd is likely to switch to naming stuff elementwise rather than lanewise: https://twitter.com/workingjubilee/status/1501274323939520514 | 21:20 |
| programmerjake | i remember you making a big deal about that... | 21:21 |
| *** jn_ is now known as jn | 22:41 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!