My first FPGA code

[rstofer]

Is this legit?. This should be 2 clocks connected to a or gate, but each clock line is enabled by their respective conditon.

always @ ((posedge data_clk and !silence_inv) or (posedge mcu_clk and silence_inv))

I will have to repeat my advice to take a step back and learn basics. If you would think for a second what kind of gates this code would create, you'd immediately understand that this code makes no sense. I don't even understand what is it you're trying to accomplish here.

It looks like a MUX selecting one of two clocks.  I don't know about newer primitives but ISE and Spartan 3 used to complain about gated clocks.  Instead they wanted some kind of enable signal at the component and just one ungated clock.

Again, synthesize the thing (for a very limited implementation) and see what the hardware looks like.  Both as an RTL view and a Technology view.  I'm betting on a MUX which will be implemented in a single LUT.  The LUT could implement the circuit with an inverter, two AND gates and an OR gate but that's the thing about LUTs, it isn't always shown how they actually implement anything.  It's just a 3 input 1 output black box.

The issue is the skew imposed on the gated clock.  Neither of these gated clocks are aligned with their original clocks.  Sure, it's only picoseconds but it impacts the timing calculations.

[lawrence11]

Its more than just the circuit. Its the circuit with a choice, a design choice. Do I use a super fast internal clock and sample @ rising edge, or do I let the information
"flow at the synchronous-source clock speed".

Here is a question I believe, of "determinism", Am I rite? I am "imagining the motor of the FPGA" now but its all in my own mind.

A choice of timing clock. For this I have to visualize my needs, and understand the FPGA more in depth, as Asmi said.

But I'm sure thee exists condensed format of this informaiton, somewhere on the internet

I need to visualize how the data travels, with either source clock or internal clock, to make this choice.

[BrianHG]

I thought this was going to be more simple since I can draw it on a paper quite easily.

https://forums.intel.com/s/question/0D50P00003yyG9DSAU/max-10-alternate-between-two-clock-sources-without-reseting-ios-values-?language=en_US

BrianHG? You knowledge would surely be useful right now.

Ok.  When I design for an FPGA, my effort drives me toward a single @posedge clock for the entire FPGA except in sections where it may be really useful.  Even then, there are ways around using multiple clocks.  Now there is no question that you can place any equation inside the @(posedge/negedge), however, if that logic goes beyond the CLK input gates of the FPGA's logic cell (usually only a 2:1 or 4:1 mux and and gate), what happens is that Quartus will take your equation, feed it's source clocks into normal gates around a logic cell, feed that through an un-clocked logic cell, and use that logic cell's output to drive a CLK wire of the logic cells' clk inputs you write code for inside that 'always @(posedge/negedge)'.  You may get away with this for  clocking a small few other logic cells in an FPGA design, however, the fabric of the FPGA wasn't designed to do this on a large scale or throughout the chip.  The FPGA is best designed to keep everything at 1 or 2 system clocks fed by the PLLs.  This is the only way you get a clean synchronous design with very predictable parallel outputs and the highest possible FMAX performance.

Now, looking at what you are trying to create, an SPI slave bus interface, is there a way to avoid all asynchronous or combinational logic clocks, use 1 system high speed clock and still meet SPI specifications.  Yes.  It may even take less logic cells as your results are already operating at you system clock speed.  You do not need to buffer between clock domains anymore.  There wouldn't be any fancy clocks with async reset lines at all, just the one 'always @(posedge SYSTEMCLOCK) begin'.  The SPI reset and enable latch would not just be part of an 'IF()' inside your SPI slave receiver routine.  However, operating as a slave, there would be a limit to how fast you may clock your SPI's SCLK compared to your system clock.  In such a setup, with this 8:1 (6:1 is still safe) clock limitation, are you actually willing to continue down this road?  What this means is if an external master feeding you a SPI SCLK at 10Mhz, I would want my FPGA core SYSTEMCLOCK clock to be at least 60MHz, or in the case of a 1MHz SCLK, I would want a minimum system clock of 6 MHz.

[lawrence11]

