<clay_1>
By putting all the arguements considered as necessary in the readme
rjordans has quit [Ping timeout: 240 seconds]
<clay_1>
this gives me `IndentationError: unexpected indent`
<clay_1>
I was tried removing arguements that the error was coming fro untill It reached a point it was pointing to `-mfasm2bels`
<clay_1>
Any Idea what I might be doing wrong ?
rjordans has joined #symbiflow
<sf-slack>
<tmichalak> clay_1: this error indicates an indentation problem in the fasm2bels.py script or any scripts used by it. Do you have a more complete error message?
<clay_1>
Is there any way I can get more complete error message ?
<clay_1>
It sais ` File "<stdin>", line 1` and then an arrow pointing at `mfasm2bels`
<clay_1>
but that was after removing some arguements. when I had them all on it was the same error on the first letter of the address of the `.tcl` file declaration
OmniMancer1 has quit [Quit: Leaving.]
<sf-slack>
<acomodi> clay_1: One thing I suggest is to use the complete flow. Take an example from the `xc7/tests` (such as counter for example) and add your test there
<clay_1>
`xc7/tests/counter` looks to me like having design source files in verilog and a constraint file. How will that help me run fasm2bels? So far by litghost's help I have run the `make dram_test_64x1d_bit_v` and from there I saw how it used the fasm2bels
<clay_1>
but since then I had no sucess
<sf-slack>
<acomodi> clay_1: Yeah, I mean, you could reproduce the test you are trying to make with your own test.
az0re has quit [Ping timeout: 240 seconds]
<clay_1>
If I make a folder with my hdl + constraint file and then do a `make my_test` ?
<sf-slack>
<acomodi> exactly
<clay_1>
Thank you, thats a nice idea!
<sf-slack>
<acomodi> You can for instance copy the counter test folder, name it as you want, change the hdl, CMakeLists and constraints file
<clay_1>
The remaining problem will be that I will still not be able to ultimately go from a bitstream to bels and thats my actual goal
<sf-slack>
<acomodi> I see... the fact is that fasm2bels was meant to be a verification method of the whole flow, and mainly for debugging purposes. It is possible to use it for your goals for instance, but it may result in troubles you have experienced
<clay_1>
oh that makes a lot of sense actually
<clay_1>
First I was trying to use the `fasm2pips.py` from the project xray but it turned out to have a bug and thats why i turned to `fasm2bels` since it felt like its a superset of it
HEGAZY has joined #symbiflow
<clay_1>
I just realized that the conda environment used was not the one created by the `make all_conda`. I think I fixed that and now I will try everything all over
mkru has joined #symbiflow
HEGAZY has quit [Ping timeout: 250 seconds]
<clay_1>
I finally had some progress!
<sf-slack>
<acomodi> clay_1: great to hear that
<clay_1>
I think that I am able to run fasm2bels for the dram_test_64x1d independently of the make
<clay_1>
then i tried to run with with only the arguements in the fasm2bels readme but I got errors which this time are much more constructive. I started tackling them from teh bottom
<clay_1>
the error was `in append_ibuf_iostandard_params if "SSTL135" in iosettings["IOSTANDARD"]:`
<clay_1>
so i added the arguement `--iostandard LVCMOS33`
<clay_1>
and this got me the following error
<clay_1>
`IOSTANDARD+DRIVE+SLEW settings provided for IOB_X0Y2 do not match their counterparts decoded from the fasmRequested: IOSTANDARD=LVCMOS33, DRIVE=NoneCandidates are: IOSTANDARD | DRIVE | SLEW |-------------------|--------|------| LVTTL | 16 | SLOW | LVTTL | 12 | SLOW | LVCMOS33 | 16 | SLOW |
<clay_1>
LVCMOS33 | 12 | SLOW |`
<sf-slack>
<acomodi> If I recall correctly that is not an error, but a warning
<clay_1>
oh that would be great !
<clay_1>
I will check the results and see if they make sense
Bertl is now known as Bertl_oO
rjordans has quit [Ping timeout: 240 seconds]
citypw has quit [Ping timeout: 256 seconds]
az0re has joined #symbiflow
balmlake has joined #symbiflow
abeljj[m] has quit [Ping timeout: 245 seconds]
abeljj[m] has joined #symbiflow
Degi has joined #symbiflow
<Degi>
Hi, I'm interested in the Summer of Code and have a PCIe interface for the ECP5 in nMigen in mind, though I'm open for other projects too
<Degi>
Yes I think I'd start with that as a base, though that project had no updates since 16 months
<ZirconiumX>
Useful reference if nothing else
<Degi>
(Also its in migen, I'd rather use nMigen, but yes, I learned a bunch from reading through the source code of that project a while ago)
<ZirconiumX>
Migrating from migen to nmigen is not that difficult as such
<Degi>
Yes, there's also litepcie which does the TLP
OmniMancer has joined #symbiflow
<mithro>
Degi: working on a PCIe interface is not a *small* task, so any student taking that on will need to have to show a pretty strong understanding of what needs to be done -- the fact you have already seen yumewatari and talking about LitePCIe and TLP is a good sign...
miek has joined #symbiflow
balmlake has quit [Ping timeout: 246 seconds]
<Degi>
Hm I've read parts of the PCIe spec and to me what seems missing is the data link layer and I guess Yumewatari needs some work on (and translation to nMigen)
<sorear>
afaik the problem with people picking that up is that debugging anything that goes wrong will be a challenge without a very expensive oscilloscope
<Degi>
Hm you could use a second FPGA to analyze the data sent out by the SERDESs
<sorear>
probably "put a LED on the board, and get very experienced with forming specific hypotheses / translating those hypotheses into HDL that turns on the LED if you're right/wrong"
<Degi>
I mean you could hook the second FPGA with UART or so up to a PC and log the data that arrives
<Degi>
Although I've done that a few times too, the dev board has 8 LEDs and its kinda OK for basic feedback
<daveshah>
One of the problems with yumewatari was tuning the analog parameters of the serdes (which have very limited documentation)
<Degi>
Hm could that be figured out with error rate tests and trial and error?
<daveshah>
Yes, but that could be quite a bit of work
<daveshah>
It would likely need several different motherboards to test too
<Degi>
Well I have 3 here
<Degi>
Hm could the values be reverse-engineered from something that lattice diamond creates? (I've never used that program yet)
balmlake has quit [Ping timeout: 246 seconds]
<daveshah>
Yes, that provides a starting point, I think that's what wq did
<Degi>
I guess that's where all the undocumented values are from
HEGAZY has joined #symbiflow
HEGAZY has quit [Quit: Konversation terminated!]
mkru has quit [Quit: Leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
wallacejohn has quit [Remote host closed the connection]
<mithro>
Degi: _florent_ in #litex has a lot of experience getting the high speed transceivers in FPGAs to play nice