Define a circuit description language about pycircuit HOT 27 CLOSED

What do you mean by this? Do you mean the TR['L1.1'] type pin definition and selection?

No, L1.1 is a pin. Assigning to L1 is assigning to a function. Since an inductor is reversible, we don't care if it's assigned to L1.1 or L1.2, the placer can optimize the wirelength by exchanging them. With simple components it doesn't matter much, since a resistor for example can be rotated and it will give the same result.

When connecting MCU's where a pin can be used as GPIO or UART_TX or PWM or SPI_SCK things get more interesting. In addition to selecting a pin that has a UART_TX, when assigning [UART_TX, UART_RX] = n1, n2 we need an additional constraint, that UART_TX and UART_RX belong to the same UART.

For an FPGA at some point I'd like to some integration with the yosys toolchain, like being able to import a generate a pin constraints file for arachnepnr based on the placement.

from pycircuit.

Had to checkout lark-parser 358d54adad79a34472f524dd0cfe3966a5877936 from Okt 15., that fixed things...

from pycircuit.

Closing this for now. I find that defining schematics isn't a pain in the ass anymore. Integration with electrogrammar is tracked in #10 and should make it even more ergonomic. New features are tracked here: #16. Further improvement suggestions are welcome.

from pycircuit.

Have you seen PHDL? I am giving a presentation at 34C3 at the end of the month on HDLs for PCB design so if you know of anymore examples besides PHDL, SKiDL and your project I would be very interested in any links.

