Hi Mugilan,
> Thanks alot for your help. I read your code carefully and I think I
> understand what is going on. The simulation using MODELSIM is great, a
> much better way than using the inherit Quartus II simulator.
Yes Modelsim is significantly better than the Quartus simulator,
that is why they give you a free version :)
> Here's what I understand of your code, correct me if I'm wrong.
>
> I can see you have created a FSM that checks for Frame_Valid and
> Line_Valid to be high. If that is the case, then it increments a
> counter that corresponds to a incrementation of memory address. Also,
> there is a "high" in write enable signal to make sure the data is
> latched to memory. When the Line_Valid goes low, then it goes to state
> S_Done and stays there until capture_enable goes low.
Yep.
> One thing I noticed is that you assigned pixclk to the FSM's clock. I
> used a clock that is at least 5 times faster than pixclk. My reasoning
> for that is because faster means no errors in missing a pixclk edge (I
> used pixclk as an input and checked for its fall time).
The sensor outputs a clock, so there is no reason not to use it.
The data sheet indicates that the sensor clock is 48MHz. I doubt
you will be running your FPGA at 5x this clock rate.
I would not recommend using a different clock. You would have
to synchronize to that clock, and thus require more logic, and
as a faster clock.
> Also I loading the code with the TS-7300 board and my CMOS
> sensor. Here's a little bit of problem.
The code I gave you might not be quite correct. The objective
of creating the ModelSim model is to get it to the point that
its I/O matches that of the sensor. Perhaps my model is
not quite correct. You'll need to play with the logic analyzer
to confirm the sensor waveforms, and then adjust the model
accordingly.
> When the capture_enable goes high and stays high, the FSM supposed to
> stay in S_Done state after the first instance of Line_Valid goes low.
Yep, that should be the case. You can adjust the testbench
waveforms to prove it to yourself.
> My problem is that it stays there for some while and then later it
> jumps back to S_Idle and runs back through the state machine again.
It can only get to S_IDLE if either the enable deasserts, or
the FSM is reset.
> Now, I tested this using a logic analyzer and alternatively an
> oscilloscope. both produced the same results. I did notice that it
> stays in the FSM all the while, no running outside of the loop. I need
> to point out that I used a manual input (vcc signal on breadboard
> using wires) for the rstN and the capture_enable signal. I realize
> that I need to sync the inputs with the sensor's clock when I connect
> the host (CPU) to the sensor. But as far as I can see from this manual
> input (I connected it to an oscilloscope and logic analyzer) it does
> not go low at all (no disturbance). How would you explain this?
Sounds like it could be a noise issue. What is your oscilloscope
bandwidth? If its a 100MHz scope, you might not see glitches.
> To be honest, I still do not fully understand why we need to
> sync the inputs to the sensor's clock :).
A flip-flop has a setup and hold requirement that an input
signal must meet when the clock triggers the register. If
a signal is coming from another clock domain, then either
the setup or hold could be violated when the signal is
sampled by the register. The output of that register will
then go to an indeterminate state for a small amount of
time. This is called meta-stability. If you follow that
register, with another register, and the meta-stability
settles within a clock period, then the next register will
either capture a high or a low - you don't know which,
however, it is likely that you will get a high or low,
and not the metastable state. That is why you see two
flip-flops in a row in the sync component.
> I really appreciate you help in this. And seeing your codes,
> I wished they actually thought me how to organize it as well
> as you did in my classes before (taking one lab class to
> code VHDL is barely enough to cover everything). I mean, I
> did not know how to link 2-3 VHDL files with different
> entities and connect them in a top-level VHDL file
> using "component" and "port map" commands.
Your advisor/professor has given you quite a difficult task
for such a small amount of teaching. Once you create components
that are generally useful, you place them in a package file.
Things like the xx_fsm.vhd file are only used in one place,
so I put them in as component declarations.
> I will implement the memory blocks in such way, I think all
> I need is a 1024 words with each 8-bit long. And I think I
> should use not_pixclk for the clock input of the memory. Can I
> just use a clock that is like 5-10 times faster than
> pixclk instead??
Here's what I would do.
When FRAME_VALID and LINE_VALID are asserted, you know you
can increment a counter. You know that the sensor will output
frames of 1024 samples (or whatever you set it up to send),
so you could add a new state SKIP that enables the counter
during FRAME_VALID and LINE_VALID, and when that counter
matches a skip value, then the state machine can transition
to the capture state, where it writes data to RAM.
The FSM and RAM should be clocked by the pixclk as I have
shown.
Make sure you look at the quality of pixclk in your breadboard.
If it looks like it has a lot of ringing, then add a 50-Ohm
source resistor on the clock line going from the sensor
to the FPGA board (the resistor goes as close to the sensor
clock driver as you can get).
> Also, I did notice that you just checked for highs in Frame_Valid
> and Line_Valid and not their rise time. This way, I don't think it
> will start scanning from the first row, i.e. Frame_Valid and
> Line_Valid can already be high at the time where you start
> scanning meaning that it could be scanning the pixels from
> the middle part of the CMOS sensor and not the very top.
Right, I wrote the state machine and model to allow you to
extend it to model the real sensor. I can't go doing all your
homework for you :)
But, as I comment above, if the host logic triggers the sensor
and enables the state machine at the same time, then the
FRAME_VALID signal will start out low, then your FSM will
skip the samples each time LINE_VALID is high, until your
skip count matches. Then the counter would be cleared, and
count to 1024 while reading the pixels you want.
The FSM transition logic would be changed to look at a comparison
of the address counter count output to the skip count, or the
pixel_count, eg. given the signals skip_count and pixel_count
with the same WIDTH as the address counter (which now needs
to be wider than the RAM);
skip_done <= '1' when (count = skip_count) else '0';
pixel_done <= '1' when (count = pixel_count) else '0';
and the LSBs of count would be address. The FSM state
transitions would then use skip_done and pixel_done as
inputs (you need to add them to the sensitivity list
in the combinatorial output generation process).
> Thanks again for your help. Have a great day.
You too. Its nice and hot here, so its time to go swimming :)
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/
|