CPLD - I2c - Logic Usage

[sriharsha.hs]

hi folks,

I implemented I2c slave in xilinx coolrunner 2 (XC2C128) CPLD to communicate with a processor which is a master. After synthesizing and fitting the design on CPLD, I2c slave logic itself consumed 65 Macrocells out of 128 Macrocells.

I need to still implement my algorithms on CPLD. I dont know which CPLD to use...Is there any better CPLD which I can use for I2C Communication?

Please help me regarding this.

Thank you.

 

[shaiko]

1. Currently, the MACHXO2 by Lattice is the "most advanced" CPLD you will find on the market. It already has a hardened I2C peripherial (and more) - meaning it's already implemented in the silicon...
2. Why CPLD ? Why not FPGA ?

 

[mrflibble]

As you have noticed, on the cpld you'll run out of flip-flops rather quickly. So if your other logic requires a lot of FFs you may want to look at using an fpga.

 

[amitjagtap]

Instead of CPLD you can go for low cast FPGA like SPARTAN 3. The cost is almost same...but you will get more logic elements in FPGA...Easily you can port I2C code and your algorithm.
Best of Luck

 

[sriharsha.hs]

Hello guys,

Thanks for the commenting on the thread. I will surely consider all the opinions.

 

[FvM]

I believe that a basic I2C slave can be implemented with less logic cells. If the application itself doesn't need much resources, CPLD can be still a reasonable option. There's however no clear distinction between large CPLDs and small flash based FPGAs. Some flash based FPGAs are marketed as CPLD, e.g. Altera MAX II and MAX V. Logic complexity, power, speed, price, acceptable form factor are the determining parameters, after fixing it you can check which device fits best.

 

[sriharsha.hs]

Hi Shaiko,

Thats right that less performed FPGA's are available for lesser price, but I need a device which is non volatile. So, thought of using CPLD as a device since I am not implementing heavy logic inside it. Just I am configuring CPLD as a manager.

- - - Updated - - -

Hi FvM,

As per you have said about the parameters considered while choosing a CPLD, I selected MicroSemi's IGLOO (AGLN060Z1), which also has a Secure AES - Encryption capability.

IGLOO is a type of flash based FPGA. which has enough resources to serve my logic complexities. since the design is not finalized, still am running behind the different CPLD's.

 

[lucbra]

if you still want 'more' logic cells and stay non-volatile, machxo2 has a big brother XP2. I've used this device in the past. It can run at reasonable speeds.

 

[sriharsha.hs]

HI FOLKS,

I need to receive the data to CPLD from the temperature monitor IC through I2C protocol. The temperature IC has a inbuilt I2C, where it acts like a slave. It will just send the data periodically. Also, I have to configure my CPLD to behave like a slave because the upper control module is a master. So, I don't have a control over the upper control module. I just need to receive the data coming from the upper module through I2C. Also I need to have the redundant I2C Bus communicating with the Upper master control module.

So, Do I require two I2c slave and one I2C master in my design or is there any better logical idea to approach the problem.?

Please help.

Thank you.

 

[FvM]

The specification isn't clear. It sounds like you want a passive eavesdropping device rather than a slave. Although this isn't a defined I2C function it should work. If I understand right, you intend regular slave functionality in addition?

What are you exactly asking?

The said eavesdropping function can share most resources of a regular slave, but won't drive out to the bus when listening to the temperature monitor communication. I presume you can figure it out yourself.

 

[sriharsha.hs]

The specification isn't clear. It sounds like you want a passive eavesdropping device rather than a slave. Although this isn't a defined I2C function it should work. If I understand right, you intend regular slave functionality in addition?

What are you exactly asking?

The said eavesdropping function can share most resources of a regular slave, but won't drive out to the bus when listening to the temperature monitor communication. I presume you can figure it out yourself.

hi FvM,

Could you please write more on "The said eavesdropping function can share most resources of a regular slave"?, because I am asking whether my understandings is right on configuring with two I2C slave and one I2C master.

Temperature sensor will be sending data through I2C to CPLD.

Thank you.

 

[mrflibble]

Could you please write more on "The said eavesdropping function can share most resources of a regular slave"?, because I am asking whether my understandings is right on configuring with two I2C slave and one I2C master.

