Displaying signals internal to the architecture part of an entity

aijazbaig1 · #1 02-Sep-2006, 06:40

Hello,
I am trying to write a code to scan the code generated by the keyboard through an FPGA board. The project is now in an early development stage.
Heres the most basic process in which I try to synchronise the inputs to the system viz. kb_clk and data to the on board 'sys_clk', the system clk.
heres the code ive written,

Code:

Library ieee;

USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;

entity code_test_process1 is
    port(
     kb_clk : IN std_logic;
     data : IN std_logic_vector(7 downto 0));
end code_test_process1;
 
 architecture trial1 of code_test_process1 is
 signal sys_clk : std_logic;
 signal current_kbclk : std_logic;
 signal current_data : std_logic_vector(7 downto 0);
 begin
     process(sys_clk)
     begin
         if rising_edge(sys_clk) then
             current_kbclk <= kb_clk;
             current_data <= data;
         end if;
      end process;
 end trial1;

the test bench file for the above program is here:

Code:

library work;
Library ieee;

USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
use work.all;

entity test_bench is
    begin
    end test_bench;
    
    architecture test of test_bench is
        signal kb_clk,sys_clk : std_logic;
        signal data : std_logic_vector(7 downto 0);
        component code_test_process1 is
            port(
             kb_clk : IN std_logic;
             data : IN std_logic_vector(7 downto 0));
         end component code_test_process1;
         for all:code_test_process1 use entity work.code_test_process1(trial1);
         begin
             P1:code_test_process1 port map(kb_clk => kb_clk,data => data);
             process
                 begin
                     data <= X"10" after 100 ns,X"08" after 200 ns,X"A2" after 300 ns,X"2F" after 400 ns,X"11" after 500 ns,X"3C" after 600 ns;
                     sys_clk <= '1' after 150 ns,'0' after 250 ns,'1' after 420 ns,'0' after 475 ns,'1' after 550 ns,'1' after 570 ns;
                     kb_clk <= '1' after 50 ns,'0' after 100 ns,'1' after 150 ns,'0' after 200 ns,'1' after 250 ns,'0' after 300 ns,'1' after 350 ns,'0' after 400 ns,'1' after 450 ns,'0' after 500 ns,'1' after 550 ns,'0' after 600 ns;
                     
                     wait;
                 end process;
             end test;

What I don't understand now is how do I display the contents of the signals 'current_kbclk' and 'current_data' which are internal to the entity code_test_process1(within the architecture part and hence hidden in some way i guess)
so that I may check if the inputs are sampled only at sys_clk or not. How do I display those signals as well on the wave?

Best Regards,
Aijaz Baig.

davekw7x · #2 02-Sep-2006, 10:53

Quote:

Originally Posted by aijazbaig1

What I don't understand now is how do I display the contents of the signals 'current_kbclk' and 'current_data' ...
on the wave?

Here's where your Modelsim gui interface is a little different than the one to which I have access right now, so I can't tell you exactly how which menu items to click to display the waveforms that you want.

I assume that you have already invoked the simulator within modelsim and you have opened the "wave" window to see some waveforms.

The Modelsim command window should contain a prompt, something like

Code:

VSIM 3>

or some such thing.

In the Modelsim command window, you can try the following:

