Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
17268 Discussions

Avalon MM templates in Qsys

Altera_Forum
Honored Contributor II
5,241 Views

Hi, 

 

Has anyone successfully implemented an Avalon MM master template in Qsys? 

 

I'm seeing a warning which I didn't see in SOPC Builder for the same system which I ignored initially: 

 

"Conduit interface can't have an associated clock" 

 

I've subsequently discovered that my data and control signals are not being passed thorugh the conduit into Qsys. If it was my own component I would go into Component Editor and change the interface propoerties but the master templates don't allow you this option - the "edit" button is greyed out. 

 

Any suggestions? 

 

John
0 Kudos
26 Replies
Altera_Forum
Honored Contributor II
2,088 Views

I'd rather edit the component's _hw.tcl file directly. 

Component editor is not very smart in managing things created with older tools. 

I think you only need to change a few lines according to Qsys syntax.
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Sounds like the conversion on the backend isn't working properly. Open up the .tcl file and look for the deceleration of the conduit and remove the part that is associating the clock interface to it. I would save a copy of it since one of these days (don't know when) I plan on removing those templates and replacing them with better ones.

0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Thanks Guys, 

 

I amended the hw_tcl file for the template, removing the clock association and that got rid of the error messages in qsys. The template is still not working but now I'm not sure why - the investigation continues.... 

 

Thanks for your inputs, 

 

John
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Just to close off on this one, I've analysed the master template signals in signaltap and have found that no avalon signals are being generated at all by the template despite the correct signals being sent to the template. 

 

I have decided to stop trying to use the master template and will instead design my own custom component in Qsys. 

 

BadOmen - if you do update the master templates, could you please let me know? 

 

Thanks again, 

 

John
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Hmmm that's odd. I haven't really been following the templates over the last few years so it could be that they broke somehow in later versions (why? no idea). 

 

You can use the masters from the mSGDMA to do that same thing in Qsys, just export the streaming ports which provide the same sort of as the master template. There are more signals to control since it offers a lot more functionality than the master templates have. Each master has a pdf document which will describe what all the control signals do. You could also look at the dispatcher block since I have small pair of modules that break out the signals as well. 

 

Alternatively you could use the read and write masters from the Qsys tutorial design. They have a similar feature set as the master templates and are optimized to run really fast. They don't come with documentation but it should be easy to figure out from the comments in the HDL.
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

I've now tried writing my own simple Avalon MM master component to write and read a single word of data from DDR2 memory using the Altera high performance memory controller.  

 

During the write transaction, the memory controller core does not assert waitrequest and it appears as though the write transaction completes according to the Avalon MM spec. However, the memory controller does not exert mem_we_n or mem_cs_n.  

 

During the read transaction, the memory controller asserts waitrequest in response to the read signal and it remains high indefintely and doesn't complete the transaction. 

 

I guess I'm doing something wrong in either the verilog control code or the qsys configuration. I would really appreciate it if anyone has time to look at the attached files and offer any advice. 

 

Thanks, 

 

John
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

hey 

 

 

you got a work around for this templates u can upload here? im facing the same problem now i want to add a master to acces ddr3 ram. 

 

 

Rene
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Does this issue happen in simulation? If so are you waiting for the calibration phase to complete (it takes around 250us if I remember correctly). So if the controller is still calibrating a few read commands will be allowed in then waitrequest will assert for around 250us and then finally the reads will return. 

 

If you are looking for similar functionality as the master templates I recommend using the master components in the Qsys tutorial example design. The interface to control them is a little different (ST sink that accepts transfer requests) but they should work a lot better. Similarily the modular SGDMA up on the wiki would be another alternative if you need more features in the master hardware.
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Hey, 

 

 

i use the template to get an block in QSYS now im tryin to interact with the user/control interface. 

 

 

wire [31:0] data [0:4]; // 4 Byte Datenfeld 

wire control_fixed_location; 

wire control_write_base; 

wire control_write_length; 

wire control_go; 

wire data_to_buffer; 

 

assign control_fixed_location = 1'b0; 

assign control_write_base = 32'h0FFFFFAA; 

assign control_write_length = 4; 

assign control_go = 1'b0; 

assign data_to_buffer = 1'b0; 

 

assign data[0] = 32'hAABBAAFF; 

assign data[1] = 32'hAABBAAFE; 

assign data[2] = 32'hAABBAAFD; 

assign data[3] = 32'hAABBAAFC; 

 

 

 

always @(posedge button_pio[0]) 

begin 

assign data_to_buffer = 1'b1; 

# 1 assign data_to_buffer = 1'b0; 

 

