Memory symbols require extensive rework about kicad-symbols

[evanshultz]

1. KLC allows + in a symbol name (see http://kicad-pcb.org/libraries/klc/G1.1/) but I think it's clear enough to not require any changes. Considering all the other abstracting we do, adding the plus doesn't make it any more easier for user to find the symbol they want.
2. Page 21 of https://www.xilinx.com/support/documentation/data_sheets/ds026.pdf shows that the C suffix means temp range which we remove or wildcard so I would leave it alone.

[bobc]

I will work on this, seems like a good candidate for symgen.

Memory_EEPROM has some MC68HC11 parts which should go into a separate library, eg. MCU_NXP_MC68

[bobc]

Can we adopt a standard convention for memory sizes? Standalone memory is usually quoted in bits, sometimes as X x Y e.g. 128k x 8. However, MCU memory is usually quoted in bytes. Additionally, we have a good mix of kb, kB, KB, and also ko (kilo octets). All this makes it pretty ambiguous when looking at a description "128kB".

In some cases, we might also need to distinguish between decimal kilo (k=1000) and binary "k" (1024). Clock speeds and data rates are always quoted with decimal prefix, so 1 kHz means 1000 Hz.

Fortunately there is a standard, we don't need to invent our own! Namely ISO/IEC IEC 80000-13:2008, described at https://en.wikipedia.org/wiki/Binary_prefix#kibi.

The prefix "k" is strictly reserved for decimal kilo (1000). For binary usages, the prefixes Ki, Mi, etc are used. Additionally, "B" is strictly reserved to mean "byte" (8 bits), and "bit" is used for bits.

Therefore:
128 kB means 128,000 bytes
128 KiB means 131,072 bytes
128 Kibit means 131,072 bits

The standard is simple to adopt and completely non-ambiguous.

[poeschlr]

The 1024 byte is not defined as k (kilo) but as Ki (kibi). And yes JDEC still uses uppercase K for 1024.
https://en.wikipedia.org/wiki/Kibibyte

[bobc]

The 1024 byte is not defined as k (kilo) but as Ki (kibi).

Yes, you understand correctly. :)

JDEC still uses uppercase K for 1024.

Perhaps, but

`The specification cites three prefixes as follows:

kilo (K): A multiplier equal to 1024 (210).
mega (M): A multiplier equal to 1,048,576 (220 or K2, where K = 1024).
giga (G): A multiplier equal to 1,073,741,824 (230 or K3, where K = 1024).

The specification notes that these prefixes are included in the document only to reflect common usage. It refers to the IEEE/ASTM SI 10-1997 standard as stating, that "this practice frequently leads to confusion and is deprecated".` https://en.wikipedia.org/wiki/JEDEC_memory_standards

So actually JEDEC recommend NOT to use K = 1024.

[bobc]

I have reviewed Memory_RAM, most of the parts are obsolete. I count about 8 parts that are still active.
I can't tell when parts were made obsolete, that information does not seem to be available since they went EOL too long ago.

I propose that all the obsolete parts be moved to obsolete folder, and we can fix up the remaining active ones. We can resurrect parts case by case if a need arises.

The following list includes aliases under the base part number.

COMP 2130 U               1kx8 dual port ram obsolete

COMP 4C1024 U             1Mx1 DRAM obsolete

COMP 4C4001 U             1Mx4 DRAM obsolete

COMP 628128 U             128kx8  active?

COMP AS6C1616 U           active

COMP CY7C185 U            obsolete?
COMP CY7C194 U            obsolete
COMP CY7C199 U            active   sram

COMP CY7C261 U            obsolete eeprom
COMP CY7C263 U            obsolete? eeprom
COMP CY7C271 U            obsolete? eeprom
COMP CY7C420 U            obsolete? fifo mem

COMP DRAM_1MX16_SOJ U     active? ISSI

COMP HM53461 U            obsolete

COMP HM62256BLFP-7T U     obsolete?
COMP HM62256BLP-7 U       obsolete?
COMP HM62256BLSP-7 U      obsolete?
COMP HM62256BLT-7SL U     obsolete?
COMP HM62256BLTM-8 U      obsolete?

COMP HM628512BFP-7 U      obsolete

COMP IDT7027_TQ100 U      active?
COMP IDT7132 U            active
COMP IDT71V65903S U       active?
COMP IDT7201 U            active

