Closed lighteningfingers closed 6 years ago
You won't have any issue with DPI models, we are not using them for now. You may see one of them in the sources (dev_dpi) but it is actually not used, we'll remove it soon. We are planning to integrate some DPI models in the future but this will be used only for optional peripherals like camera, so by default the platform will still be usable without any DPI model. The main reason why we use DPI models for such peripheral models is that we need some C/C++ libraries such as ImageMagick to open the input stream to support a wide range of formats as the target is application development, not verification. Another reason is that it makes the model usable with any platform.
in the testbench harness, at present the interface definitions for I2S CPI GPIO JTAG
which appear under the comment /DPI interfaces /
.... are not currently "ifdef'd" out, inclusion of dev_dpi.sv (where these interfaces are defined) should not be needed if DPI isn't to be used.
All these definitions are related to dev_dpi which is inactive as the platform is always launched with ENABLE_DEV_DPI=0. Let me know if you have any issue with this code, I can remove it, it is not used anymore.
is ./vectors/stim.txt generated by the SDK output.
I've yet to build the SDK, is it possible to supply a "hello world" stim.txt so I can prove the harness build
@haugoug
I'm going to attempt to get the top level harness included to run in the latest version of Cadence Incisive. Are there any particular DPI specific issues related to the supported Questasim setup that I need to take care of in the CDN tool chain (for example Questastim specific support code that is relied upon). I have some previous experience with both DPI and VPI from within the CDN tool chain so should make some rapid progress.....