| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 01:36 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has quit IRC | 04:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.176> has joined #libre-soc | 04:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.176> has quit IRC | 05:03 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has joined #libre-soc | 05:03 | |
| lkcl | markos_, the way that openocd works is that it's not actually the binary that's important (most of the time) but the .cfg scripts. it is almost 100% the case that you *never* need to actually recompile *any* version of openocd... simply use "the right .cfg scripts" | 07:51 |
|---|---|---|
| lkcl | as usual though with any popular FOSS project using github the coordination is as good as that of marlin 3D printing firmware and of the arduino software | 07:52 |
| lkcl | i.e. an absolute god-awful mess as people fork it, make modifications, and don't coordinate them back, and even if they do the maintainers aren't being paid | 07:53 |
| markos_ | lkcl, it's not github's fault, it was like that with many foss projects even before github | 07:59 |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 08:06 | |
| markos_ | anyway, at least it was a good start, communication with the board was established along with a way to upload bitstreams | 08:16 |
| openpowerbot | [irc] <programmerjake> fyi the internet may be down for me (including the CI server) later today, they're installing the cables into the walls. i should still be able to get email and irc/matrix through my cell phone | 09:02 |
| openpowerbot | [irc] <programmerjake> maybe tomorrow too | 09:02 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has quit IRC | 11:05 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.79> has joined #libre-soc | 11:05 | |
| markos_ | lkcl, I saw something on litex site and was curious, there is a screenshot of a litex soc where the cpu emulated was 1Mhz only, but it was able to use onboard DDR (on the fpga board I mean), I remember you saying that we can't use it on our systems because of lower than 100Mhz frequency, at the risk of sounding naive, maybe there is a trick we could use ourselves? | 11:27 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.79> has quit IRC | 11:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.79> has joined #libre-soc | 11:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.79> has quit IRC | 12:18 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.40.100> has joined #libre-soc | 12:19 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.40.100> has quit IRC | 12:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.49> has joined #libre-soc | 12:30 | |
| *** octavius <octavius!~octavius@92.40.168.144.threembb.co.uk> has joined #libre-soc | 12:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.49> has quit IRC | 14:03 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 16:40 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 17:59 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 18:00 | |
| *** choozy_ <choozy_!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 18:09 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 18:09 | |
| *** choozy_ <choozy_!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 18:29 | |
| lkcl | markos_, ok what you can do - and this is awful - is that you have a "manual" clock-divider or you set up the PLL so that yes it is 100 mhz... | 18:46 |
| lkcl | ... but the "CPU" clock is actually 100 mhz divided by say... 100 | 18:46 |
| lkcl | so the PLL is set up as follows: | 18:47 |
| lkcl | * main system clock is running at actually 200 mhz | 18:47 |
| lkcl | (that's the main PLL) | 18:47 |
| lkcl | * that feeds into a 2:1 divider to create a **stable** 50-50 duty cycle 100 mhz clock | 18:47 |
| lkcl | (it is pretty normal for PLLs to be so "off" that they actually create like a 40-60 duty cycle, but that each rising edge is stable... problem is "solved" by adding in a DFF that flips regularly at 1/2 the speed of the incoming clock...) | 18:49 |
| lkcl | * the same 200 mhz clock **ALSO** feeds into a 200:1 divider, producing a 50-50 duty cycle 1 mhz clock | 18:50 |
| lkcl | now, here's the thing (here's the trick): | 18:50 |
| openpowerbot | [irc] <programmerjake> if you have only all negative or all positive edge triggered flip-flops i don't see how 50-50 duty cycle is necessary | 18:50 |
| lkcl | because you *KNOW* that the 1 mhz clock will "rise and fall" exactly and routinely like clockwork (ha ha) in "sync" with the 100 mhz clock, you can cheat | 18:51 |
| lkcl | programmerjake: you get variance in timings on the propagation of combinatorial blocks | 18:52 |
| lkcl | and in some cases the impedance of those combinatorial blocks, especially through long routing, may not be as straightforward as it appears | 18:53 |
| lkcl | especially on FPGA bitstreams that start to use more of the FPGA resources than really should be. | 18:54 |
| lkcl | the typical budget you are *supposed* to use is only 10-15% of the FPGA. | 18:54 |
| openpowerbot | [irc] <programmerjake> but if those combinatorial blocks are only between d/q on flip flops and the 60-40 clock is only on clock inputs, the timing of the active clock edge is exactly the same as a 50-50 clock so that shouldn't matter | 18:55 |
| lkcl | which would in our case mean buying everyone $1,000 to $2,500 FPGAs with well over 500k LUTs | 18:55 |
| openpowerbot | [irc] <programmerjake> in the case of ddr it does matter cuz it's clocking off both edges | 18:57 |
| openpowerbot | [irc] <programmerjake> but for general traditional synchronous logic it shouldn't matter | 18:57 |
| markos_ | lkcl, that can't be right, I understand not using 100% and always leaving a percentage unused, but actually using only 10-15%? that's a huge waste | 18:58 |
| markos_ | pretty sure the company I was working for and using fpgas for video encoders used every last gate there -cost reasons- before upgrading to the next model | 18:58 |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 19:17 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 19:34 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 19:37 | |
| *** octavius <octavius!~octavius@92.40.168.144.threembb.co.uk> has quit IRC | 19:45 | |
| lkcl | markos_, it's down to the fact that 95% of an FPGA is routing crossbars | 20:01 |
| lkcl | all of which is combinatorial. FPGAs are INCREDIBLY complex in terms of both routing and resource management. | 20:02 |
| lkcl | they're subdivided down into grid arrays with massive "routing bus highways" between them | 20:03 |
| lkcl | the lead professor behind OpenFPGA spent *two hours* explaining to me how with *many years* of research he could only hope to get to within 50% of the efficiency of the proprietary routing infrastructure of Xilinx FPGAs | 20:04 |
| lkcl | it's *that* complex | 20:04 |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 20:04 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 20:04 | |
| lkcl | so there is actually very limited routing (at 95% of the ASIC!!!!) and consequently if you allocate two LUTs that are *right next to each other*, there is *NO GUARANTEE* that there is crossbar-routing/switching available to you to connect them! | 20:05 |
| lkcl | because? | 20:05 |
| lkcl | ... some *other* signals which happen to be connecting say a DFF on one side to a DSP block on the other happen to need to use the routing lanes that are between the two LUTs | 20:06 |
| lkcl | consequently to route a connection between two neighbouring LUTs, you might have to go *all the way round*... | 20:07 |
| lkcl | which of course obliterates your timing constraints, because you had to go through say 100 crossbars, each with (say) 1 ns delay... and you're now down to 10 mhz *just from routing* | 20:09 |
| lkcl | if you ooonly had designed your HDL to use 10-15% of the FPGA, you could have connected all your LUTs directly and locally, and made 200 mhz sooo easily... | 20:10 |
| *** openpowerbot <openpowerbot!~openpower@94-226-187-44.access.telenet.be> has quit IRC | 20:28 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 20:38 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 20:38 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc | 20:41 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has joined #libre-soc | 21:41 | |
| ghostmansd | Hi folks, I've raised an issue on aliases so it won't get lost: https://bugs.libre-soc.org/show_bug.cgi?id=1140 | 21:42 |
| ghostmansd | lkcl, to free you from these annoying URLs: what'd be the right way to link to tasks? I chose to fill URL in a new task, but, based on your edits, I assume that's not sufficient... | 21:52 |
| ghostmansd | Could you, please, provide a guideline? | 21:52 |
| ghostmansd | (taking 1140 and 1068 as examples) | 21:52 |
| ghostmansd | As for 995, I'm confused by discussion we had before. Is this task needed to be done? | 21:54 |
| ghostmansd | If so, what'd be the right budget for it? It never got assigned a milestone. | 21:54 |
| ghostmansd | It'd be great if we had some binutils-related tasks which can be handled quickly. I have less time since recent... | 21:54 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-90-154-80-239.ip.moscow.rt.ru> has joined #libre-soc | 22:08 | |
| lkcl | ghostmansd, andrey is supposed to be writing up the guide. | 23:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!