Libero SoC timing constraints (*.sdc) difference - fpga

After designing RTL I create my_design.sdc file (for constraining clocks, input/output delays, ...) using Synplify pro. When constraints are correct, I click on synthesize and I get another my_design_sdc.sdc file automatically. If I right click on the first one, I can select "Use for synthesis" and "Use for compile" for my_design_sdc.sdc file. What I don't understand is, which file is for what, because after compile and place and route, there is also SmartTime software which takes the my_design_sdc.sdc file.
Q1: What relations are between these two files?
Q2: Does one have to have both of them in complete chain (RTL design to program)?
Q3: If so, how can I be sure that relations between constraints are the same, if SmartTime has different commands than Synplify?
Synplify multicycle constraint definition:
set_multicycle_path [-start|-end] [-from {objectList}] [-through {objectList} [-through {objectList} ...]] [-to {objectList}] pathMultiplier[-disable] [-commentcommentString]
SmartTime multicycle constraint definition:
set_multicycle_path ncycles [-setup] [-hold] [-from from_list] [–through through_list] [-to to_list]
Also, Synplify uses define_clock command for clock constrain definition and SmartTime uses create_clock. Those are only few differences.
I'm using:
Libero SoC v11.8 sp2 (in classic constraint flow view)
IGLOO2

Q1: Synplify auto-generates a smarttime SDC-file based on the clock settings you gave synplify. So that you don't have to define all your clocks twice. As you already figured out, Synplify and Smarttime require slightly different SDC files.
Q2: Depends on your project. Typically you create a SDC file for Synplify, containing basically only clock information. Then you take the auto-generated SDC from synplify and give it to the 'compile' step, together with a third SDC where you define all input/output delays, false paths, and things like that.
Q3: That is what the auto-generated file is for. It allows you to define all the clock settings in only one SDC file.
Keep in mind that the SDC info you give Synplify is typically not terribly important. It just helps Synplify make slightly better area/speed optimization calls sometimes.
The SDC files you give to the compile step are the critical ones. Here your clocks, input/output delays and false paths must be 100% correct.
By the way: Multicycle paths are basically an "expert level mechanism". Very difficult to get those right. It is something which is very rarely used in proper design. Their function is however very frequently misunderstood and misused, causing unstable designs.
In all likelyhood, multi cycle path constraints is not something which you should use in your design.

Related

Reason for lpm_constant to exist

I'm currently analyzing a given FPGA Verilog program and I stumbled upon the lpm_constant IP-Core, provided by Altera.
The only thing it does is to provide a constant value to a bus.
My Question is, why one should use this IP-Core, instead of a wire with constant value, or a reg with initialization in initial block, or reset cycle.
I also don't see the point of the reason being either to improve performance (Fitter should take care of this anyways, regardless of implementation) or compatibility with other designs (the language Verilog/VHDL is standardized, so why would this be an issue).
Thanks for clarification.
One can use the In-System Memory Content editor to change the value of the "constant" at design run time, to help in debug and testing of the design. We lose this capability if we hard code a value in RTL.
As #JHBonarius said the only reason to use lpm_constant (Altera Megafunction) if you describe your project in a schematic way, i.e. use Block Design File (*.bdf). If you use HDL-like approach use CONSTANT to make code CAD Tools independent.

Problems getting Altera's Triple Speed Ethernet IP core to work

I am using a Cyclone V on a SoCKit board (link here) (provided by Terasic), connecting an HSMC-NET daughter card (link here) to it in order to create a system that can communicate using Ethernet while communication that is both transmitted and received goes through the FPGA - The problem is, I am having a really, really hard time getting this system to work using Altera's Triple Speed Ethernet core.
I am using Qsys to construct the system that contains the Triple Speed Ethernet core, instantiating it inside a VHDL wrapper that also contains an instantiation of a packet generator module, connected directly to the transmit Avalon-ST sink port of the TSE core and controlled through an Avalon-MM slave interface connected to a JTAG to Avalon Master bridge core which has it's master port exported to the VHDL wrapper as well.
Then, using System Console, I am configuring the Triple Speed Ethernet core as described in the core's user guide (link here) at section 5-26 (Register Initialization) and instruct the packet generator module (also using System Console) to start and generate Ethernet packets into the TSE core's transmit Avalon-ST sink interface ports.
Although having everything configured exactly as described in the core's user guide (linked above) I cannot get it to output anything on the MII/GMII output interfaces, neither get any of the statistics counters to increase or even change - clearly, I am doing something wrong, or missing something, but I just can't find out what exactly it is.
Can any one please, please help me with this?
Thanks ahead,
Itamar
Starting the basic checks,
Have you simulated it? It's not clear to me if you are just simulating or synthesizing.
If you haven't simulated, you really should. If it's not working in SIM, why would it ever work in real life.
Make sure you are using the QIP file to synthesize the design. It will automatically include your auto generated SDC constraints. You will still need to add your own PIN constraints, more on that later.
The TSE is fairly old and reliable, so the obvious first things to check are Clock, Reset, Power and Pins.
a.) Power is usually less of problem on devkits if you have already run the demo that came with the kit.
b.) Pins can cause a whole slew of issues if they are not mapped right on this core. I'll assume you are leveraging something from Terasic. It should define a pin for reset, input clock and signal standards. Alot of times, this goes in the .qsf file, and you also reference the QIP file (mentioned above) in here too.
c.) Clock & Reset is a more likely culprit in my mind. No activity on the interface is kind of clue. One way to check, is to route your clocks to spare pins and o-scope them and insure they are what you think they are. Similarly, if you may want to bring out your reset to a pin and check it. MAKE SURE YOU KNOW THE POLARITY and you haven't been using ~reset in some places and non-inverted reset in others.
Reconfig block. Some Altera chips and certain versions of Quartus require you to use a reconfig block to configure the XCVR. This doesn't seem like your issue to me because you say the GMII is flat lined.

