Verilog inout, I2C

Hello, I'm trying to create an I2C master module in Verilog. I've never
been able to successfully use inout's in Verilog and I'm still unsure why.
I compiled my code and ran a test bench and I noticed the signals were at
least changing; that is, the inout's seemed to be toggling.

After this (although I still don't know if the module is conforming to the
I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
board using the switches as inputs as I require an active high enable high
to begin transmission on the bus. When I loaded my code, compiled it again,
and installed it on the board I hooked up my logic analyzer and was excited
to see... something: nothing.

I'm confused why nothing at all showed up on my physical device while my
test benches were producing logical values. I'm posting here for any advice
from more experienced people. I've been trying to create this module for a
while now and finally started work on it but am sort of at a loss as to
where to begin my trouble shooting since I recently discovered how to
create test benches in the first place; before that I would just load it
onto my hardware lots of times.

These are the only lines that deal with the inout-ness of the pins:

inout sda;
	assign sda = (ena_sda)?sda_bit:`HIGH;
	assign sdaDataIn = (ena_sda)?`HIGH:sda;
	
inout scl;
	assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;

LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency
for I2C transmission. Is this right the use of bidirectional pins or am I
way off? If anyone wants more of the code just contact me; I don't want to
flood this post with irrelevant information. It's worth noting that in the
test-bench ena_scl and ena_sda were both working as expected which, in
turn, made sda and scl show up correctly on the simulation.

During my re-reading of this post I realized my physical test pin
assignments had no connection to the I2C bus which meant there was no
resistor to VCC on either of the lines. I fixed that; still have the exact
same output!

Thanks everyone.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>Hello, I'm trying to create an I2C master module in Verilog. I've never
>been able to successfully use inout's in Verilog and I'm still unsure
why.
>I compiled my code and ran a test bench and I noticed the signals were at
>least changing; that is, the inout's seemed to be toggling.
>
>After this (although I still don't know if the module is conforming to
the
>I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
>board using the switches as inputs as I require an active high enable
high
>to begin transmission on the bus. When I loaded my code, compiled it
again,
>and installed it on the board I hooked up my logic analyzer and was
excited
>to see... something: nothing.
>
>I'm confused why nothing at all showed up on my physical device while my
>test benches were producing logical values. I'm posting here for any
advice
>from more experienced people. I've been trying to create this module for
a
>while now and finally started work on it but am sort of at a loss as to
>where to begin my trouble shooting since I recently discovered how to
>create test benches in the first place; before that I would just load it
>onto my hardware lots of times.
>
>These are the only lines that deal with the inout-ness of the pins:
>
>inout sda;
>	assign sda = (ena_sda)?sda_bit:`HIGH;
>	assign sdaDataIn = (ena_sda)?`HIGH:sda;
>	
>inout scl;
>	assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>
>LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency
>for I2C transmission. Is this right the use of bidirectional pins or am I
>way off? If anyone wants more of the code just contact me; I don't want
to
>flood this post with irrelevant information. It's worth noting that in
the
>test-bench ena_scl and ena_sda were both working as expected which, in
>turn, made sda and scl show up correctly on the simulation.
>
>During my re-reading of this post I realized my physical test pin
>assignments had no connection to the I2C bus which meant there was no
>resistor to VCC on either of the lines. I fixed that; still have the
exact
>same output!
>
>Thanks everyone.
>
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

Not sure if you have done this but I usually in my designs create a
seperate module with the IO buffers instantiated. So in my I2C design for a
Xilinx FPGA I have the following.

// SDA IO Buffer
IOBUF U_sda(
  .I  (1'b0), 
  .IO (sda_io), 
  .O  (sda_rd), 
  .T  (sda_wr));   

// SCL IO Buffer
IOBUF U_scl(
  .I  (1'b0), 
  .IO (scl_io), 
  .O  (scl_rd), 
  .T  (scl_wr));  

I then know that the buffers are correctly done. If your buffers are ok and
you have external pullups then it should work. It may be worth if you have
something like Chipscope to have a look and see what is going on inside the
chip.

Jon 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Dec 28, 9:03=A0am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> >Hello, I'm trying to create an I2C master module in Verilog. I've never
> >been able to successfully use inout's in Verilog and I'm still unsure
> why.
> >I compiled my code and ran a test bench and I noticed the signals were a=
t
> >least changing; that is, the inout's seemed to be toggling.
>
> >After this (although I still don't know if the module is conforming to
> the
> >I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
> >board using the switches as inputs as I require an active high enable
> high
> >to begin transmission on the bus. When I loaded my code, compiled it
> again,
> >and installed it on the board I hooked up my logic analyzer and was
> excited
> >to see... something: nothing.
>
> >I'm confused why nothing at all showed up on my physical device while my
> >test benches were producing logical values. I'm posting here for any
> advice
> >from more experienced people. I've been trying to create this module for
> a
> >while now and finally started work on it but am sort of at a loss as to
> >where to begin my trouble shooting since I recently discovered how to
> >create test benches in the first place; before that I would just load it
> >onto my hardware lots of times.
>
> >These are the only lines that deal with the inout-ness of the pins:
>
> >inout sda;
> > =A0 =A0assign sda =3D (ena_sda)?sda_bit:`HIGH;
> > =A0 =A0assign sdaDataIn =3D (ena_sda)?`HIGH:sda;
>
> >inout scl;
> > =A0 =A0assign scl =3D (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>
> >LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency
> >for I2C transmission. Is this right the use of bidirectional pins or am =
I
> >way off? If anyone wants more of the code just contact me; I don't want
> to
> >flood this post with irrelevant information. It's worth noting that in
> the
> >test-bench ena_scl and ena_sda were both working as expected which, in
> >turn, made sda and scl show up correctly on the simulation.
>
> >During my re-reading of this post I realized my physical test pin
> >assignments had no connection to the I2C bus which meant there was no
> >resistor to VCC on either of the lines. I fixed that; still have the
> exact
> >same output!
>
> >Thanks everyone.
>
> >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0
> >Posted throughhttp://www.FPGARelated.com
>
> Not sure if you have done this but I usually in my designs create a
> seperate module with the IO buffers instantiated. So in my I2C design for=
 a
> Xilinx FPGA I have the following.
>
> // SDA IO Buffer
> IOBUF U_sda(
> =A0 .I =A0(1'b0),
> =A0 .IO (sda_io),
> =A0 .O =A0(sda_rd),
> =A0 .T =A0(sda_wr)); =A0
>
> // SCL IO Buffer
> IOBUF U_scl(
> =A0 .I =A0(1'b0),
> =A0 .IO (scl_io),
> =A0 .O =A0(scl_rd),
> =A0 .T =A0(scl_wr)); =A0
>
> I then know that the buffers are correctly done. If your buffers are ok a=
nd
> you have external pullups then it should work. It may be worth if you hav=
e
> something like Chipscope to have a look and see what is going on inside t=
he
> chip.

There's absolutely no reason to instantiate these sorts of buffers.
The usual assignment statements work, and have worked for many years.
All the instantiations do is make your code harder to understand and
not portable.

-a

>On Dec 28, 9:03=A0am, "maxascent"
><maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
>> >Hello, I'm trying to create an I2C master module in Verilog. I've
never
>> >been able to successfully use inout's in Verilog and I'm still unsure
>> why.
>> >I compiled my code and ran a test bench and I noticed the signals were
a=
>t
>> >least changing; that is, the inout's seemed to be toggling.
>>
>> >After this (although I still don't know if the module is conforming to
>> the
>> >I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
>> >board using the switches as inputs as I require an active high enable
>> high
>> >to begin transmission on the bus. When I loaded my code, compiled it
>> again,
>> >and installed it on the board I hooked up my logic analyzer and was
>> excited
>> >to see... something: nothing.
>>
>> >I'm confused why nothing at all showed up on my physical device while
my
>> >test benches were producing logical values. I'm posting here for any
>> advice
>> >from more experienced people. I've been trying to create this module
for
>> a
>> >while now and finally started work on it but am sort of at a loss as
to
>> >where to begin my trouble shooting since I recently discovered how to
>> >create test benches in the first place; before that I would just load
it
>> >onto my hardware lots of times.
>>
>> >These are the only lines that deal with the inout-ness of the pins:
>>
>> >inout sda;
>> > =A0 =A0assign sda =3D (ena_sda)?sda_bit:`HIGH;
>> > =A0 =A0assign sdaDataIn =3D (ena_sda)?`HIGH:sda;
>>
>> >inout scl;
>> > =A0 =A0assign scl =3D (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>>
>> >LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the
frequency
>> >for I2C transmission. Is this right the use of bidirectional pins or am
=
>I
>> >way off? If anyone wants more of the code just contact me; I don't
want
>> to
>> >flood this post with irrelevant information. It's worth noting that in
>> the
>> >test-bench ena_scl and ena_sda were both working as expected which, in
>> >turn, made sda and scl show up correctly on the simulation.
>>
>> >During my re-reading of this post I realized my physical test pin
>> >assignments had no connection to the I2C bus which meant there was no
>> >resistor to VCC on either of the lines. I fixed that; still have the
>> exact
>> >same output!
>>
>> >Thanks everyone.
>>
>> >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0
>> >Posted throughhttp://www.FPGARelated.com
>>
>> Not sure if you have done this but I usually in my designs create a
>> seperate module with the IO buffers instantiated. So in my I2C design
for=
> a
>> Xilinx FPGA I have the following.
>>
>> // SDA IO Buffer
>> IOBUF U_sda(
>> =A0 .I =A0(1'b0),
>> =A0 .IO (sda_io),
>> =A0 .O =A0(sda_rd),
>> =A0 .T =A0(sda_wr)); =A0
>>
>> // SCL IO Buffer
>> IOBUF U_scl(
>> =A0 .I =A0(1'b0),
>> =A0 .IO (scl_io),
>> =A0 .O =A0(scl_rd),
>> =A0 .T =A0(scl_wr)); =A0
>>
>> I then know that the buffers are correctly done. If your buffers are ok
a=
>nd
>> you have external pullups then it should work. It may be worth if you
hav=
>e
>> something like Chipscope to have a look and see what is going on inside
t=
>he
>> chip.
>
>There's absolutely no reason to instantiate these sorts of buffers.
>The usual assignment statements work, and have worked for many years.
>All the instantiations do is make your code harder to understand and
>not portable.
>
>-a
>

I dont see how it can be harder to understand unless you have no idea how
an IO buffer works and if thats the case you shouldnt be doing FPGA design.
All the Xilinx devices I have used use the same syntax for the common
buffers and so the code should be fine across a wide number of devices.	  

					
---------------------------------------		
Posted through http://www.FPGARelated.com

>Hello, I'm trying to create an I2C master module in Verilog. 
  [snip]
>These are the only lines that deal with the inout-ness of the pins:
>
>inout sda;
>	assign sda = (ena_sda)?sda_bit:`HIGH;
>	assign sdaDataIn = (ena_sda)?`HIGH:sda;
>	
>inout scl;
>	assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>
  [snip]
>

  assign sda       =  (sda_bit == 0) ? 1'b0 : 1'bz;
  assign sdaDataIn = sda;

Only drive the signal low, tri-state IOBUF.  This assumes sda is the IOBUF
(top-level port) and sda_bit is the internal sdaDataOut signal.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>> On Dec 28, 9:03=A0am, "maxascent" wrote:

> I dont see how it can be harder to understand unless you have no idea how
> an IO buffer works and if thats the case you shouldnt be doing FPGA design.

What if I am using an Altera device?
Your scheme does not work at all.
Andy's works either way.

   -- Mike Treseler

>
>>> On Dec 28, 9:03=A0am, "maxascent" wrote:
>
>> I dont see how it can be harder to understand unless you have no idea
how
>> an IO buffer works and if thats the case you shouldnt be doing FPGA
design.
>
>What if I am using an Altera device?
>Your scheme does not work at all.
>Andy's works either way.
>
>   -- Mike Treseler
>

To be honest I dont think you can create IP that is totally vender neutral
as they all have different ways of doing things. I accept for a simple IO
buffer you could infer rather that instantiate but some things would be
much harder to infer.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote in message 
news:F6WdnekcJseCAYDQnZ2dnUVZ_qidnZ2d@giganews.com...
> >
>>>> On Dec 28, 9:03=A0am, "maxascent" wrote:
>>
>>> I dont see how it can be harder to understand unless you have no idea
> how
>>> an IO buffer works and if thats the case you shouldnt be doing FPGA
> design.
>>
>>What if I am using an Altera device?
>>Your scheme does not work at all.
>>Andy's works either way.
>>
>>   -- Mike Treseler
>>
>
> To be honest I dont think you can create IP that is totally vender neutral
> as they all have different ways of doing things. I accept for a simple IO
> buffer you could infer rather that instantiate but some things would be
> much harder to infer.
>

Kind of defeats the object of an HDL then. Code portability was always 
touted as *THE* reason to use HDL. Without that I fail to see any advantage 
at all over a hierarchical graphical structure with embedded code - even 
using a schematic with vendor provided megawizards.

Phil 

>
>"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote in
message 
>news:F6WdnekcJseCAYDQnZ2dnUVZ_qidnZ2d@giganews.com...
>> >
>>>>> On Dec 28, 9:03=A0am, "maxascent" wrote:
>>>
>>>> I dont see how it can be harder to understand unless you have no idea
>> how
>>>> an IO buffer works and if thats the case you shouldnt be doing FPGA
>> design.
>>>
>>>What if I am using an Altera device?
>>>Your scheme does not work at all.
>>>Andy's works either way.
>>>
>>>   -- Mike Treseler
>>>
>>
>> To be honest I dont think you can create IP that is totally vender
neutral
>> as they all have different ways of doing things. I accept for a simple
IO
>> buffer you could infer rather that instantiate but some things would be
>> much harder to infer.
>>
>
>Kind of defeats the object of an HDL then. Code portability was always 
>touted as *THE* reason to use HDL. Without that I fail to see any
advantage 
>at all over a hierarchical graphical structure with embedded code - even 
>using a schematic with vendor provided megawizards.
>
>Phil 
>
>
>

I guess the problem is that the fpga vendors over the years have started
putting more complex hard IP into their devices which have to be
instantiated. Personally I try and avoid using Coregen as much as possible
as I dont think it gives the best implementation of things like FIFOs and
memories, and don't even get me started on MIG. 

Jon 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 12/31/2010 1:02 AM, maxascent wrote:
>>
>>>> On Dec 28, 9:03=A0am, "maxascent" wrote:
>>
>>> I dont see how it can be harder to understand unless you have no idea
> how
>>> an IO buffer works and if thats the case you shouldnt be doing FPGA
> design.
>>
>> What if I am using an Altera device?
>> Your scheme does not work at all.
>> Andy's works either way.
>>
>>    -- Mike Treseler
>>
>
> To be honest I dont think you can create IP that is totally vender neutral
> as they all have different ways of doing things.

Sure. The pin numbers will be different, but the io description
can be generic.

> I accept for a simple IO
> buffer you could infer rather that instantiate but some things would be
> much harder to infer.

Two things. PLLs and asynchronous block ram.

      -- Mike Treseler