cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dman23
Observer
Observer
962 Views
Registered: ‎11-06-2018

32bit counter @400MHZ

Jump to solution

Hi....

I have a system that once in a while gets an external trigger asynchronously.

i want to be able to know the time each trigger was received t, with 2.5ns resolution, though the triggers themselves will be separated by.... let's say more than 50 us.

I want to implement a 32bit counter operating at 400mhz.

I wrote a rather complicated (too complicated for that frequency, I admit) process that operates this counter, but also has some features:

Every 1000 cycles should get a sync signal from an external source, the counter should preset itself to a known state ( according to the received sync,

for example, if this is sync number 3, preset counter to 3006 and continue, if this is sync number 5, then preset to 5006 and continue, and so on.

In a simulation, all is great, no problem.

synthesis and implementation and bitstream passed with warnings. which frankly I don't really know how to read.

I do understand my approach is very very naive, to think my process will actually work.

so I am asking for your advice.

what is the correct way to approach such a counter,

how to verify it actually works... etc. 

Thanks!

 

0 Kudos
1 Solution

Accepted Solutions
820 Views
Registered: ‎01-22-2015

@dman23 

The following free book talks a lot about timing analysis, Vivado, and VHDL.  Its a little wordy but has discussion that I have not found elsewhere.

https://forums.xilinx.com/xlnx/attachments/xlnx/GenDis/40732/2/FPGAs_VHDL_First_Steps_v2p2.pdf 

Overall, I found the book to be quite accurate.  I often use the constraints templates from the book for FPGA source synchronous interfaces. 

However, the author has a personal and unconventional approach to things placed in the sensitivity list of a VHDL process.  As the author explains (correctly, I think) in appendix B of the book, the unconventional sensitivity list does no harm. 

Cheers,
Mark

View solution in original post

Tags (1)
8 Replies
joancab
Advisor
Advisor
950 Views
Registered: ‎05-11-2015

A loadable counter is something standard, should not be much of a problem. 400 MHz is a bit challenging but given you have the right speed grade, should be fine.

Synthesis may have many warnings. Me and, I thing many, just ignore them. Critical warnings should be look at. After Implementation it should be clear of warnings.

Behavioural simulation test things in ideal conditions, you can see the functional correctness there. With post-synthesis simulation you include internal path delays and other real-world effects. If your counter counts and loads well without 'X's after synthesis then it's okay. Also have a look at the timing report to have WNS positive.

0 Kudos
dman23
Observer
Observer
860 Views
Registered: ‎11-06-2018

Ok, Thanks.

any advice on how I get into timing analysis? i don't know how to read it, how to correct it, how to write constraints.

couldn't find a good HOW TO manual. 

Would like to learn it,

0 Kudos
joancab
Advisor
Advisor
854 Views
Registered: ‎05-11-2015

Good question. I don't think there is a single, good guidance to "timing taming", the reason being is more an art than a science. UG612 is probably an in-depth reference, UG903 is probably easier to follow. 

821 Views
Registered: ‎01-22-2015

@dman23 

The following free book talks a lot about timing analysis, Vivado, and VHDL.  Its a little wordy but has discussion that I have not found elsewhere.

https://forums.xilinx.com/xlnx/attachments/xlnx/GenDis/40732/2/FPGAs_VHDL_First_Steps_v2p2.pdf 

Overall, I found the book to be quite accurate.  I often use the constraints templates from the book for FPGA source synchronous interfaces. 

However, the author has a personal and unconventional approach to things placed in the sensitivity list of a VHDL process.  As the author explains (correctly, I think) in appendix B of the book, the unconventional sensitivity list does no harm. 

Cheers,
Mark

View solution in original post

Tags (1)
dman23
Observer
Observer
758 Views
Registered: ‎11-06-2018

Thanks a lot! 

I am diving right in

0 Kudos
drjohnsmith
Teacher
Teacher
747 Views
Registered: ‎07-09-2009

Lovely book, I dont knwo it, its one of the few if only ones to cover timming constraints,

   just be careful , the examples might not have been checked,

     at quick look for instance, looks like the sensitivity lists are wrong in examples,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
732 Views
Registered: ‎01-22-2015

@drjohnsmith  : Thank you for pointing out that I should add comment to my book recommendation.   I edited my previous post to include some comments.

 

@dman23  : Please see comments about the book that I have added to my previous post.

bitjockey
Adventurer
Adventurer
498 Views
Registered: ‎03-21-2011

>any advice on how I get into timing analysis? i don't know how to read it, how to correct it

The book will be a good start but the short, short version usually is:

  • Look at the timing report (failing constraints are the most important) and it will show you the FF-logic-FF path that is failing.  You will likely see LOTS of logic hops there.  Can even visualize it in the schematic drawing.
  • Figure out what part of your code is turning into that logic.  (This is often based on experience.  Being able to 'visualize' your code ahead of time and how it will synthesize is a good skill to hone.)
  • Figure out how to make it shorter.  Was it unnecessarily complex?  You will very quickly get into 'pipelining' as a solution (adding more FF into that -logic- path).  Large N-to-1 functions hurt a lot here (like a 32 bit carry chain with N=32 for the high bit).  Is there a way to compute an intermedidate result a cycle early?  I.e. do an M-to-1 function first and then do an N-M+1-to-1 next?  or can you take >1 cycle to compute the result later in the future.  Break it up.   The trick is doing this without changing the logical outcome of your code once things start arriving cycles "early" or "late" but there are techniques for handling it.

one simple way is that if you don't need a result for several cycles, just delay it unconditionally.  foo = complex function(N inputs), foo2 = foo, foo3 = foo2, and use foo3.  The compiler will move things around for you, moving "complex function" "forward" inbetween foo and foo3.  However this relies on not needing the result for a few cycles.  Particularly, if foo is needed for its own complex function() it can be trickier and you may need to alter your algorithm.

For counters, one trick is to break them in half.   A 16 bit counter runs and produces a (FF'd) roll-over signal.  This FF'd signal also increments the high 16b counter.  The high counter is now a cycle "too late" which later code corrects for (often by delaying the low bits a cycle to compensate).  Note that resetting such a counter can be trickier, so simulate well to make sure you get it right.  Your solution for infrequent resets might just be "hold reset for 2 cycles, know that the counter will always be 1 lower than expected".  Or "delay the reset pulse to the high 16 bits by a cycle to match its lag".  Etc.