e221a8ced9
Before this patch, WARNING_FLAGS applied to both C and C++, and WARNING_FLAGS_CXX applied to C++ only. This patch adds a WARNING_FLAGS_CC that applies to C only. That change should be generally useful; in particular the C code is almost ready for -Wstrict-prototypes, which does not apply to C++. -Wextra (or -W) used to only apply to C++ via WARNING_FLAGS_CXX. This patch moves it to WARNING_FLAGS, to apply to both C and C++. Unfortunately, that triggers a ton of warnings. For now, cover most of the new warnings up by adding -Wno-unused -Wno-sign-compare -Wno-type-limits to WARNING_FLAGS_CC. In the long run, I want to change the C coding style, and take off these disable-warning flags. But those changes can dribble in as separate commits; this patch is big enough already. Actually fix a couple missing-field-initializers in libveriuser/veriusertfs.c. |
||
|---|---|---|
| .. | ||
| Makefile.in | ||
| README.txt | ||
| cppcheck.sup | ||
| draw_class.c | ||
| draw_enum.c | ||
| draw_mux.c | ||
| draw_net_input.c | ||
| draw_switch.c | ||
| draw_ufunc.c | ||
| draw_vpi.c | ||
| eval_bool.c | ||
| eval_expr.c | ||
| eval_object.c | ||
| eval_real.c | ||
| eval_string.c | ||
| modpath.c | ||
| stmt_assign.c | ||
| vector.c | ||
| vvp-s.conf.in | ||
| vvp.c | ||
| vvp.conf.in | ||
| vvp_config.h.in | ||
| vvp_priv.h | ||
| vvp_process.c | ||
| vvp_scope.c | ||
README.txt
THE VVP TARGET SYMBOL NAME CONVENTIONS There are some naming conventions that the vp target uses for generating symbol names. * wires and regs Nets and variables are named V_<full-name> where <full-name> is the full hierarchical name of the signal. * Logic devices Logic devices (and, or, buf, bufz, etc.) are named L_<full_name>. In this case the symbol is attached to a functor that is the output of the logic device. GENERAL FUNCTOR WEB STRUCTURE The net of gates, signals and resolvers is formed from the input design. The basic structure is wrapped around the nexus, which is represented by the ivl_nexus_t. Each nexus represents a resolved value. The input of the nexus is fed by a single driver. If the nexus in the design has multiple drivers, the drivers are first fed into a resolver (or a tree of resolvers) to form a single output that is the nexus. The nexus, then, feeds its output to the inputs of other gates, or to the .net objects in the design.