How to create relative placement of Flip-flops in Microsemi/Actel Libero?

In the past I've used some Xilinx FPGAs and was able to easily create RELATIVE placement of flip-flips using VHDL attributes such as RLOC.
Currently I'm working with the SmartFusion2 FPGA and trying to achieve the same in Libero SoC. After looking through "Synopsys FPGA Synthesis Synplify Pro for Microsemi Edition: Attribute Reference", I was able to find "alsloc" which seems to be the direct equivalent of RLOC.
However the addition of this attribute doesn't change or affect the placement of the MACROs at all.
Looking further I found that "set_location" constraint can be used within the design constraint file to fix the location of MACROs. Unfortunately this constraints the position of the MACROs to an ABSOLUTE position on the chip and can interfere with the rest of automatic placement and routing optimization effort.
So is there a way to constraint the relative position of MACROs (specifically flip-flops) in Libero SoC using VHDL attributes or design constraint file directives?
To my knowledge, there is no direct equivalent.
The closest thing would probably be the define_region/assign_region constraints.
Use "assign_region" to associate a set of related flip-flops or entire component instances to a user defined region.
"define_region" specifies the size and location for the region.
Libero will place the associated parts inside the region.
The region still has an absolute position, but to move the flip-flops around, you only need to change the "define_region" constraint.
It is not as elegant as RLOC, but it does the job.

How to Ignore a Synthesis constraint if signal is not in design?

I have a clock in my design that drives some logic in normal operation. However occasionally I want to disable this block of logic by setting a VHDL generic to disable it. But I still have a clock constraint in my .xcf file e.g:
NET "TEST_CLK" TNM_NET = "TEST_CLK";
TIMESPEC TS_TEST_CLK = PERIOD "TEST_CLK" 20.000 ns HIGH 50 %;
If I try to run synthesis I get the following error:
Processing TIMESPEC TS_TEST_CLK: No TNM or User group name TEST_CLK is defined.
How can I tell the tools to effectively ignore this constraint when the clock has been (correctly) optimized out of the design? Is this even possible?
Vivado issues a Critical Warning for constraints that do not match the design, however it continues to build and will generate a .bit file anyway. I think this is a nice tradeoff, but you have to remember to look at the critical warnings.
Also, as Morten Zilmer commented, Vivado uses a TCL file for the constraints, so you can conditionalize the constraints or generate them based on the actual design.
When using the ISE tools, ngdbuild (Translate) has the "allow unmatched timing group" option (-aut on the command line). This is supposed to be used when you have an incomplete design. There ought to be an option under translate properties in the gui also. If you are adding the constraint at synthesis I'm not sure there is an option to specifically do this.

Graphical VHDL Component Editor

In many of my VHDL designs I create a lot of low level components in HDL (which is fine). However, when I am ready to create multiple instantiations and link them together at the top-level, I find that the file ends up being rather large with tons of internal signals going between tons of component instantiations. It gets a little unwieldy and hard to follow.
Instead, I thought what might be easier to understand and faster to develop with is if there was a graphical tool to do the high level component linking. It would be able to parse my low level HDL files and determine the port inputs/outputs and create a block (or multiple instances of that block). I could then use my mouse to create connections between the blocks and give them a text label. When I am done, it would be able to auto-generate a VHDL file with all appropriate syntax for creating internal signals, component instantiations, port declarations, etc.
I tried experimenting with Xilinx Schematic Editor, but this thing was a beast and I did not have any luck.
Is there any tool out there like this? If it could even get me 90% of the way I'd be happy.
You should take a look at www.sigasi.com
Sigasi has autocompletes to help you with the instantiations and quick-fixes to help you with the wiring. There is also a premium version that gives you a live, graphical block diagram view (demo screencast)

Resources