hi guys,
i've written the following code as a control unit for my project (FPGA
implementation of a functional microcontroller).
the code is working in simulation using modelsim.
also it is synthesised using xilinx.
but when i program it on an actual FPGA(spatan 3) i'm not getting
correct working.
the part which is not working is when i give the IN instruction.
for entering a data the in_s state will continue until the enter pin has
a low to high transition. (refer lines 104 to 110 of program)
but it is not working.
the in_s state is continuing infinitely.
please help me with this.
Thanks in advance.
vhdl newbie wrote:> elsif (rising_edge(clk)) then> current_s <= next_s; --state change.> pc_reset<='0';> end if;
...
> when in_s => --when current state is "in_s"> if rising_edge(enter) then> next_s <= fetch;> else> next_s <= in_s;> end if;
this is a very ugly way to describe hardware and is a complex type of
gated clock! I wonder, that this gets synthesized.
I disbelieve, that even the simulation works completely. The state
machine would only switch, if two signal edges occures at the same time:
clk and enter. This is a infinity small time window.
The usual way is to capture the enter signal and compare the captured
signal with the actual value.
sir thanks for your reply.
i've edited my code and is posting it now.
the previous code was a wrong code and was not the code which i wanted.
posting the actual code here.
What do you expect this to do? As you described a strictly combinatorial
process, the condition is constantly false.
This is'nt a matter for a total newbie I think. You shall consider basic
VHDL first and try simple constructions using the principle before
trying such things and get lost in overwhelmingly large texts.
By the way:
1. Please add such lengthy code as an attachment rather than literally
as a part of the posts text.
2. You do not write programs in VHDL but describe structures Please
consider this as it may be the very reason for using the construct which
I cited above.
Typo wrote:> enter_r<=enter;> if(enter_r='0' and enter='1') then> next_s <= fetch;> else> next_s <= in_s;> end if;>> What do you expect this to do?
sir, i expect this to give a rising edge detection of the enter input.
Typo wrote:> Please add such lengthy code as an attachment rather than literally> as a part of the posts text.
i'll keep that in mind :)
>Sir, ...
No need to be so formal here. Just call us be our nicks. :-)
> ... i expect this to give a rising edge detection of the enter input.
I thought so. But it seem i was a bit too laconic.
This:
>As you described a strictly combinatorial>process, the condition is constantly false.
contained the hint.
If you are unsure if something is combinatorical or clocked have look at
the implementation. How you may have a look at it depends on the
software you use.
However, if enter is not clocked into a flip-flop the code is not proper
for detecting edges.
vhdl newbie wrote:> i've edited my code and is posting it now.
Pls attach long VHDL code as *.vhd file!
Its also qouted in the box where you enter your text:
1
Rules — please read before posting
2
3
Post long source code as attachment, not in the text
Typo wrote:> not write programs in VHDL but describe structures ...
... or hardware behaviour.
But as the word itself says: VHDL is a hardware description language,
not a hardware programming language.
vhdl newbie wrote:> i've edited my code and is posting it now.
And ist this code ok in simulation? I assume not, because:
> process (current_s,enter,input,a_zero_status)
enter_r is missing in this sensitivity list.
> load_a <= "UUU";> load_b <= "UUU";
Do you think the synthesizer can implement 'U' level in real hardware?
Which voltage would one measure on a 'U' level?
Typo wrote:> if enter is not clocked into a flip-flop the code is not proper> for detecting edges.
i've changed my code now. (check line 39)
please check my code and see whether it is correct.
Lothar Miller wrote:> And ist this code ok in simulation? I assume not
YES it is working in Modelsim simulation.
Lothar Miller wrote:>> load_a <= "UUU";>> load_b <= "UUU";> Do you think the synthesizer can implement 'U' level in real hardware?> Which voltage would one measure on a 'U' level?
when i synthesised it in xilinx, i changed U to Z.
this happened because i copied the code from Modelsim.
i've attached the new code.
vhdl newbie wrote:> Lothar Miller wrote:>> And ist this code ok in simulation? I assume not> YES it is working in Modelsim simulation.
Then you may have a different behaviour in reality, because the
sensitivity list is for simulation only!
> when i synthesised it in xilinx, i changed U to Z.
You cannot have a 'Z' level inside nowadays FPGAs. Tristate levels are
resolved with a multiplexer by the synthesizer.
> i've attached the new code.
enter_r is missing in this sensitivity list. I already mentioned this,
didn't I?
> enter : in std_logic;
Where does this signal come from? Is it a asynchronous signal from
outside the FPGA (eg. a key, switch)? If so, then you have to sync this
signal to the 'clk' clock domain...
Lothar Miller wrote:> enter_r is missing in this sensitivity list.
done it now.
Lothar Miller wrote:>> enter : in std_logic;> Where does this signal come from? Is it a asynchronous signal from> outside the FPGA (eg. a key, switch)?
YES, it is an async signal from outside (a dip switch or a push button).
Lothar Miller wrote:> If so, then you have to sync this> signal to the 'clk' clock domain.
vhdl newbie wrote:> is this how to sync enter with the clock?
In that snippet enter is not synced up to now. To be in sync you must
add (at least) one more flipflop stage. So it should look like enter
-> enter_s -> enter_r and then enter_s and enter_r are used for edge
detection. But the link for this was already posted...
What happens without synchronizing is shown there (try Google
translate):
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
did the sampling using a DFF.
but now there is a different problem.
if my program is
in a
mov b,a
in a
add a,b
halt.
i need the two in statements to read two different values.
but now when i give a '1' with dip switch then both my in instructions
work simultaneously and i get the same input at both a and b registers.
my project guide said that it may be due to some sparking in the switch
which causes multiple rising edges and as the FPGA is very fast both the
instructions work at the same time.
please help me with this.
why is this happening?
is there any problem with my code?
pls suggest a method to overcome this.
thanks in advance.
vhdl newbie wrote:> is there any problem with my code?
Who knows? Post your VHDL file(s). Otherwise only guessing around is
possible...
Also write some words about the hadrware: which FPGA? How are the
switches connected? ...
And: usually you MUST begin a new thread for a new question. It is not
good practice to take over someone others thread.
Lothar Miller wrote:> Post your VHDL file(s)
i've posted it previously.
posting it again :)
Lothar Miller wrote:> which FPGA?
Spartan 3
Lothar Miller wrote:> How are the> switches connected?
the enter is connected to a dip switch on the FPGA board itself.
Lothar Miller wrote:> It is not> good practice to take over someone others thread.
this thread was started by me :)
vhdl newbie wrote:> Lothar Miller wrote:>> It is not good practice to take over someone others thread.> this thread was started by me :)
Hmmm, okokokokok... :-/
vhdl newbie wrote:> enter_r<=enter;> end if;> end process;> is this how to sync enter with the clock?
Yes, but afterwards you should use the sync'ed enter in your
description...
vhdl newbie wrote:> but now when i give a '1' with dip switch then both my in instructions> work simultaneously and i get the same input at both a and b registers.
You use a dip switch as the clock source?
That will never work unless its a bounce-free switch.
> my project guide said that it may be due to some sparking in the switch> which causes multiple rising edges and as the FPGA is very fast both the> instructions work at the same time.
It doesn't do it in the same time, but it does it within 50ns one after
the other. For you this is looking like "the same time".
> is there any problem with my code?
Not more than already mentioned. Its a problem with your hardware now.
Lothar Miller wrote:> Its a problem with your hardware now.
will giving it to a debounce circuit work??
what will be the delay after which the switch reaches a stable state?
vhdl newbie wrote:> but now when i give a '1' with dip switch then both my in instructions> work simultaneously and i get the same input at both a and b registers
And what is that "dip swith"? Is it connected to the "enter" signal?
Lothar Miller wrote:> Why not thinking for yourself? I already posted the skeletons for this> edge detection in http://embdev.net/topic/320582#3483355
did some thinking and was gonna do like this
route the enter signal to the input of the debouncer module and take the
output of this as the enter for my FSM.
OR
route the enter signal to the input of the debouncer module and take the
output of this to DFF series and its output as the enter for my FSM
will my problems be solved??
asked that to see if anyone has a more clean idea. :)
Lothar Miller wrote:> when in_s => --when current state is "in_s"> if enter_s='1' and enter_r='0' then -- rising edge> next_s <= fetch;
if the switch is bouncing, then will this work ?
i tried this and didn't work.
Lothar Miller wrote:> Aha, the copy&paste generation...
as the input instruction was not working previously, i made some changes
in my project and made the program memory and data memory into RAMs.
will start a new thread about this in the near future.
so, copying was the last resort :)
vhdl newbie wrote:> if the switch is bouncing, then will this work ?
No, you're right, it won't work. The 50MHz clock is too fast...
> so, copying was the last resort :)
The debouncing unit you found is a counter, that is reset, when the
input changes. Otherwise it counts up and when it reaches a certain
level the input is regarded as stable. Then the input signal is
forwarded.
You could write this in a few lines in your code:
i gave it a go.
It is working but there is a small problem.
before the program is executed, we should give an additional enter( so
to input a data we now need 2 rising edges of enter instead of 1).
vhdl newbie wrote:> before the program is executed, we should give an additional enter( so> to input a data we now need 2 rising edges of enter instead of 1).
No. Forget that whole "rising edge view". What you really need is one
more state at the start of the whole thing. And to leave that state you
check the switch in the same way as you do it now in the in_s state.
BTW: Did I already mention the word "thinking"?
Lothar Miller wrote:> BTW: Did I already mention the word "thinking"?
i did that, but i added an NOP state after the in_s state.
here i checked if the enter signal attains a zero back. :)
Lothar Miller wrote:> And to leave that state you> check the switch in the same way as you do it now in the in_s state.
i didn't understand this.
did you mean to check if enter is a 0 or 1?
guys i'm posting my complete project files here.
if anyone can program a spartan3 with these files please check why u
need 3 enter signals for entering 2 values.
the present program is
in a
mov b,a
in a
add a,b
halt
vhdl newbie wrote:> if anyone can program a spartan3 with these files please check
Before programming the Almighty set the simulation. Which one of the
files is the test bench? What result do you get when you are simualting
your code?
> if alu_enable='1' then> if (clock'event and clock='1') then
Where did you find this way to describe a clock enable?
Usually in the synthesis guidelines you will find it the other way
round:
if (clock'event and clock='1') then
if alu_enable='1' then
Lothar Miller wrote:> Which one of the> files is the test bench? What result do you get when you are simualting> your code?
i think i have drifted away from the subject of this thread
so i'm starting a new thread.