1. Home
  2. Field-Programmable Gate Arrays
  3. Avalon Bus <-> Wishbone Bus

Avalon Bus <-> Wishbone Bus

I'm pretty new to fpgas, but theres an i2c core on opencores.org that I'd like to use in my Altera project. I understand Wishbone is a subset of Avalon, but what is involved in bridging these two together?

I'm assuming its not too trivial since I could buy an IP bridge that does it from Men Micro, but what exactly is involved if I were to try tackling this myself?

Thanks!

Reply to
benn
Loading thread data ...

Not much, they have different names for the signals and that's most of the differences. Functionally they are almost the same.

Businesses are in business to sell, whether it's easy or hard doesn't matter, there is still $$ to be made. To roll your own...

  1. Take a look at the I2C core to see which types of transactions it handles (most likely it's a slave with only simple read and writes with a ready signal to hold things off).
  2. Read through the Wishbone spec to get an understanding of the types of transactions that can be performed, but paying more attention to the subset of ones that the I2C core actually uses.
  3. Repeat step 2 but reading the Avalon spec, making note of the differences. As I mentioned at the start, you'll probably find that signal names are darn near the only differences.
  4. Take a day or so and write the couple lines of code that it takes to create an entity/architecture that has Wishbone names on one side, Avalon on the other. Write a testbench and see that it seems to work, hook up the I2C core to the Wishbone side and see if that works then start integrating the bridge and I2C core into your main design.

The water is not too deep in making such a bridge, 'specially when narrowing it down to a particular Wishbone component. Once you've done it for one component, you'll probably find that it's also not too difficult to generalize the bridge to handle more generic Wishbone components and still you'll find that it's not terribly difficult.

Kevin Jennings

Reply to
KJ

Completely and utterly trivial.

Indeed, if it weren't for the fact that the I2c core has an unsigned port you wouldn't need to do anything at all, but since it does you need a (very thin) wrapper that presents only std_logic(_vector) ports.

Then you create a component, and simply map each port in the component builder to the equivalent Avalon signal. The only one that isn't perhaps _immediately_ obvious is that ACK waitrequest_n and BTW you map *both* cyc and stb to chipselect (and ignore the warning).

I also chose to hard-code the generic in my wrapper as well, thus not presenting it in the wrapper port map.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

It's not that tough. And a number of people have already done it, and published their work.

Get familiar with niosforum and nioswiki. The answers are out there.

G.

Reply to
ghelbig

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.