[Libre-soc-dev] daily kan-ban update 30oct2020

Cesar Strauss cestrauss at gmail.com
Fri Oct 30 23:15:47 GMT 2020


Last month
==========

* Tested a bug fix in cxxsim. Input signals greater than 32 bits are now
working properly.

* Tracked down another cxxsim bug, and produced a reduced test case for it.

The issue, this time, is about not initializing signals declared with
"reset=1". So, for instance, the "shadown" inputs of computation units
are being kept active, at zero.

I will test the fix when it arrives.

https://bugs.libre-soc.org/show_bug.cgi?id=475#c20

* Helped Cole and Luke with a JTAG unit test issue.

https://bugs.libre-soc.org/show_bug.cgi?id=511#c12

* Created an OperandProducer class, for testing the Computation Units.

See:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/test/test_compalu_multi.py;h=b0211e0b47ef8706bb4e27164341144651e02a77;hb=HEAD#l34

Since it seems to be the first use of "yield Passive()" in libre-soc,
I'll make a comment on it.

What it does, is to automatically terminate the corresponding process
when all the other "normal" (active by default) processes terminate.

It is useful in this case because the process is basically an infinite
loop, monitoring and reacting to a signal in the DUT. In fact, it could
have easily been implemented in nMigen RTL.

So, "yield Passive()" is potentially useful when replacing a RTL module
with an equivalent Python process.

Next week
=========

* Apply the new OperandProducer class to the rest of the CompUnit unit
tests.

* Start adding formal verification to the CompUnits.

I feel that the Computation Units are pretty complex, with their
interlocked stages, multiple inputs and outputs, handshakes, etc. It is
a bit onerous to keep adding asserts, at every step, to the unit tests.
Formal verification is a better way of handling this, I think.

Regards,

Cesar



More information about the Libre-soc-dev mailing list