Generating verilog gives "Clash.Netlist(1138): mkDcApplication undefined for: ..."

[peter.t...@gmail.com]

Clash 1.8.1 is not generating verilog for code that Clash 1.6.4 generates verilog from with no complaints in just a couple of minutes. There is no error output, just silent looping with no growth (some very slow and slight reduction) of memory footprint (at about 3GB). Trying to locate the problem I am splitting up the code for separate generation of verilog for each part (it was already NOINLINEd to death). For one part I am getting

> Clash: Compiling Synth.TACache.tacache_server32
> Clash: Normalization took 1.200s
> <no location info>: error:
>   Clash error call:
>  Clash.Netlist(1138): mkDcApplication undefined for: (Signed 132,Name {nameSort = User, nameOcc = "GHC.Types.Eq#", ... (LitTy (NumTy 126))))))))))],[Just (Void Nothing)])
>    CallStack (from HasCallStack):
>      error, called at src/Clash/Netlist.hs:1138:9 in clash lib-1.8.1-5MhY47XBP4u2ZDR51FYDI5:Clash.Netlist
>      mkDcApplication, called at src/Clash/Netlist.hs:863:16 in clash-lib-1.8.1-5MhY47XBP4u2ZDR51FYDI5:Clash.Netlist
>      mkExpr, called at src/Clash/Netlist.hs:507:31 in clash-lib-1.8.1-5MhY47XBP4u2ZDR51FYDI5:Clash.Netlist

(intermediate pages of data elided)

My general impression is there is either a bug or some new requirement that I am not meeting. I'm staring at the code without seeing anything and Clash 1.6.4 works fine on it to generate verilog from.

Any help?

Regards

PTB

[Christiaan Baaij]

GHC.Types.Eq# is the constructor for the `~` constraint.

See also:

* https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.8.1-release/compiler/GHC/Builtin/Types/Prim.hs?ref_type=tags#L1062-1075

Are you by any chance using `unsafeCoerce` somewhere?

Also, what version of GHC are you using? 

If you are:

* using GHC 9.4 or newer, and

* have your own primitives

I would suggest annotating them with `OPAQUE` instead of `NOINLINE`; especially if said primitives involve `Signed`, `Unsigned`, or `Index`.

--
You received this message because you are subscribed to the Google Groups "Clash - Hardware Description Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clash-languag...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clash-language/59ce9f52-c85a-4c6c-b197-a55ce4509602n%40googlegroups.com.

[peter.t...@gmail.com]

Hello Christiaan, thank you very much for your quick response. I appreciate it very much. 

In no particular order, I am using debian unstable on a  64b AMD platform and ghc with clash 1.8.1 is 9.4.7. In this particular module

there are no primitives of my own, but there are elsewhere in another module (but I have now ifdefed them out, they were only for reporting) and I have no doubt that none

of my own primitives can have been brought in inadvertently, not least because of the ifdefing. But I'll certainly use OPAQUE instead of NOINLINE  when I ifdef them back in.

I have had a look at the clash source code now and the error message  is a catch at the bottom of a case switch and that indicates  some pattern is missed. The line is

>       _ ->     error $ $(curLoc) ++ "mkDcApplication undefined for: " ++ show (dstHType,dc,args,argHWTys)

and the case switch was "case (hWTysFiltered,argExprsFiltered) of"

The error report shows the function args, not the case argument. The cases seem to cover Signed, Unsigned etc, so I think it is certainly

some type construct that has been missed but that code works under clash 1.6.4 so perhaps one could look for a change

in that function  since the 1.6.4 release? The function is "mkDcApplication declType [dstHType] bndr dc args", and the function arguments are more or less what is reported in the error

message. (I would like it if the error message showed what case has been missed).

I have added the complete error message as an attachment here.

Yes, there are a few "~" in the type declarations and I have noticed that 1.8.1 seems weaker than 1.6.4 at type inference. (For instance I used

to be able to write (n-1)+1 ~ n in 1.6.4 to tell clash that there is something to which one adds 1 to get n and it was not necessary to add 1<=n, but

now it is necessary).  With that clue I will try removing need for "thinking" on clash's part to resolve the types there. I hadn't realized it

may be the typing. It may be just one of those corner case things that will go away with any change.

 But definitely 1.6.4 copes and  the ghc with 1.6.4 is 9.0.2 . (Both setups are available in different sandboxes on the same machine)

Regards

PTB

[peter.t...@gmail.com]

I've been trying to remove type aliases and always have a type expression that is only a type variable name on the left of any "~". The support functions were

abstractly defined using types  parameterised in a type family f for which x ~ f n has BitPack x and BitSize x ~ n and that was instantiated at top level

with f ~ Signed. and causing  x ~ Signed n. I think something about that was not liked in 1.8.4 for generating verilog. It works without complaint in clashi for simulation.

I went through specializing the support functions from "f" to Signed as they would not be needed for more than that but the error message wold not shift. But

now finally it has changed (so I am indeed fiddling with the right things) to:

> ...

> Clash: Normalization took 0.424s

> <no location info>: error:
>    Clash error call:

