Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #symbiflow
kraiskil has joined #symbiflow
QDX45 has quit [Ping timeout: 256 seconds]
smkz has quit [Quit: smkz]
smkz has joined #symbiflow
kraiskil has quit [Ping timeout: 260 seconds]
craigo has quit [Ping timeout: 245 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
citypw has quit [Ping timeout: 268 seconds]
citypw has joined #symbiflow
citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
kgugala has quit [Ping timeout: 246 seconds]
gromero has joined #symbiflow
gromero_ has quit [Ping timeout: 272 seconds]
<lambda>
I must be doing something wrong, because while my microcontroller works almost perfectly, a test design that simply loops the arty's switch inputs back to the LEDs is completely broken
<sf-slack4>
<kgugala> do you have the desing published anywhere?
<sf-slack4>
<kgugala> with makefiles (and possibly with build output)
<litghost>
I think plumbing this feature from ABC9 up to yosys seems like a good feature to add in the general case, and once that feature is available, we can update the CARRY4_VPR annotation with the right attribute
<sf-slack4>
<kgugala> @lambda I see you're feeding yosys directly with rtlil - TBH I never tested the flow with this
<sf-slack4>
<kgugala> not sure if xdc plugin works with that one
<sf-slack4>
<kgugala> you can try providing sdc directly to VPR
<litghost>
XDC pluging should work as expect, because it operates directly on the RTLIL representation
<litghost>
If it doesn't work, we should probably add a test and fix it, because there should be no differences to the plugin if different frontends are used
<sf-slack4>
<kgugala> mhm
<sf-slack4>
<kgugala> it seems it does work - I see LOCs in eblif
kgugala has quit [*.net *.split]
epony has quit [*.net *.split]
microcolonel has quit [*.net *.split]
m_hackerfoo has quit [*.net *.split]
HackerFoo has quit [*.net *.split]
yeti has quit [*.net *.split]
Tokamak has joined #symbiflow
HackerFoo has joined #symbiflow
kgugala has joined #symbiflow
yeti has joined #symbiflow
microcolonel has joined #symbiflow
m_hackerfoo has joined #symbiflow
<_whitenotifier-5>
[symbiflow-arch-defs] litghost opened issue #2068: Once yosys supports "look, don't touch" add annotation to CARRY4_VPR - https://git.io/JqvYI
<lambda>
kgugala: the sources for my actual bigger design contain vhdl, which I can't just feed to symbiflow_synth, so I bundle them all together in a separate yosys run, export the ilang and pass that to synth
<lambda>
though I agree it'd be very surprising if yosys cared about the input file format
<lambda>
kgugala: do you have an arty to confirm that (1) the bitstream you built works and (2) my bitstream doesn't? alternatively, could you send me your bitstream so I can try to test (1)?
<litghost>
lambda: Couple things
<litghost>
lambda: Did you check the timing analysis from VPR?
<sf-slack4>
<kgugala> @litghost this is a simple design connecting inputs to outputs
<lambda>
yeah, there aren't even any clocks
<sf-slack4>
<kgugala> I don't think timings are any problem here
<litghost>
Ah, ya that should work fine
<litghost>
As a sanity check, take a look at the blif and make sure you I/OBUFs are on the right sites
<litghost>
Either way, given that this is just a wire design, use xc fasm2bels to run bitstream back into Vivado (or just the verilog) and make sure things look right
<litghost>
Given that it is a wire design, just looking at the fasm2bels output verilog should be enough to debug if something is grossly wrong
<lambda>
will do
<litghost>
The recommended path here is to use the bitstream to generate the FASM and then run that FASM back into verilog and/or FPGA interchange
<litghost>
Both outputs from fasm2bels can be feed into Vivado for simulation and/or timing analysis as needed
<litghost>
The FPGA interchange outputs are generally faster, but the verilog outputs are easier to hand verify
<lambda>
what can I use for bit->fasm conversion?
<sf-slack4>
<kgugala> fasm2bels can eat bit file
<litghost>
Right
<sf-slack4>
<kgugala> you just need to point it to bitread binary
<sf-slack4>
<kgugala> bitread is a part of prjxray
<sf-slack4>
<kgugala> @litghost @lambda there is sth wrong with the bistream
<sf-slack4>
<kgugala> I ran it throgh fasm2bels
<sf-slack4>
<kgugala> and only switches[0] landed where it should
kraiskil has joined #symbiflow
<sf-slack4>
<kgugala> switches[1] is constrained to C11 which should place it in LIOB33_X0Y123, but it landed in LIOB33_X0Y25
<sf-slack4>
<kgugala> sorry, it landed in LIOB33_X0Y75 (still incorrect)
<lambda>
constraints.place contains this line for it: `switches[1] 2 28 0 # set_property LOC C11 [get_ports {switches[1]}]`
craigo has quit [Quit: Leaving]
<litghost>
kgugala/lambda: If I were to guess, this is a package mismatch?
<lambda>
very possible
<litghost>
kgugala/lambda: If the wrong package data is used, then the package pin -> site map will be wrong
<sf-slack4>
<kgugala> yep, that is my first guess
<sf-slack4>
<kgugala> @lambda, can you check if the package is correct?
<lambda>
chip is XC7A35T/CSG324, which I assume corresponds to PART=xc7a35tcsg324-1
<cr1901_modern>
Does the testarch come w/ any tests I can run (for just playing around)?
<litghost>
In arch-defs?
<cr1901_modern>
Yes
<litghost>
Ya, it just runs some really simple P&R tasks
<litghost>
The GH actions CI runs them
<litghost>
One second
<cr1901_modern>
I'd like some targets for ninja
<cr1901_modern>
define_arch is a little less overwhelming for the testarch
<litghost>
6-rot_dummy_testarch_4x4_dummy_route I think would work?
<litghost>
ninja has bash completion, so try "ninja 6-rot_dummy_testarch_4x4_dummy<TAB>"
<cr1901_modern>
Interesting... it doesn't on my machine
<cr1901_modern>
Ahhh that's because I built it from source and never added the file
<cr1901_modern>
to my .bashrc
<litghost>
Ya "6-rot_dummy_testarch_4x4_dummy_route" will work
<cr1901_modern>
Awesome
<cr1901_modern>
"6-rot_dummy_testarch_4x4_dummy" by itself claims "no work to do", but the "_route" suffix works
<cr1901_modern>
I recently completed a nextpnr backend for machxo2. Moving on to symbiflow... I have a decent chunk of the CMakeLists.txt set up, but I'm still learning
<cr1901_modern>
things such as "why does yosys need to be invoked w/ special tcl scripts"?
<litghost>
VPR does need a little more hand holding than nextpnr, and some of that lives in the tcl scripts
<litghost>
It really depends on the complexity of the arch
<lambda>
kgugala: C11 should be IOB_X0Y124, right?
<lambda>
alright, that seems to match up with my arch-defs pinmap.csv, as long as x=2,y=28 is also correct (can't find those kind of coordinates anywhere else)
<litghost>
The pinmap.csv is per part, and is a translation of the prjxray-db file
<litghost>
So should be right, unless something terrible has happened with the build system
<lambda>
I wonder where it goes wrong then, XDC contains C11, .ioplace contains x=2,y=28 which should be equivalent, but then the bitstream/fasm contains something else
<lambda>
oh, test.place has x=2,y=79 for some reason
<lambda>
vpr bug I guess, it's just ignoring the constraints and making up its own placement
<litghost>
Are you regenerating the place file after you create the placement?
<litghost>
*packing
<litghost>
Question, are you using the wrapper scripts?
<litghost>
So you are just doing symbiflow_pack then symbiflow_place?
<lambda>
yes
<litghost>
In that file, I don't see the pack or place result?
<litghost>
Which VPR are you using?
<litghost>
conda or local build?
<lambda>
ah damn, they got eaten by make, sec
<lambda>
local build
<lambda>
8.1.0-dev+4acad0fb5-dirty
<litghost>
If you use the VPR from conda, does it work as expected?
<lambda>
I haven't been able to get conda to work
<cr1901_modern>
litghost: Thanks for the info. Follow-up... why is BLIF required, and backends that emit BLIF for VPR require special options. Do you understand what they are for?
* cr1901_modern
is not all that familiar w/ BLIF as opposed to the JSON output format
<litghost>
VPR uses BLIF as it's input format, that's all
<cr1901_modern>
And unless certain options are passed, VPR will choke on yosys' output BLIF?
<litghost>
eblif adds some quality of life features, specifically around parameters on sub-circuits
<litghost>
But it is worth noting that the ice40 VPR backend hasn't been actively developed in a long while
<litghost>
We run the tests to make sure it hasn't exploded, but I don't believe it has been tested on hardware in months/years
<cr1901_modern>
Hmm, I might get rid of the distinction between vpr and not-vpr mode at some point
<litghost>
Ya, it's not clear at this point why it's there
<cr1901_modern>
I legitimately did it because the ECP5 backend did it
<cr1901_modern>
Anyways, all those options are non-standard according to yosys help
<cr1901_modern>
anyways, for the record, "-conn" means "do not generate buffers for connected wires. instead use the non-standard .conn statement."
<cr1901_modern>
Idk enough about BLIF yet to understand what that means; the tcl scripts in symbiflow don't use it
<litghost>
We don't use that for the xc7 VPR flow
<litghost>
Instead we ask VPR to absorb LUT buffers
<litghost>
We have had bugs around absorbing of LUT buffers in the past, so I could see that being a thing years ago
<litghost>
But we rely on it in the current flows
<cr1901_modern>
absorb? You mean "turn a 01010101010101... etc LUT into a straight-through connection"?
<litghost>
No
<litghost>
Whenver a net is renamed (e.g. cross a module boundry) it gets a simple 1 input LUT declaration
<litghost>
One second I'll find an example
<gatecat>
I think VPR mode only makes sense for iCE40 where there are hypothetically two blif consuming flows - arachne and vpr - even if neither flow is actively used
<gatecat>
For everything else blif essentially implies vpr
<cr1901_modern>
Okay, cool. Does conv stand for "convert" (bikeshed)?
<cr1901_modern>
synth for "synthesis"
<litghost>
Yep
<cr1901_modern>
Ahh I see, so the flow is "synthesize normally w/ VPR-specific tailoring to JSON", "operate on the JSON as needed" (the I/O buffers), then "convert the JSON to BLIF".
<litghost>
That is the current flow
<cr1901_modern>
(Where is utils.tcl imported?)
<litghost>
Not idea, but it does work
<litghost>
ideal*
<cr1901_modern>
Not ideal is fine. I just need to understand it :P
sf-slack4 has quit [*.net *.split]
rejser has quit [*.net *.split]
daf1 has quit [*.net *.split]
rejser has joined #symbiflow
daf1 has joined #symbiflow
sf-slack4 has joined #symbiflow
<cr1901_modern>
AFAICT, the CMake test targets don't actually use the symbiflow_synth script, but use define_arch() to call the relevant scripts directly?
<litghost>
So the CMake system pre-exists the scripts
<litghost>
One of the cleanup steps that is being doing will be to change the scripts to be arch indepedent, and to use them in the CMake invocation
<cr1901_modern>
litghost: Thanks for the help. I think that's all the qs I have immediately. Talking to someone was immensely helpful compared to trying to figure it out on my own :P
<litghost>
Frankly there oaugth to be comments around this stuff
<litghost>
We would happily accept some PR's with any comments/notes around here
<cr1901_modern>
I have my own set of dev notes. I can add to them this weekend using this chat as a guide