• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. running 2 cross dependancy tests:

Stats

  • Locked Locked
  • Replies 7
  • Subscribers 64
  • Views 14570
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

running 2 cross dependancy tests:

archive
archive over 17 years ago

hello, i'd like to make an inout file interface between 2 dut's that feeding each other with data (to imitate the operation of socket). therefore, each dut test process reads data from one file and writes data to another, whereas the other dut, does the same only with opposite files. my question is whether specman can deal reading and writing to/from the same file on the same time without causing deadlock. should i use some sort of mutex to avoid the situation when one dut test process open a file for reading, but there's nothing to read, while the other process cannot write data to this file since it's already opened for reading by another process. perhaps you have a better solution without using files ? thanks, Zohar


Originally posted in cdnusers.org by zcabeli11
  • Cancel
  • archive
    archive over 17 years ago

    Hi Zohar,

    Can you give a few more details about what you need to achieve?

    - What is the physical interface (e.g. data-bus/Ethernet/USB etc.) between these two DUTs?

    - What type of data is exchanged on this interface (e.g. data read/write transactions or data-packets)?

    - How is your simulation set up? Are the DUT models in HDL or SystemC or e? What is the implementation of the "dut test process" for each DUT? An HDL or SystemC process? A TCM in e?

    Regards,
    Dean


    Originally posted in cdnusers.org by ddmello
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 17 years ago

    - What is the physical interface (e.g. data-bus/Ethernet/USB etc.) between these two DUTs?

    A: my file interface is simulating data-bus

    - What type of data is exchanged on this interface (e.g. data read/write transactions or data-packets)?

    A: data RW transtactions (bus length is 40bits, and i split it to 4 data lines length 10 bits each)

    - How is your simulation set up? Are the DUT models in HDL or SystemC or e? What is the implementation of the "dut test process" for each DUT? An HDL or SystemC process? A TCM in e?

    A: i'm working on specman (e) environment, and that's the impementation of each dut test process.


    i'd like to denote that both dut test processes are running seperately on the same time (not necessarily on the same machine) and the file is the only connection between them. i'm wondering if there's a better solution than my current usage of files.

    i hope i manage to clarify things ...
    thanks for the help !!!
    Zohar


    Originally posted in cdnusers.org by zcabeli11
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 17 years ago

    Unfortunately I cannot share the code but we did something like what you need using Unix sockets.  See the following paper:

    http://www.dvclub.org/images/Presentations/Arthur_Q207.pdf

    This page: http://www.sutherland-hdl.com/pli_book_examples.html
    has a link to "David Robert's Socket Example" which is a good starting point.

    Enjoy,
    /Ed


    Originally posted in cdnusers.org by earthur
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 17 years ago

    Hello again,

    thank you very much for posting this valuable link. it's pretty relevant to me and i'm currently trying to use it in my objective.
    however, this code is simulating socket between a verilog application and C program, and i need socket between both verilog programs.

    furthermore, i'd prefer that my socket will run under specman environment since i right now i'm running my socket from 2 different speman tests, each one is responsible for another DUT in IO operations with the other DUT, and generating other requested data. this socket impemented in C code ( and i'm not sure if it's possible to combine it with specman) and i need to run it someway in the background, and make it transparent to the running DUT's, so there won't be any synchronization problems...

    if you know to integrate this C code with my current available test, i'd be happy to know How.

    thanks again,
    Zohar


    Originally posted in cdnusers.org by zcabeli11
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 17 years ago

    Zohar,

    See Chapter 17 of the Specman Usage manual "Co-Verification Link" and see the examples in $SPECMAN_HOME/examples/cvl.
    This might be just what you're looking for.

    /Ed


    Originally posted in cdnusers.org by earthur
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 17 years ago

    i've been looking at Chepter 17, but unfortunately it doesn't contain any information about how to make Co-verification between 2 duts that are both written in verilog, and running with different specman processes. the question is whether i can use the Co-verification specman interface on both sides (and not specman / C as it shown in the manual) ?

    thanks,


    Originally posted in cdnusers.org by zcabeli11
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 17 years ago

    I'd take the Specman example $SPECMAN_HOME/examples/cvl/verilog|qvh/xor and try running it.
    Then I'd modify it and replace xor_driver.c with a Specman version and see if that works....Shouldn't
    take more than half an afternoon.

    /Ed


    Originally posted in cdnusers.org by earthur
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information