`vecLen of a non-vector type` in "delay by n" function

[martijnbastiaan]

This:

module Test4 where

import Clash.Prelude

topEntity
  :: HiddenClockReset System 'Source 'Asynchronous
  => Signal System Int
topEntity =
  delayBy (SNat @3) (pure 1)

delayBy n signal =
  foldr (\_ s -> delay s) signal (replicate n ())
{-# NOINLINE delayBy #-}

Behaves perfectly fine in simulation:

*Test4> printX $ sampleN 10 topEntity 
[X,X,X,1,1,1,1,1,1,1]

but refuses to compile down to verilog:

$ cabal new-run clash -- Test4.hs --verilog
Up to date
Loaded package environment from /home/martijn/Code/clash-compiler/.ghc.environment.x86_64-linux-8.4.3
Loading dependencies took 1.055727952s
Parsing and compiling primitives took 0.380146334s
Compiling: Test4.topEntity
Applied 62 transformations
Normalisation took 0.424106646s
Netlist generation took 0.001500679s

<no location info>: error:
    Clash error call:
    Clash.Netlist.BlackBox.Util(467): vecLen of a non-vector type

[martijnbastiaan]

renderTag does not account for void-types. This patch:

 renderTag b (Size e)        = return . Text.pack . show . typeSize $ lineToType b [e]
-renderTag b (Length e)      = return . Text.pack . show . vecLen $ lineToType b [e]
+
+renderTag b (Length e) = return . Text.pack . show . vecLen $ lineToType b [e]
   where
-    vecLen (Vector n _) = n
-    vecLen _            = error $ $(curLoc) ++ "vecLen of a non-vector type"
-renderTag b (Depth e)      = return . Text.pack . show . treeDepth $ lineToType b [e]
+    vecLen (Vector n _)               = n
+    vecLen (Void (Just (Vector n _))) = traceShowId n
+    vecLen thing =
+      error $ $(curLoc) ++ "vecLen of a non-vector type: " ++ show thing
+
+renderTag b (Depth e) = return . Text.pack . show . treeDepth $ lineToType b [e]
   where
-    treeDepth (RTree n _) = n
-    treeDepth _           = error $ $(curLoc) ++ "treeDepth of a non-tree type"
+    treeDepth (RTree n _)               = n
+    treeDepth (Void (Just (RTree n _))) = n
+    treeDepth thing =
+      error $ $(curLoc) ++ "treeDepth of a non-tree type: " ++ show thing
+

makes the design compile succesfully for verilog, but fails for VHDL:

  -- foldr begin
  foldr : block
    type foldr_res_type is array (natural range <>) of signed(63 downto 0);
    signal intermediate : foldr_res_type (0 to 2);
  begin
    intermediate(2) <= x;

    foldr_loop : for i in \#vec\'range generate
    begin
      block_r : block
      signal \#bb_res_res\ : signed(63 downto 0);
    begin
      -- delay begin
      test4_topentity_delay : process(\$d(%,%)\.product_sel0)
      begin
        if rising_edge(\$d(%,%)\.product_sel0) then
          \#bb_res_res\ <= intermediate(i+1)
          -- pragma translate_off
          after 1 ps
          -- pragma translate_on
          ;
        end if;
      end process;
      -- delay end

      intermediate(i) <= \#bb_res_res\;
    end block;
    end generate;

    result <= intermediate(0);
  end block;
  -- foldr end

with error:

            vempty_topentity.vhdl:33:27: no declaration for "\#vec\"                                                                                                                
            vempty_topentity.vhdl:33:5: range must be a static discrete range                                                                                                       
            vempty_topentity.vhdl:42:42: no function declarations for operator "+"                                                                                                  
            vempty_topentity.vhdl:42:42: no function declarations for operator "+"                                                                                                  
            vempty_topentity.vhdl:51:20: can't match 'i' with type integer             

[martijnbastiaan]

So the actual issue is that \#vec\ is supposed to refer to the vector of units. Because these have no actual length, Clash filters them. Usually, this is fine, but in this case VHDL cannot generate the loop as it has no length information to do so. Verilog on the other hand has no such construct (AFAIK), so we use numeric literals to generate the loop.

I've cooked up a patch which eliminates this for this specific case. Awaiting review.