[Libre-soc-dev] Introduction to Libre-SOC

[Richard Wilbur]

On Feb 7, 2021, at 10:45 AM, Jacob Lifshay <programmerjake at gmail.com> wrote:
> 
> On Sun, Feb 7, 2021, 09:23 Richard Wilbur <richard.wilbur at gmail.com <mailto:richard.wilbur at gmail.com>> wrote:


> ooh! I started on QuickBasic, it came by default with win98.

Cool!  My opinion of M$ just went up a bit (it started out pretty low, so no danger of it reaching actual favorability;>).  It is a great thing to have a programming language that comes with the operating system (it encourages the creative soul to learn how to use programming to solve problems)!

> I just finished writing a highly-parallel thread-safe hash table in Rust
> for use with the HashLife algorithm:
> https://github.com/programmerjake/parallel-hashlife-4/blob/master/src/hash_table.rs <https://github.com/programmerjake/parallel-hashlife-4/blob/master/src/hash_table.rs>

I’ll have to have a look.  Sounds intriguing.  Thanks for the link.  (I might learn a smidgen of Rust in the process. ;>)

>> The course and textbook[2] were geared
>> towards the MOSIS program from USC[3] and targeting Orbit Semiconductor’s
>> 2.0µm double-poly, double-metal, n-well process (CN20).  Interestingly,
>> Appendix A of the textbook gives process specifications, electrical and
>> SPICE parameters, and design rules for the CN20 process.  No
>> NDA’s—published in a textbook.
> 
> neat!

Do we have access to the “process specifications, electrical and SPICE parameters, and design rules” for our target process (whatever that is)?  If so, we can run simulations of our design(s) and see how our power distribution network works, small-signal, high-frequency cross-talk between traces, etc.  This can be very helpful in identifying issues before getting our first silicon.


> I once wrote a preemptive kernel in 2-3k of x86 assembly ... windows' dos
> emulator didn't like it.

Sounds cool.  What occasioned a new kernel?  Did you base it on an existing architecture or roll a new one?  Microkernel?

>  I liked the fact that there was basically one hardware address for the
>> operating system and that services were negotiated over message ports.  I
>> also liked the hardware multi-tasking with an intelligent bus
>> arbitration/sharing scheme featuring the 68000 main processor, two smaller
>> special-purpose processors, and multiple DMA engines.  They got an amazing
>> amount of stuff scheduled into that 0-wait state, 8MHz bus.
>> 
> 
> the days when memory was about as fast as the cpu...

I have thought of working out a processor whose instruction dispatch clock matched the memory bus.  For one thing the processor would undoubtably use a lot less power.  (Vastly lower clock frequency if e.g. f'~f/10, with power having a quadratic term in frequency, this drops power by a factor of 100, P’~P/100.)  Also, hitting main memory would not be nearly as costly in processor cycles (especially if we could implement it with 0 wait states).

With the radically lower clock frequency we would have the time in the processor clock period to use several phases of the clock to implement even more instructions so that they complete in one clock.  (Towards the RISC holy grail!)  The trick would be to fill the most bus clocks with active cycles in order to avoid contention.  This reduction in clock frequency would significantly reduce the high-frequency signal integrity issues involved with the interconnect buses.  It has a major dependence on characterization of the bus access behavioral models of the things that have to live on the bus.  (This depends on the ISA and internal implementation specifics of each of the denizens of that bus.)

If the processor were superscalar, it would be useful if the memory bus accommodated the width of several instructions.

Anyway, it is a question of shall we make the greatest basket ever and put all our eggs in that basket, or shall we make more than one basket of different types and spread our eggs over them.  The important difference is how easy is it to make the great basket versus several different types, how efficient, how costly, how well can we reach our goals?

Richard