Custom Component Help

Hi Max,

One way of getting your 256 bit wide data into/out of your peripheral is with 8 x 32 bit writes/reads. With a 4 bit wide address input to your slave you could latch writes to addresses 0 to 7 into slices of the 256-bit wide register, and have spare addresses for writing control flags/reading status flags. The Avalon signals you'd need to add to your logic would be read, readdata, write, writedata and address.

The Avalon interface for this is quite simple. If write is asserted, latch writedata into the destination according to the address bits. If read is asserted, latch data from the relevant source onto readdata.

From your C code, use the Altera IORD/IOWR macros to read and write your peripheral using the base address supplied by system.h.

You would have to modify your existing hardware module to wait for a control bit to be written before executing the hash, and to set a status flag when the hash is complete. Your C code would then perform the custom function by writing 8 x 32 bit values to the data registers followed by a 'go' bit to the control register, and then polling the status register until the 'ready' bit is set. You can then read the result as 8 x 32-bit values.

It would also be easy to use the 'ready' signal as an interrupt.

I know this probably isn't as detailed a reply as you'd like, but I hope it at least gives you an idea of how to proceed, and if you have more specific questions feel free to ask.

Cheers

Sharkybaba

<div class='quotetop'>QUOTE (sharkybaba @ Jun 25 2009, 03:09 AM) <{post_snapback}> (index.php?act=findpost&pid=22904)</div>

--- Quote Start ---

Hi Max,

One way of getting your 256 bit wide data into/out of your peripheral is with 8 x 32 bit writes/reads. With a 4 bit wide address input to your slave you could latch writes to addresses 0 to 7 into slices of the 256-bit wide register, and have spare addresses for writing control flags/reading status flags. The Avalon signals you&#39;d need to add to your logic would be read, readdata, write, writedata and address.

The Avalon interface for this is quite simple. If write is asserted, latch writedata into the destination according to the address bits. If read is asserted, latch data from the relevant source onto readdata.

From your C code, use the Altera IORD/IOWR macros to read and write your peripheral using the base address supplied by system.h.

You would have to modify your existing hardware module to wait for a control bit to be written before executing the hash, and to set a status flag when the hash is complete. Your C code would then perform the custom function by writing 8 x 32 bit values to the data registers followed by a &#39;go&#39; bit to the control register, and then polling the status register until the &#39;ready&#39; bit is set. You can then read the result as 8 x 32-bit values.

It would also be easy to use the &#39;ready&#39; signal as an interrupt.

I know this probably isn&#39;t as detailed a reply as you&#39;d like, but I hope it at least gives you an idea of how to proceed, and if you have more specific questions feel free to ask.

Cheers

Sharkybaba[/b]

--- Quote End ---

Thank you for your reply!

Ok, I changed the VHDL to reflect the avalon ports, and added the control and status flags. I imported the VHDL file into SOPC builder&#39;s new component editor and generated a new component. In my project directory I now have a hw.tcl file. I&#39;m confused now about what I need to do to get the addresses for each of these registers. Other files I&#39;m not sure about are sw.tcl, _regs.h, and system.h. How many of these do I need to make, or if they already exist, where do I find them?

Also, what files do I need to have together so that I can re-use this component?

Thanks!

Hi Max,

That didn&#39;t take you long!

I assume here that you&#39;re using the IDE approach to building your software project. If you&#39;re not then it&#39;ll be of limited help.

As far as addresses are concerned, the important one is the base address which is defined in system.h. If you&#39;re using the IDE like me, you should find it under your system library tree in e.g Release\system_description. It&#39;ll be called something like HASH_BLOCK_BASE. Everything within your logic can then be accessed at an offset from that base address using the IORD/IOWR macros. I usually use the native addressing/register slave approach.

I&#39;m sorry but I don&#39;t know much about packaging up your component into something you can re-use. It&#39;s not something I&#39;ve had a need to do so far.

Maybe there&#39;s someone else left in this ghost town that can assist further! If not, it might be worth a visit to the Altera Forum too.

Cheers

Sharkybaba

The offsets are determined by how your own HDL code uses the &#39;address&#39; values passed to it. If your custom component is defined to have 4 address bits then your hardware can respond to reads/writes to 16 different address offsets from your base address. Using the native versions of IORD/IOWR, if your C code does an IORD(HASH_BLOCK_BASE, 5) for example, then the value of &#39;address&#39; placed on the Avalon inputs to your logic will be 5 (and as far as your HDL is concerned the base address is irrelevant). Only you know what your logic places on the readdata port at a particular address offset, so as such you define the registers.

To try and answer the second part of your question; read, readdata etc are not registers that you can read and write. For example, the following line of code:

IOWR(HASH_BLOCK_BASE, 8, 1);

causes the Avalon switch fabric to place 8 on the &#39;address&#39; port, 1 on the &#39;writedata&#39; port and then strobe the &#39;write&#39; port. Your HDL has to use these signals to latch the data into a register, or maybe just trigger some action. Your HDL is unaware of its base address; that&#39;s just there to tell Avalon which slave port it&#39;s talking to.

Likewise:

IORD(HASH_BLOCK_BASE, 3);

causes the Avalon switch fabric to place 3 on the &#39;address&#39; port, strobe the &#39;read&#39; port and latch whatever your HDL has placed on the readdata port.

It&#39;s also important to note that the &#39;Avalon switch fabric&#39; isn&#39;t like a normal shared bus where a device has to tri-state its ouputs when not selected. It seems to behave more like a big multiplexer, so in a lot of cases you don&#39;t really need to worry about the &#39;read&#39; signal if you can be sure that for any value of the address input your readdata output is always ready. For more complex situations you can start implementing wait states, latency etc.

I hope this goes some way to clarifying things. Once you cracked the concept, it&#39;s a thing of beauty.

Good luck

Got it! Thanks so much for your help!

Last thing, does anyone else know which files need to be packaged together so that the component can be re-used in other designs?

I found it:

http://www.altera.com/literature/hb/qts/qts_qii54004.pdf (http://www.altera.com/literature/hb/qts/qts_qii54004.pdf)

That explains it very well.

Hello again! So everything was working perfectly, but I ended up needing to change over to 32x1 byte read/writes instead of 8x4 byte read/writes. I changed my C code to reflect this in IOWR/IORD calls, but the results are not promising. SOPC builder gives this warning:

"Warning: cpu_0.data_master/SHA_Unit_0.s0: SHA_Unit_0.s0 does not have byteenables. Narrow (less than 32-bit) writes from cpu_0.data_master will result in spurious writes to SHA_Unit_0.s0".

I have changed my read and write signals to be only 8-bits instead of 32-bits. Since those signals are only one byte, I don&#39;t understand how to use a byteenable to make the results more accurate.

Any thoughts?