<litghost>
hackerfoo: So I wouldn't use it as a reference
<litghost>
hackerfoo: Can I list multiple FASM features? -> Yes, but I'm not sure when that is valid
<litghost>
hackerfoo: Can you explain what you are trying to do with "BDI1MUX.DI ADI1MUX.BDI1"?
<litghost>
hackerfoo: Because I'm pretty sure it's wrong
<hackerfoo>
I'm trying to flatten two chained muxes into one, since I don't think VTR supports chaining things together.
<hackerfoo>
I understand why they have this limitation, to prevent combinatorial explosion in the interconnect.
<hackerfoo>
My current approach is to just see if this works for now, and then add support for parallel muxes to VTR later.
<litghost>
hackerfoo: Cascaded muxes do work, you just cannot connect them directly, you need to pass through an intermediate pb_type
<hackerfoo>
If muxes could switch multiple signals in parallel, I could properly flatten the two muxes into a single parallel one.
<litghost>
hackerfoo: Why do you need to mux multiple singles at all?
<litghost>
hackerfoo: The underlying structure in this case is always N to 1 muxes
<litghost>
signals*
<hackerfoo>
But then the connection information would be lost, right? You'd have to explicitly instantiate the intermediate pb_type, so VPR could no longer make that decision by itself.
<litghost>
hackerfoo: Can you make a diagram? I don't think I get what you are trying to model
<litghost>
hackerfoo: I believe you are trying to model the fact that the ADI1MUX uses the output of the BDI1MUX
<litghost>
hackerfoo: The solution is for the output of the BDI1MUX to go through the B LUT-RAM intermediate, and then connect to the ADI1MUX
<litghost>
hackerfoo: This is what the PARENT_DI stuff was about
<hackerfoo>
Yeah, give me a minute.
<hackerfoo>
I want to allow VPR to make the decision, instead of forcing it.
<litghost>
hackerfoo: There is no forcing? You are still just modelling the BDI1MUX and the ADI1MUX, yes?
<mithro>
litghost: So, I'm now generating an arch.xml with v2x which includes the pb_type.xml / model.xml -- what would be the best way to run vpr on it to test the arch.xml is valid?
<hackerfoo>
Rather than saying, for instance, DI goes to D_DRAM.DI and B_DRAM.DI when they implement a dual port RAM, I want VPR to see that they share an input, and route it through DI, setting BDI1MUX.DI
<litghost>
mithro: Simplest test? PnR a wire
<hackerfoo>
This should work fine, since there's only one mux.
<hackerfoo>
But I want it to work the same for the lower half.
<mithro>
litghost: Yes, but how do I do that in the cmake?
<litghost>
mithro: Same way you write any test that PnR's, use add_fpga_target
<litghost>
hackerfoo: I think you would agree that the CDI1MUX and BDI1MUX can be modelling with simply a <mux> interconnect block, yes?
<litghost>
modelled*
<hackerfoo>
The problem with the flattened mux is if VPR wants A_DRAM.DI to connect to DI amd B_DRAM.DI to BI, that would be invalid, but VPR won't know that.
<hackerfoo>
Yes.
<litghost>
hackerfoo: Don't use the flattened mux?
<litghost>
hackerfoo: Have ADI1MUX mux ADI1 and the output of the BDI1MUX
<litghost>
hackerfoo: In order to use the output of the BDI1MUX, you have to pass it through an intermediate pb_type, but that's fine
<hackerfoo>
But then, how does VPR know when to get A_DRAM.DI from BDIMUX? The previous solution was to force it with the modes, which worked except in 32 bit mode.
<litghost>
hackerfoo: Just re-write the mux without the modes
<litghost>
hackerfoo: The previous implementation was based on a bad understanding of the underlying hardware
<hackerfoo>
There's a bunch of ways to do it that *almost* work.
<hackerfoo>
But since the tutorial uses the flattening approach, I'm guessing that that way is the least broken, so I'm just going to try it.
<litghost>
hackerfoo: The tutorial is wrong
<litghost>
hackerfoo: Ignore the tutorial
<litghost>
hackerfoo: It is modelling something like a v6
<hackerfoo>
I don't have a better solution.
<hackerfoo>
v6 has the same arrangement.
<litghost>
hackerfoo: But that tutorial isn't actually designed to run on hardware
<litghost>
hackerfoo: So it can add flying elphanets and still be a valid tutorial
<hackerfoo>
Maybe I should ask on #vtr?
<litghost>
hackerfoo: It isn't actually a model of the real hardware
<hackerfoo>
If their own example doesn't work, we should let them know, at least.
<litghost>
hackerfoo: Their example works fine, but it isn't actually modelling a real piece of silicon
<litghost>
hackerfoo: It is modelling a fictous similiar piece of hardware
<litghost>
hackerfoo: You have to understand, VTR was never design to operate on real hardware
<litghost>
hackerfoo: It is a research tool for hypothetical FPGA's
<hackerfoo>
In order to demonstrate the expressiveness of the architecture description language, we use it to describe a section of a commercial logic block. In this example, we describe the Xilinx Virtex-6 FPGA logic slice [Xilinx Inc12], shown in Fig. 40, as follows:
<litghost>
hackerfoo: And what does the title say: "Virtex 6 like"
<litghost>
hackerfoo: Their model does not accurately represent the ADI1MUX behavior
<litghost>
hackerfoo: And it should be obvious that is the case!
<litghost>
hackerfoo: Their description of the SLICEM can output something the hardware cannot model, therefore it is wrong, period
<litghost>
hackerfoo: As a concrete example, their model does not correctly model that the D LUT-RAM must be enabled for the C/B/A LUT-RAM's to be used
<hackerfoo>
Anyway, I could fix it if it weren't for this:
<litghost>
hackerfoo: The middle mux isn't legal and the bottom mux is wrong if the mux selector isn't the same
<litghost>
hackerfoo: The top mux should be able to be modelled, so I don't know what the problem is
<hackerfoo>
Yes, I know, hence the question about linking muxes.
<hackerfoo>
With real muxes, you'd just tie the selection lines together.
<litghost>
hackerfoo: VPR doesn't support that idea
<hackerfoo>
Don't we work on VPR, though? Does it support any form of constraints other than modes?
<hackerfoo>
Anyway, the architecture definition was already wrong, so I'm just going to see if I can make it almost correct for now, and see if it works.
<litghost>
hackerfoo: As I stated earlier, you are more than welcome to start on a PR for linked muxes or muxes of bus's
<hackerfoo>
Then I can add what I need to VPR later.
<hackerfoo>
litghost: Okay. Thanks.
<litghost>
hackerfoo: I believe what was there before could never get into trouble because the techmap output a configuration that was always valid
<litghost>
hackerfoo: It consumed the BI1 pin when it didn't need too, but wasn't invalid on hardware
<litghost>
hackerfoo: I'm ignoring the RAM32 of course
Bertl is now known as Bertl_oO
acomodi has quit [Quit: Connection closed for inactivity]
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #symbiflow
hzeller has joined #symbiflow
kraiskil has quit [Ping timeout: 258 seconds]
<litghost>
hackerfoo: kem_ is active on #vtr-dev if you want to poke him about the mux stuff
<hackerfoo>
Okay. I didn't want to bother -dev with a user question, but #vtr is pretty quiet.
<hackerfoo>
There's no ADIMUX.BDI1 fasm feature? It's not listed in the documentation.
<litghost>
hackerfoo: There is not. The absence of ADI1MUX.ADI1 is either BDI1 or MC31
<litghost>
hackerfoo: Presumably MC31 is controlled via the SRL bit
<litghost>
hackerfoo: But we don't have evidence of that at this minute
<hackerfoo>
Then I guess we don't need to worry about the chained mux problem right now, since we can't configure them that way yet.
<litghost>
hackerfoo: That doesn't follow?
<litghost>
ADI1 can be either AX, BX, or DX, yes?
<litghost>
ADI1 can only come BX if BDI1 = BX
<litghost>
and ADI1 can only become DX if BDI1 = DX
<litghost>
Am I missing something?
<hackerfoo>
No, ADIMUX selects AI, BDI1, and BMC31.
<hackerfoo>
So this is also probably why RAM128X1D doesn't (didn't?) work.
<hackerfoo>
Until we figure that bit out, RAM128X1D and RAM256X1S will have to use AI.
<litghost>
hackerfoo: I wasn't talking about ADIMUX, I was talking about the effective ADI1 connection, which can be either AX, BX or DX
<litghost>
hackerfoo: s/X/I/
<hackerfoo>
Oh, okay. I get it. Currently, ADI1MUX.AI = 0 ==> BDI1?
<litghost>
hackerfoo: We probably want common D lines, and in an ideal world would check the state of the DI muxes to verify the "right" thing happened
<hackerfoo>
Why? Internally all the dual port and >64 modes use shared DI.
<hackerfoo>
I'm interested in how RAM1X32S works when using O5.
<hackerfoo>
It would have to connect CX/DX externally, I think.
<litghost>
e.g. two instances of RAM64X1D can either share or have different D lines
<litghost>
If the D lines are common, then all of the xDI1MUX's should use the DI site pin
<hackerfoo>
If they work independently, they should work shared. Primitives should be independent.
<litghost>
Not true
<litghost>
Have vivado pack two RAM64X1D's with common D lines, but different INIT's
<litghost>
The DI line will be the only site pin, BI will not be used
<litghost>
For clarify, when I say DI, I mean the SLICEM.DI site pin
<hackerfoo>
I see. You want to make sure VPR takes advantage of the internal muxes even across primitives.
<litghost>
Yes
<litghost>
It actually causes some errors in fasm2v if we don't
<litghost>
because Vivado will take advatange, even if VPR didn't
proteusguy has quit [Ping timeout: 255 seconds]
<litghost>
And I don't think we can control it
<mithro>
litghost: I have some comments around the implicit dff stuff, will try and comment a bit later tonigh
<litghost>
mithro: k
<litghost>
mithro: I'm interested how you are planning to solve things like FASM tagging implicitly. I'm not sure you can
<hackerfoo>
Apparently, if you list FASM features separated by spaces, they just get concatenated.
<litghost>
hackerfoo: We generally eat whitespace
<litghost>
hackerfoo: In this case, it prevented a natural extension
<mithro>
How do you do the equivalent of "basename" in cmake?
<litghost>
get_filename_component
<litghost>
hackerfoo: I would be open to <pin> : <feature>, <feature>
<litghost>
which would allow for <pin>:<feature>=2,<feature> ,etc
<litghost>
hackerfoo: And wouldn't require a large extension to the VPR FASM parser (which is brick stupid)
<mithro>
litghost: What about "basename xyz.xml .xml" ? (IE strip extensions?)
<litghost>
mithro: Same, still get_filename_component
<litghost>
mithro: It's overloaded
<hackerfoo>
litghost: Whatever works. I don't think writing architecture descriptions in XML is ever going to be pleasant. Luckily, it shouldn't be a common task.
<litghost>
hackerfoo: The good news is v2x in theory is replacing right these XML's by hand, and I think that will be more extensible than this
<hackerfoo>
I don't mind verbosity, but I don't like how VPR just seems to take reasonable-looking stuff and do unexpected things with it without complaining.
<hackerfoo>
"X = Y\n X = Z\n" doesn't work either. No error, though.
<litghost>
hackerfoo: Not sure what you mean? Anything in the metadata tags is our code, so don't blame VPR for that
<litghost>
hackerfoo: genfasm is seperate from the rest of VPR, but we need their internal data structures for now
<litghost>
hackerfoo: It's possible with the work that duck2 is doing, we can just parse the VPR outputs without libvpr, but that isn't something on the main line
<hackerfoo>
Wow, that really is a simple parser. It just splits on = and :, and expects two items.
<hackerfoo>
Oh well, I don't need that now.
<litghost>
hackerfoo: I did say it was dumb as bricks
<hackerfoo>
The surprising part is that it eats spaces. I figured if it didn't fail, it would work.
<litghost>
hackerfoo: The eating of spaces is intentional, but it probably shouldn't eat interior spaces
<hackerfoo>
The same thing for repeated inputs, where it only uses the first one.
<litghost>
hackerfoo: But it is important to do something like python's "str.strip()" to avoid leading and trailing white space
<hackerfoo>
Something like http://re2c.org or a hand-rolled tokenizer would take care of that.
<litghost>
hackerfoo: We do like inside VPR, and so new dependencies are not really good ideas. Fixing the space issue with a parse doesn't actually solve the "using only the first mux entry", which is probably just a bug
<hackerfoo>
The cool thing about re2c is that it doesn't add dependencies, it generates C from regular expressions. I haven't tried it yet, though.
<hackerfoo>
But it's probably overkill for this.
<litghost>
hackerfoo: There is a pass of FASM error check that is probably worth doing. Something like lint_fasm, that would check for fasm_mux issues like this
<litghost>
hackerfoo: For example, there should be a fasm_mux for each input to the mux
<litghost>
hackerfoo: And no entries for non-existent inputs
<litghost>
hackerfoo: etc etc
<hackerfoo>
From looking at output_fasm_mux, I bet it doesn't handle FOO[0].BAR[1]