Author Topic: Understanding Avalon Interfaces  (Read 6774 times)

0 Members and 1 Guest are viewing this topic.

Offline Sparky49Topic starter

  • Regular Contributor
  • *
  • Posts: 92
Understanding Avalon Interfaces
« on: May 29, 2018, 06:44:16 pm »
Hi,

Apologies in advance for the long post. I've spent ages trying to figure this out, but I can't tell if my problems lie at a fundamental ignorance, or  just something more subtle.

I'm trying to interface a verilog module I've written in Quartus Prime with a soft CPU on the same FPGA. To do this I plan to use Qysys to generate a custom component from my verilog file. However, I'm getting plenty of errors which is really down to me not understanding properly what I'm doing, and I can't make heads nor tails of the documentation I've read, primarily the Avalon Interface Specifications and Making Qsys Components...

The figure below shows my overall intentions. In short, I'd like to have a couple of external (out of fpga) outputs and inputs. Further to that, I'd like to connect a couple of inputs and outputs to the cpu. My plan is to have the cpu toggle one of the module's inputs to 'start' it, then when it toggles the same input, it reads the state of the outputs (32 bit numbers).



My understanding is that I need different Avalon components within my Qsys component (reset, avalon_slave, clk, etc) for these different parts, however chosing which would be best is proving tricky. Would it be best to chose the conduits for the external connections? Secondly what would be the most appropriate way to simply 'read' the state of the output registers in my Qsys component? Can I read these as I would, say, a parallel port on a uC? Or would I need to add control lines for reading and writing?

Again, sorry for the mess. I'm new to this and trying to get my head around it all.... :-[ If I can offer any more explanation, or if I need to rephrase sections please let me know.
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1611
  • Country: gb
Re: Understanding Avalon Interfaces
« Reply #1 on: May 30, 2018, 12:57:47 am »
I have only created a couple of components for qsys, and I too found creating an avalon interface a bit of a pain, but it can be done there is quite a bit of flexibility in terms of complexity. It was a while ago but I believe this document helped:

ftp://ftp.altera.com/up/pub/Altera_Material/.../Tutorials/making_qsys_components.pdf

You can also add some built-in components for your NIOS II processor, build the project, and check out the verilog code in the qsys folder of your project.  There should be the verilog modules that you can use as a template.
 
The following users thanked this post: Sparky49

Offline Sparky49Topic starter

  • Regular Contributor
  • *
  • Posts: 92
Re: Understanding Avalon Interfaces
« Reply #2 on: May 30, 2018, 11:08:43 am »
Many thanks for the messages guys. I think I'm just about on the right track with the use of Avalon_MM...

Am I needing a separate Avalon_MM for, say, each 32 bit register output (from my module)? That is the impression I get from the errors/warnings, but I'd like to check.  ??? Also, a seperate Avalon_MM for the 1 bit link between cpu and my module? What about the external connections? Are they suitable for MM or would I need to look at conduits for those?

Regards and thanks again.
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1611
  • Country: gb
Re: Understanding Avalon Interfaces
« Reply #3 on: May 30, 2018, 12:17:12 pm »
No need for a separate interface for each register - the interface is just that, an interface, with address, data and control lines.  Each 32-bit register in your module should have a different address though.

I realise I'm just linking to Altera appnotes but: https://www.altera.com/content/dam/altera-www/global/en.../mnl_avalon_spec.pdf

It provides examples and diagrams of what the interface is, and what is required.  You have to present an interface that you can hook up to the Avalon bus in qsys.  "External conduits" are just that, external connections that are part of your module but not part of the Avalon interface.  A PWM output for example, or an 8-bit wide input/output to be read from your FPGA's pins.  Actually a PWM module is quite a good start as it would only require a couple of register (period and duty) to write to, and can easily be tested in hardware.

I'll see if I can dig out some verilog state machines I did for an Avalon slave interface.
 
The following users thanked this post: Sparky49

Offline Sparky49Topic starter

  • Regular Contributor
  • *
  • Posts: 92
Re: Understanding Avalon Interfaces
« Reply #4 on: May 30, 2018, 12:37:35 pm »
Many thanks BuriedCode, I think I am beginning to at least understand where my holes of knowledge are. :)

No problem linking to appnotes, I have (tried) reading both of those, and generally prefer trying to figure them out, but at this stage I'm getting in a spin trying to understand what I need to implement from those.  :-DD

I've attached the current stage of my component - I think I'm getting closer, but would like to verify a few things if possible. So I've got four 'interfaces', a clk, reset, Avalon_MM for signals I want to interface with the soft cpu, and conduit for signals in my module I want to connect to a pin out to the pcb.

In my avalon_slave_0_1, I have the two outputs from my module, which are of readdata types - so my cpu can read the data in the registers. Start is intended to control my verilog module, so a writedata would make sense to me here (I know it doesn't from the appnotes, but I can't figure out what would be better suited).

However, I still get the Signal readdata appears 2 times (only once is allowed). Presumably this is related to what you mentioned re addressing the registers? If so, how do I do this? I see the app notes refs addressing, but wouldn't that mean I'd have to alter my verilog to incorporate this?

Apologies for all the talk, and questions.

Thanks as always for your help. I think this will be a sudden 'aha' moment when it makes sense.  :-\
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1611
  • Country: gb
Re: Understanding Avalon Interfaces
« Reply #5 on: May 30, 2018, 02:06:59 pm »
I mentioned addressing because that is what the Avalon bus requires.  Every bus used to connect CPU's to peripherals requires an address (32 bits in this case) and data (doesn't have to be 32-bits if your peripheral only needs 8 or 16), as well as control lines, like CS, read, write, possibly the compliments of these.  For very simple peripherals, one can omit some of these - like for a read-only peripheral for example, or a write only.

Shows us the verilog code for your Avalon interface.  There is example code available from Altera but I vaguely remember this being very hard to find - lots of broken links on Alteras website.

Here's a master interface: https://www.altera.com/support/support-resources/design-examples/intellectual-property/embedded/nios-ii/exm-avalon-mm.html
But I suspect you'll want a slave interface (the NIOS II is the maaster in this case): https://www.altera.com/support/support-resources/design-examples/intellectual-property/embedded/nios-ii/exm-avalon-memory-slave.html

It is memory mapped because QSYS has to provide addresses for these peripherals so the soft CPU can access them.  The first link I posted (Making SOPC builder components) walks you through creating a simple peripheral with an Avalon Slave interface, including verilog listing. At the very least it'll help you create the component in the tutorial.
 
The following users thanked this post: Sparky49

Offline Sparky49Topic starter

  • Regular Contributor
  • *
  • Posts: 92
Re: Understanding Avalon Interfaces
« Reply #6 on: May 30, 2018, 04:48:12 pm »
Thanks again Buried, I've attached a simplified verilog file. Please be gentle haha.  :P

I'll work through those examples you listed this evening. :)

 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 797
  • Country: lt
Re: Understanding Avalon Interfaces
« Reply #7 on: May 30, 2018, 06:15:51 pm »
I've used Avalon-MM as well as Avalon-ST. The Avalon-MM is the easiest if you do not do burst transfers, but rather let your own module to be accessed upon request as a part of memory bus and keep the data 32bits. For the required signals, check https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/manual/mnl_avalon_spec.pdf Figure 7.
 
The following users thanked this post: Sparky49

Offline Sparky49Topic starter

  • Regular Contributor
  • *
  • Posts: 92
Re: Understanding Avalon Interfaces
« Reply #8 on: May 30, 2018, 06:27:29 pm »
Thanks blueskull, a very interesting series. Unfortunately I do not have the DE10, but it was an interesting (and educational) lesson.

Scrts, thanks. My concern regarding that is really the control lines, as in fig 7. My understanding from that is in order for the cpu to read the value of a register, i will need a read control line. However, what do I connect that to in my verilog? Or can I just create another signal 'read' and leave it unconnected to anything in my verilog, but connected to '1' in my implementation (so the pcu can always read).

Of course, I still have two readdata signals in the same Avalon_MM slave, which Qsys doesn't like. :/

Many thanks.
 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 797
  • Country: lt
Re: Understanding Avalon Interfaces
« Reply #9 on: May 31, 2018, 02:48:06 pm »
Thanks blueskull, a very interesting series. Unfortunately I do not have the DE10, but it was an interesting (and educational) lesson.

Scrts, thanks. My concern regarding that is really the control lines, as in fig 7. My understanding from that is in order for the cpu to read the value of a register, i will need a read control line. However, what do I connect that to in my verilog? Or can I just create another signal 'read' and leave it unconnected to anything in my verilog, but connected to '1' in my implementation (so the pcu can always read).

Of course, I still have two readdata signals in the same Avalon_MM slave, which Qsys doesn't like. :/

Many thanks.

Yes, you need to have mandatory signals for control. If you won't control them correctly, then either your module won't be accessible from Nios or you will stall the Avalon-MM bus and Nios won't even start - it won't be able to access the memory needed for it to run.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf