Two related signals control a process. The process is launched if Sig1 or Sig2 is active. This does not mean OR logic. I bring an illustration of a register just to make it clear. You have a register that can be in loaded or in empty state. It accepts data (becomes LOADED) when is EMPTY and WRITE input is active. At a clock edage when register is being loaded it responds with ACK signal, releasing data provider. That is, ACK is active when WRITE and EMPTY = '1'. There are two options when to load data FFs of the register: - when EMPTY = '1', that is when reg. contains no valid data; or - when ACK = '1', i.e. reg. responds the fact it loads data. Logically, the device will function equvalently. The pseudo-code:
entity: WRITE: in std_logic ACK: out std_logic DIN, DOUT: std_logic_vector;
If I understand the question (it is confusing) you want to know *which* option to use to enable the register, ACK or WRITE. Since ACK is EMPTY
*AND* WRITE, ACK is at least one gate delay later than EMPTY. If the logic doesn't matter (WRITE was irrelevant) I'd normally opt to take the faster signal to improve the setup time. ...but perhaps I don't see the issue.
ACK or EMPTY, you cannot load a register if it is loaded.
...but perhaps I don't
This is an option, thanks. I do not take it into consiteration since setup time is the longest way the signal travels. As I have both signals (ACK and EMPTY) anyway, there is no additional gate delay. However, if reg loading controlling signal turns out to appear at the longest trace this option may gain sense. But (I may mistake) in modern HW traces play as an important role as the gates. If a signal is available at a certain part of a design then why to trace another one?
This is an unknown in this problem. If this is a big problem, I'd do it both ways and let synthesis/PAR work out the best solution. This is often done, though I don't think I've done it at this low of a level (usually different implementations of larger blocks).
Yes, but in the example the ACK signal is calculated for another purpose (to inform data provider that we consume the data). Thus, I have this data delay in any case, whether control loading by EMPTY or ACK.
may
design
May be this is not a big problem, but lots of small problems is always a one big problem. Bad style means you have small errors/drawbacks throughout your code. As I'm relatively young to HW I try to develop a good style.
Load the reg with *don't care* when it is empty and with data input on ACK? Good idea. But synthesier placer, router are still different tools. From the sithesier point of view, there is no difference in delay controlling the load. I don't stop wonder how intelligent sometems morern tools can be, but in general they are stupid. Optimization task is NP-complete, it is always better to simplify SW can optimize a design replacing its parts as far as behafviur is the same.
**** Let the software do its thing ***** if ACK then DATA_REG
Sure, but the slack for this register will be better, allowing easier PAR and perhaps allowing a better solution for something else. There is no point in making things worse.
Good plan. Be consistent with your style and white-space too. Lots of comments also make for a good style. I always spend a lot of time making things easy to read. It *undoubtedly* will save me time next week figuring what the hell I just did.
No. Don't use "don't cares" in synthesizable logic. The "don't care" state isn't realizable and the synthesizer may puke.
You should also have a reset clause in your process.
That depends on your toolset. The toolset I used had delays built into the synthesizer. They weren't always of great use because, as you note, wiring delay is significant and the synthesizer can't know where PAR puts things. OTOH, if your PHB is rich (I had a virtually unlimited budget ;-) there are physical synthesis tools out there that can do a much better job before PAR.
The problem is that your synthesizer doesn't have all the information needed to do the job you're asking it to do. You need timing feedback from the PAR tools.
Ack! ;-) You're using ACK as your clock and it's going to produce a level sensitive latch (not good in most technologies). (or did you just leave out the clock?)
It's also rather unlikely that your target technology has a '-' level.
What I meant by "letting the software do its thing" was implement it both ways and see which does a better job. Let the software tell you where the negative slack is, then fix it. This sort of thing is likely going to be highly implementation dependant. There is unlikely a "best way", other than not to shoot yourself (before you need to ;-).
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.