P1801 Proposal Discussion

1
P1801 Proposal Discussion
2
Wireless network access at Magma

• SSID (not broadcast) lava64 bit key or 10 digit
  Hex key 00000fffff

3
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 ECOs 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.

4
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
• List defined UPF objects
• Easily query the entire contents of a UPF object
• Have the ability to query individual options.

5
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 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.

6
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
• Its 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.

7
Proposal 2

• NB, all get commands will return a tcl list, Ive
  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_cmdgt set_scope /
• upf_cmdgt get_power_domain
• PD_interleaver
• PD_rx
• PD_tx
• upf_cmdgt get_power_domain hier
• PD_interleaver
• PD_rx
• PD_tx
• in2wire/PD_rdyacpt
• out2wire/PD_rdyacpt

8
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_cmdgt 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_cmdgt get_power_domain PD_tx -elements
• fifo
• out2wire
• How to handle include_scope?
• upf_cmdgt get_power_domain PD_Interleaver
  elements
• .

9
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?

10
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 07
• -elements a/b/O
• This would select all eight bits
• -elements upf_find a/b O0-5 type port
  regexp
• This would select 6 bits (0- 6)
• NB each tool provider should verify what is
  acceptable where are concerned, so that
  consistent examples can be provided.
• For example Magmas 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 a/b/O\\

11
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 myshift domain PD0 elements
  O exclude O7
• Alternatively
• set_level_shifter myshift domain PD0 elements
  O
• set_level_shifter myshift domain PD0 exclude
  O7
• 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

12
1877 / 1889 - Precedence And Regular Expressions

• The following would NOT be allowed
• set_level_shifter myshift domain PD0 elements
  O location self
• set_level_shifter myshift domain PD0 exclude
  O7
• set_level_shifter myshift domain PD0 elements
  O7 location parent
• The following would be allowed
• set_level_shifter myshift1 domain PD0 elements
  O location self
• set_level_shifter myshift1 domain PD0 exclude
  O7
• set_level_shifter myshift2 domain PD0 elements
  O7 location parent
• While I am on the set_level_shifter command
• Does anyone have any objection in changing
  applies_to to default ltoutput, input, both,
  nonegt 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.

13
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/qualifierobject
• For example, all of the following are valid and
  unambiguous
• /in2wire/domainpdyacpt
• /in2wire/netpdyacpt
• /in2wire/cellpdyacpt
• /in2wire/processpdyacpt
• /in2wire/pstpdyacpt

14
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

15
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 ltdomain scopegt search_string
• -type ltnetportpindesign_elementgt
• -direction ltinoutgt
• -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
• Would return all the design elements in /fifo
• upf_find /fifo PMY_. -type design_element
  -regxp
• Would return all the design elements in /fifo
  that start with PMY_

16
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-gtB
• C-gtB

A

B
C
D
17
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
• PSTs
• 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 ltobjectgt
• upf_commandgt delete_upf_object PD_rf
• This appraoch would require name qualification to
  be accepted by the comittee.

18
UPF Delete

• The upf delete command could also be one
  possible solution to Steves domain_merge problem
  on the interlever.

19
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
PD2
PD2
PD1
PD1
PD3
PD3
20
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?

21
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

22
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.

23
Switch Cell scope/extent
LOGICAL
PHYSICAL
PD_rx
in2wire
pktcntr
in2wire
pktcntr
tx_iso_en
PD_tx
fifo
tx_iso_en
fifo
tx_iso_en
out2wire
out2wire
ram
ram