1

I am using Cadence's Ethernet eVC wherein the agent's monitor is tapped at the following signals:

.            ____________                    _____
.clk   _____|            |__________________|
.      ________ _______ ________________ _________
.data  __0a____X___07__X_______0b_______X_________
.                      ^ ^

It samples data at the rising and falling edges of the clock. In the example above, the data 0x07 is garbage data, and the valid values are 0xa (clk rise) and 0xb (clk fall). However, the monitor is sampling (for clk fall) 0x7!

I'm suspecting this is a Specman-simulator synchronization issue. How can this be resolved if it is?

  • Simulator - IES 13.10

  • irun 13.10 options - (I'll include here only those which I think could be relevant to the issue, plus those which I've no idea yet what their purpose is) 

    -nomxindr  
-vhdlsync  
+neg_tchk  
-nontcglitch  
+transport_path_delays  
-notimezeroasrtmsg  
-pli_export  
-snstubelab

  • Languages - VHDL (top testbench), Verilog (DUT), Specman (virtual sequence, Enet and OCP eVCs)

  • Time between 0x07 (left ^ in the waveform above) and falling edge of clock (right ^) = 0.098ns

One colleague suggested using -sntimescale, but I still can't imagine how that is causing/would resolve the issue. Any of these search strings were not showing helpful hints, even those articles from Cadence: "specman tick synchronization delta delay timescale precision"

Qiu
  • 5,651
  • 10
  • 49
  • 56
renvill
  • 143
  • 1
  • 10
  • Make sure the timescales and precisions are the same for your VHDL, Verilog, e, etc.? `-sntimescale` could help, however I believe this option is only for specman e; you may need to find the equivalent compiler option for VHDL and Verilog. Most Verilog/SystemVerilog simulators default as 1ns/1ns, so 0.098ns will be rounded to 0. There could also be timing delays in the testbench/DUT or possible blocking/non-blocking assignment misuse. – Greg Jul 16 '15 at 21:20
  • How are your Specman clock events created? Are they connected to that very same clock net? – Ross Rogers Jul 16 '15 at 22:47
  • @RossRogers Since it's the Enet eVC that's collecting the packet information, I presume it's also using `@driver.clock` sampling event. This clock is that same clock in the waveform. – renvill Jul 18 '15 at 02:22
  • @Greg I've yet to try this. Right now I just delayed the clock to allow the eVC monitor to 'correctly' sample the data. – renvill Jul 18 '15 at 02:26
  • I want to understand how Specman can be unsynchronized with the simulator. Are there simulator commands that I can invoke or are there Specman field values that I can display to prove this issue? Or any reference material you can recommend that shows the effects of having differing timescales and precisions in HDL and Specman? – renvill Jul 18 '15 at 05:11
  • Renvill, You can query the simulator interface _from_ specman using TCL code and method `simulator_command`. Using this, in your callback of `@driver.clock`, ask the simulator what time it has. This is the easiest way to figure out a synchronization issue. Print out what Specman thinks is the time and print out what the simulator thinks is the time. – Ross Rogers Jul 18 '15 at 18:30

1 Answers1

2

This could be indeed an issue of timescale. There is a comprehensive cookbook talking about deugging specman simulator interface synchronization issues. please take a look here.

To check what is the timescale used in your simulation, you can add -print_hdl_precision option to irun to print the precision for the VHDL hierarchy. For Verilog, it will be printed automatically in case it is set either in the code or via irun options. the information will be printed during elaboration.

To check the timescale used by Specman, you can issue the following command from Specman prompt:
SN> print get_timescale()

Another option to try (only after the timescale option doesn't help) is to remove the -vhdlsync flag. Indeed in most of the mixed environments you should add this flag. But there are rare cases in which the environment works better without it. If you try removing this flag, just remember to re-elaborate.

If you don't find the solution for your problem in the cookbook, deeper investigation should be done. for example, how does specman samples the signal. is it a simple_port, event_port, tick access, etc.. also some trace and probe commands could be helpful. In such case, I suggest to contact Cadence support.

Good Luck!
Semadar

Semadar
  • 105
  • 6
  • I've updated the link. but you can also go to Cadence Online Support (COS) and search, as the link may change in the future again. – Semadar Dec 28 '17 at 09:49