My first FPGA code

[BrianHG]

Ok then, I will pick that route, 150mhz sample @ 150mhz clock, source synchronous mode.

This not being the normal mode, but source synchronous mode.

Wich will have more delay but more power efficient.

How do you figure more delay.  If your sampler is 150MHz, and you FPGA is computing at 1:1 speed, and you still need all your data to compute an answer?

You are talking a difference of maybe 2/150000000 of a second in difference as you still need to wait for that last sample to come in.

Unless you are not computing in real time, or not computing in parallel.  The 1 thing which makes using an FPGA over a MCU/CPU, the entire reason for going to such a complicated design for that raw 0 wait speed capabilities.

[lawrence11]

So it would be totally stupid, unheard of even, to run an FPGA @ 450mhz when you fastest signal is clocked @ 150mhz from source synchronous, and its source synchronous everywhere.

So I never needed a 5$ crystal?

[NorthGuy]

Do I get it guys?

You just take the source clock in and use it for sampling and some logic until you cross to your own clock domain.

Or, if the clock frequency is slow, you sample both the source clock and data with your own clock at much higher (10x+) frequency, detect transitions in the source clock and use the data samples which were taken during the transition.

[BrianHG]

So it would be totally stupid, unheard of even, to run an FPGA @ 450mhz when you fastest signal is clocked @ 150mhz from source synchronous.

So I never needed a 5$ crystal?

No.  If you have room for only 1 multiplier in your design, and you need to do 3 unique different multiplies to be performed on every sample, and you don't want to fall behind, yes, running that 1 multiplier at 3x the sample speed would make sense.

The advantage of a single crystal is running you core at 1 clock speed while everything else coming in may be operating at lower clock frequencies.  This means no clock switching necessary.  If you have inputs operating at lower sample speeds, just the input itself is clocked at that speed, then that data is passed to you main unified FPGA clock speed.  So long as your core is running a few hundred hertz faster than any sampler data input clock, you are safe to go about things this way.

[NorthGuy]

So it would be totally stupid, unheard of even, to run an FPGA @ 450mhz when you fastest signal is clocked @ 150mhz from source synchronous, and its source synchronous everywhere.

So I never needed a 5$ crystal?

450 MHz is too slow to sample 150 MHz signal. Your only choice is to sample with the source clock.

Your FPGA does need an internal clock. It better not be related to the input - because otherwise if the input clock stops, FPGA stops too.

[lawrence11]

So it would be totally stupid, unheard of even, to run an FPGA @ 450mhz when you fastest signal is clocked @ 150mhz from source synchronous, and its source synchronous everywhere.

So I never needed a 5$ crystal?

450 MHz is too slow to sample 150 MHz signal. Your only choice is to sample with the source clock.

Your FPGA does need an internal clock. It better not be related to the input - because otherwise if the input clock stops, FPGA stops too.

Well In my case that is possible.

It will simply be in standby untill the next edge, wich will save power, come to think of it.

Is the rule x4

600mhz would be necessary to sample a "reference clock" of 150mhz.

"Reference clock" and "gear connection".

A "gear connection" is a posedge, a sample is an If, correct?

[BrianHG]

Why do you want to sample the edge clk of your sampling clock?

[lawrence11]

Why do you want to sample the edge clk of your sampling clock?

You cant sample the edge of a sampling clock of 150mhz.

You must use the sampling clock as a gear connection, and let it run the logic chain.

[NorthGuy]

Why do you want to sample the edge clk of your sampling clock?

Looks like he has several clocks on different pins which he wants to use at different times to sample the same data lines, and he doesn't have (or doesn't know how to use) the clock mux.

One of the methods is to treat the clock as data (same as if you wound want to read 200 kHz SPI), but 150 MHz is too fast for this.

[lawrence11]

Not only I dont know how to use the mux, I dont know to how to setup the IP's offered by Intel and how to stay wihin an easy simulation/synth workflow.

I contacted Intel and explained the horrendous lack of direction in their online tutorials.

I need the clock mux only between the 108mhz and 150 mhz clock.

The SPI is a seperate entity.

[rstofer]

For sampling his SPI clock, your mentione 1-delay system exactly the way he can extract the SPI SCLK transition and perform a bit transaction at every low-high and high-low transition.

It is exactly how my RS232 Sync UART example detects the start bit and aligns it's internal period counter.

Which is exactly where I have used it.

[BrianHG]

Not only I dont know how to use the mux, I dont know to how to setup the IP's offered by Intel and how to stay wihin an easy simulation/synth workflow.

I contacted Intel and explained the horrendous lack of direction in their online tutorials.

I need the clock mux only between the 108mhz and 150 mhz clock.

The SPI is a seperate entity.

I'm still not sure about what you are trying to do...

to me, this is a AB selection mux:

Code: [Select]

input wire sys_clk;
input wire [7:0] data_a, data_b;
input wire data_a_rdy, data_b_rdy, select_ab;

output reg [7:0] data_mux_out;
output reg        data_mux_out_rdy;