end 

always @(posedge button_pio[1]) 

begin 

assign control_go = 1'b1; 

# 1 assign control_go = 1'b0; 

 

end 

 

 

Is that code right or did i make some mistakes? Im not sure how long to toogle control go and data_to_buffer. Is one clk cycle right?
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

I assume you want to push a button for a transfer to start? If so then I would first debounce the button signal, and then use an edge detect on the debounced signal. This will generate a clean one clock cycle pulse into the go bit.  

 

Using the positive edge for a push button directly is not a good idea because A) it's not a clock and B ) push buttons typically have a lot of bounce so when you push it it'll probably progress high ---> low ---> high a few hundred/thousand times.
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

ok i debounce now the buttons but i have the problem that control_go never get assert so my programm must be false. Any other hints why maybe how long to toogle data_to_buffer?

0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Assuming your debounced signal is active high you would create a one clock cycle pulse from it like this: 

 

// assume debounced signal is called 'button' reg button_d1; wire button_edge; always @ (posedge clk or posedge reset) begin if (reset) button_d1 <= 0; else button_d1 <= button; end end assign button_edge = (button == 1) & (button_d1 == 0); // creates a one cycle high pulse when button is asserted // button_edge can be used to drive 'go' assuming the master isn't already operating
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Thanks BadOmen i got the WriteMaster to work now but i have another quick question. 

 

the control signal control_fixed_location in the templates what does it mean  

 

"When set the master address will not increment. "  

 

What happen if i turn it on. 

 

Rene
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

That's really only meant for writing into a memory mapped FIFO. Now that Avalon-ST exists I would say it's a useless feature since you can just export a FIFO ST sink to the top level and connect to it directly. 

 

So if you want to write data to incrementing memory locations make sure that bit is turned off otherwise your data will all be written to the same address.
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Hey BadOmen thanks for ur reply but i have now another question maybe u can help. 

 

I got a read Master to work but i dont understand the control/user signals. When i toggle control_go_read the fifo signals with user_data_available that new data is in fifo but control_done doesnt get toggle (is this signal btw low activ?). When im now read this data from fifo and toogle user_read_buffer the user_data_available signal doenst go to zero again (fifo not empty?).  

 

the control_done from the read master get toogled somtimes after i write data to sdram again with my write master or when i read a multipletimes the same address in sdram. 

 

 

Thanks Rene
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Simulating the design would make debug much easier since you'll be able to see what the master is doing when it doesn't respond with the control_done going high. 

 

Some things off the top of my head: 

 

1) Make sure your start address is aligned, so if you use a 32-bit master then the start address needs to be aligned to a four byte boundary 

 

2) Make sure the transfer length is a multiple of the data width, so for a 32-bit master lengths of 4, 8, 12, 16, etc... are valid 

 

3) Never start the master with a transfer length of 0, I have no clue what will happen if you do 

 

4) Never assert control_go when control_done is low 

 

5) Never start the master at an address that doesn't exist in the system or use a transfer length so long that the master eventually accesses memory locations that do not exist. 

 

6) Never use the early_control_done signal to determine when it's safe to startup the read master, use control_done for that.
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

In the documentation the read master is called pipeline read master it is necessary to use a pipeline bridge betweeen read master and ddr ram? 

 

 

 

And i have an question to the read fifo when i read 8 byte of data and i have a data width of 32bit. is the output of the fifi the first 4 byte i read and after i toggle user_data_read the next 4 byte will send to the output. is this right?
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

A pipeline bridge is *not* necessary. The name just means that it supports pipelined read operations (i.e. it can post multiple reads before read data returns). 

 

Your description of the read behavior FIFO is correct. Lets say memory address 0 to 7 have the following values: 00 (address 0), 01, 02, ...., 07 (address 7). When the 32-bit read master reads eight bytes starting from address 0 you should expect the value '03020100' be presented first by the FIFO output followed by '07060504' after the first value is popped.
0 Kudos
Altera_Forum
Honored Contributor II
2,088 Views

Hey badOmen my code doenst work at all. i got following problems. 

 

1. when i read data the user_data_available signal toogle to high. thats right but when i read my 8 byte of data it dont go low. And when i try a second read control_done_read never goes high again.  

 

2. when i now write data to my write master fifo and i toogle control_go the control_done signal sometimes dont goes from low to high again but the system write data in my ddr3 that i can read. but the data is not always the same sometimes it is the wanted data somtimes it is a zero or sometimes it is the first 4 byte i read from the memory. 

 

 

