Ultrasound transmitter pulse

[jimmykk]

Hi
I aM trying to get a short pulse of frequency 50khz with 5 cycles from MD1213. The problem i am getting is that i am able to get only a single output from OUTB while OUTA is at VH(5V) level and does not provide any pulse out of it. i am using Altera DE1 SOC board for logic and logic for INA, INB and OE (all are between 0 and 3.3v) are coming from this board + 5V supply voltage is PROVIDED TO VDD1, VDD2 and VH while VL, VSS1 and VSS2 are connected to ground. I am not sure whether it is a hardware problem or software. Anyways, i have attached my VHDL code for this. Please check and suggest some improvements.

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
 
entity pulse_tx is
 
port(
clock_50    : in std_logic;
GPIO_0      : inout std_logic_vector(35 downto 0)
 
);
end pulse_tx;
 
 
architecture arch of pulse_tx is
 
type state_type is (init, write_state, idle_state);
signal state : state_type := init;
signal clock_5 : std_logic := '0';
signal clk_div : integer range 0 to 5 := 0;
signal count   : integer range 0 to 500000 := 0;
 
begin
-- GPIO_0(0) <= OE OF MD1213;
-- GPIO_0(1) <= INA OF MD1213;
-- GPIO_0(3) <= INB OF MD1213;
GPIO_0(35 downto 4) <= (others => '0');
 
 
process(clock_50)      -- CLOCK DIVISION PROCESS
begin
if(rising_edge(clock_50)) then
if (clk_div = 4) then
clock_5 <= clock_5 xor '1';
clk_div <= 0;
else  
clk_div <= clk_div + 1;
end if;
end if;
end process;
 
process(clock_50)
begin
if(rising_edge(clock_5)) then
if(clk_div= 4 and clock_5 = '1') then
case state is
 
when init =>
 
GPIO_0(0) <= '0';
GPIO_0(1) <= '0';
GPIO_0(3) <= '1';
if (count = 100) then
count <= count + 1;
state <= write_state;
else 
count <= count + 1;
state <= init;
end if;
 
 
when write_state =>
 
if (count > 100 and count < 250000) then
count <= count + 1;
 
if   (count = 190000) then
GPIO_0(0) <= '1';
state <= write_state;
elsif(count = 200000) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '1';
state <= write_state;
elsif(count = 200050) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '0';
GPIO_0(3) <= '0';
 
state <= write_state;
elsif(count = 200100) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '1';
GPIO_0(3) <= '1';
 
state <= write_state;
elsif(count = 200150) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '0';
GPIO_0(3) <= '0';
 
state <= write_state;
elsif(count = 200200) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '1';
GPIO_0(3) <= '1';
 
state <= write_state;
elsif(count = 200250) then
GPIO_0(1) <= '0';
GPIO_0(0) <= '1';
GPIO_0(3) <= '0';
 
state <= write_state;
elsif(count = 200300) then
GPIO_0(1) <= '1';
GPIO_0(0) <= '1';
GPIO_0(3) <= '1';
 
state <= write_state;
elsif(count = 200350) then
GPIO_0(1) <= '0';
GPIO_0(0) <= '1';
GPIO_0(3) <= '0';
 
state <= write_state;
elsif(count = 200400) then
GPIO_0(1) <= '1';
GPIO_0(3) <= '1';
GPIO_0(0) <= '1';
 
state <= write_state;
elsif(count = 200450) then
GPIO_0(1) <= '0';
GPIO_0(0) <= '1';
GPIO_0(3) <= '0';
 
state <= write_state;
elsif(count = 200500) then
 
GPIO_0(0) <= '1';
GPIO_0(3) <= '1';
state <= write_state;
 
else 
state <= write_state;
end if;
 
elsif(count = 250000) then
count <= count + 1;
state <= idle_state;
end if;
 
when idle_state =>
 
if(count > 250000 and count < 500000) then
GPIO_0(0)  <= '0';
if (count = 499999) then
count <= 101;
state <= write_state;
else 
count <= count + 1;
state <= idle_state;
end if;
end if;
 
 
 
 
end case;
end if;
end if;
end process;
end arch;

---

 

[TrickyDicky]

Well there is one fundamental bug in your code.
The 2nd process has clock_50 in the sensitivity list, but actually uses clock_5 This means the process will not work at all in simulation!
This is another important point - why do you have a generated clock? They are very bad practice on FPGAs, it can cause all sorts of timing problems - you should look into using clock enables instead.

Why is GPIO an inout? you only ever assign values to it, and never use it like a tristate - you also have no tri-state direction signals, so GPIO should just be declared OUT. FPGAs do not have internal tri-states anyway, so everything should be declared In or Out, not INOUT (unless it connects directly to a pin).

 

[rahdirs]

why do you have a generated clock? They are very bad practice on FPGAs, it can cause all sorts of timing problems - you should look into using clock enables instead.

Not to deviate from the topis of this thread,but i don't think it is an issue if generate clocks by using clocking wizard ip core which uses either pll or mmcm rather than gated clock.

Some people constraint the gated clock to use clock signal routing resources that ensure low skew delivery rather than normal logic signal routing resources.But i don't know if doing this a good practice ?

 

