I have a combinational logic circuit generating a number of waveforms from the main clock input. There are a number of external inputs to this circuit controlling the turning on and off of different outputs.
My problem is that I need a certain timing relationship between four of the outputs.
I realise that normally to obtain a given timing relationship one would use synchronous logic. But in this case as I require signals with the same frequency as the main clock I must use combinational logic.
From the output of my logic simulator I am seeing some issues which confuse me:
(a) Different logic gates have different delays, A NOT has less delay than an OR gate. May be this should have been obvious to me. Is it correct?
(b) If I add a gate to create a delay, it seems to be getting optimised out. Is there some way to stop a gate added for this purpose from being removed?
Denis, I assume (correctly?) that you implement your logic in Xilinx or Altera FPGAs. In these parts, the logic is implemented in 4-input look-up tables, and the distinction between AND, OR, and INV is meaningless. It all ends up as the through-delay in a ROM with 4 address inputs and thus 16 stored bits. You can, however, force the software to use one LUT for each gate, but there still is no systematic difference between different gate types.
I am using a Spartan XL XCS05XL. I dont think features like that from the Virtex - II are available.
Thanks for the point on the delay. As you can see Im new to some of the more basic points. Amazing how far you can get without understanding everything that goes on under the hood.
In the simulation of my final design I can see that signals that travel through more gates in my schematic have a greater delay. Does this tie in with the look up table implementation.
This implementation and consequent resulting delays issue is begining to drive me around the bend.
Below is a small diagram of my schematic. To ensure tha OP2 (Output 2) changes state after OP1 (Output 1) I set up the circuit as shown. However I find in my simulation results that OP2 changes state before OP1. This appears to defy the laws of physics but Im sure there is a simple explenation.
Signals control 1 and control 2 are low throughout.
Regards
Denis
OP2 OP1 _|_ | OR | |__| | ||____ control 1 | | |_____________| Not |_____| _|_ OR |__| ||____ | | | Not control2 | | Main Clk
Denis, it seems that you are gating the clock. This is not exactly illegal or immoral, but definitely a bad and dangerous habit. Try to avoid that. (Use CE instead).
Also remember that the software can compile your comb>
The fundamental problem is that the tools don't support what you are trying to do. And if you need a minimum delay, the silicon doesn't really support it either.
When you draw a pile of gates like that, the system tosses them in the air and comes up with an equivalent circuit that usually fits better in the part. While doing that, it doesn't worry about relative timing. It's just trying to meet setup times for the next clock. It often makes copies of your "gates" since they are free if the LUT has unused inputs.
Have you tried the floorplanner or such to see what they actually did?
The first approach is to find some way to do the job with "simple" cleanly clocked logic. That's what the tools expect you to be doing. If you can get a 2x clock, then you can put a FF after the OR gate for OP1, (and fixup the logic) and then run that signal over to the gate for OP2. That doesn't guarantee that OP1 will get to the outside world before OP2. Can you add a half clock (double clock?) delay? If so, add a FF on OP2 and clock it on the other edge. If you really want clean timings on the outside world, you want to use FFs in the IOBs. (perhaps cloning the logic, so you have a copy inside to feed to other logic)
You probably CAN trick the tools into doing something useful, but you will have problems like this, and if you change anything or the tools change, you might have to go through this all over again.
It's an interesting chicken-egg problem. Because the tools don't support this sort of thing, not many people try to do it. Since not many people do it, there is no demand for the tools to support it.
Do you have spare IO pins? One thing you can do is bring OP1 out on one pin and back in on another without telling the system about the external connection. You can probably bring it back in on the same pin, but now you are taking the risk that some smart tool will see what you are doing and "fix" it up for you.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.