numbers, numbers...

Hi,

First you made a pseudo gated clock with a different "clock"which is bad. I suggest you to resynchronize with your system clock (IN_CLK).

Even if it makes sense in VHDL, It is smarter using a whole unique system clock (IN_CLK) in this case.

You can correct this with :

ext_write : process(IN_RESETn, IN_CLK)
begin                           
  if IN_RESETn = '0' then        
    REG_R00_HORIZ_TOTAL_7_0  <= b"0010_1111";
  elsif falling_edge (IN_CLK) then 
       if falling_edge(IN_E) and IN_CSn='0' and IN_RW='0' then    --Grab data from data bus and program into indexed register.
          case REG_INDEX_ADDR_4_0 is                                         --Use Reg Index to write D0-7 to reg
              when INDEX_HT => REG_R00_HORIZ_TOTAL_7_0 <= IO_D_7_0;
etc

Secondly,

LIBRARY ieee;
USE ieee.STD_LOGIC_1164.all; -- 'Z' 'X' '1' '0' 'W' 'U' 'L' 'H' '-'
USE ieee.numeric_std.all; -- UNSIGNED, SIGNED,  + - * / mod 

Thank you for your response!

Now, this bit you've suggested...

  elsif falling_edge (IN_CLK) then 
       if falling_edge(IN_E) and IN_CSn='0' and IN_RW='0' then    --Grab data from data bus and program into indexed register.

... I see TWO clock events in the SAME process. I did not think you could do that?! Based on the fact I have tried to do this in the past and just got errors.

Andy

You cannot use two clock events in the same process - how do you expect this to work? the two clocks would have to be exactly co-incident for it to even work conceptually, but there is no way it will work on real hardware.

But mtushi is correct in saying using gated clocks is a bad idea. So do not use in_e as a clock - use the in_clk as the clock and in_e as enable:

elsif falling_edge (IN_CLK) then 
       if IN_E = '1' and IN_CSn='0' and IN_RW='0' then    --Grab data from data bus and program into indexed register.

And yes, also stop using std_logic_arith. It is not a standard VHDL package, numeric_std is.

If the hard coded value gives a different result to the register version, I can only assume the CPU is writing the wrong number.

So, not 'good practice' to use a signal logic operators with a clocking event. Gotcha. Do them separately. Roger will-co.

Yes, I have read that std_logic_arith is a non-standard package. Having admitted my guilt over this, as a newbie VHDLer, changing something which at the higher level simulates spot on, is something I was reluctant to do but I will now see if I can change over to using the standard library. I know I will get errors because I am using a MAKE_BINARY function:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.math_real.all;
package CONFIG is
	-- Convert UNSIGNED type to STD_LOGIC_VECTOR type
	function MAKE_BINARY(A : UNSIGNED) return STD_LOGIC_VECTOR;
        ..etc..
