234648231b
This patch adds functionality to do a bit or part select release when a constant value is forced to the net/register. It also adds an error message when the user tries to force a signal to a bit/part select. This is not currently handled by the run time, so is now caught in the compiler (tgt-vvp). Where when this functionality is needed, it will be easy to know what to do instead of trying to track down some odd runtime functionality. What this all means is that you can force a signal to an entire signal or you can force a constant to any part of a signal (bit, part or entire) and release any of the above. Technically the release of a constant value does not have to match the force. The runtime verifies that if you are releasing a signal driver it is being done as a full release. I don't see an easy way to check this in the compiler. To fix the signal deficiencies we need to rework the force_link code to allow multiple drivers and partial unlinking. Much of this is in the runtime, but the %force/link operator may also need to be changed like I did to the %release opcode. |
||
|---|---|---|
| .. | ||
| .cvsignore | ||
| Makefile.in | ||
| README.txt | ||
| configure.in | ||
| draw_mux.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.