It's probably more productive if you take the time and explain your application in a little more detail. I suspect that FvM was just trying to connect the dots regarding your moderately vague specification.

You have a temperature sensor as I2C slave. Check. You have an as of yet unspecified device (upper control module) that acts as I2C master. Check.

And then you have your cpld. What exactly is the cpld supposed to do?

"Temperature sensor will be sending data through I2C to CPLD."

By which I take it you mean the temp sensor will be a i2c slave and will respond to requests to read out the sensor. Typically that is done in master/slave setup, so the cpld would be the master getting the data from the slave (temp sensor).

You could do a multi-master setup, but that's annoying to do. A clean way to do it is to have the CPLD be both a master one one bus, and slave on another bus.

I guess the main question is why do you think you need both the cpld AND the unspecified upper control module to read out the temp sensor?

Why not have the cpld read out the sensor, do clever stuff with it, and then make the processed (?) data available to upstream whatever modules. In that scenario the cpld is (single) master on the bus.

 

[sriharsha.hs]

It's probably more productive if you take the time and explain your application in a little more detail. I suspect that FvM was just trying to connect the dots regarding your moderately vague specification.

You have a temperature sensor as I2C slave. Check. You have an as of yet unspecified device (upper control module) that acts as I2C master. Check.

And then you have your cpld. What exactly is the cpld supposed to do?

"Temperature sensor will be sending data through I2C to CPLD."

By which I take it you mean the temp sensor will be a i2c slave and will respond to requests to read out the sensor. Typically that is done in master/slave setup, so the cpld would be the master getting the data from the slave (temp sensor).

You could do a multi-master setup, but that's annoying to do. A clean way to do it is to have the CPLD be both a master one one bus, and slave on another bus.

I guess the main question is why do you think you need both the cpld AND the unspecified upper control module to read out the temp sensor?

Why not have the cpld read out the sensor, do clever stuff with it, and then make the processed (?) data available to upstream whatever modules. In that scenario the cpld is (single) master on the bus.

Hi mrflibble,

Thank you for writing.

I will try to explain in detail : CPLD reads the data from temperature sensor through I2C protocol, where temperature sensor acts like a I2C slave.

Upper module is a processor communicating with the CPLD through I2C , where the processor is a master. I have added the block diagram which shows the connection of Temperature sensor to the CPLD.

 

[mrflibble]

Okay, the main extra bit of information we now have is that the upper module is a I2C master.

That diagram is only extra confusing, but I guess you mean that the cpld is where it says "uC/uP" in that diagram. And where is the processor from the upper module? How is the cpld connected to the main processor? Are they all on the SAME I2C bus, or is there a seperate bus between processor and cpld? Also, what other functions does the cpld do? That, and how much design freedom do you have? Up until now I have been assuming it's all a given, but if you have a bit of room you can actually make this a design that's a bit sensible.

Oh oh oh! I just thought of something. one moment while I check ye olde datasheets.

- - - Updated - - -

Right, as I thought. Check out the AD7814, that is the equivalent chip with SPI interface. Similar pricing as well. if you have the freedom to change it, I would suggest you pick that one. Why you may ask? Because the development time (aka cost) for SPI on a cpld is bound to be lower than I2C. You are entirely free to think that it should not matter, but SPI is a lot simpler and easier to debug. And since pin count isn't much of an issue with the cpld the extra interface wires should be no problem. Not only that, but the state machine for an SPI interface will take up less resources than an I2C implementation. So you even get to cram more stuff into that cpld of yours.

And I would /even/ consider doing this if the interface between main processor and cpld happens to be I2C. Still going to be cheaper in resources. BTW: you didn't mention yet how the CPLD and main processor are communicating with each other...

 

[sriharsha.hs]

Okay, the main extra bit of information we now have is that the upper module is a I2C master.

That diagram is only extra confusing, but I guess you mean that the cpld is where it says "uC/uP" in that diagram. And where is the processor from the upper module? How is the cpld connected to the main processor? Are they all on the SAME I2C bus, or is there a seperate bus between processor and cpld? Also, what other functions does the cpld do? That, and how much design freedom do you have? Up until now I have been assuming it's all a given, but if you have a bit of room you can actually make this a design that's a bit sensible.

Oh oh oh! I just thought of something. one moment while I check ye olde datasheets.

- - - Updated - - -