end package CONFIG;
package body CONFIG is
    type tbl_type is array (STD_ULOGIC) of STD_ULOGIC;
    constant tbl_BINARY : tbl_type := ('X', 'X', '0', '1', 'X', 'X', '0', '1', 'X');
    function MAKE_BINARY(A : UNSIGNED) return STD_LOGIC_VECTOR is
	variable one_bit : STD_ULOGIC;
	variable result : STD_LOGIC_VECTOR (A'range);
    begin
	    for i in A'range loop
		  result(i) := tbl_BINARY(A(i));
	    end loop;
	    return result;
    end;
end CONFIG;

Yes, I copied that lot (not my own, hell I'm learning VHDL ;) ). No doubt more non-standard horribleness.

--- Quote Start ---

If the hard coded value gives a different result to the register version, I can only assume the CPU is writing the wrong number.

--- Quote End ---

Maybe. But the signals are (as far as I can tell) that come from my core processor when first programming this VHDL model of my 'chip' are spot on as well. The simulator couldn't 'see' these actual register contents, so I might now simply add a vector such that I can monitor the register contents.

Thanks again!

Andy

your "make_binary" function is redundant for your code as it is now. As unsigned and std_logic_vector are closely related types (they are both arrays of std_logic) you can convert from one to the other using a simple type case:

my_slv <= std_logic_vector(my_us);

my_us <= unsigned(my_slv);

it also does some X01 conversion, there already exists a function for this, called to_X01.

my_slv <= to_X01(my_slv);

But why do you want to have only 'X' and 0 or 1? the 'U' value lets you know in simulation that something hasnt been initialised properly. and how are you going to cope with 'Z' when you need to build a tri-state driver?

It seems you're re-writing code that already exists, and you probably dont need to use them anyway.

--- Quote Start ---

It seems you're re-writing code that already exists, and you probably don't need to use them anyway.

--- Quote End ---

Yes, some of it (as admitted above). And therein 'learning'... the hard way I guess. ;)

What is X01? Google time (again)..

Now we are getting to the nitty-gritty of VHDL number systems. Good. I likey. This is what I would very much like to get a firm grasp of.

Thank you again (for bearing with my most basic of questions). A lot of info on this on the internet, but far too 'varied' and in some cases contradictory, hence this thread really.

Andy

It might be easier if you try and explain what you are trying to do.

VHDL has no special number system. I think you're getting confused over the typing system.

An integer in VHDL is just a number. If used in synthesisable code, the synthesisor should convert it into a 32 bit 2's compliment notation.

The numeric_std library defines the unsigned and signed types. unsigned is pure 2^n logic, signed is 2s complement. But the reason we use unsigned is as followed:

1. It gives access to the bits inside the VHDL code.

2. We can set the length ourselves.

(these two also hold true for std_logic_vector also)

3. We can do arithmatic with it.

4. It will roll over - integer type will not (this is useful for things like address generation for FIFOs).

So, I think you're trying to run before you can walk. re-writing the basics that already exist in VHDL show you're trying too much too soon and overcomplicating your learning.

All true.

Been learning for about 6 months now, due in main to there being a MASSIVE hole in my CV where 'FPGA' & 'VHDL' should be written. Got hold of FreeRange VHDL tutorial and went from there. After getting bored with making numbers appear on a HEX display on my version of the Papilio Pro board, I thought 'sod it, I wonder if I can can make an entire computer run in my FPGA'. Like they did for the ZX Spectrum, I am now trying to do for a Camputers Lynx.

Using the OpenCores Z80 (T80 core) I found it amazingly simple for my FPGA to run the original ROM code as a VHDL LUT. In went all the glue logic (re-written many times as I learn the correct way to do things), block RAM acting as old-school DRAM etc. That works. Then went in sound, and it 'Beeps' now when powered up, just like the original Lynx. Now to make something appear on an old TV. To do that, the old Lynx computer uses a CRTC6845 chip. Again, on OpenCores, there it was so in it went (little point in reinventing the wheel). Unfortunately that core for the 6845 was not complete, so I have rewritten almost all of it and now it works (OK, simulates)... but as a result of trying to unravel it I see non-standard libraries and as you've pointed out, unnecessary functions. So I will re-write that to make it more compatible and 'correct'.

Yes I am learning, but the way I learn is through practice and by chucking myself in at the deep end and I never give up! Admittedly, a bit ar$e about face way of learning but there you go that's just the way I am. I am enjoying learning VHDL so much (apart from the many, many frustrations in getting my brain to work) and in doing so, dispelling the old theory that you cannot teach an old dog new tricks. I'm getting there (he says).

Thank you again for taking the time to respond to my thread!

Andy

Anywho, let me see if I have this right in my tiny brain:

use IEEE.std_logic_1164.all;

defines what various 'standard' states a signal state can be in at any given point in time, i.e. 'Z' 'X' '1' '0' 'W' 'U' 'L' 'H' '-'

A signal (or vector) can be all of these states, or indeed a subset of these. If using a subset, then depending on what is missing (e.g. 'Z') then the simulation may miss out on telling the user that something 'weird' is going on.

use ieee.numeric_std.all;

A standard library one would want to use.

It defines (among other things I guess):

UNSIGNED
SIGNED
+ 
- 
* 
/ 
mod

So that simple signed and unsigned math can be used on vectors: add, subtract, multiply, divide and modulus.

Also comparisons (operators) between vectors of whatever type, SIGNED or UNSIGNED:

=
/=
<=
>=
>
<

So thinking ahead then, if I wish to use a counter which I know I will want to add 1 to it periodically and then compare it to another number... hence I would want to declare it as an UNSIGNED (or SIGNED):

signal counter : UNSIGNED (7  downto 0);

And hence in a process somewhere, this is therefore OK to then do if I want to increase that counter by 1:

counter <= counter + 1;

Now I want to compare that number to another number say from a data-bus at a certain point in time. the data bus is however declared thus:

DataBus_7_0 : in STD_LOGIC_VECTOR (7 downto 0);

So, in order to match the two types, one must therefore 'cast' into the numeric_std type as this is where the compare '=' operator is defined.

Am I right in assuming this is how this is done correctly:

if counter = UNSIGNED(DataBus_7_0) then
  do_something_very_cool;

But what about comparing to a fixed number? Is this OK:

  if counter = b"0010_0000" then
    do_something_even_cooler;

Question here: that number: b"0010_0000" isn't really a 'number' per-se is it? The above comparison will actually be a logical comparison of bits yes? in other words it is both SIGNED and UNSIGNED if you get my drift? Or is this a necessity instead (or 'better practice')?:

  if counter = UNSIGNED(b"0010_0000") then
    do_make_Andy_cool_and_not_a_pedantic_nerd;

Cheers,

Andy

if counter = b"0010_0000" then
    do_something_even_cooler;

I suggest

if counter = 32 then

Unsigned or signed compare operations are performed with integer values as well.