Created attachment 66 [details] Hand-drawn diagram of 180nm Libre-SOC single core test ASIC's memory layout Luke, I think it would be highly advantageous if your hand-drawn diagram of Libre-SOC's memory architecture was clean and easily editable in software. I think this can be accomplished this week, optimistically aiming for thursday (NA west) so friday morning for you. I am creating this bug report specifically for this diagram so we can coordinate its design and accuracy here, as it appears to be a very critical part of the work you, Michael, Jacob, Yehowshua, Cesar, et al are doing right now. Please assign a budget to this task as well if you agree that this will aid your present engineering efforts.
agreed. however needs the MoU signed first before rfps can be submitted. budget *can* be assigned, would say EUR 150 be good?
(In reply to Luke Kenneth Casson Leighton from comment #1) > agreed. however needs the MoU signed first before rfps can be submitted. > budget *can* be assigned, would say EUR 150 be good? Ah, no problem, understood. EUR 150 seems like much too much for this single diagram. It took me about 2 hours, having never used inkscape before, to do what I will attach here. If you can please add the parts that are missing from the original hand-drawn diagram? I would have done them myself, however due to the resolution of the image it was very difficult to make out what I should draw. Attaching in svg so you can bring it to spec with the original drawing, and png so that I could put a white background on it.
Created attachment 67 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D1 SVG
Created attachment 68 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D1 PNG
(In reply to Cole Poirier from comment #2) > (In reply to Luke Kenneth Casson Leighton from comment #1) > > agreed. however needs the MoU signed first before rfps can be submitted. > > budget *can* be assigned, would say EUR 150 be good? > > Ah, no problem, understood. EUR 150 seems like much too much for this single > diagram. It took me about 2 hours, having never used inkscape before, to do > what I will attach here. except i know it is a detailed diagram and will take some time. > If you can please add the parts that are missing > from the original hand-drawn diagram? timeconsuming. and honestly i don't like using diagram editors. they annoy me. > I would have done them myself, however > due to the resolution of the image it was very difficult to make out what I > should draw. the names of the green bits are missing. these show where "boxes" should be created that then have arrows coming in and out. the 2x2 crossbars are also missing. the arrows are important as they show dataflow (data buses) without the dataflow the diagram is not useful as it is missing how to connect the HDL together.
(In reply to Luke Kenneth Casson Leighton from comment #5) > > except i know it is a detailed diagram and will take some time. Fair enough :) > > If you can please add the parts that are missing > > from the original hand-drawn diagram? > > timeconsuming. and honestly i don't like using diagram editors. they annoy > me. Hahaha oh boy yes! > > I would have done them myself, however > > due to the resolution of the image it was very difficult to make out what I > > should draw. > > the names of the green bits are missing. these show where "boxes" should be > created that then have arrows coming in and out. > > the 2x2 crossbars are also missing. > > the arrows are important as they show dataflow (data buses) > > without the dataflow the diagram is not useful as it is missing how to > connect the HDL together. I’m happy to do the rest of the diagram, however, I cannot so much more with the current image of the hand drawn diagram. I’ve thought of a few ways to resolve this but the only one I can think of that I’m satisfied will be efficient is to clarify the smaller less legible parts of the diagram with you on zoom tomorrow after we finish speaking with Dan. Or a zoom call another time if you have a prior commitment after our call with Dan tomorrow. Let me know :)
Created attachment 69 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D2 SVG
Created attachment 70 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D2 PNG
ok looks really good, the colour red/blue helps discern odd/even. the boxes right at the top need to be called LDSTCompUnit. the split arrow right at the top needs to go, put the single input in and another box all the way round including the addr[4]? and the crossbar, call that LDSTSplitter where PriorityPicker is, there should be two boxes named "DataMerger" *inside* which is a PriorityPicker (one each)
(In reply to Luke Kenneth Casson Leighton from comment #9) > ok looks really good, the colour red/blue helps discern odd/even. > > the boxes right at the top need to be called LDSTCompUnit. > > the split arrow right at the top needs to go, put the single input in and > another box all the way round including the addr[4]? and the crossbar, call > that LDSTSplitter > > where PriorityPicker is, there should be two boxes named "DataMerger" > *inside* which is a PriorityPicker (one each) Unfortunately I can't understand exactly what you want in writing but could clear all three points up in a minute or two on the phone. I have some other chip related stuff to talk to you and Dan about, so perhaps we can go over the diagram at the end of that call. Can we set up a 20 minute (hard-capped) chat with Dan tomorrow (Tuesday) or Wednesday?
Created attachment 73 [details] mark words and redraw needed 1). put "LDSTCompUnit" at top on each of FU0-7 2). put "PortInterface" at bottom on each of FU0-7 3). delete all bits crossed out in green. 4). make box around crossbar. 5). put "LDSTSplitter" at top of box (4) 6). put "PortInterface(Even)" at bottom of box (4) on left (red) output 7). put "PortInterface(Odd)" at bottom of box (4) on right (blue) output 8). put box round "PriorityPicker" 9). put "DataMerger" at top of box (8) 10). copy box (8) to Even side and call it "DataMerger1" (or DataMergerEven) 11). copy box (8) to Odd side and call it "DataMerger2" (or DataMergerOdd) 12) remove box (8)
(In reply to Cole Poirier from comment #10) > Unfortunately I can't understand exactly what you want in writing but could > clear all three points up in a minute or two on the phone. which unfortunately means that nobody else knows what happened. i did a quick markup of the diagram instead with clear steps.
(In reply to Luke Kenneth Casson Leighton from comment #11) > Created attachment 73 [details] > mark words and redraw needed > > 1). put "LDSTCompUnit" at top on each of FU0-7 > > 2). put "PortInterface" at bottom on each of FU0-7 > > 3). delete all bits crossed out in green. > > 4). make box around crossbar. > > 5). put "LDSTSplitter" at top of box (4) > > 6). put "PortInterface(Even)" at bottom of box (4) on left (red) output > > 7). put "PortInterface(Odd)" at bottom of box (4) on right (blue) output > > 8). put box round "PriorityPicker" > > 9). put "DataMerger" at top of box (8) > > 10). copy box (8) to Even side and call it "DataMerger1" (or DataMergerEven) > > 11). copy box (8) to Odd side and call it "DataMerger2" (or DataMergerOdd) > > 12) remove box (8) Thanks, will do this tomorrow. (In reply to Luke Kenneth Casson Leighton from comment #12) > (In reply to Cole Poirier from comment #10) > > > Unfortunately I can't understand exactly what you want in writing but could > > clear all three points up in a minute or two on the phone. > > which unfortunately means that nobody else knows what happened. > i did a quick markup of the diagram instead with clear steps. I appreciate it. I wasn't sure about how to go about this, so thank you for resolving this.
Hi Luke, here is the latest version with the corrections you drew on D3 implemented. Please let me know what needs to be done to complete this diagram.
Created attachment 75 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D4 SVG
Created attachment 76 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D4 PNG
(In reply to Cole Poirier from comment #16) > Created attachment 76 [details] > 180nm Libre-SOC single core test ASIC's memory layout diagram D4 PNG L1 Odd on right hand side. massive size of text is... unnerving, where other fonts are so much smaller.
(In reply to Luke Kenneth Casson Leighton from comment #17) > (In reply to Cole Poirier from comment #16) > > Created attachment 76 [details] > > 180nm Libre-SOC single core test ASIC's memory layout diagram D4 PNG > > L1 Odd on right hand side. > > massive size of text is... unnerving, where other fonts are so much smaller. Yes, sorry, I'm not at all capable in graphic design related things. If you tell me a better font, I'd much rather use that, as I did find it quite large and cumbersome while creating the diagram.
(In reply to Cole Poirier from comment #18) > Yes, sorry, I'm not at all capable in graphic design related things. If you > tell me a better font, I'd much rather use that, as I did find it quite > large and cumbersome while creating the diagram. sorry, the font itself is fine, the size is simply too large.
(In reply to Luke Kenneth Casson Leighton from comment #19) > (In reply to Cole Poirier from comment #18) > > > Yes, sorry, I'm not at all capable in graphic design related things. If you > > tell me a better font, I'd much rather use that, as I did find it quite > > large and cumbersome while creating the diagram. > > sorry, the font itself is fine, the size is simply too large. I fixed the even even, it's now even odd like it's supposed to be. I also scaled down the font size where it was previously gigantic. Is this diagram as of D5 now complete?
Created attachment 77 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D5 SVG
Created attachment 78 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram D5 PNG
(In reply to Cole Poirier from comment #22) > Created attachment 78 [details] > 180nm Libre-SOC single core test ASIC's memory layout diagram D5 PNG one last thing, addr[4]=1 in the "Odd" box then it looks good and can be pit in place. try the svg on the wiki, rather than the png version, see how that goes.
(In reply to Luke Kenneth Casson Leighton from comment #23) > (In reply to Cole Poirier from comment #22) > > Created attachment 78 [details] > > 180nm Libre-SOC single core test ASIC's memory layout diagram D5 PNG > > one last thing, addr[4]=1 in the "Odd" box then it looks good and can be pit > in place. try the svg on the wiki, rather than the png version, see how > that goes. Great, done. I'll give it a try.
Created attachment 85 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram F1 SVG
Created attachment 86 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram F1 PNG
Worked look great :) Closing.
(In reply to Cole Poirier from comment #27) > Worked look great :) Closing. remember to track this on your wiki page otherwise making the RFP gets difficult.
(In reply to Luke Kenneth Casson Leighton from comment #28) > (In reply to Cole Poirier from comment #27) > > Worked look great :) Closing. > > remember to track this on your wiki page otherwise making the RFP gets > difficult. Oh, ok. I thought this was the purpose of the buget allocation/tracking done here on bugzilla?
I saw the diagram this morning and I think it looks good. It is now much easier for me to understand the architecture of the memory subsystem.
(In reply to Cole Poirier from comment #29) > Oh, ok. I thought this was the purpose of the buget allocation/tracking done > here on bugzilla? once closed, where is the information about who did what? and: can you *find* the bugreport once it is closed?
(In reply to Luke Kenneth Casson Leighton from comment #31) > once closed, where is the information about who did what? > > and: can you *find* the bugreport once it is closed? I actually did just that to fill in the details on my wiki page but you're right that doing this after the fact is somewhat harder than doing it concurrently, and definitely poses the risk of tasks getting missed due to misremembering bug names etc. It adds a small amount of synchronization overhead, but I agree with you that it's better to do this concurrently on personal wikis so it's dead obvious what I'm working on/have finished from just visiting my wiki. Basically a quickly accessible summary.
The Diagram on the 3d_gpu/architecture/memory_and_cache page says the data that goes into the DataMerger is 16 bits wide. Thats wrong it should be 16 bytes wide, that is 128 bits wide.
(In reply to Tobias Platen from comment #33) > The Diagram on the 3d_gpu/architecture/memory_and_cache page says the data > that > goes into the DataMerger is 16 bits wide. Thats wrong it should be 16 bytes > wide, that is 128 bits wide. yep good catch: that should be Data[0:127]
(In reply to Luke Kenneth Casson Leighton from comment #34) > (In reply to Tobias Platen from comment #33) > > The Diagram on the 3d_gpu/architecture/memory_and_cache page says the data > > that > > goes into the DataMerger is 16 bits wide. Thats wrong it should be 16 bytes > > wide, that is 128 bits wide. > > yep good catch: that should be Data[0:127] Aha! Awesome! Thanks Tobias!!!
Created attachment 87 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram F2 SVG Fixed, Data[0:15] is Data[0:127] now.
Created attachment 88 [details] 180nm Libre-SOC single core test ASIC's memory layout diagram F2 PNG
Fixed. Closing, however, Tobias if you find any further mistakes please reopen this bug report.
Updating bugdet per https://bugs.libre-soc.org/show_bug.cgi?id=401#c1
fixing budget -- cole forgot to update the field: "budget (EUR) for this task, excluding subtasks' budget"
(In reply to Jacob Lifshay from comment #40) > fixing budget -- cole forgot to update the field: "budget (EUR) for this > task, excluding subtasks' budget" Ah! Thanks Jacob, now I know how to properly fill it in next time :)