a4eeea75ce
The basic structure for supporting assignment operators on real arrays
exists in the tgt-vvp backend. But there are a few problems, most
importantly it generates the wrong instruction for loading data from the
real array.
The instruction it uses is `%load/reala`, but that instruction does not
exist, the correct name is `%load/ar`.
In addition to this there are a few minor problems.
* Out-of-bounds access on the array triggers an assert
* Missing `%pop/real` instruction when skipping a write due to
out-of-bounds access
Address these so assignment operators are supported on real array entries.
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.