The I2C control core has been update before 4 weeks ago. It only update the verilog file "i2c_master_bit_ctrl.v", but it dose not update the VHDL one. I confused which one is correct.

Base on the revision 1.11, the behavior of these two RTL codes are already mismatch. Please see the file,

verilog/i2c_master_bit_ctrl.v: From line #217 to #218.
vhdl/i2c_master_bit_ctrl.vhd: From line #212 to #215.

For the revision 1.12, the verilog code is updated. Please see the file,

verilog/i2c_master_bit_ctrl.v: Update to the line #211 to #220.

After the update, the behavior of these two RTL codes are totally
different to generate the signal of clock enable. Any suggestion?

Kuoping

==
*revision 1.11: verilog/i2c_master_bit_ctrl.v: From line #217 to #218.

217: cnt 218: clk_en
*revision 1.11: vhdl/i2c_master_bit_ctrl.vhd: From line #212 to #215.

212: if (slave_wait = '0') then
213: cnt 214: end if;
215: clk_en
*revision 1.12: verilog/i2c_master_bit_ctrl.v: Update to the line #211 to #220.

207: else if ( ~|cnt || !ena)
208: begin
209: cnt 210: clk_en 211: end
212: else if (slave_wait)
213: begin
214: cnt 215: clk_en 216: end

The verilog code is the latest one. You're right, I forgot to update the VHDL version Richard -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Kuoping Hsu Sent: Thursday, October 05, 2006 10:48 AM To: cores at opencores.org Subject: [oc] which the RTL code of I2C core is corrected The I2C control core has been update before 4 weeks ago. It only update the verilog file "i2c_master_bit_ctrl.v", but it dose not update the VHDL one. I confused which one is correct. Base on the revision 1.11, the behavior of these two RTL codes are already mismatch. Please see the file, verilog/i2c_master_bit_ctrl.v: From line #217 to #218. vhdl/i2c_master_bit_ctrl.vhd: From line #212 to #215. For the revision 1.12, the verilog code is updated. Please see the file, verilog/i2c_master_bit_ctrl.v: Update to the line #211 to #220. After the update, the behavior of these two RTL codes are totally different to generate the signal of clock enable. Any suggestion? Kuoping == *revision 1.11: verilog/i2c_master_bit_ctrl.v: From line #217 to #218. 217: cnt http://www.opencores.org/mailman/listinfo/cores

Hi There are syntax errors in the latest VHDL code; two lines with "End If" are missing the terminating semicolons. M ----- Original Message ----- From: Richard Herveillerichard at h...> To: Date: Thu Oct 5 19:55:40 CEST 2006 Subject: [oc] which the RTL code of I2C core is corrected

Mark Murray wrote:

Richard, given the nature of the above error, can I assume that the latest VHDL version (rev 1.14) hasn't been tested at all? Not even in the testbench? I'm not complaining in any way, I'd just like to know the state of what I'm downloading. It's less work for me if I know that it has already been verified, otherwise I need to increase the coverage of my testbench. Thanks for all your work on this and numerous other cores! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

The i2c VHDL port is a translation of the verilog core, provided for the benefit of the VHDL community. The verilog core is fully tested. Any changes to the verilog port are backported to the VHDL version. The core is tested numerous times, though not as thorough as the verilog port. As the verilog port is the developer port, whereas the vhdl port is merely a translation. However the last changes were very trivial so I didn't check, which I obviously should have :p. It's fixed now. The code you download should be clean. Anyways it's always a good idea to thoroughly check whatever IP you receive. Richard -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Mark McDougall Sent: Wednesday, October 25, 2006 4:44 AM To: Discussion list about free open source IP cores Subject: Re: [oc] which the RTL code of I2C core is corrected Mark Murray wrote: Richard, given the nature of the above error, can I assume that the latest VHDL version (rev 1.14) hasn't been tested at all? Not even in the testbench? I'm not complaining in any way, I'd just like to know the state of what I'm downloading. It's less work for me if I know that it has already been verified, otherwise I need to increase the coverage of my testbench. Thanks for all your work on this and numerous other cores! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266 _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Richard Herveille wrote:

Can't I just put your email and phone number in the code??? ;) Speaking of testing, I've run into a problem simulating the VHDL core in my testbench and am wondering why the supplied testbench doesn't have the same problem (I haven't run it myself as yet)!?! Using pullups in the top level (verilog) module, the core fails in i2c_master_bit_ctrl.vhd... gen_dout: process(clk) begin if (clk'event and clk = '1') then if (sSCL = '1' and dSCL = '0') then dout http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

Richard Herveille wrote:


receive.

Can't I just put your email and phone number in the code??? ;)


[rih] :D, sure at $100 per hour for support :p


Speaking of testing, I've run into a problem simulating the VHDL core in
my testbench and am wondering why the supplied testbench doesn't have
the same problem (I haven't run it myself as yet)!?!

[rih] This is a general problem with VHDL (actually with std_logic).
You could try to change the line from
if (sSCL = '1' and dSCL = '0') then
to
if ((sSCL = '1' or sSCL = 'H') and dSCL = '0') then

Or use a conversion script like the one you described.
The code is clean, this is a simulation problem.

Richard

Mark McDougall wrote:



A more compact/standard solution is to use a strength stripper from
std_logic_1164:

sSCL sSDA
This converts a std_(u)logic value to 'X', '0', or '1', forcing L/H to
0/1, and preserving X's.

It's interesting that you have an 'H', though - presumably this is an
external signal in the testbench? If not, how does an 'H' get into the
device?

OT, but I've been watching this list for a couple of years now. I'm
sorry to have to say it, but you're going to have to create a review
procedure if you want higher-quality (read: approaching 'almost
acceptable') IP. I'm not commenting on this core in particular; I've
never looked at it.

Richard Tierney wrote:



Ah yes, thank you!!!

'H' is generated by the pullup in the top level (verilog) module of the testbench, and propogated down to the I2C core via inout ports in the hierarchy of the (VHDL) design. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall wrote:



Normal practice (as I expect you already know or have just worked out!)
is never to let anything except 0, 1, or X into the chip. This
complicates the code and may cause simulation mismatches between the RTL
and the netlist. You need to do this at the input buffer. If you look at
the Xilinx models for their input buffer (in unisim_VITAL.vhd), for
example, you'll find that it's basically:

O
This problem doesn't normally come up in the ASIC world, because you
instantiate all I/O buffers. However, if you're just writing behavioural
code and relying on the tool to infer I/O buffers, then it's a good idea
to put this code on your inputs or IOs at the top level.

[isn't it a bit late in your part of the world?!]

RT

All true.
Keep in mind this is an IP and as thus does not include any IO buffers.
I need to check for '1' in the core.
However the i2c bus requires external pull-ups.
It's the tesbench that should take care of the conversion from 'H' to '1'.
Using the many techniques discussed here.

Richard


Normal practice (as I expect you already know or have just worked out!) is never to let anything except 0, 1, or X into the chip. This complicates the code and may cause simulation mismatches between the RTL and the netlist. You need to do this at the input buffer. If you look at the Xilinx models for their input buffer (in unisim_VITAL.vhd), for example, you'll find that it's basically: O http://www.opencores.org/mailman/listinfo/cores