It sounds like having a problem with system design first, doesn't it?

We can't know how much knowldege you have yet. So, assuming, that you 
are familiar with digital design and its basic elements (combinatorial 
logic, Registers, RAMs etc.), which would be a reasonable basis for such 
a project, I would recomand the following.

Step back und try to imagine the overall system. Watch your step, as 
there could be a stool standing around :-)

You allready identified necessity of controlling LEDs. Matrix is a good 
idea. Don't know, how? Try to find some circuits to do that focusing on 
the matrix itself and switching by transistors. Those circuits are 
usually meant to be used by a microcontroller. But their output is 
comparable to that of an FPGA in respect being "digital". Only issue 
could be that the output levels differ more or less slightly. But this 
could be considered easily.

OK. Second. Some system to hold the image at its current state. State is 
changing over time (as the snake is moving). Any idea?

Third: Some system, especially a system of representation of simple 
graphical elements. This must be considered in conjunction with a fourth 
system, which takes that description, interprets it and transfers bit 
states at certain positions in the "thing" which holds the image.

Fourth: As said, a part, which interprets descriptions.

Fifth: A system which is able to manipulate the descriptions, defined by 
point 3, implemented as point 4. regarding your objective it must be 
able to manipulate x and y coordinates (in case your definition of such 
a description uses them - I would use such coordinates. It must have an 
input, whith the meaning of a direction which is then interpreted and 
changes the parameters of the graphical objects.

Sixth: a system which takes input from the real word - a joystick, a 
keyboard, just four push-swithces or something similar. This must read 
in (possibly debounced) and converted to a form of data which may be 
input to part 5.


Try to imagine this parts. First, in respect to their behavior more than 
in that of their structure. But later, of course, more reallistic as you 
must finally input some structure description in VHDL.

I would expect a series of sketches, which increase in detailedness. 
First, some connections with a note, which information they transport. A 
bunch of white boxes with some notes in it, what they do. Consider 
system in and output of the whole system.

Possibly, this gives you an idea how to begin and to proceed to a point 
where one may reason about.

Whish you good luck and always a pile of packages with coffee in your 
kitchen. You will need it. :-)

Sorry. Being worried stirring in that pot of numbers. :-)

> ... converted to a form of data which may be input to part 5.
(I didn't mention any part #5).

must be

... converted to a form of data which may be input to part 4.

Damn! Must be part #5. I am so sorry. :-[

By the way. The system decomposition was only a proposal, Feel free to 
divide parts in another way. But!

But its a good old engineers method to divide apparently "complex" 
systems into parts. Reduce complexity. It's a good occasion to exercise 
that.

Fourth point was a bit laconic.

What I meant was: Think about a way to "describe" the graphical elements 
your matrix shall show. The result is just a paper, saying something 
like:

My device will handle points of one dot. A dot is described by its x and 
y coordinate on the matrix. Advance to other elements. Which information 
will allow the distinction of dot and f.e. lines?

Each graphical element you want to display must be contained in that 
description. And consider that each information and each set of 
information which you use in your description must finally be physically 
represented inside your FPGA as a certain bit pattern. You description 
must describe that pattern, too.

OK. Hope that helps.

Seems, we each own a blanket, with the same design. :-)

-----

Seriously: Whow, whow, whow, whow. 19 hours to get form "How to do it at 
all" to such a code. That's quite fast. Had any sleep? Or did you have 
already started days before posing the first question?


Unfortunately you made some mistakes in regard to how to present the 
problem and the code.

1. Use indenting. It will ease reading and understanding. You partially 
did, but not enough.

2. Use "speaking" signal names. While the meaning of 'x' and 'y' is 
likely to be derived from your question, something like 'decA0_4' is as 
cryptic as one may wish. What the heck, does that mean? Same for 'div' 
and 'buf'. We are able to make reasonable guesses but it is more kindly 
to save us from guessing.

3. Use comments and verbal descritions. This is especially true in a 
situation where you started from "How to at all"? We can't imagine in 
which way you came to that code and can't hence come to any reasonable 
opinion about how to proceed. At last, we are courious about your 
project, too.

4. But at first: Clearly state your problem. Something, "it doesn't do" 
isn't sufficient to help you. How should it work, and what's the result 
of your attempt? What is 'buf' and why the heck shall it be manipulated 
and in which way?

Understand me right: If it would be obvious, that you are an advanced 
amateuer, we coud ommit explanations in detail as your code would speak 
for itself and your question, while your question would touch the 
essence of the problem. But in this case, neither is true.


It could not be overemphasized to work structured, perform analysis and 
provide and exercise verbalisations. As this seems not the case with 
professionals, they do it nonetheless - but inside their heads with much 
lesser paperwork as at their beginnings.