On Jan 6, 2012, at 6:48 PM, David Koontz wrote:
While technically challenging, a rather dry subject.
Getting to the actual error:
On Jan 6, 2012, at 6:48 PM, David Koontz wrote:
>
> Second,
>
> test_timesim.vhd:133:3:warning: component instance "clk_bufgp_bufg" is not
> bound
>
> Is going to require some finessing to analyze and elaborate. The model
> (tbx_test) isn't complete without it.
> grep -i mux work-obj93.cf returns nothing.
> (This is with the mcode version of GHDL-0.29 on Mac OS X).
>
>
> I'd suspect one of those changes in 08 or 09 are responsible:
>
> david_koontz@Macbook: ghdl -r tbx_test --stop-time=500us
> --wave=simu_tb_test_timesim.ghw
> test_timesim.vhd:133:3:warning: component instance "clk_bufgp_bufg" is not
> bound
> test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
>
> (The component instance is unbound regardless of applying an sdf file.) I'd
> suspect It would have to be debugged on a Linux machine.
>
Linux does the same thing
=====================
The component declaration in simprims/simprim_Vcomponents.vhd doesn't match
that found in the entity declaration for simprims/primitive/other/X_BUFGMUX.vhd.
A check in a Linux version of ghdl (GHDL 0.29 ) shows:
david-koontz-VirtualBox:/mnt/share/9597% ghdl -e tbx_test
test_timesim.vhd:133:3:warning: component instance "clk_bufgp_bufg" is not bound
test_timesim.vhd:51:14:warning: (in default configuration of test(structure))
david-koontz-VirtualBox:/mnt/share/9597% ghdl -r --no-vital-checks
--warn-no-vital-generic tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us
--wave=simu_tb_test_timesim.ghw
./tbx_test:error: test_timesim.sdf:72:29: could not annotate generic tpd_i0_o
/usr/lib/ghdl/bin/ghdl: compilation error
(tpd_i0_o happens to be the first vital timing value annotated, in an X_BUF If
I recall correctly).
We get the same answer under Linux. The story here is that ghdl is doing the
right thing under ISE 13.2 so far. Generating a local component declaration
resulted in different errors. A solution might be to find an older version of
ISE, preferably one not requiring installation (a backup image). Handcrafting
a working BUFGMUX requires more knowledge of VITAL than I'm willing to acquire
in the short term. (My first choice would be to use an FPGA's static timing
analysis tools, the number of different delay values, etc., involved is limited
although you could contemplate the issue of clock domain crossing).
Getting the X_BUFGMUX Cell to be bound
=================================
So I found I had a copy of ISE 9.1 which I extracted X_BUFGMUX.vhd, from
renamed the entityt to X_BUFGMUX_X, created a component declaration for in the
architecture declarative region, renamed the CELLTYPE in the SDF file to match,
and:
ghdl -a X_BUFGMUX.vhd
X_BUFGMUX.vhd:37:5:warning: generic "loc" is not a VITAL generic
X_BUFGMUX.vhd:42:7:warning: 'gsr' is not a port name (in VITAL generic name)
ghdl -a test_timesim.vhd
ghdl -a tb_test_timesim.vhd
(Linux would have a ghdl -e tbx_test here)
ghdl -r --no-vital-checks --warn-no-vital-generic tbx_test
--sdf=uut=test_timesim.sdf --stop-time=500us --wave=simu_tb_test_timesim.ghw
ghdl:error: vital: unhandled generic type for generic
tsetup_s_i0_posedge_negedge
I used just the X_BUFGMUX.vhd file extracted from the single vhdl file
containing all the simprim primitives because in 9.1 there is an implication of
using synopsys arithmetic in some of the later primitives (e.g. DSP48) which I
wanted to avoid. There is not distinction between other and mti in 9.1
implying the IEEE arithmetic libraries weren't in effect yet.
So, because there is a Vital timing check for setup and hold from S to i0,
positive edge S to negative edge in this version of X_BUFGMUX.vhd and the
error message is from the ghdl run time library (grt), grt-vital_annotate.adb,
we can assumed ghdl is reporting that it isn't doing a setup and hold time
check (and this is the first one of two setup and two hold checks in this
X_BUFGMUX.vhd, unhappy about something).
As an aside the only thing this particular timing check can test is effectively
cycle time for the faster of the two clocks on this clock buffer (i0 or i1)
based on the Select (S) delay from a synchronous event driving S. For a
simulation just checking back annotation for an XOR gate, who cares?
The question is whether you can do any timing checks for setup and hold time?
SDF File Syntax
=============
Looking at the SDF file for X_BUFGMUX:
(CELL (CELLTYPE "X_BUFGMUX_X")
(INSTANCE clk_BUFGP_BUFG)
(DELAY
(ABSOLUTE
(IOPATH I0 O ( 0 ))
(IOPATH I1 O ( 0 ))
)
)
(TIMINGCHECK
(SETUPHOLD (posedge S) (negedge I0) (480:600:600)(0))
)
)
There are two timing rvalues passed (480:600:600) and (0) (in pico seconds,
TIMESCALE from the SDF Header) the first three case times for setup time and
the second 0 hold time. (Keeping in mind I don't have a copy of VITAL-95).
The SDF file says 3.0 compatibility (VITAL2000), but ghdl doesn't except
comments in an SDF file (I tried), so I imagine it's only Vital-95 compliant
(SDF 2.1).
The message
ghdl:error: vital: unhandled generic type for generic
tsetup_s_i0_posedge_negedge
Seems to be complaining about the number of timing cases presented by the
generic -
tsetup_S_I0_posedge_negedge : VitalDelayType := 0.000 ns;
VitalDelayType provides a single time value, VitalDelayType01... provides
multiple ones.
The setup time rvalues specify the output transitions 0→1 and Z→1, the second
to the transitions 1→0 and Z→0 and the third to the “Z” transitions 0→Z and 1→Z.
The single hold time rvalue would apply to all transisions.
In any event VitalDelayType is appropriate for use in VitalSetupHoldCheck()
(See vital_timing.vhdl in ghdl/libraries/vital95). The complaint has to be
related to how the information in the SDF file is loaded into it which points
more than likely to how ghdl is interpreting the SETHUPHOLD clause quoted above
from the SDF file.
We see in the Version History of sdf_3.0.pdf that an alternate syntax for
SETUPHOLD has been added (since SDF 2.1). The sdf doesn't use it and the notes
above are valid for 2.1.
So it appears the syntax for TIMINGCHECK and SETUPHOLD are correct in the sdf
file.
How theTIMINGCHECK SETUPHOLD specification is mapped to the Generic
============================================================
The two timing check setup and hold tests are excerpted from X_BUFGMUX.vhd
(this verson):
VitalSetupHoldCheck (
Violation => Tviol_S_I0_posedge,
TimingData => Tmkr_S_I0_posedge,
TestSignal => S_I0_dly,
TestSignalName => "S",
TestDelay => tisd_S_I0,
RefSignal => I0_dly,
RefSignalName => "I0",
RefDelay => ticd_I0,
SetupHigh => tsetup_S_I0_posedge_negedge,
HoldHigh => thold_S_I0_posedge_negedge,
CheckEnabled => true,
RefTransition => 'R',
HeaderMsg => "/X_BUFGMUX",
Xon => Xon,
MsgOn => true,
MsgSeverity => warning);
VitalSetupHoldCheck (
Violation => Tviol_S_I1_posedge,
TimingData => Tmkr_S_I1_posedge,
TestSignal => S_I1_dly,
TestSignalName => "S",
TestDelay => tisd_S_I1,
RefSignal => I1_dly,
RefSignalName => "I1",
RefDelay => ticd_I1,
SetupLow => tsetup_S_I1_negedge_negedge,
HoldLow => thold_S_I1_negedge_negedge,
CheckEnabled => true,
RefTransition => 'R',
HeaderMsg => "/X_BUFGMUX",
Xon => Xon,
MsgOn => true,
MsgSeverity => warning);
The first one is forTestSignalName "S" and RefSignalName "I0", And only
SetupHigh and HoldHigh are specified (1→0 and Z→0 transitions 600ps and 0ps
respectively.)
Note there isn't one for (0→1 and Z→1) and ( 0→Z and 1→Z) and there is a time
specified for those (480ps and 600 ps respectively).
The second VitalSetupHoldCheck() is of no immediate interest, for "S" and "I1".
There are ASCII timing diagrams included in vital_timing.vhdl which aid in
understanding what the rest of the arguments besides SetupHigh mean. While
writing this up I also corrected HeaderMSG in both to "X_BUFGMUX_X" to see if
that had any effect (it did not).
The lack of the other two tests is likely not significant.
Where does "error: vital: unhandled generic type for generic
tsetup_s_i0_posedge_negedge" come from?
==================================================================================
The error message is generated at lines 473 and 474 of
ghdl/translate/grt/grt-vital_annotate.adb in the procedure Sdf_Generic located
at line 371. (ghdl-0.29, unchanged for a while, likely).
It's in an else statement at line 472, where the matching previous conditional
is elsif at line 430.
if Vhpi_Compare_Handles (Gen_Basetype, VitalDelayType01)
or else Vhpi_Compare_Handles (Gen_Basetype, VitalDelayType01Z)
or else Vhpi_Compare_Handles (Gen_Basetype, VitalDelayType01ZX)
then
Ok := Write_Td_Delay_Generic (Context, Gen);
elsif Vhpi_Compare_Handles (Gen_Basetype, VitalDelayArrayType01)
or else Vhpi_Compare_Handles (Gen_Basetype, VitalDelayArrayType)
then
With the first if on line 425 and the elseif on line 430 the else condition at
line 472 generating the error.
We know from X_BUFGMUX.vhd the Generic declaration that
tsetup_S_I0_posedge_negedge : VitalDelayType := 0.000 ns;
Which is saying the error is reported faithfully, it doesn't see a single
rvalue (VitalDelayType) as being appropriate here. We know it is. In
VitalSetupHoldCheck it's assigned to something that is. (SetupHigh expects a
scalar Time value).
This appears to be a shortcoming in error checking and possibly writing the
Setup time as well, likely found in grt-vital_annotate.adb and is appears to be
a ghdl implementation shortcoming (an error).
There's likely an implied issue with selecting the appropriate test case, as
well. It says there's some missing code in grt-vital_annotate.adb.
I've in mind an experiment to allow the model to work. It would involve
changing the generic to VitalDelayType01Z, and assigning the '1' value to
SetupHigh instead of the entire generic in X_BUFGMUX.vhd (and the component
declaration):
tsetup_S_I0: VitalDelayType01Z :=( 0.000 ns, 0.00 ns, 0.00 ns);
(tsetup_S_I0 instead of tsetup_S_I0_posedge_negedge)
And where it's used:
SetupHigh => tsetup_S_I0(tr10),
This implies that grt is capable of mapping all three values to the generic.
Notice only a single value for HoldHigh is given (thold_S_I0_posedge_negedge)
which according to the SDF standard the single rvalue in the SETUPHOLD
specification should be used for all cases. It should work in any event.
The issue with that is other implementations are capable of swallowing the
model and the sdf file unchanged (apparently). This is the case of the
CELLTYPE model only being interested in one transition case while the SDF
specification doesn't provide a way to specify only one, and ghdl is getting
confused. This might have been why the the alternative syntax for SETUPHOLD
was introduced as well.
There is definitely work that should be considered for ghdl. This would imply
looking at the test case in VitalTimingCheck:VitalSetupHoldCheck and applying
the rule for three rvalues found on Page 3-18 of SDF 2.1 (starting at Page
3-17, 'Specifying Delay Values' in 'Delay Definition Entries').
If three rvalues are present which one applies is knowable at assignment time.
In Tristan's implementation's defense:
The number of rvalues in the rvalue_list can be one, two, three, six or twelve.
Note, however, that the amount of data you include in a delay definition entry
must be consistent with the analysis tool’s ability to model that kind of
delay. For example, if the modeling primitives of a particular tool can accept
only three delay values, perhaps rising, falling and “Z” transitions, you
should not attempt to annotate different values for 0→1 and Z→1 transitions or
for 1→Z and 0→Z transitions. It is recommended that in such situations
annotators combine the information given in some documented manner and issue a
warning.
This is a case of ghdl doing one thing while someone else does something else.
Who is right is a matter of market share. (And requires analysis of
implementation and use in the competition). "Note, however, that the amount of
data you include in a delay definition entry must be consistent with the
analysis tool’s ability to model that kind of delay" sort of implies Tristan
was right with that "must be consistent". We can't even sure the competing
implementation selects the right delay.
A success in the above described experiment would likely un-cover several more
cases needing patching for the same reason.
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
