P1801 Proposal Discussion
Wireless network access at Magma
• SSID (not broadcast): lava
64 bit key or 10 digit Hex key : 00000fffff
April 13, 2015 -- 2
Get commands for P1801
• Why are these needed?
• To allow for instrumentality without the requirement to
•
delete everything and re-source the entire UPF file.
For ECO’s or modifications later on in the flow, mistakes
happen and having the ability to change modify (via get /
delete commands) becomes advantageous.
• To aid convergence with other ‘low power’
formats
• It is part of out ‘extent’ document to aid in convergence so
•
by providing get* and ‘atomic’ operations to access logical
information will greatly aid in this convergence.
After the acceptance of ‘proposal 6’ for XYZ access to
logical information would also be beneficial.
April 13, 2015 -- 3
Get commands for P1801
• There are two proposals for the implementation of a get command.
• Before we cover the two proposals, it should be made clear that the
proposals have further been subdivided
•
•
Get commands for UPF objects
•
The definition of a UPF object is
• A retention strategy, isolation strategy, isolation strategy, power domain, domain
colorization of a net etc..
Atomic get commands for logical ‘database’ access / queries
•
Thus providing access to logical information, such as nets, pins, design elements
etc.
• The get command should be able to
•
•
•
Return information formatted as a tcl list
Be able to be write the information to a file
Be flexible so that we can
•
•
•
April 13, 2015 -- 4
List defined UPF objects
Easily query the entire contents of a UPF object
Have the ability to query individual options.
Proposal 1
• Have a generic get command i.e. get_upf_object
that could be used to query UPF objects.
• This got shot down very quickly internally. The main
negatives were
• This command will be too complex to handle all the options of the
•
•
April 13, 2015 -- 5
various strategies.
It ‘feels’ more intuitive to have a get command for a corresponding
set command.
The command would for ever be changing whenever a new set
command was added.
Proposal 2
• Have a corresponding get_* command for each set_*
command where appropriate.
• See overleaf for a matrix of commands that are appropriate for s
get/delete command
• The benefits of this approach
• It’s clear what the command is going to do
• The options can be easily tailored to the type of data that is being
•
retrieved
As new commands are added it is easy to add the corresponding get
command where appropriate
• The down sides
• Sorry Joe!
• A lot more commands.
April 13, 2015 -- 6
Proposal 2
• NB, all get commands will return a tcl list, I’ve used a newline just
•
for ease of reading.
The current scope will be used as the anchor point for the ‘query’
• Using the interleaver example
upf_cmd> set_scope /
upf_cmd> get_power_domain
PD_interleaver
PD_rx
PD_tx
upf_cmd> get_power_domain –hier
PD_interleaver
PD_rx
PD_tx
in2wire/PD_rdyacpt
out2wire/PD_rdyacpt
April 13, 2015 -- 7
Proposal 2
•
Move information can be obtained by specifying the domain
•
•
If no options are specified the entire string required to recreate the domain is returned.
A –file option could also be easily added to write this information to a file if desired.
upf_cmd> get_power_domain PD_rx
create_power_domain PD_rx -elements {in2wire pkt_counter}
•
If specific information is required then options can be specified.
•
•
ONLY one option is permitted at a time.
-hier NOT permitted.
upf_cmd> get_power_domain PD_tx -elements
fifo
out2wire
•
How to handle –include_scope?
upf_cmd> get_power_domain PD_Interleaver –elements
.
April 13, 2015 -- 8
1877 / 1889 - Precedence And Regular Expressions
• Recap
• These mantis issues talk about precedence rules, regular expression
support and the ability to specify an exclude list.
• I agree a form of wildcarding is required to provide a
practical method of specifying a group of elements.
• There have been discussions on whether the wildcards
should be string expansions or regular expressions.
• Why not provide both?
April 13, 2015 -- 9
1877 / 1889 - Precedence And Regular Expressions
• Use simple string matching for the all commands, and
where more powerful regexp is required the upf_find
command can be used i.e.
• For example if O is an 8 bit output bus [0:7]
• -elements {a/b/O[*]}
•
This would select all eight bits
•
This would select 6 bits (0- 6)
• -elements {[upf_find a/b O[0-5] –type port –regexp]}
• NB each tool provider should verify what is acceptable
where [] are concerned, so that consistent examples can
be provided.
• For example Magma’s TCL parser would recognize the above as a
bus expansion, and would not try to execute a command called *. It
might need to be re-written as:
• -elements
April 13, 2015 -- 10
{a/b/O\[*\]}
1877 / 1889 - Precedence And Regular Expressions
•
It as been raised a number of times that there is a desire for the
specification of an exclusion list.
•
As long as this is clearly specified this would also prove a powerful filtering
mechanism.
•
If we take the previous example of the 8 bit output bus, and we want to
insert a levelshifter on all output bits except bit 7, we could:
• set_level_shifter
{O[7]}
•
Alternatively
• set_level_shifter
• set_level_shifter
•
•
myshift –domain PD0 –elements {O[*]} –exclude
myshift –domain PD0 –elements {O[*]}
myshift –domain PD0 –exclude {O[7]}
The exclude effectively acts like a clear
If an object is specified in an exclude list then there is no way in THAT
strategy of specifying any other behavior than the ‘default’
April 13, 2015 -- 11
1877 / 1889 - Precedence And Regular Expressions
•
The following would NOT be allowed
• set_level_shifter
•
•
•
self
set_level_shifter myshift –domain PD0 –exclude {O[7]}
set_level_shifter myshift –domain PD0 –elements {O[7]} –location
parent
The following would be allowed
• set_level_shifter
•
•
•
myshift –domain PD0 –elements {O[*]} –location
myshift1 –domain PD0 –elements {O[*]} –
location self
set_level_shifter myshift1 –domain PD0 –exclude {O[7]}
set_level_shifter myshift2 –domain PD0 –elements {O[7]} –
location parent
While I am on the set_level_shifter command
•
•
Does anyone have any objection in changing –applies_to to –default <output,
input, both, none> both
I.e. if you have not explicity specified a –no_shift for an element then the default applies,
this just seems clearer than the current definition.
April 13, 2015 -- 12
1877 / 1889 - Precedence And Regular Expressions Name
Qualification
•
A lot of commands have the potential for ambiguity i.e. the –elements
option on set_retention_control.
•
•
How do we distinguish a named process versus, a cell versus a net?
What is the precedence order?
•
There have been proposals to expand the number of additional options to
each commands, so each ‘object’ type is specified separately, but there
were also complaints against this to.
•
Name qualification is a powerful unambiguous method by which we can
simply the number of options and allow for combined lists of different
objects.
•
Name qualification could be of the form
•
•
scope/[qualifier]:object
For example, all of the following are valid and unambiguous
•
•
•
•
•
April 13, 2015 -- 13
/in2wire/domain:pdyacpt
/in2wire/net:pdyacpt
/in2wire/cell:pdyacpt
/in2wire/process:pdyacpt
/in2wire/pst:pdyacpt
1877 / 1889 - Precedence And Regular Expressions Name
Qualification
• Name qualification could be used for all objects.
• If an object is not specified with a name
qualification then the specified precedence rules
would apply.
• Pin
• Net
• Design element
• Process
• Strategy
April 13, 2015 -- 14
upf_find
•
•
•
EDA tools of course provide the ability to search the logical and physical
design.
UPF to some extent also needs this capability to provide portability
between tools.
The upf_find command could be used to replace the –all_inputs /
all_outputs options of levelshifter and isolation cell commands.
upf_find <domain | scope> search_string
-type <net|port|pin|design_element>
-direction <in|out>
-hier
•
Examples of use
• upf_find
PD_rx * –type pin –direction in
• Will return all the input pins on the PD_rx domain boundary
• upf_find
/fifo * -type design_element
• upf_find
/fifo PMY_.* -type design_element -regxp
• Would return all the design elements in /fifo
• Would return all the design elements in /fifo that start with PMY_
April 13, 2015 -- 15
upf_find
• Assume the logical and physical hierarchy is
identical in the example below.
• Domain boundary
• The inputs of the Orange domain are any signal that goes
from
• A->B
• C->B
A
B
D
April 13, 2015 -- 16
C
UPF Delete
• To help facilitate incrementally and the ‘interactive’ use
of UPF the ability to delete the following UPF objects
would be desirable
• Domains
• Strategies
• Net colorization
• PST’s
• Power switches
• This could also be achieved through two approaches
• Individual commands
• delete_domain,
delete_retention_strategy etc..
• A single ‘powerful’ delete command
• delete_upf_object <object>
• upf_command> delete_upf_object PD_rf
• This appraoch would require name qualification to be accepted by the
comittee.
April 13, 2015 -- 17
UPF Delete
• The upf delete command could also be one
possible solution to Steve’s domain_merge
problem on the interlever.
April 13, 2015 -- 18
Levelshifter / Iso Enhancements
• LS/ISO commands are currently pin based.
• A path based approach would provide added
flexibility.
ls –from PD1
ls –from PD1 –to PD3
PD1
April 13, 2015 -- 19
PD2
PD3
PD1
PD2
PD3
Levelshifter / Iso Enhancements
• However the current specification we have in
P1801 would still allow correct specification, it
just takes more lines.
• Additional of physical information makes this even more
complicated.
• Maybe this is best left in the implementation tool
domain as value add?
April 13, 2015 -- 20
Levelshifter / Iso Enhancements
• We do lack clear semantics on the supporting combined
•
levelshifter and isolation cells (so called combo cells)
One possible solution would to allow specification
through the map commands.
• If an output of a domain had both an lS and ISO strategy and the map
command for both specified a combo cell.
• Another would be to provide a combined LS and ISO
•
•
command, with the appropriate set/map commands.
Another would be to add a –combined option to the set
LS/ISO commands, that if specified for either command
would instruct the implementation tool to use a
combined cell.
In some cases this will not be possible (i.e. different
locations specified) so could be seen as an optimization
constraint…
April 13, 2015 -- 21
Switch Cells
• Switch cells are currently created in the scope.
• In the physical world this will not always be
guaranteed, and will quite like be a rare
occurrence.
• The scope was chosen so that there was an unambiguous
•
•
location.
We need to look at a mechanism to also allow the user to
specify the desired logical location.
Also need to decide on how we want to represent the
logical connectivity between disjoint switched voltage
islands of the same domain.
April 13, 2015 -- 22
Switch Cell scope/extent
LOGICAL
vdd_
pad
PD_Interleaver
rx_iso
_en
PHYSICAL
vss_
pad
vdd_
pad
PD_Interleaver
rx_iso
_en
rx_iso
_en
in2wire
pktcntr
PD_rx
in2wire
pktcntr
rx_
sleep
rx_
sleep
tx_iso
_en
PD_tx
tx_iso
_en
April 13, 2015 -- 23
tx_iso
_en
fifo
out2wire
tx_
sleep
vss_
pad
fifo
out2wire
ram
tx_
sleep
ram