On Tue, 2019-02-19 at 07:35 +0000, Luke Kenneth Casson Leighton wrote:

Rudi wrote:

...

Curious: What is the cycle time of the generated code versus native verilog code ?

hi rudi, nice to see you around, i haven't forgotten you :)

it's exactly the same, as it's clk-based.

Hi Luke,

yeah, I'm following the list whenever I find some time :)

What I mean with "cycle-time" is: What clock frequency can the final design run at ? That will tell you how efficient the generated versus the hand written code is.

the layout however with nmigen is... well... it's auto-generated in nmigen via yosys, where migen has its own built-in back-end, and goes to some lengths to generate verilog that looks reasonably similar to the migen it came from: that's gone in nmigen.

so, in nmigen, each signal that is assigned is separated out into its own auto-generated code-section (migen keeps them all together). resetting is auto-generated and need not be added manually. declaring a signal "resetless" may be done if it is definitely known that it requires no reset; the value of the reset may be over-ridden at declaration time: x = Signal(32, reset=0xf00baa)

in nmigen, all tests, subexpressions and consequently most assignments are done with combinatorial auto-generated wires / registers (of the correct / required / calculated / auto-calculated width), with the original python line number and file name inserted as a comment next to the expression assignment "$483 = x[1:0] // foo.py:135"

in nmigen, all if elif elif elif statements are translated to casez statements comprising a concatenated sequence of tests (derived from the if part of every single if-elif-elif-elif statement), followed by case 0b1zzzzzz case 0bz1zzzzzz case 0bzz1zzzzz and so on.

Hmm, perhaps I am not understanding this, BUT, 0b1zzzzzz and 0bz1zzzzzz and not mutually exclusive.

Perhaps a priority encoder is intended: 0b1zzzzzz 0b01zzzzz 0b001zzzz etc.

Depending what you are going to do with this code, the translation of if-else to casez is a very bad idea.

Modern synthesis tools know the difference of an if-else and a case and will try different strategies to optimize it. The documentation usually gives examples what style to use for which situation. and will guide you to generate efficient code.

If you intent to tape out a ASIC from that code, I would expect to see bad are and performace from code generate that way. Wich would make that ASIC unnecessarily expensive and slow.

three quirks which are down to python:

• n/migen works through operator overloading of python syntax.

assignment of python variables does *not* have an operator over-ride, so, annoyingly, an "eq" function had to be provided. "m.d.sync += x.eq(y)" instead of "x = y", because "x = y" would make the *PYTHON* variable x equal to y.

• operator-overloading of the "not", "and" and "or" operators

unfortunately returns a boolean rather than an object. however the "&" and "|" bit-wise operators, when overloaded, *do* actually return the objects that are returned from the overload-function. consequently, you *have* to do tests as "m.If((modulus[0:31] == 0x0) & (exponent == -127))" of course including the brackets because & and | operators take higher precedence.

• python slices go from *LSB* on the left to *MSB PLUS ONE* on the

right, where verilog goes from MSB (inclusive) *down* to LSB (inclusive). this so that you can do consecutive slices without needing to subtract one: "x = x[y:] + x[:y]" is a barrel-shifter for example. note the lack of use of "y-1".

so... it's... quirky. however, the prevalence and huge adoption of python, the advantages of OO, the fact that to generate online documentation i can use a single command from a 20-year-old tried-and-tested program named "epydoc" (or any of its maaaany Not-Invented-Here quotes replacements quotes), these for me *far* outweigh the quirks and inconveniences.

on a separate note: multiply was added yesterday, along with the original unit test process that jon dawson developed (which hilariously was as python programs). i cut out the use of a c++ program and replaced it with sfpy (berkeley softfloat 3 python bindings).

so, that's *all* of add, add64, div, div64, mul and mul64, all done, all converted to nmigen, and all unit tests passing.

i've run up to 250,000 add and add64 random-input unit tests.

the reason for using sfpy is to avoid having to call out to a subprocess (nmigen contains its own simulator), and also, sfpy supports setting of different overflow modes, which is one of the next things to add.

also, now we can add FP16, which is supported by sfpy, *without* dependence on a particular feature of a c / c++ compiler (not all c / c++ compilers *have* an FP16 type). adding FP16 is literally a matter of adding a few lines in the base class to tell it what to do when FPAdd(16) is instantiated.

l.

rudi =============================================================== Rudolf Usselmann, ASICS World Services, LTD, www.asics.ws Your IP Partner: SAS 12G, SATA-3, USB-3, SD/MMC/SDIO, FEC, etc.

The agony of poor quality remains long after the joy of low cost has been forgotten

This email message may contain confidential and privileged information. Any unauthorized use is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.