Author Topic: FPGA project where clock for it is external signal - what rules for designing?  (Read 1562 times)

0 Members and 1 Guest are viewing this topic.

Offline FlyingDutchTopic starter

  • Regular Contributor
  • *
  • Posts: 144
  • Country: pl

Hello,

let's assume that we are implementing comunication protocol where main clock is external signal (to FPGA circuit) for example 33 MHz . We likely have to input this external clock signal to "clock capable pin" of FPGA., but I don't fully understand how consequences it has to FPGA project. What if internal clock of FPGA board is much higher than thaht external clockfor example 100 Mhz. How impact such situation has to FPGA project, are there any special rules which one have to follow. How impact it has to simulation process and timing constraints for such circuit.
Could somebody describe such rules for project of clock external to FPGA circuit?

Best Regards
 
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3713
  • Country: us
If the clocks are phase locked with a simple ratio like 1:3 you can just latch data from the 100 MHz clock every third cycle.  If the ratio is not simple or the clocks are asynchronous with a relatively small ratio like 1:3 you will need to latch the input data on its own clock, the  do clock domain crossing, usually with an async FIFO to your core clock domain.  If the data is much slower than the core (like async serial at < 1 MHz) with no standard clock available you would over sample the waveform at a much higher frequency with a synchronizer chain to avoid metastability and then decode the data.

 
The following users thanked this post: FlyingDutch

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
it's all design dependent.

Why does the internal logic in the FPGA run at 100 MHz? Why is the clock provided to the FPGA only 33 MHz?

Do you need to use the 33 MHz clock in the design, or do you use a PLL to bump it up to 100 MHz and then only run the logic at 100 MHz?

The question is very broad, and it would help if you narrow it down to an actual design situation.
 
The following users thanked this post: FlyingDutch

Offline FlyingDutchTopic starter

  • Regular Contributor
  • *
  • Posts: 144
  • Country: pl
it's all design dependent.

Why does the internal logic in the FPGA run at 100 MHz? Why is the clock provided to the FPGA only 33 MHz?

Do you need to use the 33 MHz clock in the design, or do you use a PLL to bump it up to 100 MHz and then only run the logic at 100 MHz?

The question is very broad, and it would help if you narrow it down to an actual design situation.

Hello @Bassman59,

no I don't need this clock from crystal on FPGA (!00MHz). I just need 33 Mhz for clocking all design (it is clock line from implemetation of comunication protocol). I understood then when I input this external clock into "Clock capable"  pin of my FPGA (Spartan6), i can use this clock for clocking all my design.
I just want to remove IP core with "Clocking Wizard" (PLL loop on FPGA) - first I falsely assumed that this 33 MHz clock should be generated by FPGA.

Thanks for comment and Regards
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26896
  • Country: nl
    • NCT Developments
Your FPGA design will run just fine from an external clock. What you do need to be aware of is that you'll need to put input & output timing constraints on the signals entering and leaving the FPGA if they need to have a defined time relationship with the logic running inside the FPGA.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: FlyingDutch

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Possible sde trip.. You can use the clocking components on the FPGA to give you a 33MHz clock if desired. It won't match the external clock cycle-for-cycle.

If that sounds like a workable solution let us know and we can show you how (also let us know the FPGA vendor too).
« Last Edit: April 12, 2022, 11:00:06 pm by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: FlyingDutch

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7727
  • Country: ca
You should also be permitted to send your external 33MHz clock to the FPGA's PLL if you so desire.
A possible intent is to create a design synchronous to your 33MHz source, but you require your FPGA core to operate at a higher frequency.  For ease of interfacing, usually when we do this, we tend to choose perfect multiple settings for the PLL and our core, like 2:1, or 4:1.

There are even uses for still using the PLL at 1:1 speed, but where you require your core, or to drive an IO at an optional phase offset compared to your 33MHz source.  Since 33MHz is so slow, you probably wont be using it, but using the PLL to generate a programmable phase offset can begin to be useful for data buses running above 75MHz where for example it may be best to capture the data bus at a 90 degree phase offset.  The PLL was designed to accommodate such programmable precision.
« Last Edit: April 12, 2022, 08:05:52 pm by BrianHG »
 
The following users thanked this post: FlyingDutch

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3143
  • Country: ca
All FPGA designs are clocked externally. FPGA may have internal oscillators, or you can create your own oscillators from FPGA combinatorial logic, but these will not be accurate and will have huge jitter.

FPGA will have PLL (or alike) so you can use your external clock to generate clocks of different frequencies, but the external clock must have good stability.
 
The following users thanked this post: FlyingDutch

Offline radar_macgyver

  • Frequent Contributor
  • **
  • Posts: 698
  • Country: us
If the external clock is directly fed to the input logic of your design, nothing more to do other than specifying the timing constraints and using an async FIFO to cross the clock domain to your internal logic clock (as others have said). You can have multiple PERIOD constraints, one for each clock. The tools will automatically apply the correct PERIOD constraint to all FFs that are clocked by the specified clock signal. When there's a clock domain crossing between two unrelated clocks, the tools will automatically ignore that crossing and not apply any constraints there.

If the external clock feeds a DCM or MMCM within the FPGA, you would need to add some logic to detect if the external clock stopped, and apply a reset pulse to the DCM or MMCM to force it to re-lock. Don't know for sure about MMCMs, but DCMs will not auto-lock in this situation without user logic.

(also let us know the FPGA vendor too).
He did say it's for a Spartan 6
 
The following users thanked this post: FlyingDutch


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf