VHDL expert puzzle

Indeed. Altera recommends using the reset async port but with sync signal pre-synchronised. Xilinx, I believe, recommends using synchronous sync. But again we need to be careful about our wording. Synchronous sync is actually applied to input D through logic and does not mean necessarily it is pre-synchronised. Whether you name it async or sync, the signal be default is not pre-synchronised and for sake of timing at release, they have to be generated from flip's clock domain before applying it.

With today's large designs I prefer not to apply reset unless absolutely needed. I know many of us will apply it as routine to masses of buses at every node but I believe it puts massive burden on fitter to meet removal/recovery timing when such effort better be directed somewhere more critical.

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz
Loading thread data ...

Indeed. Altera recommends using the reset async port but with sync signal pre-synchronised. Xilinx, I believe, recommends using synchronous sync. But

again we need to be careful about our wording. Synchronous sync is actually

applied to input D through logic and does not mean necessarily it is pre-synchronised. Whether you name it async or sync, the signal be default is not pre-synchronised and for sake of timing at release, they have to be generated from flip's clock domain before applying it.

With today's large designs I prefer not to apply reset unless absolutely needed. I know many of us will apply it as routine to masses of buses at every node but I believe it puts massive burden on fitter to meet removal/recovery timing when such effort better be directed somewhere more critical.

Note also the resource difference between the case of using async port(just

routing) and sync reset(logic).

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz

Short of required hand placement, there is no way to 'handle' clock skew in layout in an FPGA/CPLD. Logic induced skew between any two clocks creates two clock domains. If the design is such that the two clocks are treated as unrelated (for example if data only moves from one domain to the other t hrough a dual clock fifo) then the design will work. You might get lucky, you might not if you think that any place and route tool will help you out here. Most likely you will encounter the 'bad' sort of luck, not the 'good luck'.

It doesn't need to depend on routing. Thomas' example introduced a logic d elay between the two clocks. The implementation of that logic will create a race condition.

Kevin Jennings

Reply to
KJ

That only makes sense if the delay in the async reset path is short enough and properly analyzed by the tools. There have been any number of discussions in these groups about how to properly reset a design and there is no consensus on the best way to do it.

The best way to do a reset is design specific. As I said above, there are many ways and no agreement on which is "best".

That depends on why you are using the reset. If you are only using it to establish the configuration values you can apply an async reset and not be concerned with routing since it will use only the dedicated async reset network.

Rick

Reply to
rickman

I'm not clear on this. I believe some architectures provide sync reset inputs separate from the D input and so use no logic.

Rick

Reply to
rickman

delay between the two clocks. The implementation of that logic will create a race condition.

I didn't see anything in Thomas' example that required "logic". Here is what I read. Did I read the wrong post?

this:

Reply to
rickman

Well, it will still take some resources, but maybe not much.

-- glen

Reply to
glen herrmannsfeldt

port(just

I am not aware of this type of architecture. I assume it synchronises reset

per flip and thus seems a waste of silicon compared to the case of user pre-syncing it once for all relevant flips.

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz

I don't know the Altera devices as intimately as others, but I learned the Xilinx stuff pretty well once. They have (had) two inputs to each FF, one for reset and one for set, which were configurable between sync and async.

My point is that if this is built in, which is not uncommon I think, there are no "used" resources other than dedicated resources for logic in the case sync reset and nothing for async.

I prefer to design my resets in a customized way where each section of logic is reset and released from reset asynchronously and each logic section separately takes care of the problems of cleanly starting up. That way there is no global reset competing for either routing or logic. Often nothing special needs to be done for a finite state machine (FSM) because it starts by waiting for some trigger signal anyway. Counters often use an enable which is disabled by default, etc. I pay attention to how my circuits operate from reset and so far this has not bitten me.

Rick

Reply to
rickman

The post that I referring to has the following... Clk1 > clk1 This is not logic. In VHDL it inserts a delta delay which is a zero

And that was my point.

Kevin Jennings

Reply to
KJ

I don't know where that code came from, but yes, I think you are accurately analyzing it. Your first post was replying to the OP's post containing the link to the blog. I didn't see anything like this in the blog code, there was no muxing of the clock. Where did you get the code shown above?

Rick

Reply to
rickman

clock. Where did you get the code shown above?

I was replying to Thomas' post on Nov 28. I must've clicked the wrong 'Post Reply' button or something. Link is

formatting link
$20DSP$20I$20guess$20you$20have$20in$20general$20only$20one$20clk$20and$20all$20modules$20/comp.arch.fpga/zec7-hbtrJ8/TJOleMXV490J

Kevin

Reply to
KJ

clock. Where did you get the code shown above?

Reply' button or something. Link is

formatting link
$20DSP$20I$20guess$20you$20have$20in$20general$20only$20one$20clk$20and$20all$20modules$20/comp.arch.fpga/zec7-hbtrJ8/TJOleMXV490J

Ok, I finally found it, no thanks to Google groups. Somehow the post didn't link to the right place in my reader. I've seen it screw up before.

I've kinda lost track of your point. But Thomas seems to be correct in what he said. But your point is correct, that adding logic delays to the clock distribution makes life difficult. I believe the tools typically handle that. If they didn't you would be limited to the number of global clock routes on a chip. In the real world you can have local clock distribution and the timing tools should verify and report setup and hold timing violations.

Certainly adding logic to clock distribution makes things much more complex.

Rick

Reply to
rickman

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.