d4765e3354
The `netdarray_t` type implements the `packed_width()` method by returning the packed width of the element type. It is the only non-packed type that implements the method. This triggers an assert in the vlog95 backend for tasks with dynamic array typed parameters. And while the vlog95 backend does not support dynamic array types it should not result in a crash, just an error message. The only place that relies on the behavior that the packed width of the element type is returned is in the vvp backend where variable declarations are generated. Update that code to query the packed width of the element type instead and then remove the `packed_width()` implementation for the `netdarray_t` type. This fixes the assert in the vlog95 backend. But it is also nicer from an architectural perspective as this brings the type in line with the other types in terms of behavior. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> |
||
|---|---|---|
| .. | ||
| COPYING.lesser | ||
| Makefile.in | ||
| README.txt | ||
| cppcheck.sup | ||
| draw_class.c | ||
| draw_delay.c | ||
| draw_enum.c | ||
| draw_mux.c | ||
| draw_net_input.c | ||
| draw_substitute.c | ||
| draw_switch.c | ||
| draw_ufunc.c | ||
| draw_vpi.c | ||
| eval_condit.c | ||
| eval_expr.c | ||
| eval_object.c | ||
| eval_real.c | ||
| eval_string.c | ||
| eval_vec4.c | ||
| modpath.c | ||
| stmt_assign.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 vvp 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.