cdkersey / chdl Goto Github PK

If a register's input is attached to its own output, cycdet() will segfault.

A 1-word synchronous SRAM is essentially a register, but the generated verilog code contains lines like:

wire [18446744073709551615:0] __mem_da1369;

This is bad.

Some wire declarations are after their use, therefore Xilinx Simulation Tool generates errors like:
ERROR: [VRFC 10-2071] __x169 is already implicitly declared on line 26 [h2_rom.v:322]

Not declaring them is fine for Xilinx tool since it will assume them as wire type.

CHDL's use of a function named assert() is not safe due to 's declaration of an assert macro. Should probably be renamed chdl_assert (ASSERT() doesn't need to change, but I think it should anyway).

Suppose that I am using CHDL in something else, and I am interested in guaranteeing that the code doesn't have warnings.

This can be easily reproduced by setting CXXFLAGS="-Wall -Wextra" and typing 'make'. Here is an excerpt of the output:

g++ -Wall -Wextra -fPIC -std=c++11 -O2    -c -o hierarchy.o hierarchy.cpp
In file included from regimpl.h:5:0,
                 from hierarchy.cpp:14:
tickable.h:20:18: warning: unused parameter âcdâ [-Wunused-parameter]
tickable.h:21:18: warning: unused parameter âcdâ [-Wunused-parameter]
tickable.h:22:18: warning: unused parameter âcdâ [-Wunused-parameter]
tickable.h:23:18: warning: unused parameter âcdâ [-Wunused-parameter]
In file included from hierarchy.cpp:14:0:
regimpl.h:20:10: warning: unused parameter âcdâ [-Wunused-parameter]
hierarchy.cpp: In constructor âhierarchy::hierarchy(std::string, chdl::hpath_t)â:
hierarchy.cpp:55:10: warning: âhierarchy::nameâ will be initialized after [-Wreorder]
hierarchy.cpp:54:11: warning:   âchdl::hpath_t hierarchy::pathâ [-Wreorder]
hierarchy.cpp:21:3: warning:   when initialized here [-Wreorder]
hierarchy.cpp: In member function âvoid hierarchy::print(std::ostream&, int, unsigned int)â:
hierarchy.cpp:30:33: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

This bug is important because users expect their code to compile cleanly without warnings, especially upstream projects that are subject to distribution requirements for -Wall and -Wextra.

A mux with 2^16 or so inputs (like a large LLRom) causes the compiler to use all of the RAM and grind to a halt. GCC doesn't know how to handle this. Figure out why (we should only be creating 16 instances of the function template; it's the call graph that gets interesting; is it trying to inline?) and find a reasonable workaround (possibly including sidestepping the issue by changing how LLRom works; plain old muxes aren't often this big).

Say we define a special mux like this:

  template <typename T> T Mux(bvec<10> sel, const vec<1024, T> &in) {
    bus<sz<T>::value> b;
    for (unsigned i = 0; i < 1024; ++i)
      b.connect(Flatten(in[i]), sel == Lit<10>(i));
    return b;
  }

and we build roms by attaching literals to the inputs. It becomes quite larger after tri-state merge, creating a network for all cases in which the bus will be driven 1 and another network for all cases in which the output will be driven 0. There should be some way to recognize these kinds of buses and leave them undisturbed.

My floor is still dirty, the litterbox still needs to be cleaned, and I find I'm just generally unhappy. Will this be fixed in a future release?

I think "release" is a keyword in Verilog. Harmonica2 generates a wire with this name and therefore causes an error on Xilinx tool chain

code example:

wire release;
assign release = __x172525;