The design has an internal oscillator of 2.08 mhz. The 2.08 logic has no timing errors reported once compiled, place and routed. An async clock input, 100 MHz rate, has timing errors. Trying to use the constraints to set the clock rate. I cannot seem to properly identify the net, pin, or port to set the constraint. It failed with the below warnings.
constraint.lcd file line is: create_clock -period 50.000000 -name clk1 [get_nets pin22_c]
--------------------------it failed using the constraint with this message -----------------------------------------
WARNING - No object with type NET found matching pin22_c;
WARNING - Ignoring Constraint: create_clock -period 50.000000 -name clk1 [get_nets pin22_c].
------------------------the report before using the constrain file ----------------------------------------------
Constraint: create_clock -period 5.000000 -name clk1 [get_nets pin22_c]
119 items scored, 21 timing errors detected.
Error: The following path violates requirements by 2.088ns
Logical Details: Cell type Pin type Cell name (clock net +/-)
Source: FD1P3IX CK \so/sireaddone_30 (from pin22_c +)
Destination: FD1S3AX D \so/shiftreg_i4 (to pin22_c +)
Delay: 6.928ns (27.8% logic, 72.2% route), 4 logic levels.
Constraint Details:
6.928ns data_path \so/sireaddone_30 to \so/shiftreg_i4 violates
5.000ns delay constraint less
0.160ns L_S requirement (totaling 4.840ns) by 2.088ns
All day struggle with lattice diamond trying to set the clock constraint... finally figured out what needs doing.
process the design so to have a netlist
i used an empty constraint abc.lcd file so it was in the file list
right click on this file list tab and open with lcd editor
now double click the source box and selected clock port, select pin22
double click the other boxes and enter desired values
then under file click the save to save the file
rerun the process and all is well and that clock is set 20 MHz
be happy, but dissapointed with LATTICE!
then look at the file to find the syntax is not even close to what the manuals state!
#
create_clock -period 50.000000 -name asyncclk [ get_ports { pin22 } ]
#
Related
I have a *.w file, referring to two include files ({incl\include_file.i}, {incl\do_something_file.i}). That first include-file contains the definition of a RECID variable "recordid":
DEF INPUT-OUTPUT PARAMETER recordid AS RECID.
I am capable to compile the *.w file, the listing file looks as follows: (just a fragment)
Prompt>findstr "recordid do_something" listing.txt
...
1 x DEF INPUT-OUTPUT PARAMETER recordid AS RECID.
...
1 x 1 {incl\do_something_file.i
2 x 1 INPUT-OUTPUT recordid
So, the compilation works. In top of that, I've checked the pairs of "&ANALYZE-SUSPEND" and "&ANALYZE-RESUME" clauses and everything is fine.
Nevertheless, I can't open the *.w file, as the mentioned RECID seems not to be known (errors 201 and 196).
Edit after first comments
This the exact error message I get while opening the *.w file, using the AppBuilder (I'm working with a Dutch version of the tool, hence the Dutch words in between):
---------------------------
Fout
---------------------------
This file cannot be analyzed by the AppBuilder.
Please check these problems in your file or environment:
** Onbekende veld- of variabelenaam - recordid. (201)
** .\incl\<do_something_file>.i Compilatiefout op regel 7. (196)
---------------------------
OK
---------------------------
Edit with more information on ANALYZE- clauses
I've launched following findstr command on my code with the following results:
Prompt>findstr /I "ANALYZE-RESUME ANALYZE-SUSPEND" <filename>.w
&ANALYZE-SUSPEND _VERSION-NUMBER ... GUI
&ANALYZE-RESUME
&ANALYZE-SUSPEND _UIB-CODE-BLOCK _CUSTOM _DEFINITIONS ...
&ANALYZE-RESUME
...
I confirm that the number of &ANALYZE-SUSPEND clauses equals the number of &ANALYZE-RESUME clauses, they are in the right sequence (first a SUSPEND and then a RESUME) and none of them is commented out.
Does anybody have an idea what's going wrong?
The problem was caused by an include, being outside of an suspend resume clause, in order to solve such a situation the following command might be useful:
findstr /I "ANALYZE {incl" <source_file>.w
The result should look like the following:
...
&ANALYZE-SUSPEND _UIB-CODE-BLOCK _CONTROL C-Win
&ANALYZE-RESUME
&ANALYZE-SUSPEND _UIB-CODE-BLOCK _CUSTOM _MAIN-BLOCK C-Win
{incl\something.i}
{incl\something_else.i}
&ANALYZE-RESUME
...
You see following rules:
The number of suspends and resumes must be equal.
Every suspend is to be closed by a resume.
Not one of those can be commented out.
It is advised to have includes between the suspend and the resume.
I'm designing a huge system in a FPGA, operating at system clock 320 MHz.
Certain operations must be performed at slower clock - 160MHz due to long critical paths.
I can introduce a clock enable signal, lets call it CE2, used by registers surrounding such long operations.
According to the old Xilinx documentation: http://www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_constraints_ug.pdf (page 60), I can add a special constraint:
NET CE2 TNM = slow_exception;
NET clk TNM = normal;
TIMESPEC TS01 = PERIOD normal 8 ns;
TIMESPEC TS02 = FROM slow_exception TO slow_exception TS01*2;
defining such multicycle timing constraint.
Unfortunately the above case is not descrbide in newer versions of the documentation,
and especially in documentation for Vivado tools.
Does anybody know how the above problem should be solved in XDC file for Vivado?
The new way of doing multicycle constraints in Vivado specifies the number of cycles rather than the direct period.
You can also use datapath_only constraints for false paths and clock crossings, which are more directly akin to what you used in ISE
This is a datapath_only constraint:
create_clock -period 8.000 -name arbitraryClkName -waveform {0.000 4.000} [get_ports portName];
set_max_delay -from [get_pins {hierarchical_location_source/CLK}] -to [get_clocks arbitraryClkName] -datapath_only 16.000;
Here is an actual multicycle hold command:
set_multicycle_path -hold 2 -from [get_pins {hierarchical_location_source/CLK}] -to [get_pins {hierarchical_location_sink/D}];
Here is the constraint documentation for Vivado 2014.3; you can find multicycle path documentation on page 79:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_3/ug903-vivado-using-constraints.pdf
I'm new to the MSP430 and I am trying to better understand the clock bring-up process. For my current purpose I'm going to take PMMCOREV out of the equation by using a 4 MHz MCLK which is within the 0-8 MHz range for PMMCOREV = 0.
Will someone knowledgable about these parts please check my logic and assumptions:
When the part boots XT1 is selected as the FLL reference and DCOCLKDIV is selected as the MCLK input. DIVM is 0 so the MCLK source is not divided.
When the system boots the crystal is not yet stable so I'm assuming the UCS moves in to fail-safe mode and uses REFO (internal trimmed 32K) as the FLL reference.
Already I'm a bit confused. If the divided DCO is used for MCLK how are we assured that the FLL is stable? So how is the core functioning at all?
It seems to me that MCLK should be either VLO or REFO until you can bring things up gracefully.
Can someone clarify these details and steer me in the right direction to properly initialize these clocks?
Thanks!
Per your comment, yes.
At startup DCO will be the clock - so you just need to modify the UCSCTL registers and wait for the oscillators to settle and you are good to go.
Here are the steps in general:
Change the vcore level in steps (if necessary - in your case its not)
Enable XT1
Configure the drive strength
Select your clock sources for MCLK, SMCLK, and ACLK and do any source division that you need to do
Allow XT1, XT2 and DCO to stablize by checking for fault flags.
Your external crystal is 4Mhz - Are you wanting to use it as MCLK directly? Or is your angle to use it as a reference to the FLL for DCO, and use DCO for MCLK (to achieve a higher MCLK frequency)? The core volatage that you will need depends on whatever your MCLK frequency is, not your external crystal's frequency. So if you are wanting to use a MCLK rate of higher than 8Mhz you will need to consider stepping up PMMCOREV to 01.
For convenience, here is a reference for UCS registers from SLAU208M.
http://www.ti.com/lit/ug/slau208m/slau208m.pdf#page=172
Based on your OP, I think you should do the following if you want to use XT1 are your MCLK:
//1) Enable XT1 - XT1 will be off by default. You may not need to explicitly
// perform this step. According to pg. 162 in SLAU208M, XT1 will be
// enabled when you select it as the source for one of the clocks. But I
// like being explicit!
UCSCTL6 &= ~XT1OFF //XT1OFF= 0x0001u
//2) Clear the XT1DRIVE bits - it may not be necessary to clear these bits
// explicitly, but XT1's drive strength can be reduced to 0 w/ a 4MHz
// crystal. By default, this will be b11, full scale, which will consume
// more power, but result in a quicker settling time.
UCSCTL6 &= ~XT1DRIVE0; //XT1DRIVE0 = 0x0040u
UCSCTL6 &= ~XT1DRIVE1; //XT1DRIVE1 = 0x0080u
//3) Select XT1 as the clock source for XT1. UCSCTL4 defaults to 0x44 at
// power on - DCOCLKDIV (b100). SELM_XT1CLK = b000.
UCSCTL4 &= SELM__XT1CLK; //SELM__XT1CLK = 0x0000u
//4) Wait for XT1 to stabilize
do
{
//Explicitly clear the XT1 low and high frequency fault flasg, XT2 fault flag,
//and DCO fault flag. 0X0008u, 0x0002, 0x0004, 0x0001 respectively.
UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG);
//Clear the oscillator fault interrupt flag in the special function interrupt
//flags register.
SFRIFG1 &= ~OFIFG; //0X0002U
} while (SFRIFG1&OFIFG); //Test to see if any oscillator fault flags are asserted.
I am using IAR systems, not sure if you are using CCS if those definitions will be named differently. I went ahead and typed out the hex for each of the operands.
On the msp4305438A you do not have to do anything with bypass.
Does that answer your question?
Also, in your OP you mention wanting to use XT1 as a reference for an FLL. That is accomplished using UCSCTL3. SELFREF is the field you want to set to b000 to use XT1,
Here's the definitions for the MSP4305438A header in IAR:
#define SELREF0 (0x0010u) /* FLL Reference Clock Select Bit : 0 */
#define SELREF1 (0x0020u) /* FLL Reference Clock Select Bit : 1 */
#define SELREF2 (0x0040u) /* FLL Reference Clock Select Bit : 2 */
I am not sure if this is the right stack exchange website to post this on, but if it isn't please move it to the appropriate one.
I am facing a small problem in writing my constraints file for the spartan 3 starter kit.
I have read the documentation provided by Xilinx (the manufacturer) and ive been searching online for a few weeks without any luck.
What i am trying to do is link my Netlist interface to any of the 3 40-pin-headers on the board. (See image below)
Usually its very simple, if say i want to interface a button or a led on the board, i just read the connection name on the board, for example one of the buttons is M13 and write in the UCF file something like this :
NET "BTN0" LOC = "M13";
As you can see on the image the headers are named A1, A2 and B1 on the board, but oddly enough, none of the following worked :
NET "TestOutputLine" LOC = "A1(0)"; -- The (0) is to reference a single line on an array
NET "TestOutputBus" LOC = "A1"; -- The bus is of equal dimension of A1 (which is 40)
The errors i got meant that either the target (specified by LOC) does not exist or that the assignment is invalid.
I hope you have some ideas for me.
Thanks in advance
EDIT :
Here is the output from ISE :
ConstraintSystem:59 - Constraint <NET "TestOutputBus" LOC = "A1";>
[circuit.ucf(12)]: NET "TestOutputBus" not found. Please verify that:
1. The specified design element actually exists in the original design.
But i am pretty sure that TestOutputBus exists, as a matter of fact there is nothing else in my design right now, and the correct top level unit is being used.
EDIT2 :
I updated my UCF file, right now it's like this :
NET "TestOutputBus(0)" LOC = "A1(0)";
NET "TestOutputBus(1)" LOC = "A1(1)";
But i get a different error now in mapping :
MapLib:30 - LOC constraint A1:0 on TestOutputBus<0> is invalid: No such
site on the device. To bypass this error set the environment variable
'XIL_MAP_LOCWARN'.
MapLib:30 - LOC constraint A1:1 on TestOutputBus<1> is invalid: No such
site on the device. To bypass this error set the environment variable
'XIL_MAP_LOCWARN'.
Solution :
In order to get the pins 5 and 6 mapped to TestOutputBus(0) and TestOutputBus(1) respectively what i had to use was this :
NET "TestOutputBus(0)" LOC = "N7"; -- A1 pin 5
NET "TestOutputBus(1)" LOC = "L5"; -- A1 pin 6
Note that pins 0 are not mappable thats why i used pins 5 and 6, here are the tables that show the mappable pins for all headers and their LOCs.
As it turns out, there is an address for each usable pin of each header of the FPGA.
The datasheet (http://forums.xilinx.com/xlnx/attachments/xlnx/Spartan/3411/1/S3BOARD_RM.pdf) was helpful especially pages 49 - 51
I copied this from my earlier comment to your question so it would be an actual answer and not just a comment.
You should have LOC constraints in your UCF file for every port on your top-level module. So if you have a 40-bit-wide bus as an input or output at the top level then you should also have 40 separate LOC constraints in your UCF file to make sure that the logical bus in your top-level schematic actually gets mapped to the correct pins on your FPGA. If you are only using two pins, then you can declare the bus to be 2-bits wide and use 2 LOC constraints. The FPGA will treat all unused pins as inputs and ignore them.
I once got the original ConstraintSystem:59 net xyz not found error when i accidentally selected one of my modules as a top module. The pins declared in UCF could not be found in the port declaration of wrong module.
Also i get this error when i have some pin declared in UCF but ommit it in port declaration of top module.
ISO/IEC 2022 defines the C0 and C1 control codes. The C0 set are the familiar codes between 0x00 and 0x1f in ASCII, ISO-8859-1 and UTF-8 (eg. ESC, CR, LF).
Some VT100 terminal emulators (eg. screen(1), PuTTY) support the C1 set, too. These are the values between 0x80 and 0x9f (so, for example, 0x84 moves the cursor down a line).
I am displaying user-supplied input. I do not wish the user input to be able to alter the terminal state (eg. move the cursor). I am currently filtering out the character codes in the C0 set; however I would like to conditionally filter out the C1 set too, if terminal will interpret them as control codes.
Is there a way of getting this information from a database like termcap?
The only way to do it that I can think of is using C1 requests and testing the return value:
$ echo `echo -en "\x9bc"`
^[[?1;2c
$ echo `echo -e "\x9b5n"`
^[[0n
$ echo `echo -e "\x9b6n"`
^[[39;1R
$ echo `echo -e "\x9b0x" `
^[[2;1;1;112;112;1;0x
The above ones are:
CSI c Primary DA; request Device Attributes
CSI 5 n DSR; Device Status Report
CSI 6 n CPR; Cursor Position Report
CSI 0 x DECREQTPARM; Request Terminal Parameters
The terminfo/termcap that ESR maintains (link) has a couple of these requests in user strings 7 and 9 (user7/u7, user9/u9):
# INTERPRETATION OF USER CAPABILITIES
#
# The System V Release 4 and XPG4 terminfo format defines ten string
# capabilities for use by applications, .... In this file, we use
# certain of these capabilities to describe functions which are not covered
# by terminfo. The mapping is as follows:
#
# u9 terminal enquire string (equiv. to ANSI/ECMA-48 DA)
# u8 terminal answerback description
# u7 cursor position request (equiv. to VT100/ANSI/ECMA-48 DSR 6)
# u6 cursor position report (equiv. to ANSI/ECMA-48 CPR)
#
# The terminal enquire string should elicit an answerback response
# from the terminal. Common values for will be ^E (on older ASCII
# terminals) or \E[c (on newer VT100/ANSI/ECMA-48-compatible terminals).
#
# The cursor position request () string should elicit a cursor position
# report. A typical value (for VT100 terminals) is \E[6n.
#
# The terminal answerback description (u8) must consist of an expected
# answerback string. The string may contain the following scanf(3)-like
# escapes:
#
# %c Accept any character
# %[...] Accept any number of characters in the given set
#
# The cursor position report () string must contain two scanf(3)-style
# %d format elements. The first of these must correspond to the Y coordinate
# and the second to the %d. If the string contains the sequence %i, it is
# taken as an instruction to decrement each value after reading it (this is
# the inverse sense from the cup string). The typical CPR value is
# \E[%i%d;%dR (on VT100/ANSI/ECMA-48-compatible terminals).
#
# These capabilities are used by tac(1m), the terminfo action checker
# (distributed with ncurses 5.0).
Example:
$ echo `tput u7`
^[[39;1R
$ echo `tput u9`
^[[?1;2c
Of course, if you only want to prevent display corruption, you can use less approach, and let the user switch between displaying/not displaying control characters (-r and -R options in less). Also, if you know your output charset, ISO-8859 charsets have the C1 range reserved for control codes (so they have no printable chars in that range).
Actually, PuTTY does not appear to support C1 controls.
The usual way of testing this feature is with vttest, which provides menu entries for changing the input- and output- separately to use 8-bit controls. PuTTY fails the sanity-check for each of those menu entries, and if the check is disabled, the result confirms that PuTTY does not honor those controls.
I don't think there's a straightforward way to query whether the terminal supports them. You can try nasty hacky workarounds (like print them and then query the cursor position) but I really don't recommend anything along these lines.
I think you could just filter out these C1 codes unconditionally. Unicode declares the U+0080.. U+009F range as control characters anyway, I don't think you should ever use them for anything different.
(Note: you used the example 0x84 for cursor down. It's in fact U+0084 encoded in whichever encoding the terminal uses, e.g. 0xC2 0x84 for UTF-8.)
Doing it 100% automatically is challenging at best. Many, if not most, Unix interfaces are smart (xterms and whatnot), but you don't actually know if connected to an ASR33 or a PC running MSDOS.
You could try some of the terminal interrogation escape sequences and timeout if there is no reply. But then you might have to fall back and maybe ask the user what kind of terminal they are using.