Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
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.
12748 Discussions

Help-about peripheral IP design

Altera_Forum
Honored Contributor II
1,936 Views

Hi,dear friends. 

 

Recently I have done a DAC IP as a Nios peripheral but it doesn't meet the requirment.I do this IP as the example "pwm" from Altera.com.Now I send a series number to the dac(AD5547 parallel) output during the Nios IDE,the numbers are signals of 40KHz sampled by 1MHz.The output displayed in the oscilloscope is 23.0147KHz,watching the register during debugging ,all numbers have gone into the register.So I'm confused and then I reminded the cpu as fast,the result became 37.3130KHz.It's hard to understand what happened. 

 

So I think maybe there are some problem between the transmition.So I consider some methods as list: 

1、 SPI,but it is series peripheral interface,AD5547 is parallel,so it may doesn't fit. 

2、 DMA  

3 、FIFO 

But I really don't know how to send the numbers to the DAC output.Maybe what I have done is totally wrong. 

Could you give me some suggestions of how to design DA or AD peripherals?:)  

Thanks a lot! 

ps: 

while(1) 

for(i=0;i<=24;i++) 

IOWR_ALTERA_AVALON_PIO_DATA(DATAOUT_BASE,sin_vector1[i]); 

and I set the DAC control pios as the timegraph so DAC works normally.
0 Kudos
11 Replies
Altera_Forum
Honored Contributor II
1,169 Views

the resulting frequency at the output of your dac depends upon the speed you feed the dac with new values. the faster the cpu is and or its clock, the faster the while (1) loop will be executed the faster the dac gets its next value, hence the output frequency will increase. 

but you will also get jitter, if the cpu is executing some kind of interupt and during that time cannot feed the dac with new values. 

if you want to get rid of jitter and cpu dependencies. you should use hardware instead of software to feed your dac to provide a stable and well known updating frequency of your dac data.
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

Thank you for suggestion! 

I got your meaning.But I still confused that how to set the cpu clock can I get the right 40KHz signal,I think the cpu running at uncertain rate.Select the standard the result is 23KHz,as the fast is 37KHz,I also set the cpu as fast and clock as 40MHz,the result is 43KHz.So I got a big confusion. 

Have you ever design the parallel DAC as a IP?I appreciate your great help. 

I feel a little down having done it for a long time.
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

a software based solution will never be as accurate as a hardware based solution. 

 

there a several possible solutions for this 

you dac ip can act as a master, so the nios cpu will programm this ip via its slave ports and setup memory adr of the first value and the number of values. after this you enable the master via one control bit. the master port of your dac will read value after value from the memory location without getting "help" from the cpu. a simple FSM will obey the required DAC clock and store the last read value (by your master) into your dac and start the next read from the memory. 

in that case, when the cpu has started this functionality, the cpu does not have anything left to do. 

 

or you place all the values into onchip memory inside your ip module, and when done you ip will read out value by value and feed your dac with it, assuming you have enough onchip memory availble
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

Thank you very much! 

I do it as you said ,I save the signal during the DAC IP(by NCO). 

--- Quote Start ---  

you place all the values into onchip memory inside your ip module, and when done you ip will read out value by value and feed your dac with it, assuming you have enough onchip memory availble/QUOTE],and I got the right answer. 

 

Though I set the ports like read,write,readdata,writedata,I didn't use them at all.That means the whole process have nothing business with cpu. 

 

So I'm still a little confused.what's function of cpu during the transmiton? 

Besides,I couldn't understand that the avalon bus have read,write, how long does the reading and writing take? 

 

Best regards!
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

well, without more knowledge how your design is done between nios cpu and your dac i can't give you precise hints. 

 

the avalon bus is similar to lets compare it with a telephone switching center, where masters (like nios cpu or DMA) cann call slaves (like memory or ip registers). 

some customer ips can have master and slave ports. a master like the nios cpu tells the customer ip via its slave ports that the next couple of data is stored under slave memory location 0xsomething and enables this ip functionality to fetch via its master ports the data without the help of some other master funtionality. 

such read and writes can be as fast a 1 clock cycle, but could also be longer depending upon waitstates a slave can assert if this slave is slower, or if the slaves is occupied by another master, in last case the calling master must wait until the currently accessing master is finished.
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

I see.Thank you for your kindness. 

 

--- Quote Start ---  

 

 

