Bug 389 - Review all diagrams on wiki for translation into SVG
Summary: Review all diagrams on wiki for translation into SVG
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Documentation (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks:
 
Reported: 2020-06-16 22:19 BST by Cole Poirier
Modified: 2021-06-06 17:31 BST (History)
3 users (show)

See Also:
NLnet milestone: NLNet.2019.10.Wishbone
total budget (EUR) for completion of task and all subtasks: 150
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation: 384
child tasks for budget allocation: 401 442 651
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cole Poirier 2020-06-16 22:19:52 BST
I will be reviewing every diagram on the wiki and passing the simplest and most legible ones to Elle for translation into SVG. I will need to discuss and clarify more than half of them with Luke as the more complex hand-drawn diagrams are sometimes not legible in terms of the labeling, and other times clarification is needed for wire and gate paths. It's important to get these right as they will be reference material so I will be doing batches of 5, giving my annotations and questions and asking Luke to review these. The pace will have to be reviewed as we progress in this long/medium-term process.

* bug #401 - Convert Memory Architecture diagram from hand-drawn to editable SVG
* bug #442 - Convert comp_unit_req_rel diagram to SVG
* Convert compunit_multi_rw to SVG- https://libre-soc.org/3d_gpu/compunit_multi_rw.jpg
* dependence_cell_multi_pending - https://libre-soc.org/3d_gpu/dependence_cell_multi_pending.jpg
* dependency_matrices_mem - https://libre-soc.org/3d_gpu/dependency_matrices_mem.png
* l0_to_l1_n_way_cache_buffer - https://libre-soc.org/3d_gpu/l0_to_l1_n_way_cache_buffer.png
* Decide between the two ld_st_comp_unit diagrams - https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg https://libre-soc.org/3d_gpu/ld_st_comp_unit.png
* ld_st_dep_matrix - https://libre-soc.org/3d_gpu/ld_st_dep_matrix.png
* ld_st_splitter - https://libre-soc.org/3d_gpu/ld_st_splitter.png
* mem_l0_to_l1_bridge - https://libre-soc.org/3d_gpu/mem_l0_to_l1_bridge.png
* mem_l0_to_l1_bridge_v2 - https://libre-soc.org/3d_gpu/mem_l0_to_l1_bridge_v2.png
* multi_bus_arbiter - https://libre-soc.org/3d_gpu/multi_bus_arbiter.png
* padd9_alu1 - https://libre-soc.org/simple_v_extension/padd9_alu1.png
* padd9_alu4 - https://libre-soc.org/simple_v_extension/padd9_alu4.png
* padd9_fifo - https://libre-soc.org/simple_v_extension/padd9_fifo.png
* padd9_simd - https://libre-soc.org/simple_v_extension/padd9_simd.png
* regfile_hilo_32_odd_even - https://libre-soc.org/3d_gpu/regfile_hilo_32_odd_even.png
* reg_gpio_comparator - https://libre-soc.org/pinmux/reg_gpio_comparator.jpg
* reg_gpio_fn_ctrl2 - https://libre-soc.org/pinmux/reg_gpio_fn_ctrl2.jpg
* reg_gpio_in_prioritymux - https://libre-soc.org/pinmux/reg_gpio_in_prioritymux.jpg
* reg_gpio_in_wiring - https://libre-soc.org/pinmux/reg_gpio_in_wiring.jpg
* reg_gpio_out_wiring - https://libre-soc.org/pinmux/reg_gpio_out_wiring.jpg
* reg_gpio_pinblock - https://libre-soc.org/pinmux/reg_gpio_pinblock.jpg
* reorder_alias_bytemask_scheme - https://libre-soc.org/3d_gpu/reorder_alias_bytemask_scheme.jpg
* rob_bytemask https://libre-soc.org/3d_gpu/rob_bytemask.jpg
* rob_nocam_reglanes - https://libre-soc.org/3d_gpu/rob_nocam_reglanes.jpg
* shakti_libre_riscv https://libre-soc.org/shakti/shakti_libre_riscv.jpg
* simple_floorplan - https://libre-soc.org/3d_gpu/layouts/simple_floorplan.png
* st_comp_unit - https://libre-soc.org/3d_gpu/st_comp_unit.jpg
Comment 1 Luke Kenneth Casson Leighton 2020-06-17 17:26:26 BST
cole this is a simple one to start with:

https://libre-soc.org/3d_gpu/comp_unit_req_rel.jpg

the purple additions is an "AND" gate, which has straight sides, straight
input base, and a semi-circular output.

not to be confused with an "OR" gate, which has curved (arc) sides, and
a concave arc on the input.

the idea also is to provide a series of "library" SVGs, containing
the basic "gates" - AND, OR, NAND, NOR, XOR - actually you might find
these online already... oh look what a huge surprise:

https://commons.wikimedia.org/wiki/Logic_gates_unified_symbols

so simply use those: literally cut/paste and, Elle, feel free to splurge
out on as much psychedelic use of bright primary colour as you dare, but
keep it *consistent*.  i.e. use the colour of the wires to actually _mean_
something.  make the group of wires going through "opcode" fluorescent
pink, make the little boxes with the arrow inside them (known as "latches")
deep purple, and so on.  don't change the colour of the wires half way along
their length.

the idea here is to make people's left and right brain hemispheres engage
without necessarily burning out their eyes.

where SVG images do not exist on wikimedia (such as the latch, and that
upside-down truncated pyramid called "computation") first make those,
separately, add them to a library (Cole will help create the wiki page)
and *then* cut/paste them into the diagram.
Comment 2 Cole Poirier 2020-06-17 21:24:31 BST
Perfect, thank you. Given that this is diagram is not hand-drawn, are the only improvements to be had from slightly thickening the lines and colour coding the wires? Should the gates be hollow/outline or filled/solid-colour?
Comment 3 Luke Kenneth Casson Leighton 2020-06-17 23:15:01 BST
(In reply to Cole Poirier from comment #2)
> Perfect, thank you. Given that this is diagram is not hand-drawn, are the
> only improvements to be had from slightly thickening the lines and colour
> coding the wires?

i think really it needs redoing.  the reason for SVG is so that there are no bitmaps which cannot be edited.

the main thing is, moving and adjusting bitmaps is awful.

those images are bitmap based.  moving things around i literally had to cut out a block, put it in, and then fuzz over the edges.  this clearly wastes time and looks a mess.  and is unclear.

> Should the gates be hollow/outline or filled/solid-colour?

hollow seems to be standard.  just use the wikimedia SVGs, scale them as necessary (but keep size consistent throughout)   in some diagrams the outline of the gate is coloured, matching the wires that go in and out, and it is really clear and easy to track "read dependencies" for example because everything associated with that is in green.
Comment 4 Jacob Lifshay 2020-06-18 20:17:23 BST
flip-flop and latch symbols:
https://commons.wikimedia.org/wiki/File:D-Type_Flip-flop.svg

You also might find some useful logic symbols in Dia's built-in library
https://wiki.gnome.org/Apps/Dia
Comment 5 Cole Poirier 2020-06-19 23:56:41 BST
(In reply to Luke Kenneth Casson Leighton from comment #3)

> i think really it needs redoing.  the reason for SVG is so that there are no
> bitmaps which cannot be edited.
> 
> the main thing is, moving and adjusting bitmaps is awful.
> 
> those images are bitmap based.  moving things around i literally had to cut
> out a block, put it in, and then fuzz over the edges.  this clearly wastes
> time and looks a mess.  and is unclear.

Ok that makes a lot of sense, I agree the bitmaps are ugly and waste time, will get the ball rolling on this with Elle tomorrow.
 
> hollow seems to be standard.  just use the wikimedia SVGs, scale them as
> necessary (but keep size consistent throughout)   in some diagrams the
> outline of the gate is coloured, matching the wires that go in and out, and
> it is really clear and easy to track "read dependencies" for example because
> everything associated with that is in green.

Thanks for this clarification and the 'standard' svg wire diagram symbols links!
Comment 6 Cole Poirier 2020-09-15 23:32:39 BST
Add 150 EUR to "total budget (EUR) for completion of task and all subtasks" in order to pay for bug #401
Comment 7 vklr@vkten.in 2021-06-06 17:31:04 BST
Sub Task:

Bug 651 - Convert bitmap images to vector svg - multi i/o dep cell and multi func unit