--- Quote Start ---
I now know how to make a _hw.tcl file (with the sopc component generator)
--- Quote End ---
That is how I will often obtain the first-cut of a _hw.tcl file. I then edit that file to clean it up.
--- Quote Start ---
so I would have to generate a component with the signals to the RAM(adress out,wren out,ren out,data out,q in) and fsm(rdy out,done in) as conduit signals and signals to the component from the nios ii(coef in, coef out) as avalon-MM slaves.
--- Quote End ---
You can implement things in a couple of ways;
Option 1:
a) Avalon-MM slave for the RAM component, and then conduit signals to the top-level. Those conduit signals would connect to one side of a dual-ported RAM. The other port of the RAM would connect to your control logic.
b) Avalon-MM slave for the control registers, and the conduit signals to the top-level. Those conduit signals would connect to your control logic 'enable' and 'done' signals. You could use a PIO component for these signals.
Option 2:
Eliminate the conduit signals altogether by creating a component with two Avalon-MM slave interfaces, and put the RAM, registers, and control logic into a single component.
--- Quote Start ---
I would like to know how I can access these signals from the nios ii, do I have to write some kind of functions to access the slave registers?
--- Quote End ---
The SOPC/Qsys system will have your RAM at one address and your control registers (or PIO component) at another.
--- Quote Start ---
Or are there some automatic functions created that I can use to interface with the component(ie. to set the output wren to 1, something similar to the IOWR function)?
--- Quote End ---
I believe you can write a _sw.tcl, however, I never use NIOS, so you'll have to figure that out. Basically you can use the IOWR function, and the _sw.tcl will just keep track of the address you used in SOPC/Qsys.
--- Quote Start ---
My second question is about the serializing the 2000 bits. Don't I have to enventually buffer them somewhere before the custom logic for the 62,5 clock signals and then feed them to my std_logic_vector(1999 downto 0) input? From your description I wasn't able to understand this. I understand that both the input and the output in the RAM is 32 bit wide, but how do I finally converge this to the custom logic input.
--- Quote End ---
The NIOS processor would write the values to RAM; if the NIOS writes 32-bits at a time, then it will take 63 writes to the RAM to load it.
The NIOS processor would then write to the PIO to set the enable bit.
Your control logic would then be enabled to read from the other port of the dual-port RAM. If your logic needs all 2000-bits, it could take 63 clocks to read all the bits, do something with them, write the answer back to another location in RAM, and then set the 'done' bit to indicate to the NIOS processor that the result is ready.
If you can perform a running calculation using data from a single RAM location at a time, then your control logic can read a 32-bit value (16 x 2-bit values), perform a partial calculation, store the partial result, read the next 32-bit value on the next clock, perform the next partial calculation and accumulate it, etc., until all 2000-bits have been read. Since your result is only required every 50Hz, this scheme probably makes the most sense.
Cheers,
Dave
Honored Contributor
