Verilog inout, I2C

A

ASIC

Guest
Hello, I'm trying to create an I2C master module in Verilog. I've neve
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
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 th
I2C bus protocol: baby steps) I decided to try it on my Altera DE2-11
board using the switches as inputs as I require an active high enable hig
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 excite
to see... something: nothing.

I'm confused why nothing at all showed up on my physical device while m
test benches were producing logical values. I'm posting here for any advic
from more experienced people. I've been trying to create this module for
while now and finally started work on it but am sort of at a loss as t
where to begin my trouble shooting since I recently discovered how t
create test benches in the first place; before that I would just load i
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 frequenc
for I2C transmission. Is this right the use of bidirectional pins or am
way off? If anyone wants more of the code just contact me; I don't want t
flood this post with irrelevant information. It's worth noting that in th
test-bench ena_scl and ena_sda were both working as expected which, i
turn, made sda and scl show up correctly on the simulation.

During my re-reading of this post I realized my physical test pi
assignments had no connection to the I2C bus which meant there was n
resistor to VCC on either of the lines. I fixed that; still have the exac
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 unsur
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 t
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 enabl
high
to begin transmission on the bus. When I loaded my code, compiled i
again,
and installed it on the board I hooked up my logic analyzer and wa
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 an
advice
from more experienced people. I've been trying to create this module fo
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 wan
to
flood this post with irrelevant information. It's worth noting that i
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 th
exact
same output!

Thanks everyone.



---------------------------------------
Posted through http://www.FPGARelated.com
Click to expand...
Not sure if you have done this but I usually in my designs create
seperate module with the IO buffers instantiated. So in my I2C design for
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 an
you have external pullups then it should work. It may be worth if you hav
something like Chipscope to have a look and see what is going on inside th
chip.

Jon

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Dec 28, 9:03 am, "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 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 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(
  .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.
Click to expand...
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'v
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 wer
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 whil
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 modul
for
a
while now and finally started work on it but am sort of at a loss a
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 loa
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 th
frequency
for I2C transmission. Is this right the use of bidirectional pins or a
=
I
way off? If anyone wants more of the code just contact me; I don'
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 desig
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 o
a=
nd
you have external pullups then it should work. It may be worth if yo
hav=
e
something like Chipscope to have a look and see what is going on insid
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
Click to expand...
I dont see how it can be harder to understand unless you have no idea ho
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 commo
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]
Click to expand...
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 IOBU
(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.
Click to expand...
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 ide
how
an IO buffer works and if thats the case you shouldnt be doing FPG
design.

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

-- Mike Treseler
Click to expand...
To be honest I dont think you can create IP that is totally vender neutra
as they all have different ways of doing things. I accept for a simple I
buffer you could infer rather that instantiate but some things would b
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.
Click to expand...
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 i
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 vende
neutral
as they all have different ways of doing things. I accept for a simpl
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 an
advantage
at all over a hierarchical graphical structure with embedded code - even
using a schematic with vendor provided megawizards.

Phil
Click to expand...
I guess the problem is that the fpga vendors over the years have starte
putting more complex hard IP into their devices which have to b
instantiated. Personally I try and avoid using Coregen as much as possibl
as I dont think it gives the best implementation of things like FIFOs an
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.
Click to expand...
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.
Click to expand...
Two things. PLLs and asynchronous block ram.

-- Mike Treseler
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top