always @(posedge sys_clk) begin

     if (~select_ab) begin
          data_mux_out     <= data_a;
          data_mux_out_rdy <= data_a_rdy;
     end else begin
          data_mux_out     <= data_b;
          data_mux_out_rdy <= data_b_rdy;
     end
end

I would have just converted the source 150 and 108Mhz data streams to my fixed local crystal 150MHz.

[lawrence11]

Not only I dont know how to use the mux, I dont know to how to setup the IP's offered by Intel and how to stay wihin an easy simulation/synth workflow.

I contacted Intel and explained the horrendous lack of direction in their online tutorials.

I need the clock mux only between the 108mhz and 150 mhz clock.

The SPI is a seperate entity.

I'm still not sure about what you are trying to do...

to me, this is a mux:

Code: [Select]

input wire sys_clk;
input wire [7:0] data_a, data_b;
input wire data_a_rdy, data_b_rdy, select_ab;

output reg [7:0] data_mux_out;
output reg        data_mux_out_rdy;

always @(posedge sys_clk) begin

     if (~select_ab) begin
          data_mux_out     <= data_a;
          data_mux_out_rdy <= data_a_rdy;
     end else begin
          data_mux_out     <= data_b;
          data_mux_out_rdy <= data_b_rdy;
     end
end


No, this is not a good mux, this is the kind of mux you would use on a slow signal with normal mode selection.

We want source synchronous clocking.

Mux is a hardware primitive that you have to setup with GUI then call somehow, it will create a module and ports, I think.

The it will act like a gear switcher and it wont bug when you use their IP catalog stuff.

From the ALTPLL ip catalog.

[BrianHG]

Why are you switching the PLL to a sampling clock if the samplers are providing you a reference sampling clock.
I would have just converted the source 150 and 108Mhz data streams to my fixed local crystal 150MHz and still use my AB switch code.

It is different if you need to generate the 150MHz and 108MHz clock, well, not quite as you can program your PLL to create 2 clock outputs at 2 different frequencies.

[lawrence11]

Why are you switching the PLL to a sampling clock if the samplers are providing you a reference sampling clock.
I would have just converted the source 150 and 108Mhz data streams to my fixed local crystal 150MHz and still use my AB switch code.

It is different if you need to generate the 150MHz and 108MHz clock, well, not quite as you can program your PLL to create 2 clock outputs at 2 different frequencies.

So a 150mhz clock, system clock, that never goes away, is the all around solution.

such a 150mhz clock, would have to be derived from a crystal.

The system clock of 150mhz + a few hundred hz will sample a 150mhz that is not persistent, and totally out of phase with the system clock?

I see now. So we can sample 150mhz clock with 150mhz + a few thousand hz, thus avoiding all that clock switchover stuff.

[BrianHG]

Why are you switching the PLL to a sampling clock if the samplers are providing you a reference sampling clock.
I would have just converted the source 150 and 108Mhz data streams to my fixed local crystal 150MHz and still use my AB switch code.

It is different if you need to generate the 150MHz and 108MHz clock, well, not quite as you can program your PLL to create 2 clock outputs at 2 different frequencies.

So a 150mhz clock, system clock, that never goes away, is the all around solution.

such a 150mhz clock, would have to be derived from a crystal. Because the 150mhz is not persistent.

I see now. So we can sample 150mhz clock with 150mhz + a few thousand hz, thus avoiding all that clock switchover stuff.

Yes, if your samplers has their own clocks, or you use a PLL to make their clocks, you can convert those samples to you 155MHz clock domain with a 'data_enable' which will pulse high and low as each new sample is ready.  So, with 150MHz system clock and a 75MHz sample clock, that enable will go high and low every second system clock.  Your 'gear' control for your logic.

[lawrence11]

Why are you switching the PLL to a sampling clock if the samplers are providing you a reference sampling clock.
I would have just converted the source 150 and 108Mhz data streams to my fixed local crystal 150MHz and still use my AB switch code.

It is different if you need to generate the 150MHz and 108MHz clock, well, not quite as you can program your PLL to create 2 clock outputs at 2 different frequencies.

So a 150mhz clock, system clock, that never goes away, is the all around solution.

such a 150mhz clock, would have to be derived from a crystal. Because the 150mhz is not persistent.

I see now. So we can sample 150mhz clock with 150mhz + a few thousand hz, thus avoiding all that clock switchover stuff.

Yes, if your samplers has their own clocks, or you use a PLL to make their clocks, you can convert those samples to you 155MHz clock domain with a 'data_enable' which will pulse high and low as each new sample is ready.  So, with 150MHz system clock and a 75MHz sample clock, that enable will go high and low every second system clock.  Your 'gear' control for your logic.

They do have their own clock, its SPI data and synchronous data, there is a signal that rises or falls right smack in the middle of this data. Only the fast data will have a switch, from 150 to 108.

Yeah but you proposed that same solution last time, then you mentionned the Bus of 150mhz  should be in phase with the derived PLL of 150mhz. I then told you tis was not possible.

[NorthGuy]

There are many ways for clock domain crossing.