it seems that my my code doesnt read correct 8 byte (sometimes seems to be more sometimes less) Overall i think the error must be in reading/writing to fifo. 

 

do u have any help for me i dont know where to search. 

 

wire data ; // 4 Byte Data wire control_fixed_location; wire control_write_base; wire control_write_length; wire control_read_base; wire control_read_length; wire control_go_write; wire control_go_read; wire data_to_buffer; // write data to fifo wire control_done_write; wire control_done_read; wire read_buffer_done; // read value from fifo -> next value wire read_data_available; // data in fifo wire button_pio_deb; // debouced buttons assign control_fixed_location = 1'b0; assign control_write_base = 32'h08FFFFAC; assign control_write_length = 32'h00000004; assign control_read_base = 32'h08FFFFB8; assign control_read_length = 32'h00000008; reg control_go_reg =1'b0; //write command reg control_go_reg_read =1'b0; // read command reg data_to_buffer_reg=1'b0; // write data to fifo reg read_buffer_done_reg = 1'b0; // read value from fifo -> next value reg led_pio_reg_1=1'b1; // ledflag reg led_pio_reg_2=1'b1; // ledflag reg button_old_1=1'b1; reg button_new_1=1'b1; reg button_old_2=1'b1; reg button_new_2=1'b1; reg read_or_write=1'b0; // toogle between read and write with buttons (read init) reg data_read_reg = 32'h00000000; // Read data to Write data reg data_read_reg_2 = 32'h00000000; // Read data to Write data reg flag =1'b0; reg flag2 =1'b0; Debounce Debounce_1( .clk(clkin_100), .keyin(button_pio), .keyout(button_pio_deb) ); Debounce Debounce_2( .clk(clkin_100), .keyin(button_pio), .keyout(button_pio_deb) ); always @(posedge clkin_100) begin button_old_1 <= button_new_1; button_new_1 <= button_pio_deb; button_old_2 <= button_new_2; button_new_2 <= button_pio_deb; if(read_or_write==1'b0) begin if ( button_new_1==1'b0 && button_old_1==1'b1) begin control_go_reg_read <= 1'b1 ; control_go_reg<= 1'b0; data_to_buffer_reg <= 1'b0; end else begin control_go_reg_read<= 1'b0; end if ( button_new_2==1'b0 && button_old_2==1'b1 && read_data_available==1'b1) begin if((flag==1'b0) & (flag2==1'b0)) begin data_read_reg <= data; read_buffer_done_reg <= 1'b1 ; flag<=1'b1; led_pio_reg_1<= 1'b1; end else if ((flag==1'b1) & (flag2==1'b0)) begin data_read_reg_2 <= data; read_buffer_done_reg <= 1'b1 ; led_pio_reg_1<= 1'b0; read_or_write<=1'b1; flag2<=1'b1; end end else begin read_buffer_done_reg <= 1'b0; end end // if read_or_write if(read_or_write==1'b1) begin if ( button_new_1==1'b0 && button_old_1==1'b1) begin control_go_reg <= 1'b1 ; read_or_write<=1'b0; flag<=1'b0; flag2<=1'b0; end else begin control_go_reg<= 1'b0; read_buffer_done_reg <= 1'b0; control_go_reg_read<= 1'b0; end if ( button_new_2==1'b0 && button_old_2==1'b1) begin data_to_buffer_reg <= 1'b1 ; end else begin data_to_buffer_reg <= 1'b0; end end // if read_or_write end assign data_to_buffer = data_to_buffer_reg; assign control_go_write = control_go_reg; assign control_go_read=control_go_reg_read; assign read_buffer_done=read_buffer_done_reg; assign data = data_read_reg_2; assign led_pio = control_done_read; assign led_pio = read_data_available; assign led_pio = read_or_write; assign led_pio = control_done_write;  

 

 

the simulation of my code brings the right behaviour every signal i set is 1 cycle high. is this right? I think maybe the fifos are running out of memery but i dont know why this can happen. Do you think that its possible that i get the trouble cause i use that buttons? 

 

Thanks for ur help
0 Kudos
Altera_Forum
Honored Contributor II
2,016 Views

Hey i try some new code without the buttons but it still now work how long i must assert user_write_buffer ? i assert ein cycle (10ns) is that enongh? 

 

 

after this i write new data to the interface and assert user_write_buffer again for one cycle. but it seems that the data is not correctly trasnferred into the fifo. somtimes the same 4 byte are 2 times in the fifo sometimes the correct data is there. maybe is there a minimum wait time between two write two fiffo actions? 

 

 

is 32'h08FFFFA4 a allowed begin address for 32 bit?
0 Kudos
Reply