See addendum at bottom.
On Jan 8, 2012, at 6:14 PM, David Koontz wrote:
>
> 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;
This is wrong see below.
> 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.
>
I got the model to work except for the change to the generic type and I get:
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
This included a new copy of X_BUFGMUX.vhd, the entity called X_BUFGMUX_X to
allow the component declaration to happen outside library simprim, the
component declaration added to test_timesim.vhd. I also changed the CELLTYPE
to match in the SDF file.
I also added some clock drivers to tb_test_timesim.vhd to allow the model to
complete. Without a clock running It's starved for events and just sits there
drawing cpu cycles. Perhaps GHDL could use a guard counter to notice the
simulation cycle isn't advancing when VITALizing.
I've included an archive of the vhd(l) files, the sdf file and a C-Shell script
(that can be converted to Steve Bourne's shell) for building and executing.
It requires access to the Xlilinx simprim library sources for 'other'
(vital95). I use the one from ISE 13.2 and the X_BUFGMUX.vhd I modified came
from ISE 9.1 (8.1 actually I believe). It was closet to useable of the two I
could find.
If you have rcs, you can use rcsdiff -r1.1 some.vhd or some.sdf to examine the
diferences. if you see the Icurrent version is greater tthan 1.2 you can use
rcsdiff -r1.2, .. -r1.3, etc. rcsdiff -u will give you something you can use
to patch with although you might need to change file names in the diff headers.
The attempts to play with the VitalDelayType amounted to nothing, which makes
sense in retrospect.
Any types generated are derived from the definition found in the SDF file (with
modified CELLTYPE):
(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))
// )
)
The SETUPHOLD statement being the one in question. Commenting out the the three
lines containing the TIMING CHECK with C++ style comments (shown added) should
remove the value? Not quite:
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: test_timesim.sdf:84:28: parse error
I found there is absolutely no way to remove the timing check from the SDF
file. From the SDF 2.1 spec:
Comments can be placed in SDF files using either “C” or “C++” styles.
“C”-style comments begin with /* and end with */. Nesting of “C”-style comments
is not permitted. The places in an SDF file where it is legal to put “C”-style
comments are not defined by this specification. Different annotators may have
different capabilities in this regard.
“C++”-style comments begin with // and continue until the end of the current
line (the next newline character). Annotators should ignore the double-slash
and any text after them on any line in the file.
The two paragraphs from the SDF specification seem to have been conflated.
It's legal to have restrictions on placement of C style comments (which aren't
support in GHDL) but not C++ style comments. "should ignore"
may not be strong enough.
Instead of beating my head against that rock, for the time being I'll pursue
the error message
ghdl:error: vital: unhandled generic type for generic
tsetup_s_i0_posedge_negedge
"vital: unhandled generic type for generic" only shows up in
grt-vital_annotate.adb (Thanks OS X, I can limit search to Ada files if Xcode
is limited, .adb and .ads are claimed by Xcode). It occurs in procedure
Sdf_Generic.
Turning on the Dump_Flag locally (by setting it True in Sdf_Generic,
recompiling):
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
generic: tpd_i_o 859 859 ? ? ? ? ? ? ? ? ? ?
celltype: x_buf
instance: ci_iff_imux
generic: tpd_i_o 1079 ? ? ? ? ? ? ? ? ? ? ?
celltype: x_buf
instance: cj_ibuf
generic: tpd_i_o 859 ? ? ? ? ? ? ? ? ? ? ?
celltype: x_buf
instance: cj_iff_imux
generic: tpd_i_o 1079 ? ? ? ? ? ? ? ? ? ? ?
celltype: x_buf
instance: clk_bufgp_ibufg
generic: tpd_i_o 859 ? ? ? ? ? ? ? ? ? ? ?
celltype: x_obuf
instance: co_obuf
generic: tpd_i_o 3714 ? ? ? ? ? ? ? ? ? ? ?
celltype: x_buf
instance: reset_ibuf
generic: tpd_i_o 859 ? ? ? ? ? ? ? ? ? ? ?
celltype: x_bufgmux_x
instance: clk_bufgp_bufg
generic: tpd_i0_o ? ? ? ? ? ? ? ? ? ? ? ?
generic: tpd_i1_o ? ? ? ? ? ? ? ? ? ? ? ?
generic: tsetup_s_i0_posedge_negedge 600
ghdl:error: test_timesim.sdf:77:60: setuphold and nochange not yet handled
(And an error declaration is fatal)
Line 77 in the SDF points to the SETUPHOLD (shown above as commented).
This is basically telling us there is no way to swallow this SDF file, in
particular when the offending CELL can't be modified or removed.
Contrast this with the original message:
ghdl:error: vital: unhandled generic type for generic
tsetup_s_i0_posedge_negedge
And between the two of them you could get a handle on what GHDL is complaining
about. There may be room for improvement in the reporting.
Removing the --sdf=uut=test_timesim.sdf (sdf file load) allows the simulation
to run, although I may have gotten the polarity of reset wrong.
The source for this other than non-modified primsim files are in an archive
test1.tar.gz in bug 9597 along wtih this text as annotation.
When you decompose build.csh note the path to the Xilinx simprim source code
needs to be set locally or files copied, etc.
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
