Friday, 2022-03-11

programmerjakefound this interesting paper on generating a frequency comb all the way up to around 4GHz from a driving frequency around 200MHz by using ferromagnetics:
programmerjakeassuming 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
programmerjakethe diamonds and femtosecond lasers were just used as magnetic sensors so would not be needed on a cmos-integrated version03:36
sadoon_albader[mMorning all, starting the gentoo stuff right now!05:31
sadoon_albader[mMight need a bigger SSD for the VMs though05:31
sadoon_albader[mThankfully the prices are still sane, I'm thinking of buying before some changes happen05:32
sadoon_albader[mFor starters I plan to build enough software to have a desktop environment and a simple browser (probably webkit2gtk for now)05:33
sadoon_albader[mOnce that works on pure ppc64le I will start to disable features like vsx and such and rebuild everything05:33
sadoon_albader[mWill report back if anything happens05:33
programmerjakethanks for working on that!05:38
sadoon_albader[mno problem :)05:41
lkclsadoon_albader[m, star09:50
sadoon_albader[mAs in the celestial explosions?09:53
lkclyes. big thing that constantly goes bang.09:53
sadoon_albader[mAh I guess urban dictionary was the wrong place09:54
sadoon_albader[mThank you :)09:54
lkclsame thing09:54
sadoon_albader[mI just looked for "star"09:55
lkclurr just adding a batch of AsyncFIFOs to the DRAM controller14:55
lkclshould allow the GRAM DDR3 controller to run at say 100 mhz14:56
lkclwhilst CPUs can run at anything-they-like.14:56
tplatenI'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
lkcltplaten, correct. there isn't an actual UART on the USB pins16:24
lkclyou have to wire up an external USB-UART onto the pins shown in the orangecrab-0.2.lpf (constraints) file16:24
tplatenI did wire an external uart and still don't get any output16:25
lkcl1 sec16:25
lkclto which pins?16:25
lkclactually there's nothing in that constraints file which says uart_tx and uart_rx verilog signals should be connected to anything!!16:26
lkclwhich explains why you get nothing :)16:26
lkclwhich pins did you wire up the external uart to?16:26
lkcle.g. if you look at this
lkclyou see how that defines what uart0_txd / uart0_rxd must be connected to?16:27
lkclP3 and P4 respectively16:27
lkclyou must do exactly the same thing16:27
lkclfind out the ECP5 BGA IOpad name from the orangecrab schematics16:27
tplatenI connected OC IO 0 (OC TX) to UART RX, UART TX is unconnected, as described in
tplatenI had a look at constraints/orange-crab-0.2.lpf there is LOCATE COMP "pin_gpio_0" SITE "N17"; // tx17:04
lkcltplaten fantastic18:11
lkclprogrammerjake, can you mention the "proper" fix, give full context (post the contents of the email i sent you)?18:23
lkclotherwise people will flounder around here and it won't get properly fixed18:23
lkclthe proper fix is in the synth_xilinx arithmetic techmap to split at batches of 26 of CARRY4s18:24
lkclthe reason is that the "tiles" are subdivided by big routing trunks (acomodi explained all this to me a few weeks back)18:25
lkclthere's only room to put about 23-26 CARRY4s together in a chain before you have to "cross over" one of those routing trunks18:25
lkclto do that you have to put the carry-out from one of the CARRY4s into a Signal18:26
lkcllet that "cross over"18:26
lkcland accept it as Carry-in on another batch-of-CARRY4s-in-another-tile18:26
tplatenNow, I'll test merge-3d-game18:27
lkclneither VPR nor nextpnr-xilinx can cope, therefore the "best" place to "fix" this is in the yosys techmap18:27
lkclotherwise, VPR has to put in a workaround18:40
lkcloh and then nextpnr-xilinx has to put in a workaround18:40
programmerjakeimho 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
lkclok, it's complicated20:48
lkclthe yosys synth_xilinx alu techmap just creates a bunch of chained CARRY4 blocks together.  nothing fancy, nothing clever about it, at all.20:48
lkclsymbiflow 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 algorithm20:49
lkclit'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
lkclwhat it does is: *after* you have run yosys and done some ABC9 parsing, the file is exported to JSON20:50
lkcl... then imported by a special-hatchet-job-python-script...20:51
lkclwhich does AST-node-walking...20:51
lkclwhich then outputs the JSON file after all of the carry-propagation-chains have been done...20:51
lkclwhich yosys then picks up with "read_json"20:51
lkclnow, 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
programmerjakelike it should...20:53
lkclthat hack-job verilog-to-json-to-a-python-script-to-json-and-back-out-again is just such a waste20:53
lkclit should have been done in yosys techmaps, where *all* the different xilinx toolchains could benefit from it20:53
lkclnow nextpnr-xilinx has to implement that algorithm20:54
lkclas well20:54
lkclthis 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" algorithm20:54
lkcli forgot: we're *assuming* that xilinx proprietary tools do a decent job.20:55
lkclthey obviously fix the "breaking-down-into-blocks-of-23/26" problem20:56
lkclbut we have no idea if they perform a half-decent resource-utilisation job of using carry-propagation etc.20:56
programmerjakeimho 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 tho20:56
programmerjakewell...xilinx proprietary tools do at least a better job than vpr or nextpnr here...they work20:57
lkcli made an attempt to modify the botch-program (in python), it was so complex i couldn't do it.20:57
lkclbecause 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-specific20:58
lkclthat 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 blocks20:59
lkcla bit like trying to change a programmer's high-level language mistakes by botch-patching the binary.21:00
lkcland finding out that you've violated the function ABI in the process21:01
programmerjakevpr 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 fit21:02
lkclbtw 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 developers21:04
lkcl"is best fixed" is a neutral opinion21:04
programmerjakechanged in both the nextpnr and vpr comments21:06
programmerjakeadded the email contents and link to this conversation on irclog:
programmerjakelkcl, you'd be happy, Rust's project-portable-simd is likely to switch to naming stuff elementwise rather than lanewise:
programmerjakei remember you making a big deal about that...21:21
*** jn_ is now known as jn22:41

Generated by 2.17.1 by Marius Gedminas - find it at!