help! vhdl... melting... brain...


Chris_C

Recommended Posts

ok I've been round the houses tried a number of different things and badly need a break!!!

scrMem:=scrMem + vCounter(3 downto 0);

I'm trying here to add the lowest for bits of a logic vector to an integer variable - obviously this isn't the way to do it!

 

and for further mirth enjoy this...

if cdata(hCounter(2 downto 0) downto hCounter(2 downto 0)) then

I'm trying to test the nth bit of cdata (logic vector) where the value of n is the lowest 3 bits of a logic vector

 

 

I'm so not groking the finer points of VHDL at the moment - nothing to do with the nature of fpga's I get that aspect of VHDL and circuit design isn't sequential programming thing  -  rather its the very awkward way it deals with values, bases and logic....

 

4 bits, could be four individual bits, or a nibble, or a BCD digit even (just) signed or unsigned - but struth these 4 identical bits seem to move to a different county let alone post code should you have the timerity to look at the in a slightly different way for a picosecond.... honest I've enjoyed brainf__k programming more....

 

right I'm off for a nervous break down and a strong brownian motion generator without milk...

 

 

Link to comment
Share on other sites

This should probably work.


First problem (Have to use the IEEE libraries):

scrMem := scrMem + to_integer(unsigned(vCounter(3 downto 0)));


Second (This isn't copy and paste you have to define these in the right places):


signal Nbit : std_logic_vector(2 downto 0);

Nbit <= hCounter(2 downto 0);


if (cdata(Nbit) = '?') then
    ?
else
    ?
end if;
 

Link to comment
Share on other sites

The first solution didn't seem to work, but your second suggestion helped me out... (thanks)

 

cdata := chardata(((to_integer(unsigned(ScreenMem(charx + (chary * 80)))))*16)+to_integer(unsigned(vCounter(3 downto 0))));
              

at least it works now :D.....

 

the x and y character position is used to retreve the character stored in the screen "memory" its multiplied by 16 because each character is 16 lines high, the vertical scan line position is used to select the apropriate line of the selected character...

 

I was doing this in 5 or 6 steps and I think I just munged it all together just to see if it was possible...

 

...but I still think I need to think of a better algorithm for the whole job...

Link to comment
Share on other sites

Hi Chris,

 

You want to be careful as all this has to end up being mapped onto hardware. Although you can do quite advanced math it is quite slow.

 

So you could do...

 

   mem_address <= current_start_of_row + current_column;

 

and in the clocked process

 

  if [at end of line] then

       -- move on to the next memory address as needed

 

       if [ at the end of  of horizontal raster (e.g. X = 639) ] then

         if [last line visible area (eg Y = 639) ] then

            current_start_of_row <= (others => '0');  -- reset to first memory address in frame

            mem_address           <=  (others => '0');          

         elsif [last row of a character's bitmap (e.g. y(3 downto 0)  = x"F" for characters that are 16 pixels high) ] then

            -- move to next row

            current_start_of_row <=  current_start_of_row + 80; 

            mem_address           <= current_start_of_row + 80;

         else

            mem_address           <= current_start_of_row; -- go back to the start of the current row

         end if;

      else

         if [ last pixel of character in the X axis ] then

            mem_address  <=  mem_address    + 1;

          end if;

      end if;

  end if;

 

You then end up with less complex (and therefore faster) logic - it trades complexity of logic against registers.

Link to comment
Share on other sites

yeah initially I did something equally sensible trouble was it just didn't work...

I intend to work back to something that doesn't need to multiply! at the very least!

I think I managed to track down one of my major problems, the x character position an integer accidental wasn't ranged high enough rather than have short lines for some reason it interacted (or conspired!) to throw garbage on the screen and was very difficult to diagnose.

I still cannot help but think that the hardest barrier to fpga's isn't any intrinsic property but rather vhdl - strikes me its a problem desperately in need of a solution...

maybe a new saner more usuable language could be complied into vhdl... who knows maybe verilog is the answer - I really should check it out anyhow!

Link to comment
Share on other sites

I still cannot help but think that the hardest barrier to fpga's isn't any intrinsic property but rather vhdl - strikes me its a problem desperately in need of a solution...

maybe a new saner more usuable language could be complied into vhdl... who knows maybe verilog is the answer - I really should check it out anyhow!

 

VHDL is now over 25 years old so there has been a lot of time for research in this area. - I'm sure if there was a better way it would have emerged by now.

 

You could look at MyHDL (a Python to HDL conversion), and C-to-HDL tools seem to be all the rage but expensive.

 

But maybe you are correct, and VHDL is much like programming in assembly. However, for the most part VHDL and Verilog are both in some sense complete HDLs (at least when it comes to FPGAs). As far as I can tell there is nothing that can be built using a FPGA technology that can't be expressed in either language. 

 

However, keep in mind that as you wrap things up in levels of abstraction you remove possibilities - much like how all software constructs are possible in raw machine code, not all are possible in assembler, and a lot less are possible in a high level language like 'C'.  As a concrete example, in C you can't manipulate the return address on the stack, however this was common practice when I learnt assembler.

 

It is far more likely that you are still thinking half way between programming software and designing hardware. Keep doing what you are doing - the key is to pick projects that are a little out of reach and keep stretching and grow your skills - I'm pretty sure that with just a little more experience it will all become clear.

Link to comment
Share on other sites

Yes, I think one of the negatives about Verilog is that it is so C like that people get simple things done quickly but never really transition to thinking about things from a hardware perspective. The breakthrough for me was when I bought books on Digital Logic and learned about all the basic building blocks. Then I would think about how to solve a problem using those basic building blocks, ie designing a circuit, and then how to implement those things in VHDL...

 

Jack.

Link to comment
Share on other sites

  • 2 weeks later...

Well there is the schematic entry tool in ISE, although it's rather crude and cumbersome. It does provide a great way to get started with very simple designs though.

 

I'm still very much a novice, but I have found that I struggle for a while, running up into a virtual wall of sorts and then I'll have a small breakthrough and suddenly a set of things seems perfectly clear. Then I run into another wall but it does keep getting easier. I found that writing VHDL to emulate 7400 series logic chips has been a helpful exercise, starting out with the simple gates, then working up to decoders and counters. VHDL is not so bad once you get the hang of it. I've found it easier to pick up than C, which never has really clicked well in my mind.

Link to comment
Share on other sites

Yes, this forum has been very helpful. Sometimes I just have to struggle with something for a while and then suddenly it makes sense. Other times I start to feel like my brain is just full and I have to set it aside and work on something else for a while. I also have to maintain a balance of spending some time with the other half so she doesn't complain that I've been obsessively pecking at my computer all evening.

Link to comment
Share on other sites

I've found using verilog a lot easier than VHDL but I suspect its horses for courses

this whole idea that fpga's are hard because they are a whole different paradigm is really over egged.

anyone whose made even fairly rudimentary circuits using 74 series logic should be able to get their head round things quite quickly

I still maintain the hardest thing about getting rudimentary fpga skills is VHDL

Link to comment
Share on other sites

After having learned both Verilog and VHDL, I prefer the structured nature of VHDL, I find the code easier to understand. While I generally appreciate the freedom that Verilog gives you when writing HDL, I have seen some truly horrendous pieces of code in Verilog that reminded me of obfuscated C code. It's great that the language allows you to do that, but really, should you?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.