some customer ips can have master and slave ports. a master like the nios cpu tells the customer ip via its slave ports that the next couple of data is stored under slave memory location 0xsomething and enables this ip functionality to fetch via its master ports the data without the help of some other master funtionality. 

 

--- Quote End ---  

 

 

Now if I want to design a AD IP,then it must have input ports and output ports.I'm not sure that whether the input data go into the fifo,and then fifo send the data to avalon bus,at last avalon bus write the data to AD IP register.It seems complex. 

 

Besides,I occure another problem.I made a memory initialization(use Tightly-Coupled Memory).I want to get data from the on-chip-memory to dataout ports.But it doesn't work.(in the attachment) 

 

during Nios IDE,I do like this 

 

 

volatile int i; 

volatile int *data_tcm_memory_ptr; 

 

data_tcm_memory_ptr = (alt_u32*) (0x00000000);//on-chip-memory base 

 

while(1) 

 

for(i=0;i<=24;i++) 

IOWR_ALTERA_AVALON_PIO_DATA(DATAOUT_BASE,(alt_u32*)(data_tcm_memory_ptr+i)); 

 

 

Best regards!
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

how about:for(i=0;i<=24;i++) IOWR_ALTERA_AVALON_PIO_DATA(DATAOUT_BASE,*(alt_u32* )(data_tcm_memory_ptr+i));

0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

 

--- Quote Start ---  

how about:for(i=0;i<=24;i++) IOWR_ALTERA_AVALON_PIO_DATA(DATAOUT_BASE,*(alt_u32* )(data_tcm_memory_ptr+i)); 

--- Quote End ---  

 

 

Yeah,I got it. 

I do it as you said and get the result ,but the ouput has harmonic wave and a little jitter. 

So I think through on-chip-memory(data saved in it) can enhance the speed ,but can not get the exact answer.When the nios do high-speed signal processing ,I'm not sure it can get the right answer . 

 

And ,I guess that the whole transmission is like this: when I put initial data in on-chip-memory,the avalon bus read the data and then write the data to output.Maybe my idea is wrong.Could you give me a suggestion how does the avalon bus work?
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

To remove jitter you'll need to ensure that the instructions take the same time each time thay are exectuted. 

The dynamic branch prediction will scupper this. 

As will any contention on the Avalon MM slave device. 

(Even assuming there are no cacahe delays.) 

You also need to check the assembler generated by the compiler to ensure the first loop iteration isn't coded separately.
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

 

--- Quote Start ---  

To remove jitter you'll need to ensure that the instructions take the same time each time thay are exectuted. 

The dynamic branch prediction will scupper this. 

As will any contention on the Avalon MM slave device. 

(Even assuming there are no cacahe delays.) 

You also need to check the assembler generated by the compiler to ensure the first loop iteration isn't coded separately. 

--- Quote End ---  

 

Thanks a lot! 

 

I can not understant totally.I don't know about the dynamic branch prediction. 

 

And you said checking the assembler generated by the complier to ensure the first loop iteration isn't coded separately. During my design there only have one peripheral,I don't understand the first loop iteration's meaning. 

 

Best regards!
0 Kudos
Altera_Forum
Honored Contributor II
1,169 Views

The compiler can sometimes transform a simple for(;;) statement into one where the loop body occurs twice. One copy being executed for the first iteration and the other for all further ones. 

(I can't think of an example of when ....) 

This would mean that there are a different number of clocks between the first two writes than between all subsequent pairs. 

Since you are trying to generate a fixed frequency, so need an known (and user-defined) number of clocks between the outputs. This will probably require that you instert some extra 'nop' instructions as pads (look up 'asm volatile'). 

 

There is very little info on the branch predictor, but basically the instruction prefetch and decode unit has to make an assumption as to whether a conditional branch will be taken or not. 

 

Static prediction assumes that backwards branch is assumed taken (ie assumed to be the botton of a loop), and that a forwards branch is assumed not-taken. 

 

The dynamic branch prediction logic uses the low bits of the program counter and the history of recent branches to index a table (default 256 entries) to determine what to do. This means that the first few iterations of a loop might be incorrectly predicted - leading to 2 additional clocks. 

(If a forwards branch is mis-predicted the cost is 3 clocks.) 

 

The dynamic branch prediction logic is standard in the /f processor. Altera no not publicise how to disable it.
0 Kudos
Reply