On Jan 6, 2012, at 12:17 PM, Walter F.J. Mueller wrote:

>  on ghdl-discuss in July 2007. Unfortunately all written there still
>  holds, one gets an error like
> 
>    tb_x:error: x_tsim.sdf:9:16: ':' (colon) expected
> 
>  and ghdl aborts. ghdl doesn't accept the sdf files generated by the ISE
>  tool chain.

I take it this was you?  bug #9597 https://gna.org/bugs/?9597 

Your 2007 post

works also if sdf annotation isn't enabled. If ghdl is started with
the appropriate --sdf qualifier, however, one gets the error

  tb_x:error: x_tsim.sdf:9:16: ':' (colon) expected

Apparently ghdl doesn't like the two lines

      (VOLTAGE 1.14)
      (TEMPERATURE 85)

If they are commented out, one gets

  tb_x:error: x.sdf:12:12: bad instance or celltype mistmatch

While the bug


% bin/tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us 
--wave=simu/simu_tb_test_timesim.ghw 
bin/tbx_test:error: test_timesim.sdf:14:12: bad instance or celltype mistmatch


Your original message shows an SDF file with only a single voltage and 
temperature case.  The reported bug shows three cases (and no complaints about 
a lack of colon).

There isn't anything apparently wrong with the test case sdf file, and nothing 
significant in the differences between the sdf 2.1 specification (used by 
Tristan originally) and sdf 3.0.

I take it the captured simulation model is in bin and named tbx_test?

UUT given as PATH is the TOP of the compiled model or is it?

Looking at test_arch of test we only get an unlabeled process statement while 
Structure of test (the PAR model) has the labels ci_IBUF, ci_IFF_IMUX,  
cj_IBUF,  cj_IFF_IMUX,  clk_BUFGP_IBUFG, co_OBUF, reset_IBUF, clk_BUFGP_BUFG, 
clk_BUFGP_BUFG_SINV,  clk_BUFGP_BUFG_I0_USED, Mxor_co_xor0000_Result1, 
co_OUTPUT_OFF_O1INV, co_OUTPUT_OFF_OSR_USED, co_OUTPUT_OFF_OMUX, 
co_OUTPUT_OTCLK1INV, co_0,   GLOBAL_LOGIC1_VCC (no timing), 
NlwBlock_test_GND (no timing),  NlwBlock_test_VCC (no timing),  NlwBlockROC 
(not involved), NlwBlockTOC (not involved).

We look in tb_test_timesim.vhd (TBX_ARCH of TBX_test) and we find 

    UUT : test
      port map (
        clk => clk,
        ci => ci,
        cj => cj,
        co => co,
        reset => reset
      );
In other words by default the last compiled architecture of test will be used.  
We have two, one test_arch has no labels matching the sdf file, the other 
Structure having labels matching and Cell types matching - which is what the 
error is complaining about.

This particular test case looks intended for SDF 95  (primitive/other instead 
of primitive/mti). Any testing effort we'lll stick with that.

setenv SIMPRIMS ~/Desktop/Xilinx/Xilinx/13.2/ISE_DS/ISE/vhdl/src/simprims
setenv OTHER $SIMPRIMS/primitive/other

ghdl -a --work=simprim $SIMPRIMS/simprim_Vcomponents.vhd
ghdl -a --work=simprim $SIMPRIMS/simprim_Vpackage.vhd
ghdl -a --work=simprim $OTHER/X_BUF.vhd
ghdl -a --work=simprim $OTHER/X_OBUF.vhd
ghdl -a --work=simprim $OTHER/X_BUFGMUX.vhd

Extra ordinary vital messages:

.../X_BUFGMUX.vhd:47:7: clock port name of 'ticd' VITAL generic must not appear 
here
.../X_BUFGMUX.vhd:48:7: clock port name of 'ticd' VITAL generic must not appear 
here
.../X_BUFGMUX.vhd:74:7: clock port name of 'ticd' VITAL generic must not appear 
here
.../X_BUFGMUX.vhd:75:7: clock port name of 'ticd' VITAL generic must not appear 
here

ghdl -a --work=simprim $OTHER/X_INV.vhd
ghdl -a --work=simprim $OTHER/X_LUT4.vhd
ghdl -a --work=simprim $OTHER/X_SFF.vhd
ghdl -a --work=simprim $OTHER/X_ONE.vhd
ghdl -a --work=simprim $OTHER/X_ZERO.vhd
ghdl -a --work=simprim $OTHER/X_ROC.vhd
ghdl -a --work=simprim $OTHER/X_TOC.vhd


ghdl -a test_timesim.vhd
ghdl -a tb_test_timesim.vhd


david_koontz@Macbook: ghdl -r tbx_test --sdf=uut=test_timesim.sdf 
--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))
ghdl:error: test_timesim.sdf:72:29: could not annotate generic tpd_i0_o

Oops!  And this is the only one with a clock propagation delay.  Looks like 
VITAL checking needs to be disabled analyzing it.

So far there are two points to make:

First,

% bin/tbx_test --sdf=uut=test_timesim.sdf --stop-time=500us 
--wave=simu/simu_tb_test_timesim.ghw 
bin/tbx_test:error: test_timesim.sdf:14:12: bad instance or celltype mistmatch

seems to be caused by analysis order of entity test architecture test_arch and 
architecture Structure in the original bug report.  In this case the only 
complaint was for the only timing value for an unbound component.

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).

From the header of X_BUFGMUX.vhd:

-- Revision:
--    03/23/04 - Initial version.
--    06/27/05 - CR # 200995 -- Removed Extra Timing Checks
--    01/11/06 - CR # 218698 -- Removed output initialization
--    01/11/08 - Add CLK_SEL_TYPE attribute.
--    05/20/08 - Recoding same as verilog model. (CR467336)
--             - Remove GSR Vital (CR;444306)
--     2/19/09 - Add initial to I0, I1, q0_t and q1_t (507901)
--    05/11/09 - Add period check (CR521102)
--    11/23/09 - Change Q to 0 instead of L (CR538513)
-- End Revision

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.


As far as the bad instance or cell type, if you simply tell ghdl to analyze 
*.vhd in the current working directory tb_test_timesim.vhd comes before 
test.vhd, which says you bound to the default architecture ( test_arch ) 
instead of ( Structure ).  Because you're supplying two entities with the same 
name it's something you have to cure with analysis order or not analyze the 
wrong one.

david_koontz@Macbook: ghdl -a test.vhd
david_koontz@Macbook: ghdl -a tb_test_timesim.vhd   # tbx_test, analysis order

david_koontz@Macbook: 
david_koontz@Macbook: ghdl -r tbx_test --sdf=uut=test_timesim.sdf 
--stop-time=500us --wave=simu_tb_test_timesim.ghw
ghdl:error: test_timesim.sdf:13:21: cannot find instance

replicates the original message because test.vhd, entity test, architecture 
test_arch were analyzed after test_timesim.vhd, entity test architecture 
Structure, the entity test and architecture test_arch replacing the previous 
entity test and architecture Structure.

There's no sign of any status change on bug 9597, I'd imagine if Tristan looked 
at it he'd have noticed the same thing.  So far it's not a bug, it's a feature.

Note: 

  ghdl:error: test_timesim.sdf:13:21: cannot find instance  

doesn't match:

  bin/tbx_test:error: test_timesim.sdf:14:12: bad instance or celltype mistmatch

I'd imagine Tristan actually looked at the bug even if he didn't close it,  He 
did improve error reporting.


_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss

Reply via email to