Monday, 2023-08-14

*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:36
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC04:58
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc04:58
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC05:03
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc05:03
lkclmarkos_, 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
lkclas 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 software07:52
lkcli.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 paid07:53
markos_lkcl, it's not github's fault, it was like that with many foss projects even before github07:59
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC08:06
markos_anyway, at least it was a good start, communication with the board was established along with a way to upload bitstreams08: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 phone09:02
openpowerbot[irc] <programmerjake> maybe tomorrow too09:02
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC11:05
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc11: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@> has quit IRC11:50
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc11:50
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC12:18
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc12:19
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC12:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc12:30
*** octavius <octavius!> has joined #libre-soc12:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:03
*** choozy <choozy!> has joined #libre-soc16:40
*** choozy <choozy!> has quit IRC17:59
*** choozy <choozy!> has joined #libre-soc18:00
*** choozy_ <choozy_!> has joined #libre-soc18:09
*** choozy <choozy!> has quit IRC18:09
*** choozy_ <choozy_!> has quit IRC18:29
lkclmarkos_, 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... 10018:46
lkclso the PLL is set up as follows:18:47
lkcl* main system clock is running at actually 200 mhz18: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 clock18: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 clock18:50
lkclnow, 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 necessary18:50
lkclbecause 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 cheat18:51
lkclprogrammerjake: you get variance in timings on the propagation of combinatorial blocks18:52
lkcland in some cases the impedance of those combinatorial blocks, especially through long routing, may not be as straightforward as it appears18:53
lkclespecially on FPGA bitstreams that start to use more of the FPGA resources than really should be.18:54
lkclthe 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 matter18:55
lkclwhich would in our case mean buying everyone $1,000 to $2,500 FPGAs with well over 500k LUTs18:55
openpowerbot[irc] <programmerjake> in the case of ddr it does matter cuz it's clocking off both edges18:57
openpowerbot[irc] <programmerjake> but for general traditional synchronous logic it shouldn't matter18: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 waste18: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 model18:58
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc19:17
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC19:34
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc19:37
*** octavius <octavius!> has quit IRC19:45
lkclmarkos_, it's down to the fact that 95% of an FPGA is routing crossbars20:01
lkclall of which is combinatorial.  FPGAs are INCREDIBLY complex in terms of both routing and resource management.20:02
lkclthey're subdivided down into grid arrays with massive "routing bus highways" between them20:03
lkclthe 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 FPGAs20:04
lkclit's *that* complex20:04
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC20:04
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:04
lkclso 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... 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 LUTs20:06
lkclconsequently to route a connection between two neighbouring LUTs, you might have to go *all the way round*...20:07
lkclwhich 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
lkclif 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!> has quit IRC20:28
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC20:38
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:38
*** openpowerbot <openpowerbot!> has joined #libre-soc20:41
*** ghostmansd <ghostmansd!> has joined #libre-soc21:41
ghostmansdHi folks, I've raised an issue on aliases so it won't get lost:
ghostmansdlkcl, 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
ghostmansdCould you, please, provide a guideline?21:52
ghostmansd(taking 1140 and 1068 as examples)21:52
ghostmansdAs for 995, I'm confused by discussion we had before. Is this task needed to be done?21:54
ghostmansdIf so, what'd be the right budget for it? It never got assigned a milestone.21:54
ghostmansdIt'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]!> has joined #libre-soc22:08
lkclghostmansd, andrey is supposed to be writing up the guide.23:59

Generated by 2.17.1 by Marius Gedminas - find it at!