[TrickyDicky]

Using a PLL is a good idea.
Using logic generated clocks is bad practice - its much harder to control the timing/skew

 

[ads-ee]

Not to deviate from the topis of this thread,but i don't think it is an issue if generate clocks by using clocking wizard ip core which uses either pll or mmcm rather than gated clock.

Some people constraint the gated clock to use clock signal routing resources that ensure low skew delivery rather than normal logic signal routing resources.But i don't know if doing this a good practice ?

Did you even look at the OP's code?

They generate a clock using a divider implemented in LUT-FF logic. The output clock comes from a FF not a PLL (there are NO MMCMs in an Altera part!)

On your second topic, the tools will regularly utilize the global clock routing for high fan out nets like clock enables.
A gate control on a gated clock can't use that type of resource as it needs to gate the clock prior to running it onto a global clock line.

Do you have any experience using FPGAs? These are the types of design decisions that end up costing companies a lot of wasted money when the not so competent engineer puts junk like this into a design and it starts to exhibit field/qa_testing problems during a production run. This usually happens after the first production run passed with no problems due to a different FPGA lot code.

 

[rahdirs]

Did you even look at the OP's code?
They generate a clock using a divider implemented in LUT-FF logic.

Yeah i saw his code & knew that he was using logic generated clocks.
My reply was to @TrickyDicks post,hence "not to deviate from the topic of this thread" in line1

 

[ads-ee]

Using logic generated clocks is bad practice - its much harder to control the timing/skew

