OK
The process in counter16simple looks fine, if to exclude
the problem of single-use operation of tmpoverflow
if tmpcount = "1111111111111111" then
tmpoverflow <= '1';
end if;
If it gets high it never goes down. Questionable from functional...
You know what?
You are right.
It shall work anyway
and in my comnpiler/simulator
(but this one is very often not compatible with those commonly recognised ones ;(
... it all gives the same, proper result.
- convert_signed, convert_unsigned, convert_slv,
convert(convert) !
(shame)
Sorry for...
Wow!
Neee fooking chance ...
it's just some magic in it
there is a magic spell
<elsif/if> clk'event and clk= '1' then
which makes anything inside the "if"
a register clocked with clk
first you cannot change this spell (have you seen that action in "Harry Potter"?)...
The code would be much more helpful here. There are ca 2.5 different ways of writing the reasonable FSM. Your decision - probably someone here could improve the code, just for fun.
Anyway according to
"...Is it strictly necessary to assign a value to every output in each possible...
Hi
Your problem may be shown as an example for
"What do we need the f***ing integer for?"
strictly academic arguments.
Why not to keep it all in std_logic_vector and selecting the packages std_logic_signed or std_logic_unsigned for signed/unsigned interpretation of the series of...
You can use / and * operators for signed/unsigned types (which are defined as the vectors of std_logic type bits)
the
use ieee.std_numeric.all;
clause is needed then.
Generally it is all synthesizable.
But the algorithms implemented are not the "bestest" presumably. E.g. for...
So ... let me say ... now ...
Now it is clear that the first VHDLguys reply is just t what you need
I.e.:
1. You generate the 7 times faster clock using the PLL or other magic "out of digital world" device
2. You make a 0 to 6 counter with this fast clock
3. You implement a MUX for...
Yes it is.
If your target is simulation only you just write it like in any computer language. E.g. you can write a procedure or function.
If your target is hardware you must additionally obey several rules.
For algorithms implementation the solution could be e.g. the finite state machine...
Hmmm we've got something like that here.
But for the moment it represents some non-zero commercial value. And it is very nice. So I cannot provide it.
I write this just in case your target is also something commercial ... we can always talk then ;)))
However I can address some selected...
Well
in these circumstances the second solution could be better. Surely it would make the synthesis job easier. But now a good synthesis tool would "notice" that there are two identical comparators and eventually remove one of them.
Btw such problem could be considered as a test for...
Hi
More info needed
what is there in the *.vhd, plus a few starting lines ?
what is your tool /& operating system / ?
is there anything reasonable written in the error message?
rgds
I presume you need the floating point multiplier, available for synthesis. (For fixed point or for the REAL type you just write a*b, providing the appropriate library & package).
Traditionally the floating point artihmetics modules were offered as IP soft cores for rather big cash.
Since...
It will be exactly the same - comparator with the output connected to the "enable" pin of the latched flip-flop
There is very little risk that the second solution would require additional inverter - if the flip-flop "enable" pin is active low. But then, if aGTEq16 was not...
Hi
The soft just want you to enable more iterations of the loop because the code needs more than 64 etc.
But the real problem seems the double clk'event statement in the same process which probably makes the synthesizer sick. BTW I can't imagine the appropriate hardware to do the code ...
Why...
... or just START the process STATUS with
BEGIN
fifoempty <='0';
fifofull <='0';
notempty <='0';
...
well according to the syntax errors
- there are several statements with = instead of <= or :=
- several ; missing
- the construction of the "value" register
is...
Well for the moment there are two "end if" missing.
Anyway I would suggest a little redesign. First removing frome the sensistivity list anything but clk and rst, these two are enough for the clocked process indeed.
Then not mixing the reset with any other action. In this...
The code does not say too much ...
BTW it is impossible to simly create 24 MHz from 16 MHz. In digital way - you need some much faster clock, use a counter etc. Otherwise you need something analogue. I don't see any "faster" clock here so I don't see any possibility to get the 24 MHz...
The general response is yes - the sensitivity list must contain all the signals from the "right side" ,the conditions etc. (excluding the clocked processes where only the clock and optionally reset is required).
Concerning the code presented - it is unusual. It is not common practice...
The coding (1-st version) is OK generally. But this may be done by various kinds of hardware. This could be e.g. riddiculously long cascade of MUXes. Slow. And seems like this is the case here - you get time violations.
Another solution is the single mux with more complicated logic. Faster...
If I uderstand it well ....
you shall just write "something stupid like ..."
process(clk,reset)
begin
if reset = '1' then
q <= '0';
elsif clk'event and clk = '1' then
q <= d;
end if;
end process;
this is the behavioural description of the rising edge of clk...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.