I recently bought myself a Zybo Zync-7000 dev board so I could do some schoolwork & fiddling around with it at home, but when I was going to pick out my clock out of my UCF for the first time I came across this.
## Clock signal
#NET "clk" LOC=L16 | IOSTANDARD=LVCMOS33; #IO_L11P_T1_SRCC_35
#NET "clk" TNM_NET = sys_clk_pin;
#TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 125 MHz HIGH 50%;
I know I probably just have to take the first line to get my clk signal working but what is the rest for? Or am I mistaken and do I need all of it?
We got different hardware back in school and its a bit more straightforward there.
Thanks in advance.
I assume you are using ISE and not the new Vivado since only ISE uses UCF constraint files.
## Clock signal
This line is a comment about what the following lines pertain to.
#NET "clk" LOC=L16 | IOSTANDARD=LVCMOS33; #IO_L11P_T1_SRCC_35
This line specifies which physical pin (LOC=L16) on the FPGA the clock input (the input net named "clk" in the VHDL top level) from off-chip is connected to. It also specifies that the signal uses low voltage CMOS 3.3v signaling.
#NET "clk" TNM_NET = sys_clk_pin;
This just assigns a timing name to the net. For timing specific constraints, the timing name will be used instead of the (VHDL internal) net name.
#TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 125 MHz HIGH 50%;
This specifies that the timing of "sys_clk_pin" (resolves to the VHDL net "clk") should have a frequency of 125 MHz and a duty cycle of 50%. The tool needs to know this to determine how to route the signals without violating flip flop setup or hold times. The name "TS_sys_clk_pin" is just an identifier for this particular constraint.
Properly constraining a design is very important when you are near to filling up a part or if you want to run it at a higher clock speed. You can find a great wealth of information in the Xilinx constraint guide for ISE: https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx14_7/cgd.pdf
If you don't give your design timing constraints, the tools will typically throw a warning about the lack of constraints and it will tell you how fast you can run it at the end without causing errors. Timing constraints for the clocks are the most important. You typically only need other timing constraints on synchronous inputs and cross clock boundaries.
Note that all 4 lines are, in fact, currently commented out (prepended with a #). If you want to use the 3 functional lines, you need to remove the comment designation.
Related
Is the internal clock on the ATTiny85 sufficiently accurate for one-wire timing?
Per https://learn.sparkfun.com/tutorials/ws2812-breakout-hookup-guide one-wire timing seems to need accuracy around the 0.05us range, so a 10% clock error on the AVR at 8MHZ would cause 0.0125us sized timing differences (assuming the 10% error figure is accurate, and that it's 10% error on frequency, not +/- 10% variance on each pulse).
Not a ton of margin - but is it good enough?
First of all, WS2812 LEDs are not the 1-wire.
The control protocol of WS2812 is described in the datasheet
The short answer is yes, ATTiny85, also the whole AVR family have enough clock accuracy to control the WS2812 chain. But routine should be written at assembler, also no interrupts should be allowed, to guarantee match the timing requests. When doing the programming well, 8MHz speed of the internal oscillator may be enough to output the different data to two WS2812 chains simultaneously.
So, when running 8MHz ±10%, the one clock cycle would be 112...138 ns.
The datasheet requires (with 150ns tolerance):
When transmitting "one": high level to be 550...850ns; - 6 clock cycles (672...828) matches this range (also 5 clock cycles (560...690ns) matches)
following low level - 450...750ns; - 5 cycles (560...690ns)
When transmitting "zero": high level 200...500ns; - 3 cycles (336...414ns)
following low level 650...950ns; - 6 cycles (672...828).
So, as you can see, considering tolerance ±10% of the clock's source, you can find the integer number of cycles which will guarantee match to the required intervals.
Speaking from the experience, it still be working if the low level, which follows the pulse, will be extended for a couple hundreds of nanoseconds.
There are known issues using internal oscilator with UART - should be timed to 2% accuracy while the internal oscilator can be up to 10% off with factory setting. While it can be calibrated(AVR has register OSCCAL for that purpose), its frequency is influenced by temperature.
It is worth the try, but might not to be reliable with temperature changes or fluctuating operating voltage.
References: ATmega's internal oscillator - how bad is it, Timing accuracy on tiny2313, Tuning internal oscilator
The timing requirements of NeoPixels (WS2812B) are wide enough that the only really critical part is the minimum width of a 1 bit. The ATtiny85 at 16Mhz is plenty fast to drive a string of them from a GPIO pin. At 8Mhz, it may not work (I haven't tried yet). I just released a small Arduino sketch which allows you to control NeoPixel strings of any length on a ATtiny85 without using any RAM.
https://github.com/bitbank2/NeoPixel
For devices with hardware SPI (e.g. ATMega328p), it's better to use SPI to shift out the bits (also included in my code).
My board (Papilio One 500k) has a 32 MHz on-board oscillator that is connected to P89.
I see in the default constraints (UCF) file I downloaded, it has the line:
NET CLK LOC="P89" | IOSTANDARD=LVTTL | PERIOD = 31.25 ns;
Now, why is it that the period is defined here as 31.25 ns.
If the on board oscillator is a set frequency, why is it I can set the period here?
My thought is that this statement is to inform the compiler of the period of the on board oscillator rather than specify what the period is.
You can also set the frequency in an UCF file. Here is an example:
NET "SystemClock_200MHz_p" LOC = "H9"; ## U64.4
NET "SystemClock_200MHz_n" LOC = "G9"; ## U64.5
NET "SystemClock_200MHz_?" IOSTANDARD = LVDS;
NET "SystemClock_200MHz_p" TNM_NET = "NET_SystemClock_200MHz";
TIMESPEC "TS_SystemClock" = PERIOD "NET_SystemClock_200MHz" 200 MHz HIGH 50 %;
The period in your code is set to 31.25 ns, because that's the period of a 32 MHz clock signal.
Period := 1/Frequency
Yes, the constraint has no physical impact to the board or oscillator. It's needed by the static timing analyzer (STA) to check if your design meets all timing requirements (e.g. setup and hold times).
I need develope synthesizable custom verilog code for generating a higher frequency clock from low frequency clock i.e from 50 MHz clock i need to generate 100 MHZ clock . kindly help how to do the same.
A pure Verilog solution is not stable, so dedicated FPGA resources must be used.
Please see this previous answer; it applies to Verilog also, even through tagged VHDL.
My spartan 3a fpga board has a 50mhz clock while implementing a microblaze with ram ddr2 , it required a frequency of 62mhz which was edited by my program , when asked about this , they told me that 60mhz clock is used to generate other clocks internally but how does a 50mhz clock produce a 62mhz clock which is higher !?
in Xilinx Spartan devices you can use so called DCMs (digital clock managers) that give you a whole lot of possibilities; see Spartan User Guide or Xilinx Spartan 3 DCM. with the synthesizer option, clock multiplication/division is possible.
There are built in technologies that multiply the clock to higher frequencies. See Frequency Multiplier and Phase Locked Loop
under your design name in Implementation window in ISE right click and add new sorce select IPcore then select clocking wizard you can enter the primary freq : 50 mhz and required out freq: 62 mhz and the core generator will do it for you.
I'm writing a state machine which controls data flow from a chip by setting and reading read/write enables. My clock is running at 27 MHz giving a period of 37 ns. However the specification for the chip I'm communicating with requires I hold my 'read request' signal for at least 50 ns. Of course this isn't possible to do in one cycle since my period is 37 ns.
I have considered I could create an additional state which does nothing but flag the next state to be the one I actually complete the read on, hence adding another period delay (meaning I hold 'read request' for 74 ns), but this doesn't sound like good practice.
The other option is perhaps to use a counter, but I wonder if there's perhaps yet another option I haven't visited yet?
How should one implement delay in a state machine when a state should last longer than one clock period?
Thanks!
(T1 must be greater than 50 ns)
Please see here for the full datasheet.
Delays are only reliably doable using the clock - adding an extra "tick" either via an extra state or using a counter in the existing state is perfectly acceptable to my mind. The counter has the possibility of being more flexible if you re-use the same state machine with a slower external chip (or if you use a different clock frequency to feed the FPGA) - you can just change the maximum count, instead of adding multiple "wait" states to the state machine.