VHDL expert puzzle

On 12/1/2012 7:33 PM, KJ wrote:
> On Saturday, December 1, 2012 1:47:06 AM UTC-5, rickman wrote:
>> On 11/30/2012 9:25 PM, KJ wrote:
>>> It doesn't need to depend on routing. Thomas' example introduced a
>>> logic 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?
>
> The post that I referring to has the following...
>      Clk1<= Clk when Selected else Other_Clk';
>      [..]
>      Clk2<= Clk1 when Enabled else '0';
>      [..]
>      process (Clk)
>        if rising_edge(Clk) then
>           A<= B;
>      [..]
>      process (Clk2)
>        if rising_edge(Clk2)
>           B<= A;
>
> I believe the point he was trying to make was that because of the simulation delta delay between Clk1 and Clk2 the two processess would not be clocked at the same time.  While it is true that the processes would clock at different times, it's not really because of the simulation delta delay.  An actual implementation of the above would have the same problem because it would need to synthesize the logic to create the gated clock.  The propogation delay and additional routing delay in creating the additional clock would create a race condition for signals generated in the 'clk' domain and captured in the 'clk1' or 'clk2' domains.
>
>>> clk1<= clk;
>
>> This is not logic. In VHDL it inserts a delta delay which is a zero
>> amount of time but treated as a delay in the simulator. By adding a
>> delta delay it will disrupt signals from the earlier clk domain that
>> drive FFs in the later clk1 domain. In a real chip there will be no
>> delay.
>
> And that was my point.
>
> Kevin Jennings

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

On Sunday, December 2, 2012 10:43:04 PM UTC-5, rickman wrote:
> 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?

I was replying to Thomas' post on Nov 28.  I must've clicked the wrong 'Post Reply' button or something.  Link is 
https://groups.google.com/forum/#!search/In$20DSP$20I$20guess$20you$20have$20in$20general$20only$20one$20clk$20and$20all$20modules$20/comp.arch.fpga/zec7-hbtrJ8/TJOleMXV490J

Kevin

On 12/3/2012 9:22 PM, KJ wrote:
> On Sunday, December 2, 2012 10:43:04 PM UTC-5, rickman wrote:
>> 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?
>
> I was replying to Thomas' post on Nov 28.  I must've clicked the wrong 'Post Reply' button or something.  Link is
> https://groups.google.com/forum/#!search/In$20DSP$20I$20guess$20you$20have$20in$20general$20only$20one$20clk$20and$20all$20modules$20/comp.arch.fpga/zec7-hbtrJ8/TJOleMXV490J
>
> Kevin

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