I will also extend the offer to integrate the Python port of Electro Grammar (once it's done) as I did with SKiDL. It would be cool to think about the DSL with that sort of interaction in mind.

from pycircuit.

Here is another dsl example for pcb's

I'll probably release pycircuit 2.0 by then, with a viewer (mostly done), better graphviz rendering (mostly done) and maybe monosat routing (todo).

from pycircuit.

Thanks for the link. Any comment on including descriptions in the language that Electro Grammar could parse?

from pycircuit.

Using electro grammar would be cool to parse the VALUE.

I looked at phdl again and think it's neat. I'll base the language design on it. One feature I'd like in the language is to make pin assignments flexible ex. connect to a GPIO pin not the GPIO23 pin.

from pycircuit.

I tried PHDL a little just now. Some things I noticed:

• Syntax seems really clean actually
• I would prefer not having to add semicolons
• I don't think library definitions and values should be treated like strings, the compiler should understand what these refer to and give errors when there is a missing library or something else wrong

For electro-grammar in the context of an HDL I had been thinking about what if instead of

device resistor {
    attr REFPREFIX = "R";
    attr FOOTPRINT = "R0603";
    attr LIBRARY = "rcl";
    attr VALUE = "1k";
}

We had something like:

device resistor = descr "1k 0603"

But maybe it would be best to leave this sort of parsing to tooling on top of the language rather than the language itself.

from pycircuit.

The question is how is the AST currently different than pycircuit. The other thing is writing a parser for the custom syntax, but that is independent from the AST elements. One thing is that a circuit (design) and a subcircuit (subdesign) are the same thing in pycircuit. That has the advantage that you don't need to think about if it's a reusable component or not. As long as you connect VCC and GND from two circuits together it'll work.

Then there is a device that is called footprint in pycircuit. That's because it's an abstraction level lower, you are assigning to pads directly.

Also ports and nets in phdl are both simply nets in pycircuit. This is one thing that we might want to change.

An inst is a Node and a subinst is a Sub in pycircuit. Inside a inst there are assignments of nets or ports to pins. So that is like a

with Node('C1', 'C') as c:
    # c is a Ref('C1')
    c['~'] += Net('VCC')
    c['~'] += Net('GND')

I think that pycircuit is currently a little more verbose than phdl, but I think it still can be improved without having to write a parser. The design of the ast then drives the syntax of the language, so that maybe the above example is translated from:

net vcc, gnd
inst c1 of c {
    ~ = vcc
    ~ = gnd
}

from pycircuit.

What do you think about the joule thief example written like this? I can make this work...

@circuit('TOP')
def top():
    vcc, gnd, n1, n2, n3 = nets('VCC GND n1 n2 n3')

    with Inst('TR1', 'Transformer_1P_1S') as tr1:
        tr1['L1', 'L1'] = n1, n2
        tr1['L2', 'L2'] = vcc, n3

    Inst('BAT1', 'BAT')['+', '-'] = vcc, gnd
    Inst('R1', 'R')['~', '~'] = vcc, n1
    Inst('Q1', 'Q')['B', 'C', 'E'] = n2, n3, gnd
    Inst('LED1', 'D')['A', 'C'] = n3, gnd

from pycircuit.

I think electrogrammar should be part of the language to allow syntax highlighting.

I'm ok with renaming Device to Component and Footprint to Device. Any thought on keeping Node and Sub or renaming it to Inst and SubInst?

I think we can leave the package definition for now, Component definitions will change slightly to make things simpler.

Any thoughts on the process for going from a Component netlist to a Device? For now we can add something like you suggested:

with Node('R1', 'R') as r1:
   # add electro grammar like a C style comment
   # for IC's this would simply be the package name
   # to assign a footprint
    r1 // "0603 10K 1/2W"

Some Devices can be generated automatically based on the Component and Package. Else lookup Device for (Component, Package).

Any status update on electrogrammar for python?

from pycircuit.

I think you are right, it's worth thinking about how this could be improved within Python first of all. Worth revisiting later but there is so much power that comes from embedding within a general purpose language.

Your improvement ideas are interesting, I am not quite sure what the with statement solves though. After making a proposal for SKiDL for further operator overloading I have liked it less and less the more I have thought about it. I would like to see how we could define a DSL without any overloading.

I think I also mentioned that I find the implicit circuit quite confusing. Your ideas inspired me to start to sketch out something that I would like to see. This is on a higher level, what I'd like to get as a user. The main aims are:

• Defining circuits as fast as possible
• Allow for design re-use

Please be frank about what you like and don't like about this. It may be better for me to make my own implementation rather than try and hijack your plans for pycircuit.

#example.py
from pycircuit import Circuit, Component, Pin, Resistor, Capacitor, Net, footprints

# Devices can be instantiated as before, I think an mpn field would make sense
u1 = Device(mpn='Atmega328P', pins=[Pin()] * 32)

# there are some convenience classes for common components
# these resistors are the same
r1 = Resistor('1k 0603')
r2 = Resistor(value='1k', footprint=footprints._0603)

# components can have footprints assigned or not
c1 = Capacitor('1uF') #no footprint yet

# assign a footprint
c1.footprint = footprints._0805

vcc = Net()
gnd = Net()
vout = Net()

# the circuit is explicitly instantiated
circuit = Circuit()

# and connections are explicitly made with the connect method, pins are picked
# automatically going from lower to higher picking the first free one
circuit.connect(r1, r2)
circuit.connect(vcc, r1)
circuit.connect(r2, gnd)

# connect_through works like the `>>` overloading proposal I made for SKiDL,
# this is the same as what is above
circuit.connect_through(vcc, r1, r2, gnd)

# of course you can specify pins as well
circuit.connect(r1[0], vout)

# some pins could be exported as properties with names
# we can connect as many things as we like using connect
circuit.connect(u1.vcc, u2.vcc, vcc)
circuit.connect(u1.gnd, u2.gnd, gnd)

# if we want to connect things in parallel we use connect_parallel ;)
circuit.connect_parallel(u1[0:4], u2[4:8])

#different_file.py
from pycircuit import *
import example

gnd = Net()
vcc = Net()

circuit = Circuit()

circuit.connect(example.vcc, vcc)
circuit.connect(example.gnd, gnd)

The slight problem with electro-grammar by the way is that it's kind of a natural language parser rather than a programming language parser. It may be better to restrict and formalize a subset of it rather than use it wholesale.

There hasn't been much development on it lately but you can check out the dev branch in the python directory where I played around with "easy_skidl".

from pycircuit.

So the process in pycircuit is the following (now with renamed stuff as in refactoring):

This is what we write in python. functions or ports can be assigned to nets or ports

1. [(component fun | circuit port) <> (net | port)] (done)

The first compilation step removes all ports and subinsts
2. [component fun <> net] (done)

The next compilation step assigns pins to functions
3. [component pin <> net] (done)
Here we can ERC check and export to graphviz or netlistsvg

After that devices need to be assigned to components,
this is where electrogrammar fits in
4. [device pin <> net] (wip)
Here we can export the BOM

Then we map to packages/pads
5. [package pad <> net] (done)
Here we can export to svg or kicad or a custom place format.

In this custom "place" format undoes the pin assignment done in step 2 where the solution isn't the only possible solution, and turns it into a pad assignment problem. This means the global placer can select the pins closest in it's placement.

6. Use our dumb Z3 placer and extend it to perform pad assignment
7. Use monosat for detail routing
8. Postprocess in kicad and export gerbers

from pycircuit.

Defining circuits as fast as possible
Allow for design re-use

These goals are what I have in mind too. I'm not sure if the 'assigning to functions instead of pins' is going to work out. The idea is that on a fpga or in a mcu there are selection options that should be made based on geometry, and I think altium does stuff like that (never used it).

I tried excessive operator overloading in a previous experiment which exported to spice models, but a circuit written for spice doesn't have enough information for 'manufacturing'. I've rewritten the DSL a couple of times, trying to find the right layer of abstraction. The next version is going to be very phdl like.

Looking forward to seeing your experiments if you choose to do so. Maybe we can share some parts that are useful to both projects.

from pycircuit.

assigning to functions instead of pins

What do you mean by this? Do you mean the TR['L1.1'] type pin definition and selection?

Anyway, yeah, I'll keep thinking about this and let you know when I get any further. Really I am just trying to find something I would actually use instead of a schematic editor.

from pycircuit.

Mmmh, tried electro grammar and it kind of doesn't work, I'm not to keen on the usage of js2py either =P

>>> from electrogrammar.grammar import *
>>> from electrogrammar.grammar import parse
>>> from electrogrammar.grammar import parse, matchCPL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'matchCPL'
>>> from electrogrammar.grammar import *
>>> matchCPL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'matchCPL' is not defined
>>> parse
<function parse at 0x7f6fb1310f28>
>>> parse('10k 0806')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dvc/repos/electro-grammar/python/electrogrammar/grammar.py", line 695, in parse
    return TransformNearley().transform(parser.parse(text))
  File "/home/dvc/repos/electro-grammar/python/src/lark-parser/lark/lark.py", line 189, in parse
    return self.parser.parse(text)
  File "/home/dvc/repos/electro-grammar/python/src/lark-parser/lark/parser_frontends.py", line 143, in parse
    return self.parser.parse(text)
  File "/home/dvc/repos/electro-grammar/python/src/lark-parser/lark/parsers/xearley.py", line 147, in parse
    raise ParseError('Unexpected end of input! Expecting a terminal of: %s' % expected_tokens)
lark.common.ParseError: Unexpected end of input! Expecting a terminal of: ['ANONRE_74', '__DOT', 'ANONRE_81', '__PERCENT', 'ANONRE_0', 'ANONRE_2', '__M36', 'ANONRE_2', 'ANONRE_2', '__G64', '__P54', 'ANONRE_1', '__N38', '__K31', '__N37', '__K32', 'ANONRE_2', '__U20', '__M35', '__F59', '__G65', '__F58', '__P55', 'ANONRE_2', 'ANONRE_81']
>>> 

from pycircuit.

Yeah, Python port is definitely not done. Using Js2Py is a bit strange but makes for a quick route to port the grammar to Python.

Using parse on valid input should work already as well:

>>> parse('10k 0805')
{'resistance': 10000, 'size': '0805', 'type': 'resistor'}

from pycircuit.

Using parse on valid input should work already as well

Ups... I'm getting the error with valid input too, I get the same error no matter what I write.

I'm really interested in using it in pycircuit, but I want to work on the place and route first. I'll have a new prototype of the frontend probably tomorrow.

from pycircuit.

Are you importing python/electro_grammar.py as it stands with version b274ea09fb? Don't run the python/build script, I think I was messing around and may have broken something in the actual grammar.

from pycircuit.

Also, I almost forgot to mention: for the time being I will be licensing electro-grammar as AGPLv3. I am hoping to release as MIT or similar later but it depends on a contract. Hope that's not a problem.

from pycircuit.

I think it's much better now... Feedback welcome.

from pycircuit.

So current thinking is that we can extend electrogrammar to all components, so specifying an Inst('10K 0805') should be enough to find a component. Depends on #15 #14 #10 to better understand what the extended electrogrammar should look like. It should be able to express optimizer, simulation and bom information.

from pycircuit.

Depends on #15 #14 #10 to better understand what the extended electrogrammar should look like. It should be able to express optimizer, simulation and bom information.

Can you explain what you mean by this? I have started documenting what I want out of the next electro-grammar. You should have access to that branch, maybe you can edit in the details there?

from pycircuit.

from pycircuit.

from pycircuit.

Does electrogrammar find nearest matches? So if I enter 2000.678 ohms will it suggest a 2.2k resistor?

No, the only thing of the sort it does currently is it treats tolerances and voltage ratings as a minimum when matching against the CPL parts. Matching against different En series (E6, E12 etc) would make sense. Looks like something exists for JS already but all it really needs is some lookup-tables.

from pycircuit.

Maybe we can think of CPL matching as a function that returns a value for how well it matches, and returns the top result. So if someone is looking for a 15MHz OSC it might suggest a 16MHz one with a number 15/16 representing how well it matched.

from pycircuit.