>    Clash.Netlist(1041): Under-applied constructor
>    CallStack (from HasCallStack):
>      error, called at src/Clash/Netlist.hs:1041:17 in clash-lib-1.8.1-5MhY47XBP4u2ZDR51FYDI5:Clash.Netlist

>      mkDcApplication, called at src/Clash/Netlist.hs:863:16 in clash-lib-1.8.1-5MhY47XBP4u2ZDR51FYDI5:Clash.Netlist

>      mkExpr, called at src/Clash/Netlist.hs:508:31 in clash-lib-1.8.1-5MhY47XBP4u2ZDR51FYDI5:Clash.Netlist

That is a Product case in mkDcApplication:

>  Product _ _ dcArgs ->
>       case compare (length dcArgs) (length argExprsFiltered) of
>          EQ -> return (HW.DataCon dstHType (DC (dstHType,0)) argExprsFiltered)
>          LT -> error $ $(curLoc) ++ "Over-applied constructor"
>          GT -> error $ $(curLoc) ++ "Under-applied constructor"      <-- HERE

Is it saying the comma type constructor is applied to one type instead of two? No it isn't. Clashi would

complain, and it doesn't! Could it be reading parens as always wanting to contain a tuple instead of alternatively

a non-tuple compound type expression? 

Anyway, to change the error I only changed/refined the types, not the code, so this has to be a type problem. I think

it's parsing something strangely, but why here (wherever it is) and nowhere else I do not know. I have written nothing

that I have not written in another module that generated verilog without a problem.

I just checked and the same error appears generating vhdl and systemverilog.

Does the above message give a sharper clue to what it might be about?

Regards

PTB.

[Christiaan Baaij]

It's saying a data constructor for a product type (e.g. a tuple (,,,) or a record type) is given fewer term-level arguments than expected.

But this is after all kinds of transformations.

We should make the error message better so that it at least prints the name of the data constructor.

Perhaps you can make a patched version of the compiler.

So that you have:

      Product _ _ dcArgs ->
        case compare (length dcArgs) (length argExprsFiltered) of
          EQ -> return (HW.DataCon dstHType (DC (dstHType,0)) argExprsFiltered)
          LT -> error $ $(curLoc) ++ "Over-applied constructor"

          GT -> error $ $(curLoc) ++ "Under-applied constructor " ++ show dstHType ++ "\n\nApplied args:\n" ++ show argExprsFiltered

I also suggest moving this discussion to the github issue tracker instead of the mailing list.

To view this discussion on the web visit https://groups.google.com/d/msgid/clash-language/375e6082-e1a7-40a0-beac-e72d218c81cdn%40googlegroups.com.

[peter.t...@gmail.com]

Yes, I'll figure out moving it in the morning. Meanwhile here is the extended error reporting. Looks innocuous.

> Clash: Normalization took 0.371s

> <no location info>: error:
>    Clash error call:

>    Clash.Netlist(1044): Under-applied constructor Product "GHC.Tuple.(,)" Nothing [Vector 1 (SP "GHC.Maybe.Maybe" [("GHC.Maybe.Nothing",[]),("GHC.Maybe.Just",[Product "GHC.Tuple.(,)" Nothing [Signed 126,SP "GHC.Maybe.Maybe" [("GHC.Maybe.Nothing",[]),("GHC.Maybe.Just",[Signed 32])]]])]),Signed 126]   
>    Applied args:
>    []
>    CallStack (from HasCallStack):
>      error, called at src/Clash/Netlist.hs:1044:17 in clash-lib-1.8.1-HGqecslfsXx3PEFezUYUbi:Clash.Netlist
>      mkDcApplication, called at src/Clash/Netlist.hs:863:16 in clash-lib-1.8.1-HGqecslfsXx3PEFezUYUbi:Clash.Netlist
>      mkExpr, called at src/Clash/Netlist.hs:508:31 in clash-lib-1.8.1-HGqecslfsXx3PEFezUYUbi:Clash.Netlist

[peter.t...@gmail.com]

Do you have enough data to be able to reproduce the problem over there? I attached the function args printout up the page here a bit. I would like to

try working around the problem here.

The case switch failure on Product occured on what more nicely formatted is as follows:

> "GHC.Tuple.(,)" Nothing
>   [ Vector 1
>     (SP "GHC.Maybe.Maybe"
>     [ ("GHC.Maybe.Nothing",[])

>     , ("GHC.Maybe.Just"

>       , [ Product "GHC.Tuple.(,)" Nothing
>           [ Signed 126
>           , SP "GHC.Maybe.Maybe"
>             [ ("GHC.Maybe.Nothing",[])

>             , ("GHC.Maybe.Just" , [Signed 32])

>             ]
>           ]
>         ]
>       )
>     ])
>   , Signed 126
>   ]

I guess it represents type "( Vec 1 (Maybe (Signed 126,Signed 32) , Signed 126  )" . That seems OK to me.

Regards

PTB

On Monday, December 18, 2023 at 3:42:48 PM UTC christia...@gmail.com wrote:

[peter.t...@gmail.com]

See https://github.com/clash-lang/clash-compiler/issues/2628 where a test case is posted.