There is a similar question here, which was answered with
Yes, rising_edge()/falling_edge() should only be used for clock
signal. While it works in simulation it can cause problems and
unintended hardware in synthesis.
Is the same thing true for using the 'event attribute to detect edges of non-clock signals like in the following example?
process (rndm_sig)
begin
if (rndm_sig'event and rndm_sig = 1) then
-- do something.
end if;
end process;
Any signal used as X'event and X= 1 or rising_edge.(X) will be treated by the synthesis tool as a clock.
In an FPGA that means the routing tool will try to assign a dedicated clock net to the signal, with all that it entails. e.g. the signal has to be routed to a dedicated clock input which can cause significant delay and skew against the other signals.
Also the signal had better be 'clean'. It means that a FF will clock if there is the tiniest spike on the signal. It also means that if your signal is not 'clean', some FFs may trigger and some may not.
The timing tool will need to know the period and high/low time and try to make the set-up and hold time work against all other clocks. This can cause major problems and/or extra logic in the design. If the signal is totally asynchronous against the other clocks you can have meta stability and may need to add synchronizers after the clocked register(s).
So it comes down to: it is strongly recommended to use only 'real' clock signals for the X'event and X= 1 or rising_edge.(X) constructs.
At the same time there is one rule in digital design which says: all rules are out if there is no other solution.
In the ASIC industry, where I come from, you had to talk to some senior designers before you broke the basic rules. Then you had to add some big emphasized comment around the code stating "Yes this breaks the rule but there was no other way because we had this and this and this and it has been reviewed and signed of by X and Y " And yes, I once used a latch in a design.
Related
I am doing a small task where I have to count the pulses coming from two inputs. The requirement doesn't specify clock. Currently I have a process that is triggered when any of the input changes and then corresponding count is increased.
My question is Should I use clock for this design and make the process Clock sensitive and then check if inputs have Changed? Is it a good practice to use Clocks in VHDL design?
Sub-question- I have to double buffer the input data. Does this mean I have to use clock and pass inputs through two flipflops? or is there a way to double buffer data without using clock?
It is possible to design asynchronous circuit with VHDL. The design rules are a bit different than synchronous design (using request and acknoledge signals).
Your need is not very complex and could be designed without clock but you have to be careful with your memorisation element. Specialy if you work with an FPGA, these devices are not supposed to work asynchonously. So look carefully the synthetizer results.
(If it's school homework, use a clock ;) In digital design, the clock usage is the default case. Asynchronous logic is an advanced concept)
Kind on hard-simple question,
i know it's general but that is exactly why i am asking...
if i write a code in vhdl and i use a process which starts this way:
Process(clk,x,y,x)
begin
...
end process
is there any way which in i won't have to save x,y,z values ? the way i understand this, if i wont save them, i wont be able to say if one of them changed which means i have to save them.
im writing assignment with a friend for university and we have different opinions. thanks a lot for helpers !
It totally depends on your needs.
In case you don't know - when you make some project in VHDL for FPGA, CPLD etc. you have to forget about what you knew about programming, because you are designing hardware, not software. You mostly, if not always, you don't have to save this values, for example when you make combinatorial circuit. In this case you don't care what was before, but only what this value is currently. Look at some examples with finite states machines, that has process with combinatorial logic.
And lastly – if you put clock to sensitivity list, it means that you want it to be synchronous, and process will launch only on some edge of this clock, so putting any more signals to it (with exception for reset) is pointless.
Here is a D flip-flop with a CLOCK ENABLE input.
click here, I am new, can't post images yet, sry
This makes me wonder. Why not just AND gate the CLOCK and the CLOCK ENABLE inputs and output this to the flip flop clock input.
I feel like I cannot do this because the clock is somehow special, but on paper, this seems to work the same way. So if this isn't right, why?
You can do it using an AND gate (between the clock and clock enable) and removing the Multiplexer just like you're proposing. Please remember that there is no single way of solving any digital design problem. Be creative.
On the negative side of this implementation, adding a gate in the clock path (the AND gate) would mean that the clock would be delayed (due to the delay from the gate). In a more complex system, it would be a problem because the clock would not be in phase for all the components using it (this flip flop will have a delayed version of the clock).
I am trying to generate a synthesizable buffer in VHDL for a time-to digital project in FPGA.
I have been looking around but cannot find any set-up out there.
I have been recommended that stackoverflow has very good answers.
Could you please give me some tips for this course work, and I would be very greatful to any approach you might come up with.
Thank you a lot in advance!
Regards
Doing time-delay-circuits (TDC) is somewhat hard right now.
Basically, it boils down to having HDL that describes multiple registers all reading the same signal. You then need to apply a keep directive, e.g. equivalent_register_removal for Xilinx. You will possibly also need a timing ignore constraint on the signal you are sampling.
You then need to carefully examine the fabric of your FPGA and make sure your flop flops are placed in the same slice across multiple sites that can all be connected through the same kind of wire (check FPGA Editor), i.e. will have the same time delay.
You can build a minimal test design for Xilinx in FPGA editor. Once you have the routing down, you can then formulate appropriate constraints for your UCF file and build much bigger, more complex TDCs.
I'm only familiar with Altera from a few years ago. But Altera doesn't give you an interface like Xilinx's FPGA editor, so you're on your own determining the placement of your flops. I saw a presentation once about a university work group doing TDCs with Altera and ultimately it boiled down to measuring the resolution by using input stimuli to check whether the design was routed according to their wishes. If it was not, they would adjust some timing parameters out of sensible bounds, rinse and repeat.
The last step of course is to sample your signal in the synchronous part of your design (where the counter is) and read the counter plus flip flop contents when the event you wanted occurs (i.e. rising edge, falling edge). Then you have major time units in your counter and minor time units as a bitfield in the flip flop state.
If you want even spread among your flip flop delays, you will need to carefully examine the delay length of paths between the flip flops and adjust for your overall clock period.
So basically, counter * clock_period + index_of_highest_set_bit_in_flip_flop_state * path_delay is then your delay time.
You will also need to check the FPGA datasheet to know your minimal timings, i.e. the fastest toggle time the input buffer can achieve, the minimal setup and hold time of your flops etc.
I have a clock in my vhdl code but i don't use it , simply my process just depends on handshake when one component finishes and gets an output out , this output is in the sensitivity list of my FSM and is then becomes an input to the next component and of course its output is also in the sensitivity list of my FSM(so to know when will component finishes its computation)... and so on.
Is this method wrong ? it works in simulation and also in post-route simulation but gets me warnings like this : warning :HOLD High VIOLATION ON I WITH RESPECT TO CLK; and
warning :HOLD Low VIOLATION ON I WITH RESPECT TO CLK;
is this warnings not important or will my code damage my fpga because it doesn't depend on a clock ?
The warning you are getting are timing violations. You get these because the tools detect that your design does not obey the necessary timing restrictions for the internal primitives.
For instance, inputs to lookup-tables (which is one of the main building-blocks inside an FPGA) need to be held for a specific time for the output to stabilize. This is very hard to guarantee when your entire timing relies only on the latencies and delays of the components themselves, and switch on a completely asynchronous basis.
Depending on your actual design (mostly the size and complexity of it), I'll wager the guess that you'll end up with a lot of very-hard-to-debug errors once you get it inside an FPGA. You'll have a much, much, much easier time using a clock. This will allow you to have a clear idea of when signals arrive where, and it will allow you to use the internal tools to check your timing. You'll also find it much easier to interface to other devices, and your system will be less susceptible to noisy inputs.
So all in all, use a clock. You (probably) wont damage your FPGA by not doing it, but a clock will save you from tons of trouble.
your code does most probably not damage your FPGA because it doesn't depend on a clock. however, for synthesis you should always use registered (clocked) logic. without using a clock your design will not be controllable because of timing/delay/routing/fan out/... this will let your FSM behave "mysteriously" when synthesized (even if it worked in simulation).
you'll find plenty of examples for good FSM implementation style with google's help (search for Moore or Mealy FSM)
Definitely use a clock. And only one clock throughout the design. This is the easiest way - the tools support this design style very well. You can often get away with a single timing constraint, especially if your inputs are slow and synchronous to the same clock.
When you have gained experience designing this way, you can move outside of this, but be ready for more analysis, timing constraints and potentially build iterations while you learn the pitfalls of crossing clock-domains and asynchronous signals.