COMP MK4501 U             obsolete fifo
COMP MK4511 U             obsolete

COMP MS628128 U           obsolete

COMP MT48LC16M4A2TG U     obsolete
COMP MT48LC4M16A2TG U     obsolete
COMP MT48LC8M8A2TG U      obsolete

COMP RAM_32KO U           ?
COMP SRAM_512Ko U         ?

COMP TC524256Z U          obsolete
COMP UPD42280V U          obsolete

[poeschlr]

I agree with you about these obsolete parts. (My suggestion with the waiting list does not apply to parts that have long been made obsolete.)

[bobc]

Ok, I will submit a PR to do that.

There are also 3 generic parts without datasheets, I don't know if there are active parts that match them. I propose to obsolete those as well:

DRAM_1MX16_SOJ
RAM_32KO
SRAM_512Ko

[jkriege2]

I would remove them ... because the other option that would make sense to me is we would have to research, find some datasheet that matches and rename them ... In the current form I don't see that they have any value to anybody?

[poeschlr]

I would remove them as well. There is simply no purpose in generic symbols for such specialized parts.

[bobc]

I've submitted PR #286 to move obsolete RAM parts to obsolete folder.

[jkriege2]

#286 has been merged!

[antoniovazquezblanco]

Updated initial comment to keep track of the progress

[antoniovazquezblanco]

1. Memory_UniqueID only lists two components: DS2401P and DS2401Z. Both seem obsolete in that configuration and have been replaced with a DS2401P+ and DS2401Z+ variant that is lead free. Should we rename them or leave them be as they are?

[antoniovazquezblanco]

2. Memory ROM has XC18V01SO20 which is obsolete in one of its variants. Should we rename the component to be XC18V01SO20C which is not obsolete?

[antoniovazquezblanco]

Marked Memory_UniqueID and Memory_ROM as finished then.

[antoniovazquezblanco]

3. Memory_NVRAM. Could not find anything relevant about MB81461ZIP. Should we delete?

[evanshultz]

3. It was easy to find https://retrocdn.net/images/7/78/MB81461_datasheet.pdf (from https://segaretro.org/File:MB81461_datasheet.pdf), but I couldn't find an official datasheet and I'm pretty sure this is a very obsolete part.

Should our default behavior be delete or move to the obsolete folder? Since the obsolete folder isn't in the sym-lib-table it shouldn't affect users but allows us to keep old symbols. I'm not sure there's real value in keeping them, but I don't see a particular downside either. I suppose old KiCad schematics might be easier to sort out if the original symbols used were still in the obsolete folder of our repo instead of only in Git's history?

[antoniovazquezblanco]

You are right. Moving to obsoletes is better. Done in the PR above.

[antoniovazquezblanco]

4. Memory Controller lib only contains the CH376 device. The original datasheet is only available in Chinese at http://wch.cn/downloads/CH376DS1_PDF.html the unofficial translation has been moved and the URL needs to be changed. The chip is quite peculiar to my eyes because it is able to perform USB communication and SD management but it is expected to be coordinated by a small MCU. I don't know how common this is or whether it has been correctly classified. Should I update the datasheet URL with the chinese version (no EN version available)? Should this chip be here or in some Interface* lib?

[evanshultz]

At #814 Rene agreed to use the unofficial datasheet that covered the MPN added to the library when the official English ones didn't have that exact MPN. Our discussion was that since English is the language of the KiCad library we should include an English datasheet. That PR was for a chip from the same company.

Yeah, I agree with you. This is an IC that allows a generic parallel or serial interface to communicate through USB or an SD card. It really is just an interface/expander IC and I'd say moving it to Interface.lib is the best place since it has a host of interfaces and would be cumbersome to specifically classify. I don't find it at any of the regular IC vendors so we can't look to them to see how they classified it.

[antoniovazquezblanco]

PR created

[antoniovazquezblanco]

Marked Memory_EEPROM and Memory_EPROM as done. Seems that bobc has already done that.

Thanks!

[evanshultz]

I see that Memory_RAM is not checked off at #520 but it is above. Does that mean all problems brought up for this lib in the other issue are resolved and this lib can be checked off over there?

[antoniovazquezblanco]

I the list above I was only checking for obsolete parts. For the parts that remain in the library further checking is needed. I was trying to make progress in baby steps in my free time.