According to another answer, it seems yes, but it looks like any binary counter implementation uses some kind of "clock".
So, is NAND/NOR still turing complete without "clock" component?
For an overview of the topic, this related post is helpful.
A combinational logic circuit composed of NAND and NOR gates without feedback loops is not a Turing complete machine. It lacks memory and it cannot execute a program with loops and conditional branches. The output values only depend on the current input values. Disregarding transient signal changes, such a circuit exhibits a purely static behaviour.
However, SR flip flops as basic elements of sequential logic can be built out of NAND gates. Additional combinational logic determines, how the state machine transitions from one state to the other. Such a finite state machine is still not Turing complete, as it has a finite amount of memory. See this related post.
So, an infinite NAND/NOR circuit could be a candidate to analyze for Turing completeness.
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)
I was wandering, in terms of "performance" if there's some kind of difference between vhdl structural and behavioural. I know that nowdays is more common to write behavioural instead of structural but since i'd like to have an understanding in terms of performance i have been thinking that maybe there's some difference...
There is no hardware-related reason to prefer one form or the other.
It may be that one form leads to faster simulation than the other; I haven't seen any evidence for this in general, but then I haven't looked. It is true that after synthesis, the design is translated into a structural form, and post-synthesis simulation is slow, but this is due to the sheer size of the resulting structural version expressed as thousands of individual gates and their interconnections.
What matters more is the quality of synthesis results: It should be possible to write a design in both forms and have it synthesise to essentially the same hardware. And this seems to be generally true, in my experience.
Sometimes you will find synthesis tools have difficulty efficiently translating a construct (usually behavioural) but not as frequently as in the past.
What matters most (unless you are pushing the boundaries of speed or FPGA size) is clarity, leading to readability, reliability, efficiency, testability, maintainability and so on. If you can't understand it you can't see the inefficiencies or even test it properly.
Here, structural VHDL has a role to play at the top level : dividing a system into blocks like CPU, memory interface, FFT processor, UART, SPI and so on. Sometimes hierarchically, so you might want to divide the memory interface into refresh logic, error correction, address multiplexing, and so on.
But most blocks - for example, tasks that a single state machine can handle, are clearest and simplest when expressed behaviourally. So in a UART you might have two separate processes for TX and RX, while an SPI interface (which sends and receives on the same SPI clock) is probably best as a single behavioural process.
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.
Is it a good design practice to use combinatorial logic to drive the output of a module in VHDL/Verilog?
Is it okay to use the module input directly inside a combinatorial block,and use the output of that combinatorial block to drive another sequential block in the same module?
An answer to the two questions really depends on the overall design methodology
and conditions, and will be opinion based, as Morgan points out in his comment.
The questions are in special relevant for a large design with timing pushed to
the limit, and where multiple designers contribute with different modules. In
this case it is important to determine a design methodology up front which
answers the two questions, in order to ensure that modules provided by
different designers can be integrated smoothly without timing issues.
Designing with flip-flops on all outputs of each module, gives the advantage
that when an output is used as input to other module, then the input timing is
reasonable well defined, and only depends on the routing delay. This makes it
a Yes to question 1.
Having a reasonable well-defined input timing makes it possible to make complex
combinatorial logic directly on the inputs, since most of the clock cycle will
be available for this. So this also makes it a Yes to question 2.
With the above Yes/Yes design methodology, the available cycle time is only
used once, and that is at the input side of the module, before the flip-flops
that goes on the output. The result is that multiple modules will click nicely
together like LEGO bricks, as shown in the figure below.
If a strict design methodology is not adhered to in different modules, then
some modules may place flip-flops on the input, and some on the output. A
longer cycle time, thus slower frequency, is then required, since the worst
case path goes through twice the depth of combinatorial logic. Such a design
is shown in the figure below, and should be avoided.
A third option exists, where flip-flops are placed on all inputs, and the
design will look like the figure below if two different modules use the same
output.
One disadvantage with this approach is that the number of flip-flops may be
higher, since the same output is used as input to multiple flip-flops, and the
synthesis tool may not combine these equivalent flip-flops. And even more
flip-flops than this may be required, if the module that generates the output
will also have to make a flip-flopped version for internal use, which is often
the case.
So the short answer to the questions is: Yes and Yes.
The answer to both questions as expressed is basically yes, provided the final design meets speed targets, and the input signals are clean.
The problem with blocks designed this way are that the signal timings through them are not accurately defined, so that combining several such blocks may result in an absurdly slow design, or one in which fast input signals don't propagate cleanly through the design.
If you design such a circuit, and it meets ALL your input and output timing constraints as well as any clock speed constraints you set, it will work.
However if it fails to meet the clock constraints you will have to insert registers to "pipeline" the design, breaking up long slow chains of combinational logic. And you will have to observe the input and output timings reported by synthesis and PAR, and they can get complicated.
In practice (in an FPGA : ASICs can be different) registers are free with each logic block (Xilinx/Altera, not true for Actel/Microsemi) and placing registers on each block's inputs and/or outputs makes the timings much simpler to understand and analyse.
And because such a design is pipelined, it is normally also much faster.
I am aware of the need to synchronize all inputs to an FPGA before using those inputs in order to avoid metastability. I'm also aware of the need to synchronize signals that cross clock domains within a single FPGA. This question isn't about crossing clock domains.
My question is whether it is a good idea to routinely register all of the inputs and outputs of every internal hardware module in an FPGA design. The rationale is that we want to break up long chains of combinational logic in order to improve the clock rate so that we can meet the timing constraints for a chosen clock rate. This will add additional cycles of latency proportional to the number of modules that a signal must cross. Is this a good idea or a bad idea? Should one register only inputs and not outputs?
Answer Summary
Rule of thumb: register all outputs of internal FPGA cores; no need to register inputs. If an output already comes from a register, such as the state register of a state machine, then there is no need to register again.
It is difficult to give a hard and fast rule. It really depends on many factors.
It could:
Increase Fmax by breaking up combinatorial paths
Make place and route easier by allowing the tools to spread logic out in the part
Make partitioning your design easier, allowing for partial rebuilds.
It will not magically solve critical path timing issues. If there is a critical path inside one of your major "blocks", then it will still remain your critical path.
Additionally, you may encounter more problems, depending on how full your design is on the target part.
These things said, I lean to the side of registering outputs only.
Registering all of the inputs and outputs of every internal hardware module in an FPGA design is a bit of overkill. If an output register feeds an input register with no logic between them, then 2x the required registers are consumed. Unless, of course, you're doing logic path balancing.
Registering only inputs and not outputs of every internal hardware module in an FPGA design is a conservative design approach. If the design meets its performance and resource utilization requirements, then this is a valid approach.
If the design is not meeting its performance/utilization requirements, then you've got to do the extra timing analysis in order to reduce the registers in a given logic path within the FPGA.
My question is whether it is a good idea to routinely register all of the inputs and outputs of every internal hardware module in an FPGA design.
No, it's not a good idea to routinely introduce registers like this.
Doing both inputs and outputs is redundant. They'll be no logic between the output register and the next input register.
If my block contains a single AND gate, it's overkill. It depends on the timing and design complexity.
Register stages need to be properly thought about and designed. What happens when a output FIFO fills or other stall conditions? Do all signals have the right register delay so that they appear at the right stage in the right cycle? Adding registers isn't necessarily as simple as it seems.
The rationale is that we want to break up long chains of combinational logic in order to improve the clock rate so that we can meet the timing constraints for a chosen clock rate. This will add additional cycles of latency proportional to the number of modules that a signal must cross. Is this a good idea or a bad idea?
In this case it sounds like you must introduce registers, and you shouldn't read the previous points as "don't do it". Just don't do it blindly. Think about the control logic around the registers and the (now) multi-cycle nature of the logic. You are now building a "Pipeline". Being able to stall a pipeline properly when the output can't write is a huge source of bugs.
Think of cars moving on a road. If one car applies it's brakes and stops, all cars behind need to as well. If the first cars brake lights aren't working, the next car won't get the signal to brake, and it'll crash. Similarly each stage in a pipeline needs to tell the previous stage it's stopping for a moment.
What you can find is that instead of having long timing paths along your computation paths going from input to output, you end up with long timing paths on your enable controlling all these register stages from output to input.
Another option you have is, to let the tools work for you. Add add the end of your complete system a bunch of registers (if you want to pipeline more) and activate in your synthesis tool retiming. This will move the registers (hopefully) between the logic where it is most useful.