Exactly, seen this and was brought in to fix two different designs that used generated and gated clocks. First design fixed by hand each and every clock gating circuit in the FPGA by hand placing and routing all gating nets. (Because I was told the design works and it just needs tweaks to get it up and running, yeah right...took me 3 months to fix all the timing problems). Second design, I threw the original FPGA designers design away, and started from the specification (took 3 months to get it up and running from design start to lab bring up (zero problems in integration), only problem in the design was a inverted input signal, was named incorrectly, and a messed up clock coming into the FPGA, non-monotonic transition between logic levels :shock:.

So moral of my story is the OP should not use generated clocks or use some gated clock structure to implement their design.

- - - Updated - - -

About the OP's code it seems to not be well though out. There seems to be a lot of redundant assignments that should be done in one place and overridden in the one place it needs to be.

Also I think the counter value could be reduced if the design used an enable instead along with a much easier to read case statement in place of the if-elsif-elsif....endif structure.

 

[jimmykk]

Thanks a lot for your contribution .....i have changed GPIO to OUT
but i did not get this thing about clock:-

"The 2nd process has clock_50 in the sensitivity list, but actually uses clock_5 This means the process will not work at all in simulation!
This is another important point - why do you have a generated clock? They are very bad practice on FPGAs, it can cause all sorts of timing problems - you should look into using clock enables instead."

can you please post the way you want me to implement clock using clock enables.

Also, as i mentioned that OUTB was coming out fine but OUTA was already at high level(VH). here are the two screenshots for: 1. OE, INA and INB
2. OE, OUTA and OUTB respectively.

i think If OUTB is coming, then OUTA should also be working or maybe there is hardware problem.

 

[TrickyDicky]

can you please post the way you want me to implement clock using clock enables.

You dont implement a clock at all, you create a clock enable. You run all your logic at the system clock level, and anything that runs slower uses the clock enable:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
process(clk)
begin
  if rising_edge(clk) then
    enable <= not enable;
 
    if enable = '1' then
      --stuff in here runs at clk/2
    end if;
  end if;
end process;

---

 

[ads-ee]

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
-- divide by 4 enable
process (clk, rst)
begin
  if (rst = '1') then  -- async reset
    count <= 0;
    enable <= '0';
  elsif rising_edge(clk) then
    count <= count + 1;
    if (count = 3) then
      enable <= '1';
    else
      enable <= '0';
    end if;
  end if;
begin
end process;
 
-- process running at clk, but only enabled every clk/4.
process (clk)
begin
  if rising_edge(clk) then
    if (rst = '1') then -- synchronous reset
      -- reset values
    elsif (enable) then
      -- do this stuff every clock cycle when enabled
    end if;
  end if;
end process;

---

oh, well looks like tricky beat me at posting, but at least mine is different because it shows how to do this with more than a divide by 2.

 

[rahdirs]

This is another important point - why do you have a generated clock? They are very bad practice on FPGAs, it can cause all sorts of timing problems - you should look into using clock enables instead."

can you please post the way you want me to implement clock using clock enables.

In a clock enable design,there would no be clock_5,you'll only only have clock_50,but you would have another ce (clock enable)signal input that would rise every clock_50/clock_5 cycles (4 ?) for only one cycle of the clock_50 signal. Effectively only switching on my circuit once every clock_50/clock_5 system clocks.

Generate the clock enable from the counter as follows:

-- vhdl
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
 
-- entity declaration
 
architecture dancing is
     signal counter : natural range 0 to 3 := 0;
     signal clk_en : std_logic := '0'; 
begin
     clockdivider : process (clock_50) is
     begin
        if rising_edge ( clock_50) then
            counter <= (counter + 1) mod 4;
            if (counter = 3) then
                clk_en <= '1';
            else
                clk_en <= '0';
            end if;
        end if; -- clock edge
    end process clockdivider;

And to use the clock enable, inside your 2nd process.

   -- use the clock enable whenever you need to do something at the sample frequency.
   do_something : process (clock_50) is
   begin
        if rising_edge (clock_50) then
            isEnabled : if clken = '1' then
                -- ... do whatever 
            end if isEnabled;
      end if; -- clock
    end process do_something;

--Updated
Looks like my post is same as @ads-ee.Ignore this then.
And you need to add other signals into your sensitivity list which are being read inside process

 

[jimmykk]

Hi
i made the changes and reposting the code. Now guys, what you think about that OUTA problem. If you think code is ok, then definitely problem is somewhere with hardware. i can provide my schematics if needed.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity pulse_tx is

port(
clock_50    : in std_logic;
GPIO_0      : out std_logic_vector(35 downto 0)

);
end pulse_tx;
architecture arch of pulse_tx is
type state_type is (init, write_state, idle_state);
signal state : state_type := init;
signal clk_en : std_logic := '0';
signal counter : integer range 0 to 9 := 0;
signal count   : integer range 0 to 500000 := 0;

begin
-- GPIO_0(0) <= OE OF MD1213;
-- GPIO_0(1) <= INA OF MD1213;
-- GPIO_0(3) <= INB OF MD1213;
GPIO_0(35 downto 4) <= (others => '0');
GPIO_0(2) <=  clk_en;

process(clock_50)      -- CLOCK DIVISION PROCESS
begin
if(rising_edge(clock_50)) then
counter <= counter + 1;
if (counter = 9) then
clk_en <= '1';
counter <= 0;
else 
clk_en <= '0';

end if;
end if;
end process;

process(clock_50)
begin
if(rising_edge(clock_50)) then
if (clk_en = '1') then
case state is

when init =>
--count <= 0;
GPIO_0(0) <= '0';
GPIO_0(1) <= '0';
GPIO_0(3) <= '1';
if (count = 100) then
count <= count + 1;
state <= write_state;
else 
count <= count + 1;
state <= init;
end if;


when write_state =>

if (count > 100 and count < 250000) then
count <= count + 1;

if   (count = 190000) then
GPIO_0(0) <= '1';
state <= write_state;
elsif(count = 200000) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '1';
--GPIO_0(3) <= '1';
--count <= count + 1;
state <= write_state;
elsif(count = 200050) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '0';
GPIO_0(3) <= '0';
--count <= count + 1;
state <= write_state;
elsif(count = 200100) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '1';
GPIO_0(3) <= '1';
--count <= count + 1;
state <= write_state;
elsif(count = 200150) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '0';
GPIO_0(3) <= '0';
--count <= count + 1;
state <= write_state;
elsif(count = 200200) then
GPIO_0(0) <= '1';
GPIO_0(1) <= '1';
GPIO_0(3) <= '1';
--count <= count + 1;
state <= write_state;
elsif(count = 200250) then
GPIO_0(1) <= '0';
GPIO_0(0) <= '1';
GPIO_0(3) <= '0';
--count <= count + 1;
state <= write_state;
elsif(count = 200300) then
GPIO_0(1) <= '1';
GPIO_0(0) <= '1';
GPIO_0(3) <= '1';
--count <= count + 1;
state <= write_state;
elsif(count = 200350) then
GPIO_0(1) <= '0';
GPIO_0(0) <= '1';
GPIO_0(3) <= '0';
--count <= count + 1;
state <= write_state;
elsif(count = 200400) then
GPIO_0(1) <= '1';
GPIO_0(3) <= '1';
GPIO_0(0) <= '1';
--count <= count + 1;
state <= write_state;
elsif(count = 200450) then
GPIO_0(1) <= '0';
GPIO_0(0) <= '1';
GPIO_0(3) <= '0';
--count <= count + 1;
state <= write_state;
elsif(count = 200500) then
--GPIO_0(1) <= '0';
GPIO_0(0) <= '1';
GPIO_0(3) <= '1';
----count <= count + 1;
state <= write_state;
else 
--count <= count + 1;
state <= write_state;
end if;

elsif(count = 250000) then
count <= count + 1;
state <= idle_state;


end if;

when idle_state =>

if(count > 250000 and count < 500000) then
GPIO_0(0)  <= '0';
--GPIO_0(1)  <= '0';
--GPIO_0(3)  <= '1';
if (count = 499999) then
count <= 101;
state <= write_state;
else 
count <= count + 1;
state <= idle_state;
end if;
end if;




end case;
end if;
end if;
end process;
end arch;

 

[TrickyDicky]

Did you check your code in a stimulated test bench to ensure it produces the correct values at the correct time?

 

[jimmykk]

i did check it...i will try to change the hardware and then retry, hopefully this helps

 

[D.A.(Tony)Stewart]

Zoom better so I can see actual vs expected and show difference

 

[jimmykk]

Hi
Here is the zoomed ones FOR ONE of the input and its corresponding output