Right, as I thought. Check out the AD7814, that is the equivalent chip with SPI interface. Similar pricing as well. if you have the freedom to change it, I would suggest you pick that one. Why you may ask? Because the development time (aka cost) for SPI on a cpld is bound to be lower than I2C. You are entirely free to think that it should not matter, but SPI is a lot simpler and easier to debug. And since pin count isn't much of an issue with the cpld the extra interface wires should be no problem. Not only that, but the state machine for an SPI interface will take up less resources than an I2C implementation. So you even get to cram more stuff into that cpld of yours.

And I would /even/ consider doing this if the interface between main processor and cpld happens to be I2C. Still going to be cheaper in resources. BTW: you didn't mention yet how the CPLD and main processor are communicating with each other...

Hi mrflibble,

You are right that, CPLD will be in the place of uP/uC, CPLD will be connected to the master processor through I2C bus. I still need to develop custom control logic for CPLD which will take care of some specified functions. The temperature monitoring sensor mentioned about in my previous reply has to be interfaced through I2C protocol, where sensor acts as a slave. My question is : Is it possible to receive the data through data line of Temperature monitoring sensor without actually creating the I2c protocol in CPLD? by providing only the clock signal through one of the I/O of CPLD and receiving at the other I/O.

AD7814 looks interesting to me as I can interface through SPI, which has lots of advantage as you have mentioned. I am going with IGLOO nano AGLN060 (FPGA like CPLD) for my design since its cost is same as Xilinx cool runner XC2C128 CPLD.

Thank you.

 

[mrflibble]

So AD7814 spi based temp sensor + IGLOO fpga, sounds sensible to me. That's that part taken care of. So for the communication with temp sensor part you only have to implement an SPI master.

Now for the main processor... any particular reason why the interface between the main processor and the cpld (well, igloo fpga) has to be i2c? If it /has/ to be, then you can do a simple i2c slave for the fpga. If you can get make it SPI between fpga and main cpu as well, then that simplifies things even more. That way you'd need SPI master for comms with the temp sensor, and SPI slave so the main cpu can read out all your favorite data from the fpga.

 

[sriharsha.hs]

Hi mrflibble,

Yes, spi based temp sensor + IGLOOF fpga sounds sensible.

But, I still I wanted to know, whether we can fool temperature sensor to get the data by sending the clock and address from CPLD, without actually not implementing I2C protocol.?

 

[FvM]

But, I still I wanted to know, whether we can fool temperature sensor to get the data by sending the clock and address from CPLD, without actually not implementing I2C protocol.?

Unclear what you exactly mean with this. An I2C slave doesn't respond to anything but the clearly defined I2C bus transactions. If your logic deviced wants to perform the conversation, it needs to implement at least rudimentary I2C master functionality.

I previously mentioned the option to query the temperature sensor by a microprocessor and passively listen this transaction by your CPLD ("eavesdropping" mode). If appropriate, it would save you from implementing the I2C master function and also keep a simple single master I2C bus topology.

Generally, you probably need to learn a bit about I2C (and concurrent like SPI) protocol details to be able to make use of the various suggestions.

 

[mrflibble]

Even if you want to passively snoop on the I2C bus (aka eavesdropping), you still need to write some HDL code that interprets those pesky SCL and SDA signals. So if you think you get a free ride that way ... guess again.

Forget about I2C for temp sensor comms. Oh wait, human CNS can't handle negatives. Right. CONCENTRATE ON THAT I2C BUS REAL HARD! DO NOT FORGET ABOUT IT! FOCUS ON IT FOR 48 HOURS AT LEAST!

well, that's that settled. spi it is.

 

[sriharsha.hs]

Even if you want to passively snoop on the I2C bus (aka eavesdropping), you still need to write some HDL code that interprets those pesky SCL and SDA signals. So if you think you get a free ride that way ... guess again.

Forget about I2C for temp sensor comms. Oh wait, human CNS can't handle negatives. Right. CONCENTRATE ON THAT I2C BUS REAL HARD! DO NOT FORGET ABOUT IT! FOCUS ON IT FOR 48 HOURS AT LEAST!

well, that's that settled. spi it is.

Hi mrflibble,

So are you concluding by telling to use spi rather than I2c ? Anyhow, i didn't understood your last two lines.