Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

SoC: Example C-code for accessing Avalon Slave peripherals?

Hi - I recently obtained an Arria V SoC card and I'm having a couple of problems...

1) All my existing designs present an external interface that looks like an Avalon Slave. In the past, I hooked this to the Avalon JTAG master via QSYS, wrote all my control SW in TCL, and ran it on System Console. Now I have an Arria V SOC board. I'm going to use the Golden System Reference Design as is and just add my design as a FPGA Avalon Slave peripheral. I know that Qsys will generate a .h file with the base address of my peripheral, but I have two questions

a) What does the C code that accesses my peripheral actually look like? All the .h file contains is a base address (call it "foo"). I know that conceptually my code will look like

int main ()

{

dumvar0 = contents(address (foo+4)); // reading the peripheral

contents(address(foo+8) = dumvar1; // writing the peripheral

}

But I'm not sure what the valid C syntax would look like for this example above - can anyone point me to an example?

b) once I write my C. I believe I compile it on the host. I found a hello world example for this on Rocketboards referring to the "linaro ARM compiler"). Is that what I want to do, or, how do I want to compile this? (is there a cookbook example how-to somewhere?)

After it's compiled, I assume I can FTP it to the linux on the dev. board (which should boot right up using the GSRD since I won't have tweaked anything) and just execute it. yes?

Thanks!

/j

9 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    You don't have to make use of SoC just to test the hardware you're designing. You should be able to use the same flow that you're used to using System Console TCL scripts.

    Essentially, what you're suggesting is how the flow works, but...there's more to it than that. What's your end goal and why? If you just want to use the ARM cores to test your hardware, I'm not sure I would recommend that. Adding Linux to the mix usually means device drivers for your custom hardware.

    I'd recommend continuing your typical HW test flow, for now. At some point in the future, after you've learned a bit more about the SoC architecture (especially the various bridges and how they're mapped into memory), you can look to start integrating your hardware further.

    Regards,

    slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hi Slacker - Thanks for the kind advice. The purpose of doing it this way is to edge in to using the SoC. Coming up we expect to have the SW part of our work get more complex, and the response time through System Console will be inadequate. I didn't realize I needed to justify my need to earn an answer :-) . Hopefully you can now share some code with me or answer my question? "Writing Device Drivers for my custom hardware" is EXACTLY what I need to do, and I'm comfortable doing it, if someone could give me examples of the actual Read/Write commands.

    Thanks!

    /j
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Right. For now, I would make use of the DS-5 IDE and extensions to the HWLibs/SoCal examples that are shipped as part of SoCEDS. It's a more direct method of accessing your hardware and (I think) it's the best "next step" for you and your team.

    There are several bridges that go between the HPS and FPGA side of the SoC. When you're creating your Qsys design, you'll connect the bridges to your Avalon slaves. Take a look at this link to understand more about how the chip is architected and how to make use of it (http://www.alse-fr.com/archive/soc_sw_lab_13.0.pdf), particularly Module 4. The rest of the stuff you're interested in (including simple "/dev/mem" linux code) is all there as well.

    Google is definitely my friend... :-)

    Cheers!

    slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Thanks - I've started to dig into SocEDS but I would rather try to get something simple running before plowing through the whole package. I looked at that Arrow lab but not seeing any C code examples. I'm trying to defer becoming a SW/Linux expert right now as we may bring someone in with more of a SW background (I'm more of a HW guy). I've validated my approach with local AEs, but they have been unable to find me example code so I posted here. If you have any simple /dev/mem driver examples, please post them. Thanks!

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    It's right at the beginning of section 4.2 in the PDF link that I sent. Sure, it's just GPIO accesses, but it is toggling LEDs hanging off either the HPS or FPGA side from Linux "user land" code. I think that's enough to get going. You could also "bit bang" raw memory from within u-boot if you wanted to.

    Most other sorts of Linux drivers require a combination of Linux knowledge and knowledge of the hardware that you're interacting with. You have to determine which of the driver "paradigms" that your hardware best fits into based on how you want the HPS side to interact with it. Understanding of both will enable you and your team to design hardware that is efficient and effectively utilized.

    What sort of transactions do you want/need to test?

    Cheers,

    slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Ok - this is a start thanks. It looks like there are some library functions that do what I want? alt_setbits_word does the write. I still need the read. Even better - where I can I find a definition of the library functions? in the SoCEDS docs?

    For now, all I need to do is perform longword reads/writes to my instantiated Avalon Slave.

    thanks

    /j
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I know this thread is a few months old by now, but did you ever figure out what you were looking for, Jeff? I actually need to do the same sort of thing now (read and write from a slave peripheral).

    So far I think I have the writing to the slave figured out (the example in http://zhehaomao.com/blog/fpga/2013/12/27/sockit-3.html just uses a simple assignment of a pointer), but can't figure out how to read from the slave....

    By the way, the link to the pdf given earlier in this thread seems to be broken. That sounds like a helpful resource - can anyone re-link it for me?

    Thanks,

    John
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Ok thanks. Your code makes sense to me, but the peripheral I'm using is a Verilog module that I've written to be an Avalon MM slave and I can't get your method to work... I think I must be misunderstanding the addressing or the Verilog side of things, so I'll probably move my inquiry to a new thread.