Re: Any ideas on how to do this?

On a sunny day (26 Nov 2006 08:29:52 -0800) it happened "J.P. Garcia"
<74m45h11@xxxxxxxxx> wrote in
<1164558592.595173.315780@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:

On Nov 26, 10:16 am, Jan Panteltje <pNaonStpealm...@xxxxxxxxx> wrote:
I am trying to understand this.
Monocycle procesor (everything in one clock cycle?) Great if you did that!
But _however_ you slice it, a VGA display cannot display more values per
second then the number of frames per second it displays, no matter what.
Say you had 50MHz FPGA clock, and the VGA runs at 50Hz frame rate (50 fps).
This gives you 1 000 000 cycles between displays.

Even if your counter is upped or lowered much faster, it would make sense
in the max speed case for the VGA to only grab its value every frame
(20mS here), then do a binary to BCD conversion, add something for ASCII, and
then display it.

Why would this not be enough?

When we refer to monocycle we are referring to the fact in which you do
a instruction each clock tick.

Yea, that is what I ment.

If you did everything in one clock
cicle, well it would be... Amazing and superoptimized.

In FPGA I have a DES decode in one clock (no processor though, just expanded
the algo to gates).


I know that a VGA has a horizontal and vertical refresh, and we need to
divide the original 50Mhz frequency to something that's able to show
anything in the screen.
However, my VGA module uses 25Mhz. It's somehow based in this one (
http://www.cs.utsa.edu/~danlo/research/DigilentSpartan3/VGATest.htm ),
but I can freeze the display to show a fixed value for as long as I
want to.

However to do the binary to BCD conversion would just freeze the screen
for a while with the previous value and then show the one that's valid
when it's over, and taking into account that we're using a 50 or 25 Mhz
clock this process would be somehow short.

Not sure here, here is some pseudo code, assuming you have a VGA V sync available:

allocate a spare 32 bits counter
allocate 10 7 bits counters for the decimals
if(negedge Vsync)
{
inhibit main 32 bits counter // do not want a undetermined toggled state
copy counter to spare counter
allow main counter again

spare counter to bcd

add ASCII '0'

// result now ready
result to display RAM.
}

As processes run in parallel in FPGA, you would indeed get to see something like:
000 000 0001
000 000 9430
000 020 4501
when running up.
Nothing would 'freeze' and you cannot see that any faster anyway, human eye is not faster.
This dilemma in normally solved in digital clocks by use multiple speed for up and down buttons.
(as you mentioned user input)
So first short button touch is one up (or down).
Longer then 100mS on button steps 10 up (or down)
Longer then 1S on button steps 100 up (or down).


We're not using ASCII because it would be just filling our little
available free logic gates in a lot of stuff we don't need to.

Well if you want to display BCD 0-1-2- -9 as a number on the screen,
and also have any text, you just add ASCII '0' (= 48 decimal) to each BCD value,
and use a normal character generator (with character ROM).
Spartan has enough memory for that I think, to put the ROM in dual port RAM
if must be.
However you slice it, the character symbols 0 through 9 must be somewhere, if
you want to display these.
For a nice 8(width) x 9(height) font with 10 digits you would need only
90 bytes ROM.... maybe just using defines would do it in verilog.

If the number is just in a corner of the screen you can work around a full VGA
size diplay RAM by just using that part, and the rest in timing :-)

I think I have covered it 100% now?

.

Quantcast