Hi guys,

The provided testbench works; it has been tested on synopsys vcs, cadence
ncsim, and modelsim. These are the 3 leading simulators.
The core works; I have confirmed reports of over 50 companies using the
core in their designs; a few more if you add those companies using the
commercially available versions. And it works out of the box!!!
I added a makefile (for ncsim only) that runs the testbench.
Combining the core (in rtl), the testbench (in bench), the makefile (in
sim/bin), and the documentation (in doc) you should be able to get this
running. Ok admitted you need to understand the wishbone bus interface; so
download that spec too.

I heard complaints about the doc, people not being able to find the
testbench, people not being able to hook everything together.
To be honest, this indicates either a lack of knowledge of using IP cores
(which is fine, but then don't blame the core), or just a general lazyness
in searching opencores.

The testbench is self checking; this means it is not waveform oriented.
Forget about checking waveforms with your eyes. This might work for the
i2c interface but not for bigger IP cores. Instead the testbench initiates
transfers and automatically checks the core (i.e. the status of the i2c
bus and registers). Obviously the testbench does wiggle the sda and scl
lines ;)


Down to the stupid questions;
1) Did you run the provided testbench or are your running your own?
2) Did you create the open-drain outputs using the tri-state buffers as
described in the doc. Please don't tell me you don't understand the doc as
it provides a graphical representation and the actual code to implement
the buffers (both in vhdl and verilog).
3) Did you pull-up SDA and SCL in the testbench?

Some notes:
1) There is a typo in the VHDL code; scl_pad_i sda_pad_i 2) No idea why there's still a documentation folder. It should be removed.

Richard

I'm getting the same problem that DR is getting. SDA and SCL are not
toggling. Has anyone been able to get it to work or is this how the test
bench works? Richard has done a great job putting this together, I just
wish he would've included an explicit readme file and a simulation result
for reference.
Steve

1. The documentation is better than other documentation for IP's I have paid for. In fact, it's clear, concise and very useful. 2. The code works as advertised. It compiles perfectly, and runs out of the box. 3. I personally have used the code in 3 different tool sets with no issues. Tool issues? With all this apparent issues with the core, I think we should be thanking Richard for the code. Thanks Richard for a great core. Stan Hodge Honeywell Electronics and Lighting   -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of richard at herveille.net Sent: Tuesday, April 03, 2007 9:14 PM To: Discussion list about free open source IP cores Subject: Re: [oc] I2C Issue Hi guys, The provided testbench works; it has been tested on synopsys vcs, cadence ncsim, and modelsim. These are the 3 leading simulators. The core works; I have confirmed reports of over 50 companies using the core in their designs; a few more if you add those companies using the commercially available versions. And it works out of the box!!! I added a makefile (for ncsim only) that runs the testbench. Combining the core (in rtl), the testbench (in bench), the makefile (in sim/bin), and the documentation (in doc) you should be able to get this running. Ok admitted you need to understand the wishbone bus interface; so download that spec too. I heard complaints about the doc, people not being able to find the testbench, people not being able to hook everything together. To be honest, this indicates either a lack of knowledge of using IP cores (which is fine, but then don't blame the core), or just a general lazyness in searching opencores. The testbench is self checking; this means it is not waveform oriented. Forget about checking waveforms with your eyes. This might work for the i2c interface but not for bigger IP cores. Instead the testbench initiates transfers and automatically checks the core (i.e. the status of the i2c bus and registers). Obviously the testbench does wiggle the sda and scl lines ;) Down to the stupid questions; 1) Did you run the provided testbench or are your running your own? 2) Did you create the open-drain outputs using the tri-state buffers as described in the doc. Please don't tell me you don't understand the doc as it provides a graphical representation and the actual code to implement the buffers (both in vhdl and verilog). 3) Did you pull-up SDA and SCL in the testbench? Some notes: 1) There is a typo in the VHDL code; scl_pad_i _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

This is a newbie question but why would the waveform not represent the the test bench?--- On Tue 04/03, richard at herveille.net > wrote: From: [mailto: richard at herveille.net]To: cores at opencores.orgDate: Wed, 4 Apr 2007 03:13:37 +0200 (CEST)Subject: Re: [oc] I2C IssueHi guys,The provided testbench works; it has been tested on synopsys vcs, cadencencsim, and modelsim. These are the 3 leading simulators.The core works; I have confirmed reports of over 50 companies using thecore in their designs; a few more if you add those companies using thecommercially available versions. And it works out of the box!!!I added a makefile (for ncsim only) that runs the testbench.Combining the core (in rtl), the testbench (in bench), the makefile (insim/bin), and the documentation (in doc) you should be able to get thisrunning. Ok admitted you need to understand the wishbone bus interface; sodownload that spec too.I heard complaints about the doc, people not being able to find thetestbench, people not being able to hook everything together.To be honest, this indicates either a lack of knowledge of using IP cores(which is fine, but then don't blame the core), or just a general lazynessin searching opencores.The testbench is self checking; this means it is not waveform oriented.Forget about checking waveforms with your eyes. This might work for thei2c interface but not for bigger IP cores. Instead the testbench initiatestransfers and automatically checks the core (i.e. the status of the i2cbus and registers). Obviously the testbench does wiggle the sda and scllines ;)Down to the stupid questions;1) Did you run the provided testbench or are your running your own?2) Did you create the open-drain outputs using the tri-state buffers asdescribed in the doc. Please don't tell me you don't understand the doc asit provides a graphical representation and the actual code to implementthe buffers (both in vhdl and verilog).3) Did you pull-up SDA and SCL in the testbench?Some notes:1) There is a typo in the VHDL code; scl_pad_i I'm getting the same problem that DR is getting. SDA and SCL are not> toggling. Has anyone been able to get it to work or is this how the test> bench works? Richard has done a great job putting this together, I just> wish he would've included an explicit readme file and a simulation result> for reference.> Steve> _______________________________________________> _______________________________________________http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores>_______________________________________________http://www.opencores.org/mailman/listinfo/cores _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20070405/2bea2282/attachment.htm

A waveform generated from the testbench obviously represents the testbench. But what's the added value? A testbench that checks itself is much easier to modify, run, and verify than visually comparing waveforms. Testbenches without waveforms run an order of magnitude faster than those dumping waveforms and are portable between simulator platforms. This makes them the preferred method of verification. There are many signals in the core, which ones do you want to see? No matter what answer you provide, it's always the signal not listed that's the problem. Watching waveforms is nice if you're debugging a specific section of the code and you know where to look. But in a system with millions of nets it can be a nightmare. My personal approach is to write self checking testbenches. Initially this takes about 3times as much than writing a simple testbench and checking the waveforms. However in the end they always prove to be more cost efficient. Where cost is defined by flexibility, extensibility, portability, system run time, and system requirements. As an example the commercially available i2c master/slave core has a huge testbench. It runs for 20minutes on my compute server (believe me it's a very fast machine). With signal dump enabled (i.e. generating waveforms) it runs for an hour. The resulting signal database is huge. Now what signal did you want to compare??? I hope this explains ... Richard --- On Tue 04/03, richard at herveille.net > wrote:

Hi,
Please provide testbench for i2c master testing .i am not able to find it anywhere

Hi...i am a new user here. As per my knowledge this I2C works on 3.3V. So, do not use 5 V supply, use 3.3V. If it is directed from the board supplier you need level converter or multiplexer with 5V tolerant SDA and SCK. Make sure nothing gets over 3.3V to the data and clock pin.