Code:

 add wave /test_bench/p1/*

(test_bench is your top-level entity and p1 is the name of the component instantiated therein. This adds all signals in that entity to the "wave" window.)

If this doesn't work, get back to me, and I will try to get some more specific instructions for your interface.

My Modelsim on-line help documentation includes a "tutorial". If yours has one, I strongly recommend that you go through it first. It should have a section on "Adding items to a Wave Window" or some such thing.

Poke around your GUI "help" documentation (Probably the User Manual). Look for a section on "Graphic Interface" and look for "Signals Window", "Struct Window" or similar-sounding items. It should show you how to display the structure of your design (a hierarchical tree of your entities) and how to display the signals within a given entity and them add the signals to the "wave" window.

Regards,

Dave

aijazbaig1 · #3 02-Sep-2006, 12:08

Hello.
I was able to add those two signals to the wave window by using the command line version command
add wave/test_bench/p1/* which adds all the signals within the component instantiation P1.

Now I seem to have a different problem. In my test_bench entity(i.e. in the architecture part) I have made sys_clk work like a clock for a specified period of time. It isn't showing up on the wave window when I simulate for about 600 ns.
Only the signals data and kb_clk seem to get updated with some values. Not even sys_clk gets updated with the values I supplied.
Would you let me know where am I going wrong here.
(I've included a zipped version of the wave image as before so that you may have a look).

And by the way its kinda sad not to be online so often like during the summer vacations but I know these courses on VHDL based design are gonna keep me a lil too busy now

Hope to hear from you soon,

davekw7x · #4 02-Sep-2006, 13:17

Quote:

Originally Posted by aijazbaig1

Now I seem to have a different problem. In my test_bench entity(i.e. in the architecture part) I have made sys_clk work like a clock for a specified period of time. It isn't showing up on the wave window when I simulate for about 600 ns.
Only the signals data and kb_clk seem to get updated with some values. Not even sys_clk gets updated with the values I supplied.

The only connections between the different entities and components of a design are through their ports.

In VHDL there are no global variables or signals. (And that's a Really, Really Good Thing, in my opinion. Not that it matters what my opinion is. There simply aren't any. Period.)

Here's your port declaration for the code_test_process entity:

Code:

    port(
     kb_clk : IN std_logic;
     data : IN std_logic_vector(7 downto 0));

There is only one signal into that entity: kb_clk

The local signal sys_clk inside code_test_process doesn't have a driver. Therefore, it has a std_logic_value of 'U' (uninitialized). Since the process inside that architecture, any signals driven by that process remain 'U'.

To get some action, you could try the following:

Code:

ARCHITECTURE trial1 OF code_test_process1 IS
    SIGNAL sys_clk       : STD_LOGIC;
    SIGNAL current_kbclk : STD_LOGIC;
    SIGNAL current_data  : STD_LOGIC_VECTOR(7 DOWNTO 0);
BEGIN

    sys_clk <= kb_clk;

    gen_data: PROCESS(sys_clk)
    BEGIN
        IF RISING_EDGE(sys_clk) THEN
            current_kbclk <= kb_clk;
            current_data  <= data;
        END IF;
     END PROCESS gen_data;

END trial1;

Or, just forget about sys_clk inside that architecture and:

Code:

ARCHITECTURE trial1 OF code_test_process1 IS
    SIGNAL current_data : STD_LOGIC_VECTOR(7 DOWNTO 0);
BEGIN

    gen_data: PROCESS(kb_clk)
    BEGIN
        IF RISING_EDGE(kb_clk) THEN
            current_data <= data;
        END IF;
    END PROCESS gen_data;

END trial1;

Regards,

Dave

aijazbaig1 · #5 03-Sep-2006, 02:55

Hello.
Thanks for the idea. However what I want is to read the keystrokes and display them on the display output of an FPGA board.
Now as per documentation, the signal kb_clk is not a real clock. It is just a signal generated by the keyboard to enable us to read the actual data corresponding to a keystroke at the 'correct time'. To be more specific, we can be sure of getting the actual data if we read in the data signal only on the falling edge of this kb_clk.
So both these signals kb_clk and kb_data are like normal inputs to the board and the first thing in this little school project is that we need to synchronise both these 'external' inputs to the on board clock viz. the sys_clk.
I've tried to accomplish this using a process as you can see. So one cannot assign the value of the signal kb_clk to the signal sys_clk as you suggested. I hope you now have an idea of what im trying to do..

And if u can suggest a simpler and/or a better way and/or something that just works

then i'd be glad to see where I am going wrong here.

davekw7x · #6 03-Sep-2006, 09:46

Quote:

Originally Posted by aijazbaig1

Hello.
Thanks for the idea. However what I want is to read the keystrokes and display them on the display output of an FPGA board.
Now as per documentation, the signal kb_clk is not a real clock. It is just a signal generated by the keyboard to enable us to read the actual data corresponding to a keystroke at the 'correct time'. To be more specific, we can be sure of getting the actual data if we read in the data signal only on the falling edge of this kb_clk.

This is a very practical problem. The easiest and most robust designs are where there is one system clock and all processes are synchronous with this clock.

Capturing outside events (that are not synchronous with respect to system clock) is almost always an issue.

In order to solve this problem you need some system specification. In all designs, before you actually start designing, you should have a design specification that describes:

inputs(s) ==> processing ==> output(s)

The rest of this post is mostly a lesson in logic design considerations, with VHDL examples of the design and its simulation testbench.

Suppose your kb_clk has a minimum pulse width of one millisecond. That is, it goes high when a key is struck and stays high for (at least) one millisecond before going low. The new data are guaranteed to be valid when the kb_clk goes low and to stay valid until the next new kb_clk event. Suppose your system_clock is running at 10 MHz. That means that its period is 100 ns, so it can be used to sample the kb_clk and will never "miss a beat". There are a couple of common, easy-to-use and easy-to-synthesize techniques for synchronizing external signals. The kb_clk signal is just treated as a "normal" signal, and does not itself go to a "clock" input of a flip-flop.

Now, suppose your kb_clk has a minimum pulse width of one microsecond and your system clock is running at 100 kHz (clock period = 10 microseconds). It should be clear that you can't use the system clock to sample the kb_clk signal in an effort to detect its falling edge. Since the system clock is so much slower, it is possible (likely) that a kb_clk pulse will be missed. In this case you capture the kb_data with a process that is triggered by the falling edge of kb_clk, and you must also create a process that uses kb_clk to set a flip-flop (or something) that stays set until a system clock comes along and resets it. In other words you still have the issue of creating a synchronous "data ready" signal from every asynchronous external keyboard event.

In both cases you have to be familiar with some practical hardware issues concerning problems that arise in the "real world" whenever the data input and clock input to a flip-flop (or whatever) change at the exact same time (or they both change within some very small time interval). The issue is covered in hardware design classes as "metastability" of sequential elements.

In the second case you have an additional issue that may affect simulation and real hardware testing: A gate array or fpga with more than one clock domain (some flip-flops affected by one clock and some affected by another) must be handled very carefully.

Another consideration for simulation (but not necessarily absolutely necessary for fpga designs) is that all sequential processes should have a reset signal so that counters and other state machines can always start in a known state before the system clock starts doing its thing. In most of my design, every single process in the whole design has an asynchronous reset signal. For historical purposes, I usually use an active-low asynchronous reset, and the processes usually look something like this:

Code:

    gen_data_rdy: PROCESS(sys_clk, resetb)
    BEGIN
        IF (resetb = '0') THEN
            data_rdy <= '0';
        ELSIF rising_edge(sys_clk) THEN
            data_rdy <= kb_pulse;
        END IF;
    END PROCESS gen_data_rdy;

This is an idiom. This is guaranteed to be synthesizable, and the use of an asynchronous reset is almost always in my designs for test purposes as well as for ease of simulation.

Here is a possible component to capture the keyboard data in the case where the system clock is much faster than external events:

Code:

-- get_kb_data.vhd
--
-- Keyboard data are guaranteed to be valid at the falling edge
-- of kb_clk.
--
--
-- It is assumed that the period of the system clock, sys_clk, is somewhat
-- shorter than the minimum positive pulse width of kb_clk
-- 
-- We capture keyboard data and make it available to the rest of
-- the system. We also generate an output signal, data_rdy, that
-- is synchronous with sys_clk and had a positive pulse width of
-- exactly one period of sys_clk.
--
LIBRARY ieee;

USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.ALL;

ENTITY get_kb_data IS
    PORT (kb_clk        : IN  std_logic;
          kb_data       : IN  std_logic_vector(7 DOWNTO 0);
          sys_clk       : IN  std_logic;
          resetb        : IN  std_logic;
          datout        : OUT std_logic_vector(7 DOWNTO 0);
          data_rdy      : OUT std_logic
          );
END get_kb_data;

ARCHITECTURE lan OF get_kb_data IS

    -- depending on technology, kb_clk may have to be reclocked
    -- in another stage.
    SIGNAL kb_clk1  : std_logic; -- kb_clk reclocked by sys_clk
    SIGNAL kb_clk2  : std_logic; -- kb_clk1 delayed one sys_clk
    SIGNAL kb_pulse : std_logic; -- kb_clk was '1' and changed to '0'



BEGIN

    --
    -- data_ready looks is generated synchronously from kb_pulse
    -- Since kb_pulse captures the data into the dataout register,
    -- reclocking kb_pulse tells the outside world that there is a
    -- new value in dataout ready to be used.
    --
    gen_data_rdy: PROCESS(sys_clk, resetb)
    BEGIN
        IF (resetb = '0') THEN
            data_rdy <= '0';
        ELSIF rising_edge(sys_clk) THEN
            data_rdy <= kb_pulse;
        END IF;
    END PROCESS gen_data_rdy;
    --
    -- generates an output that is exactly one sys_clk period wide
    -- when kb_clk goes from '1' to '0'
    --
    synchronizer: PROCESS(sys_clk, resetb)
    BEGIN
        IF (resetb = '0') THEN
            kb_pulse <= '0';
            kb_clk2  <= '0';
            kb_clk1  <= '0';
        ELSIF rising_edge(sys_clk) THEN
            kb_pulse <= kb_clk2 AND (NOT kb_clk1);
            kb_clk2  <= kb_clk1;
            kb_clk1  <= kb_clk;
        END IF;
    END PROCESS synchronizer;

    --
    -- Captures kb_data synchronously with sys_clk, using kb_pulse
    --
    gen_datout: PROCESS(sys_clk, resetb)
    BEGIN
        IF (resetb = '0') THEN
            datout <= (OTHERS => '0');
        ELSIF rising_edge(sys_clk) THEN
            IF (kb_pulse = '1') THEN
                datout <= kb_data;
            END IF;
        END IF;
    END PROCESS gen_datout;

END lan;

Here is a generator for the kb_clk and kb_data signals consistent with your example. I gave it a 10 MHz system clock. Even the cheapest FPGA components nowadays support 100 MHz (or faster) system clocks, so the use of a 10 MHz system clock is kind of "loafing along". Usually Keyboard strobes are somewhat longer (tens of milliseconds or more), but this is only an example.

Code:

-- gen_get_kb_data.vhd
--
-- Testbench signal generator for get_kb_data
--
-- For timing values given here, run the simulation for one microsecond
--
-- Note that simulation is simplified by giving all generator
-- signals initial values.
--

LIBRARY ieee;
USE     ieee.std_logic_1164.ALL;

ENTITY gen_get_kb_data IS
    PORT (kb_clk    : OUT std_logic := '0';
          kb_data   : OUT std_logic_vector(7 DOWNTO 0) := (OTHERS => '0');
          sys_clk   : OUT std_logic;
          resetb    : OUT std_logic
         );
END gen_get_kb_data;

ARCHITECTURE lan OF gen_get_kb_data IS

    -- give sys_clk an initial value so that the periodic signal
    -- can be generated with a simple assignment. This signal
    -- is the internal equivalent to sys_clk.
    --
    SIGNAL sys_clk_int   : std_logic := '0';
    CONSTANT half_period : time := 5 ns; -- half period of 10 MHz clock

BEGIN

    resetb <= '0', '1' AFTER 2 ns;

    -- Generate the system clock periodically
    --
    sys_clk     <= sys_clk_int;
    sys_clk_int <= NOT sys_clk_int AFTER half_period;


    -- For test purposes, avoid changes exactly on sys_clk edges
    -- Also, avoid changes of kb_data exactly coincident with kb_clk
    -- This example makes the data valid five nanoseconds before
    -- falling edges of kb_clk. The data remain valid long enough
    -- for the new-data event to be synchronized by sys_clk
    --
    gen_kb_clk_and_data: PROCESS
    BEGIN
        kb_data <= X"10" AFTER 100 ns,
                   x"08" AFTER 200 ns,
                   x"A2" AFTER 300 ns,
                   x"2F" AFTER 400 ns,
                   X"11" AFTER 500 ns,
                   x"3C" AFTER 600 ns;

        kb_clk  <= '1'   AFTER  55 ns,
                   '0'   AFTER 105 ns,
                   '1'   AFTER 155 ns,
                   '0'   AFTER 205 ns,
                   '1'   AFTER 255 ns,
                   '0'   AFTER 305 ns,
                   '1'   AFTER 355 ns,
                   '0'   AFTER 405 ns,
                   '1'   AFTER 455 ns,
                   '0'   AFTER 505 ns,
                   '1'   AFTER 555 ns,
                   '0'   AFTER 605 ns;
        WAIT;
    END PROCESS gen_kb_clk_and_data;
END lan;

Finally, the testbench with a simple structural architecture that ties the device under development to the signal generator:

Code:

-- test_get_kb_data.vhd
--
-- Testbench for get_kb_data
--
LIBRARY ieee;

USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.ALL;

ENTITY test_get_kb_data IS
END test_get_kb_data;

ARCHITECTURE test_bench OF test_get_kb_data IS

    COMPONENT get_kb_data
        PORT (kb_clk    : IN  std_logic;
              kb_data   : IN  std_logic_vector(7 DOWNTO 0);
              sys_clk   : IN  std_logic;
              resetb    : IN  std_logic;
              datout    : OUT std_logic_vector(7 DOWNTO 0);
              data_rdy  : OUT std_logic
              );
    END COMPONENT;

    COMPONENT gen_get_kb_data
        PORT (kb_clk    : OUT std_logic;
              kb_data   : OUT std_logic_vector(7 DOWNTO 0);
              sys_clk   : OUT std_logic;
              resetb    : OUT std_logic
             );
    END COMPONENT;

    SIGNAL kb_clk   : std_logic;
    SIGNAL kb_data  : std_logic_vector(7 DOWNTO 0);
    SIGNAL sys_clk  : std_logic;
    SIGNAL resetb   : std_logic;
    SIGNAL datout   : std_logic_vector(7 DOWNTO 0);
    SIGNAL data_rdy : std_logic;


BEGIN

    i_get_kb_data: get_kb_data
    PORT MAP (kb_clk    => kb_clk,
              kb_data   => kb_data,
              sys_clk   => sys_clk,
              resetb    => resetb,
              datout    => datout,
              data_rdy  => data_rdy
             );

    i_gen_get_kb_data: gen_get_kb_data
    PORT MAP (kb_clk    => kb_clk,
              kb_data   => kb_data,
              sys_clk   => sys_clk,
              resetb    => resetb
             );

END test_bench;

Run for 1 us.

Regards,

Dave

aijazbaig1 · #7 04-Sep-2006, 03:21

Hello.
That was one good thing to read about in the post. Now I have come up with a program which does gets compiled. However the result isn't what is expected.
To enable you to read the documentation which my school superviser provided as an 'aid' to get the job done, I've included this link where u can read what we are supposed to be doing.
Additionally, you can have a look at my post and see what can be done to fix the logical errors in the code.

Code:

--
-- VHDL Architecture lab1_lib.kbd_scanner.behavioral
--
-- Created:
--          by - aijba273.student (olympen-11.edu.isy.liu.se)
--          at - 09:26:02 09/04/06
--
-- using Mentor Graphics HDL Designer(TM) 2004.1b (Build 12)
--
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;

ENTITY kbd_scanner IS
   PORT( 
      kb_clk  : IN     std_logic;
      kb_data : IN     std_logic;
      sys_clk : IN     std_logic;
      db      : OUT    std_logic_vector (7 DOWNTO 0);
      fcs     : OUT    std_logic;
      rlcs    : OUT    std_logic;
      rrcs    : OUT    std_logic;
      rsb     : OUT    std_logic_vector (6 DOWNTO 0);
      sdcs    : OUT    std_logic
   );

-- Declarations

-- Declarations

type exemplar_string_array is array (natural range <>, natural range <>) of character;
attribute pin_number : string;
attribute array_pin_number : exemplar_string_array;
attribute buffer_sig: string;
attribute buffer_sig of sys_clk : signal is "IBUFG";
attribute pin_number of sys_clk : signal is "P88";
attribute pin_number of fcs : signal is "P41";
attribute pin_number of rlcs : signal is "P79";
attribute pin_number of rrcs : signal is "P80";
attribute pin_number of sdcs : signal is "P132";
attribute pin_number of kb_clk : signal is "P94";
attribute pin_number of kb_data : signal is "P93";
attribute array_pin_number of db : signal is ("P67", "P60", "P62", "P57", "P49", "P46", "P44",
"P68");
attribute array_pin_number of rsb : signal is ("P48", "P42", "P27", "P29", "P28", "P40",
"P47");


END kbd_scanner ;

--
ARCHITECTURE behavioral OF kbd_scanner IS
signal temp_kb_clk : std_logic;
signal temp_kb_data : std_logic;
signal detect_falling_kb_clk : std_logic:= '0';
signal scancode_barrel : std_logic_vector(9 downto 0);-- container for the whole 11 bit frame
signal scancode : std_logic_vector(7 downto 0);
begin
fcs <= '1';
rlcs <= '1';
rrcs <= '1';
sdcs <= '1';
sync_keyboard : process(sys_clk) -- process to synchonize signals kb_clk and kb_data to sys_clk
 begin
  if sys_clk'EVENT and sys_clk = '1' then -- rising edge of the sys_clk detected
   temp_kb_clk <= kb_clk;
   temp_kb_data <= kb_data;
  end if;
end process;

dtct_falling_kb_clk : process(temp_kb_clk) -- process to detect the falling edge of synchronised kb_clk
 begin
  if temp_kb_clk'EVENT and temp_kb_clk = '0' then -- falling edge of the kb_clk detected
      detect_falling_kb_clk <= '1';
  end if;
 end process;  


convert_scancode : process(detect_falling_kb_clk)
variable clk_cnt : integer := 0; 
begin
 if detect_falling_kb_clk = '1' then 
  scancode_barrel <= kb_data&scancode_barrel(9 downto 1); -- for every rising edge of the detect falling edge signal,shift the data
  clk_cnt := clk_cnt + 1;                                 -- bits in scancode_barrel to the right.do this 11 times
  if clk_cnt = 11 then 
   db <= scancode_barrel(7 downto 0);
   -- db <= scancode;  
  end if;
 end if;
 case scancode is
  when "00010110" => rsb <= "1101101";
  when "00011110" => rsb <= "0100010";
  when "00100110" => rsb <= "0100100";
  when "00100101" => rsb <= "1000101";
  when "00101110" => rsb <= "0010100";
  when "00110110" => rsb <= "0010000";
  when "00111101" => rsb <= "0101101";
  when "00111110" => rsb <= "0000000";
  when "01000110" => rsb <= "0000100";
  when "01000101" => rsb <= "0001000";
  when others => rsb <= "0010010";
 end case;
end process;
end Behavioral;

I have also included the wave window which shows that the signal detect_falling_edge doesn't behave the way it is supposed to behave. That signal should consist of signal pulses which go to 1 for an entire period of sys_clk during which the falling edge of the synchronised sys_clk has been detected. But in my own case it becomes a one during the first run and it remains so for the rest.I wonder if this is responsible for the malfunctioning of the program.

Hoping to hear from you soon,

davekw7x · #8 04-Sep-2006, 08:11

Quote:

Originally Posted by aijazbaig1

That was one good thing to read about in the post.the signal detect_falling_edge doesn't behave the way it is supposed to behave.

What a great assignment! You will learn a lot by implementing it correctly.

I won't address anything other than your sticking point:

Here's your process. (I reformatted it to my taste; there is nothing wrong with your way; I just like working with things that look familiar to me.)"

Code:

--
-- process to detect the falling edge of synchronised kb_clk
--
dtct_falling_kb_clk : PROCESS(temp_kb_clk)
BEGIN
    IF temp_kb_clk'EVENT AND temp_kb_clk = '0' THEN
        detect_falling_kb_clk <= '1';
    END IF;
END PROCESS;

You have defined a signal driver, which will be synthesized into a flip-flop that will be set to '1' when the temp_kb_clk changes from '1' to '0', and the flip-flop value stays there forever (or until power-failure or cosmic rays or some other non-simulated event causes the FPGA to lose its mind). That explains the simulation results: it is doing exactly that.

Furthermore, since it depends on an edge of kb_clk, and you are explicitly told not to use multiple clocks for a given flip-flop, there is no synchronous way ever to get it back to a '0' state again. Big problem.

Quote:

Originally Posted by your assignment--- reformatted slightly by davekw7x

1.3.3.3

To avoid a lot of trouble in the design phase a few hints are needed

1. Do not use multiple clock definitions, i.e. , use only one statement with ’EVENT defining a clock.

2. The use of ’EVENT and ’LAST_VALUE are not useful in the context of synthesis except for defining the rising or falling edge of clock.

It seems to me that one of the points here is that all signals should be synchronized to the system clock. That is, no flip-flops (or other state machines) should change values except on the rising edge of the system clock. In other words, the only signal with 'EVENT or 'LAST_VALUE attached (or with the rising_edge() stuff I showed last time) in the entire design should be your system clock. That is the essence of elementary synchronous design: one clock domain. Period.

By the way, I'm thinking that the ModelSim tcl stuff for the testbench that is in the assignment has a little flaw according to your post. I think the first line should be something like

Code:

force -repeat 83ns sys_clk 0 0, 1 42ns

The instruction in the assignment (without the "us" on the period and repetition values to indicate "microseconds") uses simulation default time steps, which is, apparently, 1 ps. (So the resulting clock has a frequency of something like 12 GHz --- somewhat beyond the range of the target technology.) Anyhow, if you are going to use the tcl stuff for your testbench, make the change I suggested, and the simulation will look more reasonable, I think (with the system clock something like 12 MHz).

Of course you can simulate this behavioral stuff with any clock speed that you want, but later on, if you want to check the simulation results with synthesized logic (including calculated delays from the actual device), you will need a more realistic clock. (You can check with your instructor to see if you are really supposed to be using a 12 GHz simulation clock.)

Now, back to the problem you specifically asked about:

I showed a general way of creating a signal you can use to detect a new key event last time, but your instructor tells you pretty much the same thing here:

Quote:

Originally Posted by your assignment

detect_falling_kb_clk
Creates an output which is one during one system clock cycle when a falling edge of the synchronized kb_clk signal has been found. This can be done by comparing the current value of the synchronized kd_clk signal with the old value (stored in the previous clock period) of the synchronized kb_clk signal.

So: use system clock to capture the old value in a flip-flop. Then at the next system clock see if the old value was '1' and the current value is '0'. (My way had a flip-flop for current value and shifted "current" value to "old" value each time for the comparison.)

Regards,

Dave

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Rate This Thread
Rate This Thread:

Displaying signals internal to the architecture part of an entity

Re: Displaying signals internal to the architecture part of an entity

Re: Displaying signals internal to the architecture part of an entity

Re: Displaying signals internal to the architecture part of an entity

Re: Displaying signals internal to the architecture part of an entity

Re: Displaying signals internal to the architecture part of an entity

Re: Displaying signals internal to the architecture part of an entity

Re: Displaying signals internal to the architecture part of an entity