No Brian I am not willing to go down this road.

The design has 3 clocks if you count the spi as a clock, that is set in stone.

Spi can be slow I dont care, 10mhz is fine.

We are getting to the point where the FPGA is not keeping up with my logical abilities with gates, due to these pesky clock issues.

It shouldnt be a big deal, I have MAX10 and running the clock pins on the right clk_p pins and clk_n pin for the SPI.

mcu clk: clk7_p pin
spi clk: clk7_n pin
data_clk: clk6_p pin

[BrianHG]

No Brian I am not willing to go down this road.

     I'm sorry, but my expertise is using 1 single clock for everything so I need never worry about clock logic.

     Instead, I personally would treat all the SPI inputs as a function of switching states.  It is far simpler to use the 'IF ( spi inputs )' or case ( function (spi inputs) ) including the SPI CLK input as a variable inside the '(...)' instead of having separate clock domains with weird alternate asynchronous switching states and transferring data between these clock domains with that possible issuing timing errors.  Any logic I write within those brackets always happens at the edge of my main system clock.

[NorthGuy]

Clock muxes are certainly real.

They are not created through LUTs. Using LUT output as a clock is a disaster in the making.

Why do you think the HDL code should translate to LUTs? The tools will map the code to the hardware blocks which are the most appropriate (at least they're supposed to).

[lawrence11]

Ok, you guys are confusing me now.

Lets talk about 2 things, these are the terminologies used in intel's documentation.

1: normal mode aka Global system clock

2:Source synchronous clocks

[rstofer]

Clock muxes are certainly real.

They are not created through LUTs. Using LUT output as a clock is a disaster in the making.

Why do you think the HDL code should translate to LUTs? The tools will map the code to the hardware blocks which are the most appropriate (at least they're supposed to).

AFAICT, all logic is done in LUTs for Xilinx.  I don't know that there are any logic blocks consisting of a simple gate or collection of similar gates like a 7400 quad NAND.  But I could be very wrong...

[NorthGuy]

Ok, you guys are confusing me now.

Lets talk about 2 things, these are the terminologies used in intel's documentation.

1: normal mode aka Global system clock

2:Source synchronous clocks

Global clock is the clock which can reach any part of FPGA. You usually will generate at least one such clock and clock most of your stuff with that clock.

Source synchronous clock refers to the clock generated by the same source which sends data to you. And the data being sent is synchronized to this clock. This typically refers to transmissions between different entities on the board.

Speaking of SPI, when master sends somehing, its clock is source synchronous. When master receives something, the clock is not source synchronous: the clock is produced by the master, but the data is produced by the slave.

[NorthGuy]

AFAICT, all logic is done in LUTs for Xilinx.  I don't know that there are any logic blocks consisting of a simple gate or collection of similar gates like a 7400 quad NAND.  But I could be very wrong...

The logic is done in LUTs, but your HDL can imply different hardware structures as well. Say, if you create an array (or FSM for that matter), it may be synthesized as a BRAM block. If you do multiplication, it may be synthesized as DSP. You can read the Xilinx guidelines which explain how to imply certain elements - there must be some prescribed way for clock muxes as well. You can instantiate things directly (I usually do), but, for some reason, most people would recommend implying things with your HDL.

Edit: found a Xilinx write-up for you about this:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx10/isehelp/ise_c_imp_instantiation_and_inference.htm

[lawrence11]

Yeah I know what it means in terms of signals.

I have such things.

Parallel data with either a 150mhz clock on a pin, or 108mhz clock on another pin. both clk_p pins. Data pins never change.

And spi, wich has its own clock pin of course.

[BrianHG]

Ok, you guys are confusing me now.

Lets talk about 2 things, these are the terminologies used in intel's documentation.

1: normal mode aka Global system clock

2:Source synchronous clocks

1 & 2 are both the same, if you wire your global system clock to your source's clock.  However, in the case of something like SPI's clock, that pin may stop and go at any time.  So if you use that clock input as a system clock, everything stops when that clock pin stops.

Now, if you have to interface with a device whose bus clock is 4MHz (like a CPU 4MHz clock which is always on), but you wish to run your FPGA logic at 40MHz, you may call the 40MHz your global system clock while that 4 MHz bus clock coming in at one of the inputs, that you would call your 'Source Synchronous Clock'.  This does not mean you cannot take that clock input, feed it through the FPGA PLL and get the FPGA to run internally at 40MHz still, but that 4MHz input is what is synchronous to your source.  If running your FPGA at 4MHz is fine, then using that clock input direct to your always@(posedge) means your entire FPGA is now running synchronous to your source.

[rstofer]

Ok, you guys are confusing me now.

Lets talk about 2 things, these are the terminologies used in intel's documentation.

1: normal mode aka Global system clock

2:Source synchronous clocks

Your design is fundamentally flawed and that's what was being mentioned above.  I hesitate to bring it up but I would design the thing as a state machine

State 1 : wait for CS* to go high then go to state 2
State 2 : wait for CS* to go low then maybe start a transaction timer (to abort hung transactions), set up a bit counter and go to state 3
State 3 : wait for the proper edge of the SPI_Clk - DO NOT use edge statements, know what the idle state is supposed to be and transition when the clock comes out of idle.  Clock the data bit into the register, decrement the bit counter and goto state 4
State 4 : wait for the SPI clk to go idle then goto state 1 if the bit counter is 0 else state 3.


In each state check for timeout on the timer and decide how to abort a hung transaction.  I would set an error bit and branch to state 1.

As long as my system clock was much faster than my SPI clock, the state machine will work.  I would still synchronize the CS*, Clock and Data signals when they come into the chip.  Details up above somewhere.

I didn't diagram the state machine, I certainly didn't code it up and write a test bench so I most certainly do not guarantee it is correct.  But it's the way I would approach the problem.  There would be one clock, the system clock driving the FSM and no need to clock anything with the SPI clock.  Of all the things that scream for a test bench, this is it!

I'm sure there are other approaches.

Take it as a truism that you can't gate clocks and get reliable logic.  Xilinx says so...  Or at least they did with ISE.

[lawrence11]

Ok, you guys are confusing me now.

Lets talk about 2 things, these are the terminologies used in intel's documentation.

1: normal mode aka Global system clock

2:Source synchronous clocks

1 & 2 are both the same, if you wire your global system clock to your source's clock.  However, in the case of something like SPI's clock, that pin may stop and go at any time.  So if you use that clock input as a system clock, everything stops when that clock pin stops.

Now, if you have to interface with a device whose bus clock is 4MHz (like a CPU 4MHz clock which is always on), but you wish to run your FPGA logic at 40MHz, you may call the 40MHz your global system clock while that 4 MHz bus clock coming in at one of the inputs, that you would call your 'Source Synchronous Clock'.  This does not mean you cannot take that clock input, feed it through the FPGA PLL and get the FPGA to run internally at 40MHz still, but that 4MHz input is what is synchronous to your source.  If running your FPGA at 4MHz is fine, then using that clock input direct to your always@(posedge) means your entire FPGA is now running synchronous to your source.

I also have a crystal, its an active type ~ 5$ oscillator, theres 25 mhz, 50 mhz, and so on...

Thought I didnt have to mention this one.

[BrianHG]

Then the question would be, if you take that crystal input, and also drive say your external CPU with the same crystal, that CPU's bus would be synchronous to your design.  You can also take that crystal, feed the FPGA, and on an output of the FPGA, have a clock out feeding your CPU which was derived from the crystal's input.  If this case, the clock you feed out of you FPGA would be synchronous to the CPU clock.

However, even if the frequency is the same, if you have 2 different 50MHz crystal oscillators, 1 tied to your CPU and the other tied to your FPGA.  The 2 clocks are no longer synchronous since we cannot guarantee both crystals stay in perfect phase.  Now, special measures would need to be taken to ensure that the CPU data bus with it's 50MHz  is properly captured in, or transmitted to while your FPGA clock would be operating at a slightly lower or higher frequency.

[lawrence11]

Cant I just sample my data from the 150 mhz clk6_p pin @ 450 Mhz

When some enable pin activates, sample my data from the 108mhz clk7_p pin @ 324 Mhz

And sample my spi with ~50 mhz clock?

I use posedge/nedgede statement to say "hey, this is the perfect time sample", edge is right smack in the middle of data timing. So I am sorry if this is causing confusion.

[BrianHG]

Cant I just sample my data from the 150 mhz clk6_p pin @ 450 Mhz

When some enable pin activates, sample my data from the 108mhz clk7_p pin @ 324 Mhz

And sample my spi with ~50 mhz clock?

I use posedge/nedgede statement to say "hey, this is the perfect time sample", edge is right smack in the middle of data timing. So I am sorry if this is causing confusion.

Yes, you can sample serial or parallel data such data at such speeds with ease, ie 150MHz and 108MHz with ease.  450MHz and 324MHz is a little more worrying... SPI at 10MHz is so slow, you can use any system clock at 50MHz and above to read that SCLK and MOSI as if it were just normal input pins while your serial decoding logic basically can wrap cycles around it in speed.  The Intel FPGA does support multiple parallel clocks and it's memory cores allows you to read and write from 2 different clock domains simultaneously with ease.  This means one side on these dual port rams may operate on the 150MHz input bus clock.  That side of the ram is 'synchronous clocked' to the data input bus.  The other side of your dual port ram may be clocked by your 50MHz clock, of if you are using the PLL, any multiple of that clock to perform internal mathematical functions.  This does not mean you cannot use that 150MHz clock to run you FPGA logic functions as a synchronous design.  It is up to you the developer.

[lawrence11]

I dont have data coming @ 450 nor 324 Mhz.

I was proposing internal clock speeds. Wich should be derived from the crystal clock, PLLed

[rstofer]

AFAICT, all logic is done in LUTs for Xilinx.  I don't know that there are any logic blocks consisting of a simple gate or collection of similar gates like a 7400 quad NAND.  But I could be very wrong...

The logic is done in LUTs, but your HDL can imply different hardware structures as well. Say, if you create an array (or FSM for that matter), it may be synthesized as a BRAM block. If you do multiplication, it may be synthesized as DSP. You can read the Xilinx guidelines which explain how to imply certain elements - there must be some prescribed way for clock muxes as well. You can instantiate things directly (I usually do), but, for some reason, most people would recommend implying things with your HDL.

Edit: found a Xilinx write-up for you about this:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx10/isehelp/ise_c_imp_instantiation_and_inference.htm

Certainly!  I can declare an array for main memory and it will PROBABLY be put in BlockRAM but it could be put in LUTs (where the D-flops are located).  Or, I can instantiate a BlockRAM and guarantee it is going to be placed in BlockRAM.

[lawrence11]

Isnt it a default to have an active clock like I showed you?

Brian you seem to have changed your proposal.

Seriously, were you guys thinking I was gonna use SPI as a system clock and didnt have such a clock?

[rstofer]

I would think that clock speeds above 100 MHz (and maybe even 50 MHz) would be an advanced topic.  Anything in the 400+ MHz range is certainly going to require great care in logic design to meet timing.  Pipelining comes to mind.  Again, just because it simulates doesn't mean it will synthesize.  Pay attention to the timing report.  Unless you are dealing with a very high dollar chip, I would not expect timing closure much over 100 MHz.

My little LC3 project will run at 100 MHz on an Artix 7 100T but timing fails at 200 MHz.  I didn't iterate over values to find the highest possible frequency because the crystal oscillator is 100 MHz and that is as fast as I want to push the design.  In ISE they used to tell you the maximum possible frequency.  I haven't found that datapoint in Vivado.  I'm sure it's there somewhere but I haven't run across it.

[BrianHG]

I dont have data coming @ 450 nor 324 Mhz.

I was proposing internal clock speeds. Wich should be derived from the crystal clock, PLLed

I focused on SPI since you started this thread with a SPI receiver.  SPI is a special case as it's clock can stop and go, and, sometimes, you may want to reset logic not based on the SPI clock, but an asynchronous event with the SPI input pins.

I am assuming that your 108 and 150 MHz clocks are a normal standard bus where you don't begin resetting you internal logic on these weird occasions, when the clock is going low instead of the normal latching high, or the clock stops and other control signals take over to command your system functions, right?

As for your system FPGA clock, you will run into a maximum capability reported by Quartus depending on how you describe logic and functions in your Verilog code.  Since what HDL is describing is a set of wires connected together through gates which perform your equations feeding a set of flipflops' 'D' inputs while their 'Q' output switches/latches those input's results at the next clock, a really complex set of logic gates between the 'Q' output results feeding the next stage 'D' flipflops inputs may lower this maximum possible clock rate, otherwise, the late arriving latched data will give you errors.

In my RS232 debugger thread, on the cheapest FPGA, the RS232 UART can easily run above 200MHz.  However, the debugger itself was written for simplicity of function and ease of reading the code.  On the same bottom end FPGA, it can operate just above 125MHz max.  Now, I can modify it to perform at 200MHz, but, reading the code, many would ask why did I latch and compare some fundamental functions along 2 stages with latched registers, making the simple code look like it perceived or processed time along a skew.  This would be a deliberate necessary step if I wanted that code, with the same structure and commands to perform above 200MHz like the RS232 UART is capable of.

If your top data clock is 150MHz and you want to do some processing of that data in real time, the Max10 can handle that with ease and you have some breathing room.  Getting a processing design to run in the 250MHz on the slowest available Max10 would take some work as this is the clock limit of the internal dual-port memory blocks.  Looking at the '-C8' version data sheet, the slowest function you have is the 18x18bit multiplier.  Running that multiplier in single stage clock mode, this means your 2 input's multiplied results are ready by the next clock cycle is 160MHz in single power supply mode, 190MHz in dual power supply mode.  I would use this 160MHz as your worst case scenario, so, 150MHz on one of you data buses, as a target system clock frequency is a good fit.  Depending on what you are doing, if you have some sophisticated math or rules, you may have to learn how to pipeline your design to maintain this 150MHz performance.

[NorthGuy]

Parallel data with either a 150mhz clock on a pin, or 108mhz clock on another pin. both clk_p pins. Data pins never change.

You can create one block which handles one set of data, and the other block which handles the other set. You can route the data to both blocks.

The speed of their clock doesn't matter, as long as it is not too fast for you.

[BrianHG]

My little LC3 project will run at 100 MHz on an Artix 7 100T but timing fails at 200 MHz.  I didn't iterate over values to find the highest possible frequency because the crystal oscillator is 100 MHz and that is as fast as I want to push the design.  In ISE they used to tell you the maximum possible frequency.  I haven't found that datapoint in Vivado.  I'm sure it's there somewhere but I haven't run across it.

They removed the feature in Vivado:
https://www.xilinx.com/support/answers/57304.html
I find it kind of funny that with a bloody computer, and soooooo much on screen data and tables to show you everything that you have to read that thread, and use the formula given to you in that thread to calculate the FMAX on your own.  Where the formula is ' 1/(T-WNS) ' and T is your given clock period.  Though, on their timing reports video:
https://www.xilinx.com/video/hardware/timing-summary-report.html
They pretty much have an use all the same terminology and data timing points as Quartus' timing report, yet the 1 single number figure they want you to calculate by hand with a calculator is the FMAX?  I just want an Idea of how much work I need to do to stretch my design or it's expand-ability at a glance before digging into the difficult numbers.

[lawrence11]

Please be more clear when you say, "you can create a block"?

Something like this? The calculation in question is comparing the magnitude of 2 bytes, with an upper and lower value. I just wanna make sure the same logic is re-used and the sampled clock just de-selected, switched and not some whole new logic re-created, lets be efficient here.


always @(posedge clk_1)begin

             if(enable==1'b0) begin

                     calculation
                    ....
             
                end
                end

always @(posedge clk_2)begin

             if(enable==1'b1) begin

                     calculation
                    ....
             
                end
                end