citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
_whitelogger has joined #symbiflow
Maya-sama has joined #symbiflow
Miyu has quit [Ping timeout: 245 seconds]
OmniMancer has joined #symbiflow
proteusguy has joined #symbiflow
kraiskil has joined #symbiflow
_whitelogger has joined #symbiflow
kraiskil has quit [Ping timeout: 245 seconds]
kraiskil has joined #symbiflow
Maya-sama is now known as Miyu
kraiskil has quit [Ping timeout: 255 seconds]
kraiskil has joined #symbiflow
citypw has quit [Ping timeout: 244 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
proteusguy has quit [Remote host closed the connection]
citypw has joined #symbiflow
ayumis13 has joined #symbiflow
ayumis13 has quit [Ping timeout: 256 seconds]
Bertl_zZ is now known as Bertl
OmniMancer has quit [Quit: Leaving.]
hzeller has joined #symbiflow
proteusguy has joined #symbiflow
<sf-slack>
<mkurc> elms: FYI regarding the `scalable_proc` test design: It can be implemented on ICE40 arch directly provided that you use the BRAM mode. In the BRAM mode the data is stored in an initialized Verilog array. There is also a DRAM mode in which the data is stored in explicitly instantiated Xilinx DRAMs.
proteusguy has quit [Ping timeout: 245 seconds]
<sf-slack>
<mkurc> Status update: I am implementing a generic tile grid coordinate mapping to be used later for splitting CLBs into SLICEs. For now it will handle just arbitrary tile relocation without splitting etc.
hzeller has quit [Ping timeout: 250 seconds]
<sf-slack>
<kgugala> @mithro I checked the git-blame-ignore-revs and to add it we actually need to commit the formatting results
hzeller has joined #symbiflow
<sf-slack>
<kgugala> (we need to put formatting result hash into ignore file)
<tpb>
Title: Add format target for source code formatting by kgugala · Pull Request #2 · kmurray/libblifparse · GitHub (at github.com)
<sf-slack>
<kgugala> or maybe we'll wait for kem_ to merge the format target, run and commit formatting and then add ignore
<sf-slack>
<kgugala> ?
<sf-slack>
<acomodi> Hi everyone. I have started again the approach on the equivalent tiles as I think I was taking a wrong direction. Right now I have been able to change the XML architecture parsing and moved the top level pb_type only features and properties to the `tiles`. CI will fail because all the XML archs in `vtr_flow/archs` do not have a `tiles` top level tag. Here's the updated PR:
<sf-slack>
<acomodi> litghost, mithro: I am planning to use the same data structure present in VTR right now (probably I'll rename it) to represent the tile (currently it is the `t_type_descriptor`). This struct has everything the tile needs and it previously stored the top level pb_type information.
<hackerfoo>
I (seriously) enjoy reading well-written hardware documentation. I wish software documentation was more like it.
<duck2>
a good point. i sometimes procrastinate reading microcontroller datasheets, but not man pages or readthedocs. perhaps it's related to the difference between hw and sw projects
<hackerfoo>
man pages are good, but I don't like auto generated API docs. But with hardware documentation, I often learn something beyond what I need to solve my immediate problem.
<hackerfoo>
Especially with TI's documentation.
kraiskil has joined #symbiflow
<elms>
hackerfoo: What exactly are you reading?
<elms>
There is definitely an art to good datasheets and app notes. But the variance is large in my experience.
<hackerfoo>
Just the Xilinx 7-series stuff right now, but it reminded me how much I prefer datasheets over software documentation, if nothing else just for the pictures to break up the text.
<elms>
Just listened to an amp hour podcast with Adam McCombs and they discuss that one vendor has amazing databooks on their SEM but most other manufactures are barely existent.
<elms>
Agree. Having a human in the loop helps with readability. Some software APIs are generated and no one ever thinks to look at them.
<tpb>
Title: VPR Data Structure IO serializer library - Google Docs (at docs.google.com)
<mithro>
duck2: That is what I was thinking...
<duck2>
looking at it now
<mithro>
duck2: Still could be a terrible idea :-P
<elms>
litghost: Is it correct to think that configuration of non-routing features are essentially decided during the place step in VPR?
<elms>
Maybe I start with asking if there is a one-to-one relationship with features and particular steps in pack-place-route?
<litghost>
elms: non-routing features (e.g. within site) are decided during *pack*
<litghost>
elms: And yes, there is a 1-to-1 relationship. non-routing features are determined soley during pack, and routing features are determined during route
<elms>
litghost: and then in place they are associated with specific sites?
<litghost>
elms: place determins where the clusters are located within the grid
<litghost>
elms: So place does change where in the grid the cluster goes, but the particular features are constant
<elms>
how is that different from what I said. I think I'm missing a subtle detail
<litghost>
elms: I believe I'm agreeing with you?
<elms>
ok just making sure. Thanks
<duck2>
mithro: i was thinking about making an XML parser generator for the arch file(ideas/#4), and complete flatbuffers support for rr_graph while revisiting its data structures(edge metadata is stored in a map from pair to string :O)
<duck2>
i think you propose a generic serializer/deserializer? so that the libraries can be used from within symbiflow-arch-defs
<mithro>
duck2: I'm less concerned with reusing the libraries in symbiflow-arch-defs and more with have very efficient implementations for getting the data in and out of vpr in different file formats...
<duck2>
should the serializer/deserializer work with all the formats in the Required formats section?
<mithro>
duck2: That would be the plan
<mithro>
duck2: Ones in bold are the most important
<tpb>
Title: [WIP] synth_xilinx to now infer SRL16E/SRLC32E by eddiehung · Pull Request #914 · YosysHQ/yosys · GitHub (at github.com)
<duck2>
so a generic schema file defines the data structures, then we generate readers/writers for all required formats and also stubs for the internal data structures. then vpr implements the data structures.
<duck2>
just to get it right, for example, should the arch file then support XML, JSON, ASCII... formats via flags? or is it the responsibility of the build process to tell the generator to make only the XML reader/writer for it, since the arch file is known as an XML file?
<mithro>
duck2: vpr should support all the file formats and just choose the right one?
<duck2>
depending on the file. like gimp. i see. but why should vpr support all XML, JSON, flatbuffers formats for an arch file? debugging? ease of generation by other programs? ease of handwriting?
<mithro>
duck2: Well, it needs human readable ASCII for debugging, XML for compatibility and a more efficient binary format for speed
Bertl is now known as Bertl_zZ
<duck2>
i see. i think a such library would be a little too generic. the project will be a library which takes a schema and generates readers/writers for many file formats. then it would be integrated into vpr. in my opinion, a specialized solution would be better: top.net, route and place files are small and work reasonably well. the arch file is also wor
<duck2>
king but lacks extensibility. that can be fixed by using a schema-generated reader/writer. but the problem with rr_graph is different: an XML rr_graph is inflated(1gb rr_graph gzips to 52mb) and the format needs to be tuned for speed&memory usage.
<mithro>
duck2: For larger designs the .net and .route files can get into the gigabyte sizes too
<mithro>
The packed .net format also makes my brain hurt every time I try and read it :-P
<mithro>
duck2: I agree that the rr_graph file is the most important as it is 10x to 100x the size of the other files at the moment
<duck2>
a mmapped format makes sense for rr_graph. it also removes the need for streamed reading. but making it isn't straightforward. for instance the current rr_graph reader doesn't read segment ids for nodes before indexing the node data. i think it would be a huge improvement too.
<duck2>
all in all, i think improvements for the file formats could be done without writing a generic parser generator. custom binary formats for net, place, route and rr_graph can be created and utilities to inspect and edit them or convert them to readable format&back can be made.
<duck2>
this also saves us the trouble of deciding what an abstract schema element means in XML, in JSON, in ASCII... and much debugging effort to see if the _generated_ readers&writers produce expected results while, say, converting xml->ascii->xml
<hzeller>
+1. I think focusing on some new binary representation first is good and then focus on the readable and legacy formats be generated to/from this. The binary format probably needs to have some sort of stable API to get the data in/out and it can then have its own private binary representation.
<hackerfoo>
You should be able to use the same approach to ensure compatibility, and it's probably safe to assume little endian architectures and just add static asserts to deal with big endian when needed.
<hzeller>
the endianness then can be fixed at distribution time, making a specific format relevant for one platform. Or the mmap()ed version is platform indpendent with e.g. flatbuffers. Or it can be read with ntohl() etc. I'd not worry about endianness in the first iteration.
<hackerfoo>
If you can avoid any conversions, then you don't have to copy, which means you can just mmap read-only and let the OS swap in and out as needed. This means you should be able to work with much more than will fit in RAM, without having to implement some sort of custom paging scheme.
<hackerfoo>
I haven't tried this yet, but it should work in theory.
<hzeller>
yes, this is the idea. I've applied this technique to very fast large read-only data in the past.
<duck2>
does the flatbuffers reader mmap to a struct ptr currently? or would i have to reinvent that?
<litghost>
duck2: flatbuffers can operate on mmap, but it does require using the library to access the data
<litghost>
duck2: It does some straight forward pointer chasing in the form of offsets
<mithro>
I think we have decent evidence that the cost of loading a rr_graph file from disk verses programmatically generating it in memory could be important for performance
<mithro>
memory bandwidth >>>> disk bandwidth
<duck2>
it's one thing i don't understand in vpr: if it can make a rr_graph itself, why is there a rr_graph file? and vice versa
<duck2>
sorry if sounds stupid :D
<mithro>
duck2: The rr_graph that vpr can generate doesn't exactly match real world hardware
<mithro>
duck2: It's an approximation that is close enough for doing research, but doesn't really work that well for real devices
<mithro>
duck2: Allowing vpr to be provided a prebuilt rr_graph allows it to be used for any arbitrary routing fabric
<mithro>
duck2: Make sense?
<mithro>
elms: Great work on getting the formatting / testing stuff for arch defs going again!
<duck2>
i see. then we cannot generate a rr_graph in memory if it's supplied as a file. i thought you suggested part of the graph can be generated in memory after getting some information from the disk.
<mithro>
duck2: We need to always support loading an arbitrary rr_graph
<mithro>
duck2: But a potentially new file format could allow us to describe the rr_graph using a bunch of parameters and generate it in memory
<elms>
mithro: Thanks. Going to try and chip away at stuff like that. Maybe one or two more next week. Plan finish up adding more tests around the rr_graph python code.
<duck2>
mithro: i think that can be a project on its own
<duck2>
i'm updating my draft-draft to roughly this: schema-generated parser for arch.xml, flatbuffers/custom binary for rest of file formats