Standardized Data Structures Lef/Def routines
Hej everybody! Sorry for not joining mumble sessions, I feel a little of on communications, but anyway, hope my question finds some positive echo ;) As I tried to understand project structures of the whole design flow - correct me if I am wrong - each part of the program uses its own file formats or parsers as data structures for macros and layers, from what I skimmed: * Graywolf uses a YACC parser for some file formats (don't know which) * in the qflow repo is some form of lefdef parser using YACC, where I am not sure if it is just for some UI stuff or supposed to be a actual parser * in qroute 20% of the LOCs are for lefdef parsing with a hand written parser I am not sure if there are some more forms of lefdef readers? So my general plan would be to write a more generic router (being more algorithmic agnostic providing a general data structure, to experiment with some routing algorithms, splitting in global and detailed routing and so on). Before dealing with this I would opt to have some common core dealing with lefdef reading and writing. Is there maybe already some tool doing this? In the last week I started going through the lefdef ref manual 5.8 and to manually parse lef files into some c++ structs, see[1] to have a look yourself. From quite some big lef files it already can parse >90% the mayor chunck. Being quite uncommented and not tougth through to much, but before wasting more time on this I wanted to get some feedback. Is the general lefdef-lib thing a idea worth spending more energy on? Is there already another attempt to do so in progress? Thanks for information and feedback! P.S. Is there already something up for the hackathon? Would be definitely up for it ;) Paul [1] https://github.com/paulwuertz/siliconverter
Hi As you can see in the project I've already implemented DEF and LEF parsers using BISON/FLEX. I mainly use them to read DEF and LEF files in order to load the layouts into the layout editor, but the grammar is there. It's a general data structur which also can be used otherwise. A new start for place and route would be pretty cool. Graywolf is full of old baggage (30 year old, unused appendix code) and ugly coding style in some places. I've cleaned it up as good as I was able to, but it still hase some pretty nasty behaviour. And QRouter has some performance issues when it comes to multi threading, I had to implement the multithreading feature myself and it's still buggy. Also maybe you wanna take the problem on in a more robust programming language like Rust or Go? Cheers David On Saturday, 28 April 2018 12:01:08 PM HKT p4w5 wrote:
Hej everybody!
Sorry for not joining mumble sessions, I feel a little of on communications, but anyway, hope my question finds some positive echo ;)
As I tried to understand project structures of the whole design flow - correct me if I am wrong - each part of the program uses its own file formats or parsers as data structures for macros and layers, from what I skimmed:
* Graywolf uses a YACC parser for some file formats (don't know which) * in the qflow repo is some form of lefdef parser using YACC, where I am not sure if it is just for some UI stuff or supposed to be a actual parser * in qroute 20% of the LOCs are for lefdef parsing with a hand written parser
I am not sure if there are some more forms of lefdef readers? So my general plan would be to write a more generic router (being more algorithmic agnostic providing a general data structure, to experiment with some routing algorithms, splitting in global and detailed routing and so on).
Before dealing with this I would opt to have some common core dealing with lefdef reading and writing. Is there maybe already some tool doing this? In the last week I started going through the lefdef ref manual 5.8 and to manually parse lef files into some c++ structs, see[1] to have a look yourself. From quite some big lef files it already can parse >90% the mayor chunck. Being quite uncommented and not tougth through to much, but before wasting more time on this I wanted to get some feedback.
Is the general lefdef-lib thing a idea worth spending more energy on? Is there already another attempt to do so in progress?
Thanks for information and feedback! P.S. Is there already something up for the hackathon? Would be definitely up for it ;) Paul
[1] https://github.com/paulwuertz/siliconverter _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
-- Best regards CEO, David Lanzendörfer Lanceville Technology 22A, Block2, China Phoenix Mansion, No.2008 Shennan Boulevard, Futian District, Shenzhen
My former supervisor sent me a reference from this project[1]. Looks cool, gonna look more deep into it later. Anybody heard of it before? [1] https://github.com/rsyn/rsyn-x On 2018-04-28 20:57, Hagen SANKOWSKI wrote:
Hello David and Paul.
On 04/28/2018 04:54 PM, David Lanzendörfer wrote:
Also maybe you wanna take the problem on in a more robust programming language like Rust or Go? Well, I am not a programmer, but I would vote for Rust. This kills a lot of wrong pointer behavior.
Hagen.
_______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi rsyn-x looks pretty awesome! Maybe we can incorporate some of it into QtFlow? ^^ Cheers David On Thursday, 3 May 2018 11:44:40 PM HKT p4w5 wrote:
My former supervisor sent me a reference from this project[1]. Looks cool, gonna look more deep into it later. Anybody heard of it before?
Hej David, since you said we could reuse the LEFDEF modules from qtrouter I would propose making them a git submodule in qtrouter and a separate repo for the lefdef (and potentially then also the GDSII and maybe some more modules). If you agree I would replace the QString, QVector... with std:: elements and work for a merge with new bindings for this repos, so that the qtrouter is a little slimmer and we have seperate issues for this project parts and make them more reusable. Greetings, Paul On 2018-05-03 21:25, David Lanzendörfer wrote:
Hi rsyn-x looks pretty awesome! Maybe we can incorporate some of it into QtFlow? ^^
Cheers David
On Thursday, 3 May 2018 11:44:40 PM HKT p4w5 wrote:
My former supervisor sent me a reference from this project[1]. Looks cool, gonna look more deep into it later. Anybody heard of it before?
Hi Paul Yeah! Super idea! Go ahead and fork and then make a pull request! I'm looking forward to a better modularity. Cheers David On Wednesday, 9 May 2018 11:30:07 PM HKT p4w5 wrote:
Hej David, since you said we could reuse the LEFDEF modules from qtrouter I would propose making them a git submodule in qtrouter and a separate repo for the lefdef (and potentially then also the GDSII and maybe some more modules). If you agree I would replace the QString, QVector... with std:: elements and work for a merge with new bindings for this repos, so that the qtrouter is a little slimmer and we have seperate issues for this project parts and make them more reusable.
Greetings, Paul
On 2018-05-03 21:25, David Lanzendörfer wrote:
Hi rsyn-x looks pretty awesome! Maybe we can incorporate some of it into QtFlow? ^^
Cheers
David
On Thursday, 3 May 2018 11:44:40 PM HKT p4w5 wrote:
My former supervisor sent me a reference from this project[1]. Looks cool, gonna look more deep into it later. Anybody heard of it before?
-- Best regards CEO, David Lanzendörfer Lanceville Technology 22A, Block2, China Phoenix Mansion, No.2008 Shennan Boulevard, Futian District, Shenzhen
Hi Paul What's the status of your modularization attempt? Do you have a GitRepo somewhere? Maybe I can help! Cheers David
since you said we could reuse the LEFDEF modules from qtrouter I would propose making them a git submodule in qtrouter and a separate repo for the lefdef (and potentially then also the GDSII and maybe some more modules). If you agree I would replace the QString, QVector... with std:: elements and work for a merge with new bindings for this repos, so that the qtrouter is a little slimmer and we have seperate issues for this project parts and make them more reusable.
participants (3)
-
David Lanzendörfer -
Hagen SANKOWSKI -
p4w5