KiCAD VLSI design
Hi folks So we need to approach the folks from CERN who design the KiCAD tool. What I would like to ask them is, whether they could take the code base of their PCB editor and hack it a bit, so that it can place and route VLSI designs as well. As far as I know KiCAD, it's actually already possible, by constraining the angles of the wires to 90 degrees and adding a grid lock for placement of components. What is missing though, is the ability to load gds libraries and to export it into GDS/Magic/DEF. It would be cool to have KiCAD for drawing analog circuits and then generating a VLSI layout from it, where you can drag and drop your components accordingly and connect it like in a PCB. Cheers David
Hello All, I would note that if we want to use KICAD for analog design, then another feature would be needed: the possiblity of "parametric cells". For example, if we need an AND gate, we can simply take it from the library. But if we need a transistor with a 123/8u size and 15 fingers for some reason, that cannot be solved using static library cells, as pre-designing all possible combinations is not realistic. Instead, we need an approach in which the library element is not a layout, but a script that takes parameters and generates the layout in real-time. Upon instantiation, the generated layout is included into the design as a "normal" subcell and travels with the design (that is, it is embedded into the design and not just referenced from the lib). But when the parameters are changed, the script is re-run and the in-design instance is updated. Regards, Ferenc On Sun, Jan 20, 2019 at 3:42 PM David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
Hi folks So we need to approach the folks from CERN who design the KiCAD tool. What I would like to ask them is, whether they could take the code base of their PCB editor and hack it a bit, so that it can place and route VLSI designs as well. As far as I know KiCAD, it's actually already possible, by constraining the angles of the wires to 90 degrees and adding a grid lock for placement of components. What is missing though, is the ability to load gds libraries and to export it into GDS/Magic/DEF. It would be cool to have KiCAD for drawing analog circuits and then generating a VLSI layout from it, where you can drag and drop your components accordingly and connect it like in a PCB.
Cheers David_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Reading this, I start dreaming of common centroid differential pair and current mirror pcells with optional dummy and guard ring structures. Some of the better commercial PDKs in Cadence get close to that. tatzelbrumm On Sun, Jan 20, 2019 at 4:09 PM Éger Ferenc <eegerferenc@gmail.com> wrote:
Hello All,
I would note that if we want to use KICAD for analog design, then another feature would be needed: the possiblity of "parametric cells". For example, if we need an AND gate, we can simply take it from the library. But if we need a transistor with a 123/8u size and 15 fingers for some reason, that cannot be solved using static library cells, as pre-designing all possible combinations is not realistic. Instead, we need an approach in which the library element is not a layout, but a script that takes parameters and generates the layout in real-time. Upon instantiation, the generated layout is included into the design as a "normal" subcell and travels with the design (that is, it is embedded into the design and not just referenced from the lib). But when the parameters are changed, the script is re-run and the in-design instance is updated.
Regards, Ferenc
On Sun, Jan 20, 2019 at 3:42 PM David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:
Hi folks So we need to approach the folks from CERN who design the KiCAD tool. What I would like to ask them is, whether they could take the code base of their PCB editor and hack it a bit, so that it can place and route VLSI designs as well. As far as I know KiCAD, it's actually already possible, by constraining the angles of the wires to 90 degrees and adding a grid lock for placement of components. What is missing though, is the ability to load gds libraries and to export it into GDS/Magic/DEF. It would be cool to have KiCAD for drawing analog circuits and then generating a VLSI layout from it, where you can drag and drop your components accordingly and connect it like in a PCB.
Cheers David_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Also, again, the ability to recursively include PCB (or library parts) within PCBs aka Cells. I did not reply earlier, the reason for this is firstly a full cell may have already been done (manual or auto routing) saving time and CPU , secondly, certain layouts may simply be far too complex or regular and may need to be generated either programmatically or by having blocks that the autorouter is permitted to place and route but not alter, thus saving time and also making the design easier to verify. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
It's more for the purpose of designing analog IP cores which require manual "finesse" when being placed and routed. The actual place and route of the SoCs and MCUs will of course be done automatically using the nice place&route tool from Andreas. -David
Also, again, the ability to recursively include PCB (or library parts) within PCBs aka Cells.
I did not reply earlier, the reason for this is firstly a full cell may have already been done (manual or auto routing) saving time and CPU , secondly, certain layouts may simply be far too complex or regular and may need to be generated either programmatically or by having blocks that the autorouter is permitted to place and route but not alter, thus saving time and also making the design easier to verify.
On Sunday, January 20, 2019, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:
It's more for the purpose of designing analog IP cores which require manual "finesse" when being placed and routed. The actual place and route of the SoCs and MCUs will of course be done automatically using the nice place&route tool from Andreas.
There are a number of NxN and NxM Dependency Matrices that I would prefer to be laid out parametrically or manually, as separate library cells, FOLLOWED by using a nice autorouter tool. The amount of CPU time taken by an autorouter to identify something that is *already known* by a human to be regularly structured is going to be a waste of time and power, and it is unlikely to be able to spot that it may be laid out regularly in the first place. I have seen the results created by autorouters. They are a dog's dinner mess, and the algorithms an insane order of complexity. Giving autorouters limited rein and doing a complex design in a hierarchical fashion will be critical to getting a sane layout. You may be thinking of a different couple of orders of magnitude less than the task I have in mind, here David. I am designing a quad core 800mhz design with L1/L2 cache, multi issue out of order vector processing, virtual memory and 16, 32 and 64 bit IEEE754 FP units (we may also add FP8, have to see). Performance target is 4 32bit FP FMACs per core per cycle, so a total of at least 16 FMAC ALUs, potentially double that, to minimise data routing (a trick I learned on comp.arch: ALUs are cheap, data routing horribly expensive). I am NOT going to throw such a massively complex design at an autorouter and hope for the best. It would be flat out insane to consider. The hybrid hierarchical approach would allow the autorouter to lay out an FPU FMAC cell, that, on successful completion, can be incorporated into a larger ALU cell (per core), that in turn may be incorporated into a CPU Cell, that in turn may be incorporated into an SoC final layout. Each time *using* the autorouter however NOT repeat NOT to allow it to REDO cells that have already been done: ONLY allow it to place and route them. Restricting and simplifying the scope of work needed to be done by SEVERAL orders of magnitude. In this way I stand a chance of having a complete design in a sane amount of time. -David
Also, again, the ability to recursively include PCB (or library parts) within PCBs aka Cells.
I did not reply earlier, the reason for this is firstly a full cell may have already been done (manual or auto routing) saving time and CPU , secondly, certain layouts may simply be far too complex or regular and may need to be generated either programmatically or by having blocks that the autorouter is permitted to place and route but not alter, thus saving time and also making the design easier to verify.
-- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Catching up with this thread ... On Sun, Jan 20, 2019 at 5:45 PM Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
[...]
You may be thinking of a different couple of orders of magnitude less than the task I have in mind, here David. I am designing a quad core 800mhz design with L1/L2 cache, multi issue out of order vector processing, virtual memory and 16, 32 and 64 bit IEEE754 FP units (we may also add FP8, have to see).
Performance target is 4 32bit FP FMACs per core per cycle, so a total of at least 16 FMAC ALUs, potentially double that, to minimise data routing (a trick I learned on comp.arch: ALUs are cheap, data routing horribly expensive).
I am NOT going to throw such a massively complex design at an autorouter and hope for the best. It would be flat out insane to consider.
The hybrid hierarchical approach would allow the autorouter to lay out an FPU FMAC cell, that, on successful completion, can be incorporated into a larger ALU cell (per core), that in turn may be incorporated into a CPU Cell, that in turn may be incorporated into an SoC final layout.
Each time *using* the autorouter however NOT repeat NOT to allow it to REDO cells that have already been done: ONLY allow it to place and route them.
Restricting and simplifying the scope of work needed to be done by SEVERAL orders of magnitude.
In this way I stand a chance of having a complete design in a sane amount of time.
ok, so what is the transistor feature size, and the required reliability and repeatability of transistor parameters in the CMOS process that supports a design of such scale? Followup question to the foundry alchemists: Do you think you stand a chance to implement a process with such small feature sizes and such tight specifications in a sane amount of time? Irrespective of that, it always makes sense to select or write design tools that don't run into some "640k ought to be enough for anybody" barrier. - tatzelbrumm
On Friday, February 1, 2019, Christoph Maier <christoph.maier@ieee.org> wrote:
Catching up with this thread ...
On Sun, Jan 20, 2019 at 5:45 PM Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
[...]
You may be thinking of a different couple of orders of magnitude less
than the task I have in mind, here David. I am designing a quad core 800mhz design with L1/L2 cache, multi issue out of order vector processing, virtual memory and 16, 32 and 64 bit IEEE754 FP units (we may also add FP8, have to see).
ok, so what is the transistor feature size, and the required reliability and repeatability of transistor parameters in the CMOS process that supports a design of such scale?
Don't know yet. Still a long way off. However it would not be a surprise to find that one core took up the same area as a 4 core RISC design, just because of the fact that it does 4 issue FP ops. Monster, basically. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Hi Auto generating parametric cells isn't actually *that* difficult. One could actually imagine scripting a generator in QML or so. But it would be interesting to know whether the KiCAD folks would be interested at all to cooperate on this. Cheers David
Hello All,
I would note that if we want to use KICAD for analog design, then another feature would be needed: the possiblity of "parametric cells". For example, if we need an AND gate, we can simply take it from the library. But if we need a transistor with a 123/8u size and 15 fingers for some reason, that cannot be solved using static library cells, as pre-designing all possible combinations is not realistic. Instead, we need an approach in which the library element is not a layout, but a script that takes parameters and generates the layout in real-time. Upon instantiation, the generated layout is included into the design as a "normal" subcell and travels with the design (that is, it is embedded into the design and not just referenced from the lib). But when the parameters are changed, the script is re-run and the in-design instance is updated.
Regards, Ferenc
On Sun, Jan 20, 2019 at 3:42 PM David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:
Hi folks So we need to approach the folks from CERN who design the KiCAD tool. What I would like to ask them is, whether they could take the code base of their PCB editor and hack it a bit, so that it can place and route VLSI designs as well. As far as I know KiCAD, it's actually already possible, by constraining the angles of the wires to 90 degrees and adding a grid lock for placement of components.
The design constraints one needs to pay attention to when routing PCBs and ICs are VERY different, though.
What is missing though, is the ability to load gds libraries and to export it into GDS/Magic/DEF. It would be cool to have KiCAD for drawing analog circuits and then generating a VLSI layout from it, where you can drag and drop your components accordingly and connect it like in a PCB.
It would be cool to have that in Cadence Virtuoso, actually. Haven't really seen that (schematic driven analog layout) at a useful level of functionality in the academic versions I got to play with so far. And what Ferenc says in his response to this about parametric cells. tatzelbrumm
Cheers David_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Has the Electric integrated circuit CAD software been considered and rejected for some reason? https://www.staticfreesoft.com/ I have kept track of it since it became open source, but have only played a bit with it and not used it for any real project yet. I have a bit more experience with Magic. While I am a big fan of KiCAD, it seems to me that starting out with something originally created for integrated circuits would be a better choice. In fact, Electric also has resources allowing it to be used for PCBs but it would be awkward for that compared to KiCAD. I can see that using a single tool for everything would be attractive, however. I am just not sure it is practical. -- Jecel Assumpcao Jr
On 1/20/19 9:16 PM, Jecel Assumpcao Jr. wrote:
Has the Electric integrated circuit CAD software been considered and rejected for some reason?
Yes. We evaluate a lot of tools during our 1st Hackathon in May last year. Unfortunately no tool matches our need. In my humble opinion it was a bad move from Electric to switch to Java. Java catches more programmer on the good side but also has do deal with a huge memory footprint. I guess, that our clients playing with smaller laptops than with big iron. So memory is an issue as long as dealing with VLSI (routing, placement, and all the other stuff) needs a lot of them. Both, Java and the design which needs memory also probably does not fit into laptops.
While I am a big fan of KiCAD, it seems to me that starting out with something originally created for integrated circuits would be a better choice. In fact, Electric also has resources allowing it to be used for PCBs but it would be awkward for that compared to KiCAD. I can see that using a single tool for everything would be attractive, however. I am just not sure it is practical.
We would get more VLSI designer, if we are using a familiar GUI for most of them. Something like KiCad which has a great momentum, or Lepton EDA (a active gEDA fork) could be help. Our first attempt was to clone QFlow (http://opencircuitdesign.com/qflow) - which also needs a lot of work. The effort to doing all the stuff alone is to big for us - our small team is already occupied.
Electric: "Download the latest "Java" version" It was translated to Java, this says it all. The tool is not under much development. And the old "ugly" C-Version is still there. Maybe, one could take some of the C code and build it into KICAD. It would be an advantage to design in 3D view like a brick that gets structured. A PCB design is just layers with the approach how to route my cable. But a chip design is a 3D structure consisting of different layers which should be visible as a rotated brick. Maybe one can use CAD FreeCAD but with smaller grid, of course:-) On Sun, Jan 20, 2019 at 2:52 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
On 1/20/19 9:16 PM, Jecel Assumpcao Jr. wrote:
Has the Electric integrated circuit CAD software been considered and rejected for some reason?
Yes. We evaluate a lot of tools during our 1st Hackathon in May last year. Unfortunately no tool matches our need.
In my humble opinion it was a bad move from Electric to switch to Java. Java catches more programmer on the good side but also has do deal with a huge memory footprint. I guess, that our clients playing with smaller laptops than with big iron. So memory is an issue as long as dealing with VLSI (routing, placement, and all the other stuff) needs a lot of them. Both, Java and the design which needs memory also probably does not fit into laptops.
While I am a big fan of KiCAD, it seems to me that starting out with something originally created for integrated circuits would be a better choice. In fact, Electric also has resources allowing it to be used for PCBs but it would be awkward for that compared to KiCAD. I can see that using a single tool for everything would be attractive, however. I am just not sure it is practical.
We would get more VLSI designer, if we are using a familiar GUI for most of them. Something like KiCad which has a great momentum, or Lepton EDA (a active gEDA fork) could be help. Our first attempt was to clone QFlow (http://opencircuitdesign.com/qflow) - which also needs a lot of work. The effort to doing all the stuff alone is to big for us - our small team is already occupied. _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
On 1/20/19 9:53 PM, ludwig jaffe wrote:
Electric> "Download the latest "Java" version"
If someone plays with the idea of writing his own tool .. I assume, the used language/system should be - memory safe (avoiding pointer arithmetics), - small memory footprint (w/o garbage collector), - sophisticated and typed, - concurrent, - attract developer. Candidates are - Rust - Lisp / Scheme / Racket - ML, Haskel which does not fit all points above in one language. Which suggestions do you have?
Cpp is also a valid candidate. Kicad is written in Cpp, btw. 3D graphics needs to be quickly drawing and exact. On Sun, Jan 20, 2019 at 4:10 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
On 1/20/19 9:53 PM, ludwig jaffe wrote:
Electric> "Download the latest "Java" version"
If someone plays with the idea of writing his own tool ..
I assume, the used language/system should be - memory safe (avoiding pointer arithmetics), - small memory footprint (w/o garbage collector), - sophisticated and typed, - concurrent, - attract developer.
Candidates are - Rust - Lisp / Scheme / Racket - ML, Haskel which does not fit all points above in one language.
Which suggestions do you have?
FreeCAD https://www.freecadweb.org/ is parametric, and this sounds good to me. We should try to model a waver structure in FreeCAD, just for the joke of it. Maybe, it performs good. On Sun, Jan 20, 2019 at 4:21 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Cpp is also a valid candidate. Kicad is written in Cpp, btw. 3D graphics needs to be quickly drawing and exact.
On Sun, Jan 20, 2019 at 4:10 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
On 1/20/19 9:53 PM, ludwig jaffe wrote:
Electric> "Download the latest "Java" version"
If someone plays with the idea of writing his own tool ..
I assume, the used language/system should be - memory safe (avoiding pointer arithmetics), - small memory footprint (w/o garbage collector), - sophisticated and typed, - concurrent, - attract developer.
Candidates are - Rust - Lisp / Scheme / Racket - ML, Haskel which does not fit all points above in one language.
Which suggestions do you have?
Ad: "FreeCAD is a 3D CAD/CAE parametric modeling application <https://www.freecadweb.org/wiki/About_FreeCAD>. It is primarily made for mechanical design, but also serves all other uses where you need to **model 3D objects with precision and control over modeling history**" sounds promising On Sun, Jan 20, 2019 at 4:24 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
FreeCAD https://www.freecadweb.org/ is parametric, and this sounds good to me. We should try to model a waver structure in FreeCAD, just for the joke of it. Maybe, it performs good.
On Sun, Jan 20, 2019 at 4:21 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Cpp is also a valid candidate. Kicad is written in Cpp, btw. 3D graphics needs to be quickly drawing and exact.
On Sun, Jan 20, 2019 at 4:10 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
On 1/20/19 9:53 PM, ludwig jaffe wrote:
Electric> "Download the latest "Java" version"
If someone plays with the idea of writing his own tool ..
I assume, the used language/system should be - memory safe (avoiding pointer arithmetics), - small memory footprint (w/o garbage collector), - sophisticated and typed, - concurrent, - attract developer.
Candidates are - Rust - Lisp / Scheme / Racket - ML, Haskel which does not fit all points above in one language.
Which suggestions do you have?
FreeCAD is a light year away from VLSI tools... It's like trying to screw a screw out with a hammer... -lev On Monday, 21 January 2019 5:26:03 AM HKT ludwig jaffe wrote:
Ad: "FreeCAD is a 3D CAD/CAE parametric modeling application. It is primarily made for mechanical design, but also serves all other uses where you need to **model 3D objects with precision and control over modeling history**" sounds promising
Maybe, it can be abused, just scale the measurements. Add a mask which is like sheet metal, and get etched structures which are like a brick, so you can see a brick and masks as an assembly. There are many tools out there which can be abused for other purposes. I abused a schematics entry tool to generate models of business processes, just by drawing a performer symbol, a task symbol, an event symbol and so on and then I drew a schematic with these symbols and got a netlist of the business process. On Mon, Jan 21, 2019 at 12:16 PM David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
FreeCAD is a light year away from VLSI tools... It's like trying to screw a screw out with a hammer...
-lev
On Monday, 21 January 2019 5:26:03 AM HKT ludwig jaffe wrote:
Ad: "FreeCAD is a 3D CAD/CAE parametric modeling application. It is primarily made for mechanical design, but also serves all other uses where you need to **model 3D objects with precision and control over modeling history**" sounds promising
Since neither the older C nor the newer Java versions of Electric are being developed, my idea was to fork the C code. That is the one that was actually used commercially for IC design and the one that I had some experience in. I have no idea if there are improvements or bug fixes in the Java version or if it is a simple rewrite. Of the many rewrites I have seen, the only one I ever saw any value in was the change in Spice from Fortran to C as the original code's memory management was just too horrible due to Fortran's limitations. About KiCAD, it works great for the PCB sizes we use. But imagine trying to design a printed circuit of 15 meters by 20 meters. What changes would be needed in KiCAD to make this practical? This is what designing integrated circuits is like - the ratio of feature size to project size is four orders of magnitude or more. -- Jecel
Hi good point regarding the size of a PCB. If you are fit with electric I would also support developing the c code as I know some c and fast ferforming tools are written in c. First thing to do is get latest c source and make a doxyfile with dot enabled to generate caller and called graphs and some HTML to surf and understand the code. We should give electric a try provided we code c. Cheers ludwig On Monday, January 21, 2019, Jecel Assumpcao Jr. <jecel@merlintec.com> wrote:
Since neither the older C nor the newer Java versions of Electric are being developed, my idea was to fork the C code. That is the one that was actually used commercially for IC design and the one that I had some experience in. I have no idea if there are improvements or bug fixes in the Java version or if it is a simple rewrite. Of the many rewrites I have seen, the only one I ever saw any value in was the change in Spice from Fortran to C as the original code's memory management was just too horrible due to Fortran's limitations.
About KiCAD, it works great for the PCB sizes we use. But imagine trying to design a printed circuit of 15 meters by 20 meters. What changes would be needed in KiCAD to make this practical? This is what designing integrated circuits is like - the ratio of feature size to project size is four orders of magnitude or more.
-- Jecel _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Ludwig Jaffe wrote on: Mon, 21 Jan 2019 21:11:41 +0100
Hi good point regarding the size of a PCB.
If instead of a single window you can see the PCB at different scales at the same time then it would be practical to do very large PCBs. You could see the start and end points for a line going all the way across with two windows while seeing the whole board in a third. I don't think KiCAD does this and don't know how hard it would be to add (but I guess it shouldn't be too hard). One other thing that IC tools normally allow and which PCB tools don't have is to switch between "black box" and full representations of subcircuits. So you might start out with only four rectangles labeled core0 to core3 and then click on core1 to see it divided into rectangles labaled icache, dcache, control and datapath. Then you can click on datapath to see it replaced by even smaller rectangles labeled ALU, registers and so on. It can be hard to design an IC if you are forced to see all the transistors all the time (and the tool will run very slowly and use up a lot of memory).
If you are fit with electric I would also support developing the c code as I know some c and fast ferforming tools are written in c. First thing to do is get latest c source and make a doxyfile with dot enabled to generate caller and called graphs and some HTML to surf and understand the code.
We should give electric a try provided we code c.
I am still looking at the various options, which was why I was asking about Electric instead of actually recommending it. For now I tend to prefer Magic (which seems to be used as a GDS file viewer in this project). I do have a lot of experience with C but prefer to program in Smalltalk when possible. -- Jecel
the one tool that hasn't yet been mentioned is alliance2 / coriolis. this is a mature tool that has as a separate project some proven cell libraries for 180nm, 130nm and 90nm. it's implemented in c++ as python modules, so there's the ultra-high-speed of c++ combined with the flexibility of python. l.
Their build system sucks and it's virtually impossible to build a distribution package for it...
the one tool that hasn't yet been mentioned is alliance2 / coriolis. this is a mature tool that has as a separate project some proven cell libraries for 180nm, 130nm and 90nm. it's implemented in c++ as python modules, so there's the ultra-high-speed of c++ combined with the flexibility of python.
Hi, I forked the electric and it builds nicely. You need the development files of motif (works on many machines, has nice "classic" gui) Read the README.md for building instructions. I compiled it and it runs. https://github.com/levush/electric Cheers Ludwig On Tue, Jan 22, 2019 at 8:54 PM David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
Their build system sucks and it's virtually impossible to build a distribution package for it...
the one tool that hasn't yet been mentioned is alliance2 / coriolis. this is a mature tool that has as a separate project some proven cell libraries for 180nm, 130nm and 90nm. it's implemented in c++ as python modules, so there's the ultra-high-speed of c++ combined with the flexibility of python._______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Catching up on the thread ... On Wed, Jan 23, 2019 at 11:15 AM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi, I forked the electric and it builds nicely. You need the development files of motif (works on many machines, has nice "classic" gui) Read the README.md for building instructions. I compiled it and it runs.
Ludwig, is there a screenshot of a proof-of-concept chip design to take a look at? - tatzelbrumm
https://github.com/levush/electric
Cheers
Ludwig
On Tue, Jan 22, 2019 at 8:54 PM David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:
Their build system sucks and it's virtually impossible to build a distribution package for it...
the one tool that hasn't yet been mentioned is alliance2 / coriolis. this is a mature tool that has as a separate project some proven cell libraries for 180nm, 130nm and 90nm. it's implemented in c++ as python modules, so there's the ultra-high-speed of c++ combined with the flexibility of python._______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
screenshot: wikipedia is your friend https://en.wikipedia.org/wiki/Electric_(software) On Thu, Jan 31, 2019 at 11:30 PM Christoph Maier <christoph.maier@ieee.org> wrote:
Catching up on the thread ...
On Wed, Jan 23, 2019 at 11:15 AM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi, I forked the electric and it builds nicely. You need the development files of motif (works on many machines, has
nice "classic" gui)
Read the README.md for building instructions. I compiled it and it runs.
Ludwig, is there a screenshot of a proof-of-concept chip design to take a look at?
- tatzelbrumm
https://github.com/levush/electric
Cheers
Ludwig
On Tue, Jan 22, 2019 at 8:54 PM David Lanzendörfer <
david.lanzendoerfer@o2s.ch> wrote:
Their build system sucks and it's virtually impossible to build a
distribution
package for it...
the one tool that hasn't yet been mentioned is alliance2 / coriolis. this is a mature tool that has as a separate project some proven cell libraries for 180nm, 130nm and 90nm. it's implemented in c++ as python modules, so there's the ultra-high-speed of c++ combined with the flexibility of python._______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
On Wednesday, January 23, 2019, David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
Their build system sucks and it's virtually impossible to build a distribution package for it...
It's just cmake. There's nothing special. I got it up and running last year on debian, spoke to jean-paul, and submitted patches, which were accepted. Now, yes, boost is a bitch on steroids, the people who created it should be castrated or something suitably painful as a way to reflect the level of pain that they've inflicted on others through their thoughtless lack of proper strategic planning on API changes. I believe I have had up to EIGHT f**bbn versions of libboost simultaneously installed at some point. Absolute insanity. Anyway. If i recall correctly I set up a debian/stable chroot in order to get out of the hell that is boost. The normal way that this is dealt with in debian is to use the auto-chroot-build debian developer tools. This guarantees a consistent clean environment. I forget the name of the tool, so did the chroot manually. The patches that I added were down to strange spurious changes to the linker phase of upstream cmake or dependencies. Cant recall the details but I had to list all of the libraries manually even those that had aleady been linked in to other shared libraries. On ubuntu they allow shared libraries to recursively pull in their dependent shared libraries into the executable being linked. It was a pain in the ass to track down, but should be fine, now. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Hi all, having Kicad to support VLSI design would be great. As the tool is then maintained by the cern. So we can focus on other stuff. Also cern would have a benefit as they could design their asics using Kicad. The users of KiCad get to know our project and are able to design chips. A 3Win situation. Try to promote it from the view of cern benefiting from vlsi design capabilities. Electric as backup solution: So I generated doxygen with caller grapghs and so on for electric which takes long having 4 xeon cores and enough ram in the vm. the documentation is uploading to github, so wait a while and you can git clone and have fun with the project. Maybe, I should make a different repository for the documentation as it is huge. https://github.com/levush/electric/tree/master/doc Cheers, Ludwig On Wed, Jan 23, 2019 at 5:49 AM Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
On Wednesday, January 23, 2019, David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
Their build system sucks and it's virtually impossible to build a distribution package for it...
It's just cmake. There's nothing special. I got it up and running last year on debian, spoke to jean-paul, and submitted patches, which were accepted.
Now, yes, boost is a bitch on steroids, the people who created it should be castrated or something suitably painful as a way to reflect the level of pain that they've inflicted on others through their thoughtless lack of proper strategic planning on API changes. I believe I have had up to EIGHT f**bbn versions of libboost simultaneously installed at some point. Absolute insanity.
Anyway.
If i recall correctly I set up a debian/stable chroot in order to get out of the hell that is boost.
The normal way that this is dealt with in debian is to use the auto-chroot-build debian developer tools. This guarantees a consistent clean environment. I forget the name of the tool, so did the chroot manually.
The patches that I added were down to strange spurious changes to the linker phase of upstream cmake or dependencies. Cant recall the details but I had to list all of the libraries manually even those that had aleady been linked in to other shared libraries.
On ubuntu they allow shared libraries to recursively pull in their dependent shared libraries into the executable being linked.
It was a pain in the ass to track down, but should be fine, now.
L.
-- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi all, due to the size of the html doc I made a new repository which is uploading to github. It is there https://github.com/levush/electric-html-doc The html-doc tarball will be removed from the https://github.com/levush/electric as soon as possible in order to allow for checking out the source code quickly. Cheers, Ludwig On Wed, Jan 23, 2019 at 6:30 AM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi all,
having Kicad to support VLSI design would be great. As the tool is then maintained by the cern. So we can focus on other stuff. Also cern would have a benefit as they could design their asics using Kicad. The users of KiCad get to know our project and are able to design chips. A 3Win situation. Try to promote it from the view of cern benefiting from vlsi design capabilities.
Electric as backup solution: So I generated doxygen with caller grapghs and so on for electric which takes long having 4 xeon cores and enough ram in the vm. the documentation is uploading to github, so wait a while and you can git clone and have fun with the project. Maybe, I should make a different repository for the documentation as it is huge. https://github.com/levush/electric/tree/master/doc
Cheers,
Ludwig
On Wed, Jan 23, 2019 at 5:49 AM Luke Kenneth Casson Leighton < lkcl@lkcl.net> wrote:
On Wednesday, January 23, 2019, David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
Their build system sucks and it's virtually impossible to build a distribution package for it...
It's just cmake. There's nothing special. I got it up and running last year on debian, spoke to jean-paul, and submitted patches, which were accepted.
Now, yes, boost is a bitch on steroids, the people who created it should be castrated or something suitably painful as a way to reflect the level of pain that they've inflicted on others through their thoughtless lack of proper strategic planning on API changes. I believe I have had up to EIGHT f**bbn versions of libboost simultaneously installed at some point. Absolute insanity.
Anyway.
If i recall correctly I set up a debian/stable chroot in order to get out of the hell that is boost.
The normal way that this is dealt with in debian is to use the auto-chroot-build debian developer tools. This guarantees a consistent clean environment. I forget the name of the tool, so did the chroot manually.
The patches that I added were down to strange spurious changes to the linker phase of upstream cmake or dependencies. Cant recall the details but I had to list all of the libraries manually even those that had aleady been linked in to other shared libraries.
On ubuntu they allow shared libraries to recursively pull in their dependent shared libraries into the executable being linked.
It was a pain in the ass to track down, but should be fine, now.
L.
-- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi I've seen there is an option to build with Qt instead of the pretty oldschool TK library. Since the modern version of Qt makes things compile kindof portable (Qt also builds on Windows), it would actually be a neat idea to make it use Qt as the standard lib on Linux as well. Cheers -lev
due to the size of the html doc I made a new repository which is uploading to github. It is there https://github.com/levush/electric-html-doc
The html-doc tarball will be removed from the https://github.com/levush/electric as soon as possible in order to allow for checking out the source code quickly.
So why should we use Qt? The electric tool builds fine with motif and is useable. If there is no special feature exept design or having used modern libs, I would opt against, as Qt gets new revisions and changes so the code needs to be changed. e.g. qt4 ->qt5. Motif is there and there is not much change so we dont have to work on this matter. It is about bringing functionality not design or coolness. Cheers, Ludwig (still uploading about 1GB at a small link) On Wed, Jan 23, 2019 at 7:49 AM David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
Hi I've seen there is an option to build with Qt instead of the pretty oldschool TK library. Since the modern version of Qt makes things compile kindof portable (Qt also builds on Windows), it would actually be a neat idea to make it use Qt as the standard lib on Linux as well.
Cheers -lev
due to the size of the html doc I made a new repository which is uploading to github. It is there https://github.com/levush/electric-html-doc
The html-doc tarball will be removed from the https://github.com/levush/electric as soon as possible in order to allow for checking out the source code quickly.
Hi
having Kicad to support VLSI design would be great. As the tool is then maintained by the cern. So we can focus on other stuff. Also cern would have a benefit as they could design their asics using Kicad. The users of KiCad get to know our project and are able to design chips. A 3Win situation. Try to promote it from the view of cern benefiting from vlsi design capabilities. That was exactly my reasoning behind suggesting to incorporate VLSI capabilities into KiCAD...
-lev
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it: http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf The typical unix command line style reminds me of the old Berkeley tools. I am sure this makes makefile fans very happy (just as vi-like commands in Magic is "intuitive" to some people). This list of free VLSI tools seems reasonably complete: http://www.vlsiacademy.org/open-source-cad-tools.html Besides standard cells, I have studied other design methods in the past such as PPL (Path Programmable Logic from the University of Utah) or Gate Matrix from Bell Labs. https://dl.acm.org/citation.cfm?id=74714 http://cdmbuntu.lib.utah.edu/cdm/ref/collection/uspace/id/1351 https://ieeexplore.ieee.org/document/1156074 I don't currently have access to ACM and IEEE online stuff, but these references might be useful to some people. These are not open source tools, however. I actually bought a copy of the PPL tools back in 1990 but can't use them due to a silly protection scheme. But the ideas might be worth looking at. -- Jecel
Hi Jecel, thanks for your input the Alliance tools look funny unixish and also quite complete, so why not using them. Also the page mentions a process library. The ebook on the tools gives a good overview, thanks! http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf The home page of Alliance is here: https://www-soc.lip6.fr/equipe-cian/logiciels/alliance/ The source is there: git clone it. https://www-soc.lip6.fr/git/alliance.git Thanks, Ludwig On Wed, Jan 23, 2019 at 8:10 PM Jecel Assumpcao Jr. <jecel@merlintec.com> wrote:
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it:
http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The typical unix command line style reminds me of the old Berkeley tools. I am sure this makes makefile fans very happy (just as vi-like commands in Magic is "intuitive" to some people).
This list of free VLSI tools seems reasonably complete:
http://www.vlsiacademy.org/open-source-cad-tools.html
Besides standard cells, I have studied other design methods in the past such as PPL (Path Programmable Logic from the University of Utah) or Gate Matrix from Bell Labs.
https://dl.acm.org/citation.cfm?id=74714 http://cdmbuntu.lib.utah.edu/cdm/ref/collection/uspace/id/1351 https://ieeexplore.ieee.org/document/1156074
I don't currently have access to ACM and IEEE online stuff, but these references might be useful to some people. These are not open source tools, however. I actually bought a copy of the PPL tools back in 1990 but can't use them due to a silly protection scheme. But the ideas might be worth looking at.
-- Jecel _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi Jecel, hi all. I git cloned the tool and try to build it. one needs to cd to alliance/src and run autostuff which is a shell script to generate automake files. Then do export ALLIANCE_TOP=/opt/alliance ./configure --prefix=$ALLIANCE_TOP gmake install as written in alliance/src/README and ... you need libmotif-devel libs installed like in electric, as both tools are quite old :-) But motif is ok, looks a bit vintage. Cheers, Ludwig On Wed, Jan 23, 2019 at 8:53 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel,
thanks for your input the Alliance tools look funny unixish and also quite complete, so why not using them. Also the page mentions a process library. The ebook on the tools gives a good overview, thanks! http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The home page of Alliance is here: https://www-soc.lip6.fr/equipe-cian/logiciels/alliance/
The source is there: git clone it. https://www-soc.lip6.fr/git/alliance.git
Thanks,
Ludwig
On Wed, Jan 23, 2019 at 8:10 PM Jecel Assumpcao Jr. <jecel@merlintec.com> wrote:
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it:
http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The typical unix command line style reminds me of the old Berkeley tools. I am sure this makes makefile fans very happy (just as vi-like commands in Magic is "intuitive" to some people).
This list of free VLSI tools seems reasonably complete:
http://www.vlsiacademy.org/open-source-cad-tools.html
Besides standard cells, I have studied other design methods in the past such as PPL (Path Programmable Logic from the University of Utah) or Gate Matrix from Bell Labs.
https://dl.acm.org/citation.cfm?id=74714 http://cdmbuntu.lib.utah.edu/cdm/ref/collection/uspace/id/1351 https://ieeexplore.ieee.org/document/1156074
I don't currently have access to ACM and IEEE online stuff, but these references might be useful to some people. These are not open source tools, however. I actually bought a copy of the PPL tools back in 1990 but can't use them due to a silly protection scheme. But the ideas might be worth looking at.
-- Jecel _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi all, building alliance, make now complains about missing yacc. libmotif-dev was needed before, to pass ./configure generated by calling src/autostuff I installed bison and libbison-dev as replacement for yacc and the make continues. looks good, still compiling on a laptop ... I want to have all the tools in form of source code and I want to be able to build them from that source, in order to make sure that the project is self-sufficient on software. Cheers, Ludwig On Wed, Jan 23, 2019 at 9:04 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel, hi all. I git cloned the tool and try to build it. one needs to cd to alliance/src and run autostuff which is a shell script to generate automake files. Then do export ALLIANCE_TOP=/opt/alliance ./configure --prefix=$ALLIANCE_TOP gmake install
as written in alliance/src/README
and ... you need libmotif-devel libs installed like in electric, as both tools are quite old :-) But motif is ok, looks a bit vintage.
Cheers,
Ludwig
On Wed, Jan 23, 2019 at 8:53 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel,
thanks for your input the Alliance tools look funny unixish and also quite complete, so why not using them. Also the page mentions a process library. The ebook on the tools gives a good overview, thanks! http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The home page of Alliance is here: https://www-soc.lip6.fr/equipe-cian/logiciels/alliance/
The source is there: git clone it. https://www-soc.lip6.fr/git/alliance.git
Thanks,
Ludwig
On Wed, Jan 23, 2019 at 8:10 PM Jecel Assumpcao Jr. <jecel@merlintec.com> wrote:
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it:
http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The typical unix command line style reminds me of the old Berkeley tools. I am sure this makes makefile fans very happy (just as vi-like commands in Magic is "intuitive" to some people).
This list of free VLSI tools seems reasonably complete:
http://www.vlsiacademy.org/open-source-cad-tools.html
Besides standard cells, I have studied other design methods in the past such as PPL (Path Programmable Logic from the University of Utah) or Gate Matrix from Bell Labs.
https://dl.acm.org/citation.cfm?id=74714 http://cdmbuntu.lib.utah.edu/cdm/ref/collection/uspace/id/1351 https://ieeexplore.ieee.org/document/1156074
I don't currently have access to ACM and IEEE online stuff, but these references might be useful to some people. These are not open source tools, however. I actually bought a copy of the PPL tools back in 1990 but can't use them due to a silly protection scheme. But the ideas might be worth looking at.
-- Jecel _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi all, there is a problem building alliance: ./.libs/libVrd.a(vmcasmld.o): In function `DrucReadRulesComment': /home/user/src/alliance/alliance/src/druc/src/vmcasmld.c:121: undefined reference to `vrd_y_in' /home/user/src/alliance/alliance/src/druc/src/vmcasmld.c:135: undefined reference to `vrd_y_lineno' ./.libs/libVrd.a(vmcasmld.o): In function `DrucInitInstruction': /home/user/src/alliance/alliance/src/druc/src/vmcasmld.c:183: undefined reference to `vrd_y_in' any ideas? Cheers, Ludwig On Wed, Jan 23, 2019 at 9:16 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi all, building alliance, make now complains about missing yacc.
libmotif-dev was needed before, to pass ./configure generated by calling src/autostuff I installed bison and libbison-dev as replacement for yacc and the make continues. looks good, still compiling on a laptop ...
I want to have all the tools in form of source code and I want to be able to build them from that source, in order to make sure that the project is self-sufficient on software.
Cheers,
Ludwig
On Wed, Jan 23, 2019 at 9:04 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel, hi all. I git cloned the tool and try to build it. one needs to cd to alliance/src and run autostuff which is a shell script to generate automake files. Then do export ALLIANCE_TOP=/opt/alliance ./configure --prefix=$ALLIANCE_TOP gmake install
as written in alliance/src/README
and ... you need libmotif-devel libs installed like in electric, as both tools are quite old :-) But motif is ok, looks a bit vintage.
Cheers,
Ludwig
On Wed, Jan 23, 2019 at 8:53 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel,
thanks for your input the Alliance tools look funny unixish and also quite complete, so why not using them. Also the page mentions a process library. The ebook on the tools gives a good overview, thanks! http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The home page of Alliance is here: https://www-soc.lip6.fr/equipe-cian/logiciels/alliance/
The source is there: git clone it. https://www-soc.lip6.fr/git/alliance.git
Thanks,
Ludwig
On Wed, Jan 23, 2019 at 8:10 PM Jecel Assumpcao Jr. <jecel@merlintec.com> wrote:
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it:
http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The typical unix command line style reminds me of the old Berkeley tools. I am sure this makes makefile fans very happy (just as vi-like commands in Magic is "intuitive" to some people).
This list of free VLSI tools seems reasonably complete:
http://www.vlsiacademy.org/open-source-cad-tools.html
Besides standard cells, I have studied other design methods in the past such as PPL (Path Programmable Logic from the University of Utah) or Gate Matrix from Bell Labs.
https://dl.acm.org/citation.cfm?id=74714 http://cdmbuntu.lib.utah.edu/cdm/ref/collection/uspace/id/1351 https://ieeexplore.ieee.org/document/1156074
I don't currently have access to ACM and IEEE online stuff, but these references might be useful to some people. These are not open source tools, however. I actually bought a copy of the PPL tools back in 1990 but can't use them due to a silly protection scheme. But the ideas might be worth looking at.
-- Jecel _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
ludwig jaffe schreef op wo 23-01-2019 om 21:04 [+0100]:
Hi Jecel, hi all. I git cloned the tool and try to build it. one needs to cd to alliance/src and run autostuff which is a shell script to generate automake files. Then do export ALLIANCE_TOP=/opt/alliance ./configure --prefix=$ALLIANCE_TOP gmake install
as written in alliance/src/README
and ... you need libmotif-devel libs installed like in electric, as both tools are quite old :-) But motif is ok, looks a bit vintage.
Cheers,
Ludwig
On Wed, Jan 23, 2019 at 8:53 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel,
thanks for your input the Alliance tools look funny unixish and also quite complete, so why not using them. Also the page mentions a process library. The ebook on the tools gives a good overview, thanks! http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf
The home page of Alliance is here: https://www-soc.lip6.fr/equipe-cian/logiciels/alliance/
The source is there: git clone it. https://www-soc.lip6.fr/git/alliance.git
Alliance is getting older now, it is mainly a VHDL based synthesis tool. The VHDL does not support the more recent extensions of VHDL. Recent more development has been done on coriolis which is a more modern place and route tool. This tool has also been used together with yosys for synthesis. Pdf documentation is included now in the repo and is attached. Main trick is to checkout the devel_anabatic branch of https://www-soc.lip6.fr/git/coriolis.git. With questions one can contact the alliance users mailling list; some seem to think Jean-Paul (the main developer of Coriolis) does not bite. The build system needs to get used to and may need some more flexibility; but implementing that will I think take less time than a whole spanking new VLSI tool chain. There is also some example bench in the alliance-check-toolkit repository (https://www-soc.lip6.fr/git/alliance-check-toolkit.git) in the benchs/snx directory. greets, Staf.
Hi staf, Thanks for your suggestion. We need to make a table with lots of tools as candidates for our flow and find criteria containing features we need and how important they are 1 to 23 and the degree of fullfillmemt of the tools in each criterion by 1 to 23 and then we calculate points= importance of criterion * fullfillment * 3*(random(0to1)+0.01) Random is between 0 and 1 We get a room of solutions from which we pick manually by good discussion. Cheers Ludwig On Wednesday, January 23, 2019, Staf Verhaegen <staf@fibraservi.eu> wrote:
ludwig jaffe schreef op wo 23-01-2019 om 21:04 [+0100]:
Hi Jecel, hi all. I git cloned the tool and try to build it. one needs to cd to alliance/src and run autostuff which is a shell script to generate automake files. Then do export ALLIANCE_TOP=/opt/alliance ./configure --prefix=$ALLIANCE_TOP gmake install as written in alliance/src/README
and ... you need libmotif-devel libs installed like in electric, as both tools are quite old :-) But motif is ok, looks a bit vintage.
Cheers, Ludwig
On Wed, Jan 23, 2019 at 8:53 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel, thanks for your input the Alliance tools look funny unixish and also quite complete, so why not using them. Also the page mentions a process library. The ebook on the tools gives a good overview, thanks! http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf The home page of Alliance is here: https://www-soc.lip6.fr/equipe-cian/logiciels/alliance/ The source is there: git clone it. https://www-soc.lip6.fr/git/alliance.git
Alliance is getting older now, it is mainly a VHDL based synthesis tool. The VHDL does not support the more recent extensions of VHDL. Recent more development has been done on coriolis which is a more modern place and route tool. This tool has also been used together with yosys for synthesis. Pdf documentation is included now in the repo and is attached. Main trick is to checkout the devel_anabatic branch of https://www-soc.lip6.fr/git/coriolis.git. With questions one can contact the alliance users mailling list; some seem to think Jean-Paul (the main developer of Coriolis) does not bite. The build system needs to get used to and may need some more flexibility; but implementing that will I think take less time than a whole spanking new VLSI tool chain. There is also some example bench in the alliance-check-toolkit repository (https://www-soc.lip6.fr/git/alliance-check-toolkit.git) in the benchs/snx directory. greets, Staf.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
We need to go bottom up and integrate good stuff as we are lazy. Beeing lazy is a virtue as it saves time and energy for the important things Cheers Ludwig On Sunday, January 27, 2019, ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi staf,
Thanks for your suggestion. We need to make a table with lots of tools as candidates for our flow and find criteria containing features we need and how important they are 1 to 23 and the degree of fullfillmemt of the tools in each criterion by 1 to 23 and then we calculate points= importance of criterion * fullfillment * 3*(random(0to1)+0.01) Random is between 0 and 1 We get a room of solutions from which we pick manually by good discussion.
Cheers
Ludwig
On Wednesday, January 23, 2019, Staf Verhaegen <staf@fibraservi.eu> wrote:
ludwig jaffe schreef op wo 23-01-2019 om 21:04 [+0100]:
Hi Jecel, hi all. I git cloned the tool and try to build it. one needs to cd to alliance/src and run autostuff which is a shell script to generate automake files. Then do export ALLIANCE_TOP=/opt/alliance ./configure --prefix=$ALLIANCE_TOP gmake install as written in alliance/src/README
and ... you need libmotif-devel libs installed like in electric, as both tools are quite old :-) But motif is ok, looks a bit vintage.
Cheers, Ludwig
On Wed, Jan 23, 2019 at 8:53 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Hi Jecel, thanks for your input the Alliance tools look funny unixish and also quite complete, so why not using them. Also the page mentions a process library. The ebook on the tools gives a good overview, thanks! http://www.cc.toin.ac.jp/sc/palacios/openbook/vlsie.pdf The home page of Alliance is here: https://www-soc.lip6.fr/equipe-cian/logiciels/alliance/ The source is there: git clone it. https://www-soc.lip6.fr/git/alliance.git
Alliance is getting older now, it is mainly a VHDL based synthesis tool. The VHDL does not support the more recent extensions of VHDL. Recent more development has been done on coriolis which is a more modern place and route tool. This tool has also been used together with yosys for synthesis. Pdf documentation is included now in the repo and is attached. Main trick is to checkout the devel_anabatic branch of https://www-soc.lip6.fr/git/coriolis.git. With questions one can contact the alliance users mailling list; some seem to think Jean-Paul (the main developer of Coriolis) does not bite. The build system needs to get used to and may need some more flexibility; but implementing that will I think take less time than a whole spanking new VLSI tool chain. There is also some example bench in the alliance-check-toolkit repository (https://www-soc.lip6.fr/git/alliance-check-toolkit.git) in the benchs/snx directory. greets, Staf.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it:
An existance proof for Alliance documentation! Thanks for dredging this up! Honestly, I have never seen Alliance documentation before. This is more of a tutorial than actual proguram documentation, but it does the job. Slightly discouraging is the line that the (NERO) router can handle "up to 4K gates". Another discouraging line is "Real pads are specific to a foundry and must be designed to fit to those of Alliance". The rate at which I came up with discouraging lines by randomly perusing the document was also discouraging. . . Regards, Tim +--------------------------------+-------------------------------------+ | R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design | web: http://opencircuitdesign.com | | 19601 Jerusalem Road | phone: (240) 489-3255 | | Poolesville, MD 20837 | cell: (408) 828-8212 | +--------------------------------+-------------------------------------+
Hello Tim, Hello List! On 1/23/19 8:59 PM, Tim Edwards wrote:
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it:
An existance proof for Alliance documentation! Thanks for dredging this up!
Honestly, I have never seen Alliance documentation before. This is more of a tutorial than actual proguram documentation, but it does the job.
Slightly discouraging is the line that the (NERO) router can handle "up to 4K gates". Another discouraging line is "Real pads are specific to a foundry and must be designed to fit to those of Alliance". The rate at which I came up with discouraging lines by randomly perusing the document was also discouraging. . .
Please provide us with a list of issues you have with Alliance - I plan to go to Paris for https://wiki.f-si.org/index.php/FSiC2019 On the speakers list there are a couple of the original authors of Alliance. I would ask them all about your item list :-) Best Regards, Hagen Sankowski
Hi Hagen, then take the compile errors here. If one checks in code to a git repository, he should make sure that the code compiles. Function is not required, but compile should work on all checked in code. You can try to check-out the code and do what I did, just read my mails. Maybe, my vm on that laptop is somehow screwed up. btw: the make to be used is make and not gmake, because make is gmake on modern linux distributions. As make was the unix make and not the gnu make called gmake there. Cheers, Ludwig On Wed, Jan 23, 2019 at 9:27 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
Hello Tim, Hello List!
On 1/23/19 8:59 PM, Tim Edwards wrote:
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now have read this book which has a nice example of using it:
An existance proof for Alliance documentation! Thanks for dredging this up!
Honestly, I have never seen Alliance documentation before. This is more of a tutorial than actual proguram documentation, but it does the job.
Slightly discouraging is the line that the (NERO) router can handle "up to 4K gates". Another discouraging line is "Real pads are specific to a foundry and must be designed to fit to those of Alliance". The rate at which I came up with discouraging lines by randomly perusing the document was also discouraging. . .
Please provide us with a list of issues you have with Alliance - I plan to go to Paris for https://wiki.f-si.org/index.php/FSiC2019
On the speakers list there are a couple of the original authors of Alliance. I would ask them all about your item list :-)
Best Regards, Hagen Sankowski
_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hello Hagen,
Please provide us with a list of issues you have with Alliance - I plan to go to Paris for https://wiki.f-si.org/index.php/FSiC2019
On the speakers list there are a couple of the original authors of Alliance. I would ask them all about your item list :-)
I have been invited to speak at that conference, which I am considering. I am a bit disappointed that the group does not seem to know about the similar FOSSi foundation. To repeat a talking point of one of the FOSSi members, it seems like unnecessary fracturing of an already very small community. However, if you are going to be there, and the Alliance authors, there are two additional reasons to go. ---Tim +--------------------------------+-------------------------------------+ | R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design | web: http://opencircuitdesign.com | | 19601 Jerusalem Road | phone: (240) 489-3255 | | Poolesville, MD 20837 | cell: (408) 828-8212 | +--------------------------------+-------------------------------------+
do we have an issue tracker like mantis? Maybe, we should set up a project server with shell accounts for everyone with ssh, git, mantis and some other tools. Here we should store all source code for tools we are using and all the artifacts we are generating, so that we are really self-sufficient. Would be nice to just open an issue with mantis. Cheers, Ludwig. On Wed, Jan 23, 2019 at 9:33 PM Tim Edwards <tim@opencircuitdesign.com> wrote:
Hello Hagen,
Please provide us with a list of issues you have with Alliance - I plan to go to Paris for https://wiki.f-si.org/index.php/FSiC2019
On the speakers list there are a couple of the original authors of Alliance. I would ask them all about your item list :-)
I have been invited to speak at that conference, which I am considering.
I am a bit disappointed that the group does not seem to know about the similar FOSSi foundation. To repeat a talking point of one of the FOSSi members, it seems like unnecessary fracturing of an already very small community.
However, if you are going to be there, and the Alliance authors, there are two additional reasons to go. ---Tim
+--------------------------------+-------------------------------------+ | R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design | web: http://opencircuitdesign.com | | 19601 Jerusalem Road | phone: (240) 489-3255 | | Poolesville, MD 20837 | cell: (408) 828-8212 | +--------------------------------+-------------------------------------+ _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
also an ebook collection should be hosted, so that we can link to the books we read or recommend the others to read. Having a common library would be good. On Wed, Jan 23, 2019 at 9:59 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
do we have an issue tracker like mantis?
Maybe, we should set up a project server with shell accounts for everyone with ssh, git, mantis and some other tools. Here we should store all source code for tools we are using and all the artifacts we are generating, so that we are really self-sufficient. Would be nice to just open an issue with mantis.
Cheers,
Ludwig.
On Wed, Jan 23, 2019 at 9:33 PM Tim Edwards <tim@opencircuitdesign.com> wrote:
Hello Hagen,
Please provide us with a list of issues you have with Alliance - I plan to go to Paris for https://wiki.f-si.org/index.php/FSiC2019
On the speakers list there are a couple of the original authors of Alliance. I would ask them all about your item list :-)
I have been invited to speak at that conference, which I am considering.
I am a bit disappointed that the group does not seem to know about the similar FOSSi foundation. To repeat a talking point of one of the FOSSi members, it seems like unnecessary fracturing of an already very small community.
However, if you are going to be there, and the Alliance authors, there are two additional reasons to go. ---Tim
+--------------------------------+-------------------------------------+ | R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design | web: http://opencircuitdesign.com | | 19601 Jerusalem Road | phone: (240) 489-3255 | | Poolesville, MD 20837 | cell: (408) 828-8212 | +--------------------------------+-------------------------------------+ _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
host this thing in hong-kong for freedom reasons :-) On Wed, Jan 23, 2019 at 10:00 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
also an ebook collection should be hosted, so that we can link to the books we read or recommend the others to read. Having a common library would be good.
On Wed, Jan 23, 2019 at 9:59 PM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
do we have an issue tracker like mantis?
Maybe, we should set up a project server with shell accounts for everyone with ssh, git, mantis and some other tools. Here we should store all source code for tools we are using and all the artifacts we are generating, so that we are really self-sufficient. Would be nice to just open an issue with mantis.
Cheers,
Ludwig.
On Wed, Jan 23, 2019 at 9:33 PM Tim Edwards <tim@opencircuitdesign.com> wrote:
Hello Hagen,
Please provide us with a list of issues you have with Alliance - I plan to go to Paris for https://wiki.f-si.org/index.php/FSiC2019
On the speakers list there are a couple of the original authors of Alliance. I would ask them all about your item list :-)
I have been invited to speak at that conference, which I am considering.
I am a bit disappointed that the group does not seem to know about the similar FOSSi foundation. To repeat a talking point of one of the FOSSi members, it seems like unnecessary fracturing of an already very small community.
However, if you are going to be there, and the Alliance authors, there are two additional reasons to go. ---Tim
+--------------------------------+-------------------------------------+ | R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design | web: http://opencircuitdesign.com | | 19601 Jerusalem Road | phone: (240) 489-3255 | | Poolesville, MD 20837 | cell: (408) 828-8212 | +--------------------------------+-------------------------------------+ _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi
host this thing in hong-kong for freedom reasons :-) Agreed. Right now we've got a colocation space in Germany and one in Switzerland. But they suck up to the US as well, as we know. So a server somewhere in Hong Kong or Shenzhen might actually be a good idea.
-lev
Hi all, I would strongly suggest Hong Kong as China mainland will be filtered behind the chinese firewall. If we do encrypted traffic (ssh, ssl, vpn) the authorities could become interested and start to ask stupid questions and may want to have back doors and private keys. I hate such stuff and just want to operate an encrypted development server that has all the freedom it deserves where we can put all our stuff without needing to ask someone, if we may do so or even worse would need to do self censorship. Europe is not free, it is infested with greedy lawyers and politicians who happen to be lawyers in most cases at least in germany. Dont host in germany, not in the EU and also not in the USA (you know why some stuff of the openbsd project is hosted in canada ;-) crypto is a weapon, AES shirts were forbidden to be exported from the US) Look for hosting in Hong Kong and if you like and if you have decent internet you can also host at home / fab or university or a place like that. I am sure that one can buy used servers by DELL, HP or even some Chinese brand (US computers may / do have back doors in management interface. Never ever connect the management interface HPILO or DELL DARC and all the other shit like that (remote console over ethernet with virtual floppy/cdrom mounter) to the internet. Have a hardware (separate box, with two separate NICs, may be an openwrt router 2NICS!) VPN router if you really need to connect the remote admin interface. Have no way to route traffic from that VPN to/from the internet. The VPN is only a reserved net like 10.0.0.0/28 I would suggest to buy something used some standard 2U server with 3.5 inch HDDs and put 2 HDDs and have raid1 with the linux kernel this is a stable and simple solution. Never trust a raid controller and its firmware, as when the controller is gone, your data is gone. Have much fun, Ludwig On Thu, Jan 24, 2019 at 1:29 PM David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote:
Hi
host this thing in hong-kong for freedom reasons :-) Agreed. Right now we've got a colocation space in Germany and one in Switzerland. But they suck up to the US as well, as we know. So a server somewhere in Hong Kong or Shenzhen might actually be a good idea.
-lev
Tim Edwards schreef op wo 23-01-2019 om 15:33 [-0500]:
Hello Hagen,
I am a bit disappointed that the group does not seem to know about the similar FOSSi foundation. To repeat a talking point of one of the FOSSi members, it seems like unnecessary fracturing of an already very small community.
They know about it, but they seem to be more on the free software side of the spectrum and FOSSi more on the open source spectrum. I don't really mind as everything in open source will increase the pool. greets, Staf.
On Wed, Jan 23, 2019 at 11:26 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
Tim Edwards schreef op wo 23-01-2019 om 15:33 [-0500]:
Hello Hagen,
I am a bit disappointed that the group does not seem to know about the
similar FOSSi foundation. To repeat a talking point of one of the
FOSSi members, it seems like unnecessary fracturing of an already very
small community.
https://fossi-foundation.org/code-of-conduct this contains incredibly dangerous toxic language that poisons and overshadows peoples' minds. imagine putting that document in front of a six to nine year old, and having to answer questions, "daddy, what are racism and sexism?" please for god's sake do not poison the libre-silicon effort with the same awful wording. if any such toxic document is added to this project i will cease contributing and interacting with the project and its members immediately and will never, under any circumstances, recommend the project, discuss it with anyone, or help in any way to find funding or other resources for it. l.
Holy shit, conduct. These are luxury problems of politicians! Oh, our mos transistor could be female. On Thu, Jan 24, 2019 at 8:36 AM Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
On Wed, Jan 23, 2019 at 11:26 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
Tim Edwards schreef op wo 23-01-2019 om 15:33 [-0500]:
Hello Hagen,
I am a bit disappointed that the group does not seem to know about the
similar FOSSi foundation. To repeat a talking point of one of the
FOSSi members, it seems like unnecessary fracturing of an already very
small community.
https://fossi-foundation.org/code-of-conduct
this contains incredibly dangerous toxic language that poisons and overshadows peoples' minds. imagine putting that document in front of a six to nine year old, and having to answer questions, "daddy, what are racism and sexism?"
please for god's sake do not poison the libre-silicon effort with the same awful wording. if any such toxic document is added to this project i will cease contributing and interacting with the project and its members immediately and will never, under any circumstances, recommend the project, discuss it with anyone, or help in any way to find funding or other resources for it.
l. _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
" Reporting Guidelines While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. If you believe someone is violating this code of conduct, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion. Should there be difficulties in dealing with the situation, you may report your compliance issues in confidence to the board of directors of the FOSSi Foundation. You can find their contact information on the board overview page <https://fossi-foundation.org/organization>. " blockleiter https://en.wikipedia.org/wiki/Blockleiter /// we dont need such shit. Lets just do our development and talk tech stuff, and everything is fine. Cheers, Ludwig On Thu, Jan 24, 2019 at 8:40 AM ludwig jaffe <ludwig.jaffe@gmail.com> wrote:
Holy shit, conduct. These are luxury problems of politicians! Oh, our mos transistor could be female.
On Thu, Jan 24, 2019 at 8:36 AM Luke Kenneth Casson Leighton < lkcl@lkcl.net> wrote:
On Wed, Jan 23, 2019 at 11:26 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
Tim Edwards schreef op wo 23-01-2019 om 15:33 [-0500]:
Hello Hagen,
I am a bit disappointed that the group does not seem to know about the
similar FOSSi foundation. To repeat a talking point of one of the
FOSSi members, it seems like unnecessary fracturing of an already very
small community.
https://fossi-foundation.org/code-of-conduct
this contains incredibly dangerous toxic language that poisons and overshadows peoples' minds. imagine putting that document in front of a six to nine year old, and having to answer questions, "daddy, what are racism and sexism?"
please for god's sake do not poison the libre-silicon effort with the same awful wording. if any such toxic document is added to this project i will cease contributing and interacting with the project and its members immediately and will never, under any circumstances, recommend the project, discuss it with anyone, or help in any way to find funding or other resources for it.
l. _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi
Holy shit, conduct. These are luxury problems of politicians! Oh, our mos transistor could be female.
If you interview people on the streets nowadays it's really funny. Once they did an interview in Germany on the streets and asked: "Do you know what a transistor is?" One guy answered: "A guy who used to be a woman?" :'D -lev
Hi Luke
https://fossi-foundation.org/code-of-conduct
this contains incredibly dangerous toxic language that poisons and overshadows peoples' minds. imagine putting that document in front of a six to nine year old, and having to answer questions, "daddy, what are racism and sexism?"
please for god's sake do not poison the libre-silicon effort with the same awful wording. if any such toxic document is added to this project i will cease contributing and interacting with the project and its members immediately and will never, under any circumstances, recommend the project, discuss it with anyone, or help in any way to find funding or other resources for it.
No worries about that. I've already received lots of hatred on Twitter for my ice cold and solid position against virtue signaling new speech from the regressive "left". We will have a variation of the original "code of conflict" of Linus Torvalds before he was blackmailed out of his position as chief maintainer. There's no "color revolution" happening on my watch. -lev
On Thursday, January 24, 2019, David Lanzendörfer < david.lanzendoerfer@o2s.ch> wrote: No worries about that.
I've already received lots of hatred on Twitter for my ice cold and solid position against virtue signaling new speech from the regressive "left".
Fascinating - did you point out to them that their hatred is a violation of the conduct that they seek to uphold? Or that it ISN'T on their list of proscribed behaviours? I would be interested to hear how high the resultant mental mushroom cloud reaches... :)
We will have a variation of the original "code of conflict" of Linus Torvalds before he was blackmailed out of his position as chief maintainer. There's no "color revolution" happening on my watch.
Thank god for that. I have spoken to dozens of people about this. It seems to be that they have a failure of *desire* to comprehend how dangerous these toxic documents are. They will do absolutely any amount of mental avoidance tricks as a way to not face the issue. It is really quite fascinating. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Hi
Fascinating - did you point out to them that their hatred is a violation of the conduct that they seek to uphold? Or that it ISN'T on their list of proscribed behaviours?
I would be interested to hear how high the resultant mental mushroom cloud reaches... :) Usually the debate goes like this: "But you're right now hateful against me an falsely accuse me of 'hating women', which is in no way related to me refusing to use the word 'they' in singular, because it's just grammatically *wrong*."
Then the answer is: No! Hate can only come from white people towards people of different ethnicity! Then I: But that's not only a wrong but also in itself racist definition... Then them: No! Racism can only be from white people towards people of different... Me: Blocks them on Twitter. Sometimes it's also enough to quote Mao. It's fun to observe how wanna-be Marxists deal with an actual Maoist :D
Thank god for that. I have spoken to dozens of people about this. It seems to be that they have a failure of *desire* to comprehend how dangerous these toxic documents are. They will do absolutely any amount of mental avoidance tricks as a way to not face the issue. It is really quite fascinating.
Exactly. Like bill C-16. -lev
Dont talk about "people of color" gender fnord, hate fnord, israeli politics, the trump administration, brexit, illuminati and so on. Dream in verilog and talk tech stuff Cheers Ludwig On Sunday, January 27, 2019, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:
Hi
Fascinating - did you point out to them that their hatred is a violation of the conduct that they seek to uphold? Or that it ISN'T on their list of proscribed behaviours?
I would be interested to hear how high the resultant mental mushroom cloud reaches... :) Usually the debate goes like this: "But you're right now hateful against me an falsely accuse me of 'hating women', which is in no way related to me refusing to use the word 'they' in singular, because it's just grammatically *wrong*."
Then the answer is: No! Hate can only come from white people towards people of different ethnicity!
Then I: But that's not only a wrong but also in itself racist definition...
Then them: No! Racism can only be from white people towards people of different...
Me: Blocks them on Twitter.
Sometimes it's also enough to quote Mao. It's fun to observe how wanna-be Marxists deal with an actual Maoist :D
Thank god for that. I have spoken to dozens of people about this. It seems to be that they have a failure of *desire* to comprehend how dangerous these toxic documents are. They will do absolutely any amount of mental avoidance tricks as a way to not face the issue. It is really quite fascinating.
Exactly. Like bill C-16.
-lev
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Has nothing to do with *people* of color: That's what I ment: -> https://en.wikipedia.org/wiki/Colour_revolution -lev On Sunday, 27 January 2019 2:52:42 PM HKT ludwig jaffe wrote:
Dont talk about "people of color" gender fnord, hate fnord, israeli politics, the trump administration, brexit, illuminati and so on. Dream in verilog and talk tech stuff Cheers
Ludwig
Yeah Lets not talk about fnord the illuminati fnord. Because fnord politics fnord is unproductive and unrelated to getting a transistor to switch. fnord And praise the lizard overlords :D fnord -lev On Sunday, 27 January 2019 2:52:42 PM HKT ludwig jaffe wrote:
Dont talk about "people of color" gender fnord, hate fnord, israeli politics, the trump administration, brexit, illuminati and so on. Dream in verilog and talk tech stuff Cheers
Ludwig
On Thursday, January 24, 2019, Tim Edwards <tim@opencircuitdesign.com> wrote:
Thanks, Luke, for mentioning Alliance. I had forgotten about it, but now
have read this book which has a nice example of using it:
An existance proof for Alliance documentation! Thanks for dredging this up!
Honestly, I have never seen Alliance documentation before. This is more of a tutorial than actual proguram documentation, but it does the job.
Slightly discouraging is the line that the (NERO) router can handle "up to 4K gates".
Autorouters are damn hard, limitations do not surprise me.
Another discouraging line is "Real pads are specific to a foundry and must be designed to fit to those of Alliance".
Foundries above 90nm just do not give out the cell libraries. They just don't. There are cell libraries for 180, 130 and 90nm if you look.
The rate at which I came up with discouraging lines by randomly perusing the document was also discouraging. . .
Contact jp on mailing list, he is very helpful.
-- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Last May we did our 1st LibreSilicon Hackathon to evaluate all the tools and formats, which could be interesting for us. Well, I like to re-post the Outcome here again https://hackmd.c3d2.de/libresilicon The site is in German and should be almost complete. Regards, Hagen Sankowski
On Wed, Jan 23, 2019 at 10:05 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
Last May we did our 1st LibreSilicon Hackathon to evaluate all the tools and formats, which could be interesting for us.
Well, I like to re-post the Outcome here again
https://hackmd.c3d2.de/libresilicon
The site is in German and should be almost complete.
As I have some time to think, I wonder: Has any of you done an actual analog IC design, comprising * (parametric) cell definition * schematic capture * schematic simulation (corners? Monte Carlo??) * layout (schematic driven? manual??) * Layout DRC * LvS * layout parasitic extraction * post layout simulation * streamout (to CIF? to GDS??) with any of these tool chains? In the meantime, I'm trying to get academic local access to Cadence, so that I can separate the task of designing proof-of-concept analog circuits from developing and maturing a tool chain. Gruß aus Berlin tatzelbrumm
Hello Tatzelbrumm! On 1/23/19 10:13 PM, Christoph Maier wrote:
On Wed, Jan 23, 2019 at 10:05 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
Last May we did our 1st LibreSilicon Hackathon to evaluate all the tools and formats, which could be interesting for us.
Well, I like to re-post the Outcome here again
https://hackmd.c3d2.de/libresilicon
The site is in German and should be almost complete.
As I have some time to think, I wonder: Has any of you done an actual analog IC design, comprising * (parametric) cell definition * schematic capture * schematic simulation (corners? Monte Carlo??) * layout (schematic driven? manual??) * Layout DRC * LvS * layout parasitic extraction * post layout simulation * streamout (to CIF? to GDS??) with any of these tool chains?
Nope. You are the Pioneer on the white territory where no one was gone before. As chancellor Merkel would say: You´re are entering "Neuland". :-) On the gEDA tools suite (should be also on the Lepton EDA fork) as well as KiCAD are tools for Schemetic entry, export to Spice3f and simulate with ngspice. Here the Monte Carlo Simulation is involved. On Magic there is a tool which does the task from Layout to Spice3f export. Here should be the Layout Parasitic extraction. And with ngspice again Post Layout Simulation. BTW, should be possible to go from Schematic (in Ascii) to Magic (in Ascii).. be script or hand. Magic has the streamout to CIF and GDS2 - we already did the PearlRiver Testwaver this way. For the whole flow, I guess a lot of tools are missing. Please find your way, ask on the list, hopefully someone here can give you a helping hand or provide a tool. Also to collect all informations, you're figuring out on your way through the analog design flow, somewhere on a Blog, Wiki, or even paper on the list would be great.
In the meantime, I'm trying to get academic local access to Cadence, so that I can separate the task of designing proof-of-concept analog circuits from developing and maturing a tool chain.
Every Journey starts with a small Step. Regards, Hagen.
"BTW, should be possible to go from Schematic (in Ascii) to Magic (in Ascii).. be script or hand. " Here we should make a python script to take a netlist from KiCad or gschem (geda or lepton) ad put it into a layout tool like magic. If we can extract parameters and get a spice netlist, we could do simulation and go from there, and BACKANNOTATE to the schematics tool, so we can use the parasitics also as wanted components. EG one wants to design a low pass filter, he can use the capacity of the base or gate of a transistor, depending on frequency. So lets talk about flow and do it bottom up. So take tools which are there and abuseable for our purposes and then we build glue scripts using a mighty language like python3. Cheers, Ludwig who is in favor of scripting with python3 On Thu, Jan 24, 2019 at 8:07 AM Hagen SANKOWSKI <hsank@posteo.de> wrote:
Hello Tatzelbrumm!
On 1/23/19 10:13 PM, Christoph Maier wrote:
On Wed, Jan 23, 2019 at 10:05 PM Hagen SANKOWSKI <hsank@posteo.de> wrote:
Last May we did our 1st LibreSilicon Hackathon to evaluate all the tools and formats, which could be interesting for us.
Well, I like to re-post the Outcome here again
https://hackmd.c3d2.de/libresilicon
The site is in German and should be almost complete.
As I have some time to think, I wonder: Has any of you done an actual analog IC design, comprising * (parametric) cell definition * schematic capture * schematic simulation (corners? Monte Carlo??) * layout (schematic driven? manual??) * Layout DRC * LvS * layout parasitic extraction * post layout simulation * streamout (to CIF? to GDS??) with any of these tool chains?
Nope. You are the Pioneer on the white territory where no one was gone before. As chancellor Merkel would say: You´re are entering "Neuland". :-)
On the gEDA tools suite (should be also on the Lepton EDA fork) as well as KiCAD are tools for Schemetic entry, export to Spice3f and simulate with ngspice. Here the Monte Carlo Simulation is involved.
On Magic there is a tool which does the task from Layout to Spice3f export. Here should be the Layout Parasitic extraction. And with ngspice again Post Layout Simulation.
BTW, should be possible to go from Schematic (in Ascii) to Magic (in Ascii).. be script or hand.
Magic has the streamout to CIF and GDS2 - we already did the PearlRiver Testwaver this way.
For the whole flow, I guess a lot of tools are missing. Please find your way, ask on the list, hopefully someone here can give you a helping hand or provide a tool. Also to collect all informations, you're figuring out on your way through the analog design flow, somewhere on a Blog, Wiki, or even paper on the list would be great.
In the meantime, I'm trying to get academic local access to Cadence, so that I can separate the task of designing proof-of-concept analog circuits from developing and maturing a tool chain.
Every Journey starts with a small Step.
Regards, Hagen. _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi
Since neither the older C nor the newer Java versions of Electric are being developed, my idea was to fork the C code. That is the one that was actually used commercially for IC design and the one that I had some experience in. I have no idea if there are improvements or bug fixes in the Java version or if it is a simple rewrite. Of the many rewrites I have seen, the only one I ever saw any value in was the change in Spice from Fortran to C as the original code's memory management was just too horrible due to Fortran's limitations. Porting it to a more modern C-dialect, maybe providing C++ interface libraries, might actually be a really neat idea. I'd be in! Lets fork it and begin updating it to modern standards! ^^
About KiCAD, it works great for the PCB sizes we use. But imagine trying to design a printed circuit of 15 meters by 20 meters. What changes would be needed in KiCAD to make this practical? This is what designing integrated circuits is like - the ratio of feature size to project size is four orders of magnitude or more. It's a really good point. I didn't take into account that someone might wanna design a very complicated circuit, which might result in a very large IP core. Maybe we should go for electric...
Can you fork it and push it to GitHub somewhere? Maybe introduce CMake as build system? Then we can get started. Cheers -lev
participants (9)
-
Christoph Maier -
David Lanzendörfer -
Hagen SANKOWSKI -
Jecel Assumpcao Jr. -
ludwig jaffe -
Luke Kenneth Casson Leighton -
Staf Verhaegen -
Tim Edwards -
Éger Ferenc