On Tue, Jun 26, 2018 at 7:46 AM, Hagen SANKOWSKI hsank@posteo.de wrote:
Good Morning.
morning, hagen.
On 06/26/2018 07:56 AM, Luke Kenneth Casson Leighton wrote:
Well, it is my part to design the Standard Cell Library for our LibreSilicon technology, as soon as I get the test wafer structures in Silicon. I already designed cells years ago.
excellent.
Luke, please provide me the cells you would like to get - I'll do what is possible.
that's great to hear. the strategy i was advised of by people on the librecores list summarised ass: keep the IO cell absolutely standard (which basically means an analog design), and keep the muxing separate (and entirely digital).
attached is an example diagram. there's only one thing missing from it and that's the current control selection. apart from that it's identical to (based on) the elinux.org ericsson IO cell diagram (link sent already, previous message).
here is a list of requirements:
* pull-up control which switches in a 10k (50k?) resistor
* pull-down control which switches in a 10k (50k?) resistor
* a "mode" setting that flips it between Open-Drain (floating if LO, and pulled to GND if HI) and CMOS (MOSFET) Push-Push modes. see https://en.wikipedia.org/wiki/Open_collector#MOSFET for details on Open Drain (requires a MOSFET).
* a "hysteresis" setting that controls the input schottky filter's sensitivity. this is important for push-buttons for example, to stop spiking (bounce) that would be amplified and result in massive noise spikes onto all wires throughout that entire area of the chip. low middle and high settings are needed to cover filtering ranges of say 2mhz, 5mhz, 10mhz and unlimited (disabling hysteresis). looking at STM32F documentation helps here as does this https://electronics.stackexchange.com/questions/156930/stm32-understanding-g...
* an input-enable selector
* an output-enable selector
* also required is a means to change the current output: 10mA, 20mA, 30mA and 40mA are reasonable
* also the input and output really need *automatic* level-shifting, built-in to the IO cell. so whilst there is a VDD for driving the pad (and setting the CMOS threshold levels for input), there is *also* a need for an IO VREF. this is *important*. the input and output needs to be CMOS push-push (standard logic) whilst the IO pad needs to be switchable between OD and PP.
* input threshold voltages that trigger the input from HI to LO should be standard CMOS voltage levels (even in OD mode), which i believe is below 0.3 * VDD for "LO" and 0.7 * VDD for "HI"
* output voltage levels should be as close to 0 as possible for LO (0.3v or below @ nominal temperature) and as close to VDD as possible for HI (VDD-0.3v or above @ nominal temperature).
* some ability to protect itself from over-driving (current fights) when in output mode are a must.
* the ability to protect itself from *being* over-driven when in input mode is not strictly necessary (over-voltage tolerance e.g. 5V tolerance when VDD is well below that) but would be nice to have as an option (two variants: one for ECs which need 5V tolerance and one for SoCs where it's not).
BTW, we already talked same years back in Brussels at FOSDEM about your great EOMA86 idea. I really like it :-) Keep going!
thanks :)
So, do you like to provide us (or me?) a list of requirements / features your embedded SoC really needs, which are nice to have and which are to avoid?
documented here:
http://libre-riscv.org/shakti/m_class/
i need to update it as i've managed to track down an LPDDR3 PHY (USD $300k), and also HyperRAM (upcoming JEDEC xSPI).
Please dream, speculate, write down the list for the free and open silicon variant of your modules.
all documented on that page (see "Interfaces" sections), with full links to libre-licensed HDL that i've been able to find (which is most of them: eMMC is missing, and i'd like to do USB2 PHY rather than have three ULPI/UTMI interfaces).
the top-level bugtracker entry tracking them is here: http://bugs.libre-riscv.org/show_bug.cgi?id=2
And yes, I like to put in this card into my next "Brotkasten"-Style [0] laptop and developing the next generation even on this laptop.
cool :)
I think, with getting this numbered list, we can great cooperating, even for dedicated IO Cells, RAMs and so on. do not hesitate.
awesome.
the project that i'm working on needs a 512 mbyte DRAM, to be made in a minimum of 110nm (which is where you can get up to 400mhz double data-rate). twin 128 mbyte DRAMs would do fine, as probably would four 64 mbyte DRAMs (in a pinch).
i have been promised (free, monetarily-zero-charge) access to a university's 180nm foundry *IF* and *ONLY* if the entire design is libre. if you can design a DRAM that can be tested for tape-out on 180nm which has a HyperRAM interface i *might* be able to justify putting it to the sponsor.
could you give me some idea of the die area that a 512mb DRAM would take up, say, in 110nm? and is the size dependent on geometry at all? some cells are not (you can't shrink IO pads for example, no matter what geometry), but i don't know enough about DRAM design (other than, "it's a capacitor" and a transistor)
l.
