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.
Related
I'm working with a ProASIC3L, and I keep getting these errors:
Planning global net placement...
Error: PLC004: No legal global assignment could be found. Some global nets have shared
instances, requiring them to be assigned to overlapping global regions.
Global Nets Whose Drivers Are Limited to Quadrants or Which Have No Valid Locations:
|--------------------------------------------|
|Global Net |Valid Driver Locations |
|--------------------------------------------|
|GLA |(None)
|--------------------------------------------|
|GLB |(None)
|--------------------------------------------|
|RST_N_c |(None)
|--------------------------------------------|
Info: Consider relaxing the constraints for these nets by removing region constraints,
unassigning fixed cells and I/Os, relaxing I/O bank assignments, or using input
buffers without hardwired pad connections.
Error: PLC003: No legal global assignment could be found because of complex region and/or IO
technology constraints.
Error: PLC005: Automatic global net placement failed.
INFO: See the GlobalNet Report from the Reports option of the Tools menu for information about
the global assignment.
The Layout command failed ( 00:00:01 )
The GLA and GLB signals come from a PLL block and are then passed down a few module layers to all the different components in the design. I'm kinda a rookie to clock management and tbh dont really know how to approach debugging. Anyone got any advice for me?
I had to apply additional constraints for clock placement for PRO ASIC3, though this was very long time ago. My advice is to dig into specific ProASIC3L documentation and/or ask Microchip FAE. He/She has access to factory database that has similar problems and resolutions. I think this is a shortest path to resolve this.
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.
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.
I am trying to map the properties of a medical device as described by a sequence of OBX segments in a PCD-01 message to FHIR resources. The properties described in the PCD-01 message are
the device type (such as a blood pressure cuff) (found in FHIR Device
resource)
the manufacturer name and model number (found in the FHIR Device
resource)
the production specifications (found in the FHIR DeviceComponent
resource)
properties such as time capabilities (found in the FHIR DeviceMetric)
I would expect that the logical way to do this would be to populate each of these resources with the data from the said OBX segments and then "link" them together by making the DeviceMetric a contained resource of the DeviceComponent which is a contained resource of the Device. However, a contained resource cannot contain further contained resources so I need to include two contained resources in the Device resource.
However, the example for the DeviceComponent at
http://www.hl7.org/fhir/2015May/devicecomponent-example-prodspec.json.html
shows the Device a contained resource of the DeviceComponent, exactly backwards of what I would expect. How are these resources supposed to be used? I cannot use any single one of these resources to describe all the properties of the actual device, the real difficulty being that the manufacturer and model names are not in the same resource as the production specification information.
Also, if the Device type identifies that the device is a blood pressure cuff, what does the DeviceComponent type indicate? There really is no 'component' in this case, the device is a stand-alone BP cuff and nothing else, I am just forced to use the DeviceComponent resource in order to describe the production specification values.
Any help on this would be greatly appreciated!
Thanks Ewout for your very well explanation.
To Brian: As you mentioned IEEE 11073-20601 in one of your comments, may I make an assumption that you are only dealing with MDS and Metric as the DIM model for your blood pressure cuff?
Thus, to describe the blood pressure cuff observation (PCD-01 message), your resource of interest are the following:
Device: to describe the device type (preferably using nomenclature as defined in IEEE 11073-10101), manufacture and model number, udi, etc. This resource is created once, and will live through the lifetime of the device unless there is a change with location/organization/patient.
DeviceComponent: to describe the MDS where you can populate production specification, operational status of the device, etc. This resource would have the same lifetime as the device resource unless there is a change with software version, hardware version, or operational status for example.
DeviceMetric (x3): to describe each metric (systolic, diastolic, pulse) including type (preferably using nomenclature as defined in IEEE 11073-10101), unit (preferably using nomenclature as defined in IEEE 11073-10101, but UCUM is fine), identifier (metric unique identification that is assigned by the device, for example, handle ID), and measurementPeriod (if the device happens to repetitively taking measurement at a specified period time, for example, every hour). Same lifetime like DeviceComponent unless there is the change in unit or measurement period.
Observation (DeviceMetricObservation profile): to describe the actual measurement. (In PCD-01, we used OBX-4 to describe the c-tree path that link the observation to the actual metric in the tree. For FHIR, we use device element to describe the external reference to the DeviceMetric)
I would not recommend to use contained resource. I think we should probably create all Device/DeviceComponent, and DeviceMetric resources ahead of time, cache their links and used those as external references. For example, Device resource will be created first, then DeviceComponent whose source element contains the external reference to the Device resource, then DeviceMetric resource whose parent element contains the external reference to DeviceComponent and source element contains the external reference to Device. Now that we have a somewhat well-organized containment tree setup using those resources and links, whenever the device produces a new measurement, we only to create the observation resource, setup the link to DeviceMetric, and that should be it.
Please let me know if you have further questions. Thanks
"the Device a contained resource of the DeviceComponent, exactly backwards of what I would expect"
This is the way that the resources are defined - DeviceComponent refers to Device as a source, rather than Device listing it's components. I'm not sure why they are defined that way - I'll ask the committees (Orders/Obs and Devices) to comment.
I would think that if the Device is a blood pressure cuff, it has a single component that carries the values. That's not the most obvious solution, but it's certainly how things have developed over the years in the PCD space.
The physical composition of a Device is done by the DeviceComponents pointing to their "parent" component using DeviceComponent.parent, e.g. channel to VMD and VMD to the MDS. All components point to the "logical" Device they belong to, using DeviceComponent.source.
In this model, the "Device" is the "administrative" resource for the device (it does not change much and has manufacturer information etc.), where as the DeviceComponent models the physical part, including operation status and is much more volatile.
If you want to express which logical device your observation came from, you can just use Device, if you need to be more specific observation can point to DeviceMetric (which is really a kind of DeviceComponent).
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)