I try to construct the following:
CO
|
/carry\ ____
s2 ---(((---|I0 |------------ O
+------+((---|I1 |
| +-(+---|I2 |
| | +----|I3__|
| +-(-----------+
| | |
| /carry\ ____ |B ___ BQ
D -----+------(((---|I0 |-+-----| |-+
s0 --+((---|I1 | > | |
s1 ---(+---|I2 | s3 -|S | |
| +-|I3__| s4 -|CE_| |
| +--------------------+
|
/carry\
|||
I write in Verilog, and instantiates SB_LUT4, SB_CARRY, SB_DFFESS primitives. To try to get a LUT cascade, I edit a .pcf constraints file (set_cascading...). However, synthesis (Lattice IceCube 2017.01.27914) disregards the constraints:
W2401: Ignoring cascade constraint for LUT instance 'filt.blk_0__a.cmbA.l.l', as it is packed with DFF/CARRY in a LogicCell
In the admirable Project IceStorm I can't see any reason why a combination of cascaded LUTs and the carry chain can't be used.
I am aware that a (slightly) newer IceCube2 is available. I know of the Yosys/arachne-pnr/icepack/iceprog toolchain. But before changing a toolchain, it seems prudent to ask if anyone solved this problem already, or if it is indeed not possible to combine the carry chain and LUT cascades?
Update - a quick install of Yosys/arachne-pnr/icetools synthesizes my design without warnings, but visualisation in ice40_viewer (and log output) indicates that the chained lut is not used.
I try to improve our build process and use 2-3 predefined parameters for run on one single build.
Description: we have build configuration with parameters C1, C2, C3 and related build steps B1, B2, B3. They link to each other C1-B1, C2-B2, C3-B3. In this scheme all works fine, I pass parameters like mentioned here - How to pass Arguments between build configuration steps in team city?,
but I'm a bit worried because B1, B2, B3 are full copy each other and this i would like to improve it. Only one problem I couldn't find any mechanism to pass parameters from different configuration.If I use %dep. mechanism i can use parameter from only one configuration.
UPD: Currect scheme
+---+ +---+ +---+
| | | | | |
| C1| | C2| | C3|
| | | | | |
+-+-+ +-+-+ +-+-+
| | |
| | |
+-v-+ +-v-+ +-v-+
| | | | | |
| B1| | B2| | B3|
| | | | | |
+---+ +---+ +---+
the desired scheme:
+---+ +---+ +---+
| | | | | |
| C1| | C2| | C3|
| | | | | |
+-+-+ +-+-+ +-+-+
| | |
| | |
| +-v--+ |
| | | |
| | | |
+-----> B1 <----+
| |
+----+
C1, C2, C3 setup configuration parameters
B1 contains only build steps, like clean, build, dist
Could anyone help me with that? Any ideas?
In your case, you can introduce a TeamCity Metarunner. The idea is that you combine multiple build steps with parameters, and extract them as new entity, available as build runner.
See this documentation section for step by step instructions on creating a metarunner.
You can define a parameter in the template, call it, for example, external.param and give no definition.
Then, in each configuration (C1, C2 and C3) define the value of this parameter as reference to specific dependency.
external.param = %dep.<source_cfg_id>.<source_param_name>%
I have an array in sphinx / rst, and I would like to reference a line or cell from other part of my documentation.
How can I create an inline markup reference target in the array?
The array looks like this:
+-----------------+-------------------------+-------------------------------------------------------+
| e | c | p |
+=================+=========================+=======================================================+
| e1 | c1 | p1 |
+-----------------+-------------------------+-------------------------------------------------------+
| e2 | c2 | p2 |
+-----------------+-------------------------+-------------------------------------------------------+
I did not think this was possible, but this worked for me.
+----+----+-------------------------+
| e | c | .. _my-reference-label: |
| | | |
| | | p |
+====+====+=========================+
| e1 | c1 | p1 |
+----+----+-------------------------+
| e2 | c2 | p2 |
+----+----+-------------------------+
and then the link to the target would be:
:ref:`Link title <my-reference-label>`.
The formatting makes the targeted cell larger than it should be, but you can fiddle with the other column widths to get percentage widths close enough.
According to RFC - RFC 6020 - LeafRef I can understand that the leaf can contain a leafref which inturn have the path pointing to the instance which is referenced but question is how many leafrefs are possible for one leaf? Only one or many?
Ex.
leaf mgmt-interface {
type leafref {
path "../interface/name";
}
type leafref {
path "../interface/ip";
}
}
Is the above possible?
A leafref may only target a single leaf or leaf-list node via path. There may only be one type substatement to a leaf (also applies to leaf-list, typedef) and there may only be a single path substatement to type.
7.6.2. The leaf's Substatements
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| default | 7.6.4 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.6.3 | 1 | <--
| units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
12. YANG ABNF Grammar
type-stmt = type-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
type-body-stmts
"}")
type-body-stmts = numerical-restrictions /
decimal64-specification /
string-restrictions /
enum-specification /
leafref-specification /
identityref-specification /
instance-identifier-specification /
bits-specification /
union-specification
leafref-specification =
;; these stmts can appear in any order
path-stmt stmtsep
[require-instance-stmt stmtsep]
path-stmt = path-keyword sep path-arg-str stmtend
Note: it is not possible to use union for leafref types in YANG 1.0. This has changed in YANG 1.1 however, where any built-in YANG type may appear inside a union.
9.12. The union Built-In Type
A member type can be of any built-in or derived type, except it MUST
NOT be one of the built-in types "empty" or "leafref".
I have the problem debugging an complicated recursive function I'm using the idiom:
dbg:tracer(),dbg:p(all,c),dbg:tpl(Mod,Fun1,x),dbg:tpl(Mod,Fun2,x)...
This gives me a flat list of calls to all functions where it is very hard to find out which return belongs to which call.
Is there a easy way to make this more readable e.g. by indenting.
I could just post process the text produced and indent for each call, and outdent for each return, but this sounds not very elegant to me.
In the meantime I figured it out how to do this, its actually not too hard. To have a process handling the trace message output you just have to use dbg:trace/2,3 and write one function that does the formatting.
We write a small module containing the function to pass to dbg:trace:
-module(trtool).
-export([nested/2]).
nested({trace, _Pid, call, {Mod, Fun, Param}}, Level) ->
io:format("~s~p:~p ~p\n",
[lists:duplicate(Level, "| "), Mod, Fun, Param]),
Level + 1;
nested({trace, _Pid, return_from, {Mod, Fun, Arity}, Rval}, Level) ->
L = Level - 1,
io:format("~s~p:~p/~b -> ~p\n",
[lists:duplicate(L, "| "), Mod, Fun, Arity, Rval]),
L;
nested(Any, Level) ->
io:format("trace_msg: ~p\n", [Any]),
Level.
The function takes two arguments, in the first it gets passed the trace message which is a tuple with convenient fields. To find out how the messages you want to format are structured just start with a simple function that prints everything like the last clause of the example function.
The second format is a kind of state that could contain any data. We pass the initial value when calling dbg:trace and return the next value from our function.
In the nested example we just pass the indent level which will be incremented and decremented in the call and return_from clauses.
Now lets try this out, first calling dbg:tracer/2, first parameter must be the atom process, second parameter a tuple containing our newly written fun and the initial value for the state param.
1> dbg:tracer(process, {fun trtool:nested/2, 0}).
{ok,<0.70.0>}
Then we set up tracing as before:
2> dbg:p(all, c), dbg:tpl(user_default,hop,x),dbg:tpl(user_default,rec,x).
{ok,[{matched,nonode#nohost,2},{saved,x}]}
Then we start our function call to trace and the nesting can be easily followed:
3> rec(3).
user_default:rec [3]
| user_default:rec [3,1,3]
| | user_default:rec [3,1,2]
| | | user_default:rec [3,1,1]
| | | | user_default:rec [3,1,0]
| | | | | user_default:hop [3,1,0]
| | | | | user_default:hop/3 -> {3,21}
| | | | user_default:rec/3 -> {3,21,1}
| | | | user_default:rec [6,2,-1]
| | | | | user_default:hop [6,2,1]
| | | | | user_default:hop/3 -> {2,46}
| | | | user_default:rec/3 -> {2,46,1}
| | | user_default:rec/3 -> {5,67,2}
| | | user_default:rec [8,3,0]
| | | | user_default:hop [8,3,0]
| | | | user_default:hop/3 -> {3,144}
| | | user_default:rec/3 -> {3,144,1}
| | user_default:rec/3 -> {8,211,3}
| | user_default:rec [11,4,1]
| | | user_default:rec [11,4,0]
| | | | user_default:hop [11,4,0]
| | | | user_default:hop/3 -> {3,258}
| | | user_default:rec/3 -> {3,258,1}
| | | user_default:rec [14,5,-1]
| | | | user_default:hop [14,5,1]
| | | | user_default:hop/3 -> {2,260}
| | | user_default:rec/3 -> {2,260,1}
| | user_default:rec/3 -> {5,518,2}
| user_default:rec/3 -> {13,729,5}
user_default:rec/1 -> {15,729}
{15,729}
4>
There is not way you can do that with the current dbg tracer process, you would have to write your own. If you start dbg:tracer/2 and use a process or port to capture the data and print it the way you want it to be.
It is probably faster and easier though to (as you say) parse the data post tracing and format it then.