Hi Dave,
Thanks alot for your help, using dual port ram has its advantages
compared to the single port ram.
I recently ran into another problem while trying to interface the CMOS
sensor to the FPGA. The CMOS sensor had 3 main control signals
(Frame_Valid, Line_Valid and PIXCLK) as an indicator to latch data
through its 8 bit data bus. Frame_Valid pulses high at active columns,
Line_Valid pulses high at active rows and fall time of PIXCLK
indicates stable data to be latched.
To deal with this, I created a state machine that runs through a
series of states that check for each control signal consecutively. My
problem is that my state machine does not work, i.e. the program is
not in any of the states. I verified this by connecting each state to
an output pin that pulses high if the machine is within the state. I
used a logic analyzer to measure these lines and as soon as I finish
resetting, it starts from state "Initial" and jumps out of the state
machine loop.
Frankly, I have no clue of what is going on. I have an "ELSE" clause
at the end of each "IF" statements that specifies it to go to the
state "Initial" if it fails to meet all the conditions.
I hope you can shed some light on this. Thank you
Mugilan
--- In David Hawkins <> wrote:
>
> Hi Mugilan,
>
> > I think that is an implementation of a dual port ram with
> > 16 words (32 bits long each).
> > Here is my implementation, tell me if I'm doing this right.
> >
> > MEMORY : altsyncram
> > GENERIC MAP (
> > intended_device_family => "Cyclone II",
> > width_a => 8,
> > widthad_a => 10,
> > numwords_a => 1024,
> > operation_mode => "SINGLE_PORT",
> > outdata_reg_a => "UNREGISTERED",
> > indata_aclr_a => "NONE",
> > wrcontrol_aclr_a => "NONE",
> > address_aclr_a => "NONE",
> > outdata_aclr_a => "NONE",
> > init_file => "SDStateMachineExample.mif",
> > lpm_hint => "ENABLE_RUNTIME_MOD=NO",
> > lpm_type => "altsyncram"
> > )
> > PORT MAP (
> > wren_a => MW,
> > clock0 => NOT(CLOCK),
> > address_a => MemAdd,
> > data_a => DataCMOSInternal,
> > q_a => DataOutInternal
> > );
> >
> >
> > DataCMOSInternal <= DataCMOS;
> > DataOut <= DataOutInternal;
>
> This isn't dual ported. Read the generics :)
>
> Here's an example of a dual-ported RAM from a Stratix II design:
>
> u4: altsyncram
> GENERIC MAP (
> widthad_a => SYS_ADDR_WIDTH,
> widthad_b => SYS_ADDR_WIDTH,
> width_a => SYS_DATA_WIDTH,
> width_b => SYS_DATA_WIDTH,
> width_byteena_a => SYS_BYTEEN_WIDTH,
> width_byteena_b => SYS_BYTEEN_WIDTH,
> numwords_a => 2**SYS_ADDR_WIDTH,
> numwords_b => 2**SYS_ADDR_WIDTH,
> byte_size => SYS_DATA_WIDTH/SYS_BYTEEN_WIDTH,
>
> clock_enable_input_a => "BYPASS",
> clock_enable_input_b => "BYPASS",
> clock_enable_output_a => "BYPASS",
> clock_enable_output_b => "BYPASS",
>
> address_reg_b => "CLOCK0",
> byteena_reg_b => "CLOCK0",
> indata_reg_b => "CLOCK0",
> outdata_aclr_a => "CLEAR0",
> outdata_aclr_b => "CLEAR0",
> outdata_reg_a => "CLOCK0",
> outdata_reg_b => "CLOCK0",
> wrcontrol_wraddress_reg_b => "CLOCK0",
>
> power_up_uninitialized => "FALSE",
> read_during_write_mode_mixed_ports => "DONT_CARE",
> intended_device_family => "Stratix II",
> operation_mode => "BIDIR_DUAL_PORT",
> lpm_type => "altsyncram"
> )
> PORT MAP (
> clock0 => clk,
> aclr0 => rst,
>
> -- Port A
> wren_a => en(DECODE_RAM1),
> address_a => addr(SYS_ADDR_WIDTH-1 downto 0),
> byteena_a => byteen,
> data_a => wrdata,
> q_a => rddata_mux(DECODE_RAM1),
>
> -- Port B
> wren_b => ram1_wren,
> address_b => ram1_addr,
> byteena_b => ram1_byteen,
> data_b => ram1_d,
> q_b => ram1_q
> );
>
> The generics for a Cyclone II device will be different.
>
> > Now, my DataCMOS are input signals connected to CMOS sensor using the
> > DIO2 header on the FPGA. My DataOut are output signals connected to
> > the FPGA pins that connects to the BD08-BD15.
> >
> > With this, I believe that using the CPU-FPGA bus (used only for
> > reading from FPGA), I can immediately save all the data from FPGA
> > memory to the CPU. For the addressing purposes, I was just going to
> > use a counter that counts the address from beginning to end. Correct
> > me if I'm wrong, but I think suppose we have 32 words (8 bits long
> > each) memory block, the addressing for this will just run from 0-31.
>
> Its not quite that simple, as during a read, the address will be
> driven onto the bus, the FPGA will capture it and either drive it
> onto the FPGA RAM directly, or use it to load a RAM address
> counter (I don't know if the processor drives the address for
> each data phase, or expects a burst). The FPGA will then need to
> drive data onto the data bus 'at an appropriate time'. That timing is
> processor specific, and is what you need to determine.
>
> You can't arbitrarily drive the bus at any time, you can only
> drive the bus when the FPGA is selected for read, and that is
> the logic you need to extract from the opencores.org design.
>
> > You mentioned:
> >
> > "What you need to ensure is that the memory map of the CPU is
> > configured to assert the correct read/write control signals to the
> > FPGA. The opencores.org FPGA image will have that interface already."
> >
> > I think what I need is:
> >
> > 1) make sure the bus is set to read from FPGA when needed
> >
> > 2) save the data from the bus into CPU memory
> >
> > I don't know how to do all that.
>
> Here's how the data gets to the CPU;
>
> 1. The ARM core reads from an address
>
> 2. The processor address decode logic (the memory controller)
> determines that the address is targeting the local bus,
> and the chip-select of the FPGA, and asserts the appropriate
> bus signals.
>
> 3. Depending on the controller setting, it will either assert
> the read signals for a predetermined amount of time, and
> at that time, complete the read, expecting valid data on
> the bus, or the processor can be stalled by a wait-state
> control input (I can't recall what the TS board has).
> When the data is ready on the bus, the CPU wait-control
> is deasserted, and the read completes.
>
> There may be some additional decoding between the processor
> and the FPGA too. There's a CPLD on the board that may share
> the address space of the FPGA. You'll have to read the docs
> and look at the address map.
>
> > I hope I am making sense with this approach. My deadline is next
> > Friday, May 2. So I am trying to make this work without complicated
> > methods such that I can debug it easily if I run into any problem.
> > What do you think?
>
> I think you need to ignore your application for a day or so,
> download the opencores.org design, and play with that design.
> I'm pretty sure it has some registers in it for accessing the
> opencore ethernet controller. If you can understand how two
> different address registers are accessed, then you can understand
> how to access a RAM block.
>
> Don't stress too much :)
>
> Cheers,
> Dave
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|