ec809c9137
This patch fixes the code generator to correctly create three value
constant delays. It also fixes a bug in the compiler related to the
precalculation of the high-Z delay when only two delays are given.
Previously if was using a pointer not a value comparison to find
the minimum value.
Variable delays should work when one or three values are given.
For the two value case we need to do a comparison at run time and
that will require changing the compiler/run time interface so that
can only go into the V0.10 branch. This patch can be applied to
both development and V0.9. I have added a sorry message and an
assert for this case. I will add the variable two delay case at a
later time. We also do not support mixing constant and variable
delays on a single statement. That is a much bigger change and
can wait until someone asks for it.
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| Makefile.in | ||
| README.txt | ||
| draw_mux.c | ||
| draw_net_input.c | ||
| draw_switch.c | ||
| draw_ufunc.c | ||
| draw_vpi.c | ||
| eval_bool.c | ||
| eval_expr.c | ||
| eval_real.c | ||
| modpath.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.