For example, Xilinx has asynchronous FIFOs - you write it with one clock and read it with a different clock. So you write with 150 MHz clock and read with 200 MHz internal clock.

Another FIFO, you write with 108 MHz clock and read with the same 200 MHz internal clock.

All you need to do is select the correct FIFO.

Altera should have something similar.

[BrianHG]

There are many ways for clock domain crossing.

For example, Xilinx has asynchronous FIFOs - you write it with one clock and read it with a different clock. So you write with 150 MHz clock and read with 200 MHz internal clock.

Another FIFO, you write with 108 MHz clock and read with the same 200 MHz internal clock.

All you need to do is select the correct FIFO.

Altera should have something similar.

FIFO is overkill, but simple as the FPGA vendors push them that way to show off asynchronous clocking dual port rams.
You just need 4 registers on a source clock, and 4:1 MUX on the out side operating 2 clocks behind the sampling 4 registers.

And if you were able to operate at 1:1 frequency, then using this technique, you system clock can realistically only need to be 1MHz faster than your sample clock.

[lawrence11]

Why are you switching the PLL to a sampling clock if the samplers are providing you a reference sampling clock.
I would have just converted the source 150 and 108Mhz data streams to my fixed local crystal 150MHz and still use my AB switch code.

It is different if you need to generate the 150MHz and 108MHz clock, well, not quite as you can program your PLL to create 2 clock outputs at 2 different frequencies.

So a 150mhz clock, system clock, that never goes away, is the all around solution.

such a 150mhz clock, would have to be derived from a crystal. Because the 150mhz is not persistent.

I see now. So we can sample 150mhz clock with 150mhz + a few thousand hz, thus avoiding all that clock switchover stuff.

Yes, if your samplers has their own clocks, or you use a PLL to make their clocks, you can convert those samples to you 155MHz clock domain with a 'data_enable' which will pulse high and low as each new sample is ready.  So, with 150MHz system clock and a 75MHz sample clock, that enable will go high and low every second system clock.  Your 'gear' control for your logic.

What do you mean by "samplers", are you talking about a pin, aka CLKx_p or n, or are you talking about series or parallel data that has a rising(or falling) ege right smack in the middle of this data, aka a clock (sampler).

Well whatever the case, rest assured, all 3 clocks coincide with their respective CLKx_p or n pin.

Even my XXMhz crytal corresponds to CLK0_p.

[BrianHG]

If you have a CLK input pin for the sampler, then that sampler has it's own clock.
For example, I have a HDMI receiver IC.  It send me a clock with the data.  It feeds an input on my FPGA so it generates it's own clock.

If you have an 'output pin' seeding a clock to the sampler, then your FPGA is generating the sampling clock.

For example, I have an audio ADC connected to my FPGA.  It requires a clock signal.  Within my FPGA, I create that 96KHz clock by dividing my main system clock from the PLL and drive the audio ADC's clock input.

You may also have another external crystal oscillator dedicated to feeding your ADC and FPGA input.

[BrianHG]

Why are you switching the PLL to a sampling clock if the samplers are providing you a reference sampling clock.
I would have just converted the source 150 and 108Mhz data streams to my fixed local crystal 150MHz and still use my AB switch code.

It is different if you need to generate the 150MHz and 108MHz clock, well, not quite as you can program your PLL to create 2 clock outputs at 2 different frequencies.

So a 150mhz clock, system clock, that never goes away, is the all around solution.

such a 150mhz clock, would have to be derived from a crystal. Because the 150mhz is not persistent.

I see now. So we can sample 150mhz clock with 150mhz + a few thousand hz, thus avoiding all that clock switchover stuff.

Yes, if your samplers has their own clocks, or you use a PLL to make their clocks, you can convert those samples to you 155MHz clock domain with a 'data_enable' which will pulse high and low as each new sample is ready.  So, with 150MHz system clock and a 75MHz sample clock, that enable will go high and low every second system clock.  Your 'gear' control for your logic.

What do you mean by "samplers", are you talking about a pin, aka CLKx_p or n, or are you talking about series or parallel data that has a rising(or falling) ege right smack in the middle of this data, aka a clock (sampler).

Well whatever the case, rest assured, all 3 clocks coincide with their respective CLKx_p or n pin.

Even my XXMhz crytal corresponds to CLK0_p.

I'm sorry, we assumed that the 108MHz data and 150MHz data came from an AD sampler just by some of the previous language being used.  Ok, lets just call it a parallel data port with it's own clock coming in.

[lawrence11]

Ok yeah, I am not sampling 150mhz sinewave with ADC's.

Sampling meant, registering the value of the parallel dataset at the sampling time, aka edge of a clock.

Dont get mixed up, my FPGA has no ADC's.

The CLK has its own sampler, or the sampler has its own CLK, however you wanna put it.

Anyways, I have to pat myself on the back some more, that was some incredible foresight to associate CLK pins with clocks.

[lawrence11]

Yeah I gotta hand it to us Canadians, we smart.

Also those from New Zealand.

Basically the whole Commonwealth, we smart...

Am I forgetting anybody?