> i need to produce a signal with rising edge alone of 1 micro second in> test bench, please help.
Several parameters are missing. What is the lower value (bottom
horizontal line) and what is the upper value (top horizontal line). They
cannot be simply '0' and '1', because in digital levels (like the "bit"
type or the "std_logic" type) there is nothing in between...
Why do you write HOW you want to solve something, and not simply, WHAT
you need this for?
It is of course (without any problems) possible to generate "analog"
values in VHDL. This here generates a real ramp from 0.0 to 1.0
between 10 and 11 us:
entity ramp isPort (o : outreal);
architecture Behavioral of ramp isbeginprocessbeginwaitfor10 ns;
if now<10 us then-- before the "rising edge"
o <= 0.0;
elsif now>11 us then-- after the "rising edge"
o <= 1.0;
else-- Ladies and Gentelemen: the "rising edge"
o <= real((now-10 us)/1 ns)/1000.0;
>It is of course (without any problems) possible to generate "analog">values in VHDL.
Cool, now you just have to find an input where you can feed it to. ;-)
Unless you are a little more specific about your intentions what you
want to do in which context, you won't get useful advice. :-(
Peter K. wrote:> Cool, now you just have to find an input where you can feed it to. ;-)
Because all of this discussion is in my eyes only good for simulation,
you can feed it everywhere... ;-)
But of course something like this may be of interest also in generating
stimuli in a testbench for a synthesizable device. Of course the real
value you get up there must then be converted to any kind of digital
vector. But that indeed wil involve only one additional line of code.
thanku friends for ur kind response
am new in the field of vhdl,
now am working on rtx1280rh fpga
the processor vl generate a watch dog clear pulse, in the absence of
this pulse fpga vl generate a nonmaskable interupt.
in vhdl programming in testbench stimulus i found all signal transition
from 0 to 1 0r 1 to 0.
the nmi is generated at the falling edge of a data ready signal.
the error found was continous unpredictable occurrence of nmi,i believe
dat if i could jst make a change in the falling edge of data ready,
rather dan a sudden transition from 1 to 0 in test bench ,the problem
could be solved
> rtx1280rh fpga
Google does find absolutely nothing about that...
> the processor vl generate a watch dog clear pulse, in the absence of> this pulse fpga vl generate a nonmaskable interupt.
This sounds like a pure digital design.
> i believe dat if i could jst make a change in the falling edge of data> ready, rather dan a sudden transition from 1 to 0 in test bench ,the> problem could be solved
Why do you believe that? You have a pure digital design, why do you want
to trick around with analog values? If there is any problem it will be a
timing or a behaviour problem. But nothing you can solve with "a little
> the error found was continous unpredictable occurrence of nmi,
How did you find that error? With a test bench? Or in "real life"?
> i believe
Maybe thats the wrong way...
entity testbench is
architecture behavioral of testbench is
signal tb_Clock6MHz:std_logic :='0');
component WDModule_behave is
variable o:out real;
wait for 495 us;
if now<495 us then -- before the "rising edge"
o <= 0.0;
elsif now>496 us then -- after the "rising edge"
o <= 1.0;
else -- the "rising edge"
o <= real((now-495 us)/1 ns)/1000.0;
tb_WDclr <='0','1' after 557us,'0' after 557.555us,'1' after 667us,'0'
tb_Clock6MHz <=not tb_Clock6MHz after tb_Clk/2.0;
tb_Aclr ='0','1' after 480500ns,'0' after 480550ns,'1' after
482500ns,'0' after 482800ns,'1' after 1556us,'0' after 1556.3us
WDModule_behave_0:WDModule_behave port map
--i want to control xdrdy rising edge, can any one point out the error
in this programming???????
> --i want to control xdrdy rising edge, can any one point out the error> in this programming???????> Xdrdy:in std_logic;
A std_logic has 9 possible values, starting with U then X, 0, 1, Z, W,
L, H to - (thats the way, the type std_logic is defined!)
And there is absolutely no way to assign a value half between 0 and 1
to a std_logic. So the main problem is, that you obviously do not have
the faintest idea what you are doing!
Answer this question in a conclusive way: WHY do you think, your problem
could be solved with "a slow rising edge"?
"a slow rising edge"?????
no i need a fast rising edge
the xdrdy coming is not an ideal(lyk a perfect square wave)one, it is
having rising and falling edge, i need 2 control it and make them
perfect square like,becoz of this falling edge nmi is generated
> the xdrdy coming is not an ideal
You cannot simulate a "not ideal" std_logic input!
So the problem does not come from and is not solvable within simulation.
> the xdrdy coming is not an ideal(lyk a perfect square wave)one
So that is a signal in real life, not just in simulation? You can
measure that signal with an oscilloscope? How does it look like? What
you need to "sharpen" a slow rising signal in real life is a
schmitttrigger, or a debouncing unit with edge detection.
But again: you cannot simulate that "slow" slope with a std_logic type!
ofcourse it was viewd in oscilloscope , then only it was analysed dat
its bcoz of that slow falling edge error is occuring,practically its nt
possible to attain ideal one, bt atleast we can reduce the falling
> ofcourse it was viewd in oscilloscope>> ...>>> a sudden transition from 1 to 0 in test bench
Youre mixing and muddling up real life and simulation. And that makes it
a hard task to help you. For future: it is a BIG difference betwenn
simulation and real life. Although a design may run perfectly in
simulation, it may do not a single step in real life. And so it is
ESSENTIALLY to get clear, where the problem is!
> we can reduce the falling edge???
You CANNOT reduce the slope. It is defined by hardware. Find out, WHY
thata signals slope isn't steep enough. See, how you can fix it at the
source of that signal.
If a fix there is not possible then YOUR design must cope up with a slow
falling slope. And here are two ways:
1. Take an additional schmitttrigger buffer outside the FPGA
(fast, but with impact on hardware)
2. Use "debouncing and edge detection" inside the FPGA
(will produce several cycles latency)