[Libre-silicon-devel] Status update

David Lanzendörfer david.lanzendoerfer at o2s.ch
Fri Jul 6 07:43:02 CEST 2018


Hi
> > b) I've now worked myself into the topic of creating a generic DRAM
> > controller out of lightdram, as Luke has suggested.
> > Turns out it's a bunch of Python scripts which produce a single mashed
> > together Verilog module. It's a total mess and ugly as hell.
> 
>  nice!
> 
> > I think I will just "translate" this Python code into Scala/Chisel so that
> > it can be used directly as an IP core in our SauMauPing framework.
> 
>  mmm... you could save a lot of time and effort and import it as an
> external verilog module.  one of the things that i do which annoys the
> crap out of people is jump from project to project, leveraging things
> from one project to augment another, saving vast amounts of time and
> completing work in a fraction of the time that *entire teams* of
> people previously tried to do.  it's not a popular skill 
> 
>  it does however mean not passing judgement.  python code is far
> easier to read and understand than any scala / chisel code i've ever
> seen.  chisel is nowhere near as popular as python, and never will be.
> but that in some ways is beside the point: the point is that the
> python code has been used to generate *silicon proven* layouts.
> 
>  unless you were prepared to write an auto-translator to translate
> python code into scala, it would be a huge amount of effort... to do
> what... *abandon* a silicon-proven design?? Does Not Compute 
> 
>  save some effort: use the auto-generated verilog as-is.  plus... see
> below: a hyperram interface that i've found is in verilog as well.
> 
>  btw if you're really concerned and want to test the openram
> auto-generated verilog, i've been working with cocotb successfully
> recently, and it means that you can write actual tests that..
> y'know... are actually readable?  and understandable?  and like... use
> standard python test frameworks?  and like... ordinary programmers can
> help with?

The thing with this auto generated code is that it meshes everything into one 
verilog module.
While Chisel produces nice hierarchical blocks, which makes it way easier to 
debug and understand.
Additionally it basically assumes that "you want" to do an SoC so it kindof 
doesn't allow for easy extraction of the IP core...
Additionally would we get stuck with an IP core with hard coded bus width and 
so on.
Parameters are much nice, wouldn't you say?

About the silicon verification: We have to do this anyway, because we develop 
a new process here. And a iVerilog test bench seems good enough for me to 
start with.

> > This will be especially relevant as soon as we switch over to the Yuen
> > Long
> > series which will be a full feature desktop CPU, which mins we will have
> > DIMM/ SODIMM slots soldered to a DDR3/DDR4 bus, connected to the CPU.
> 
>  honestly, for a first version, i feel either using SRAM (or multiple
> SRAM buses, they typically only run up to 133mhz), or better HyperRAM
> which is only 12 wires, would be quicker and easier.  HyperRAM is
> basically octal SPI.  taking any quad-SPI and turning it into octal
> SPI is... um... not hard (but see below: i did a quick google search
> and found one already)
> 
> that gets you 150mhz 8-bit data which is 150mbytes/sec for a budget of
> 12 wires.  want 300bytes/sec, put down 2x interfaces.  want
> 600mbytes/sec?  put down 4x interfaces.  that's only 48 wires.
> 5x12=60 wires and you have something equal to a DDR3 800mhz data
> rate.... *and it's entirely digital*.
> 
>  whereas DDR3... *deep breath*.... the PHYs are analog.  symbiotica
> eda quoted USD $300k and 8-12 *months* to do a DDR3 PHY layout.  as
> in, *just* the layout.
> 
>  later on you could do the DDR version of HyperRAM.  it requires 13
> wires (differential clock), dropping the voltage to 1.8v, and the data
> lines now need to be analog as you drive on the rising *and* falling
> edge.  i'm told by experienced people that DDR (rising and falling
> edge detection) is analog, and so should be avoided if at all
> possible, to drastically simplify design and chances of first success.
> 
>  60 wires to get a 750 mbyte/sec data transfer rate with 5 parallel
> 8-SPI buses and *no need to do analog* has got to be a lot better even
> than doing SRAM.  SRAM is like... ridiculous numbers of wires by
> comparison.  it's 133mhz but 133mhz @ 32 bit i think, but the address
> lines are totally separate from the data lines, whereas in 8-SPI the
> address and data encoding are a standard protocol, documented in the
> HyperRAM spec.
> 
>  also, using hyperram, the guy behind blackmesalabs did a small PCB
> (libre licensed, CERN) so you could use one of the cypress
> off-the-shelf HyperRAM ICs as a first test chip, and have a second
> independent parallel project drop-in replacement, later.
> 
>  l.
> 
>  p.s.  https://github.com/blackmesalabs/hyperram looks like it won't
> be needed to be implemented, you could just use that.
The first revision ever will be CMOS-only, we won't have SRAM cells yet most 
likely by December.
So everything more complicated than a NOR-gate needs to be wired onto the dev 
board externally.
That includes SRAM and Flash.
I guess we will just check for the least expensive components, with a 
standardized interface, on TaoBao and will use these for a demo board.

Cheers
	David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://list.libresilicon.com/pipermail/libre-silicon-devel/attachments/20180706/8cc65cdb/attachment.sig>


More information about the Libre-silicon-devel mailing list