<jeremyh_>
Unfortunately, I get the following error right near the end of building it
<jeremyh_>
Info: IOLOGIC component OFS1P3BX_1 connected to PIO Bel X38/Y0/PIOB
<jeremyh_>
Info: IOLOGIC component OFS1P3BX connected to PIO Bel X35/Y0/PIOAERROR: CE signal or polarity mismatch for IO flipflop IFS1P3BX_1 with other IOFFs at location.
<jeremyh_>
ERROR: Packing design failed.
<jeremyh_>
oop
<jeremyh_>
sorry that should be 4 lines
<jeremyh_>
im not exactly sure what can cause this problem, if it is an issue with nextpnr or an issue with the code (I'm guessing the latter)
<jeremyh_>
could anyone please point me in the right direction with how to debug something like this? I'm a bit stuck unfortunately
<slagernate>
may want to check design is small enough (logic/FF and pin count utilization), and that your litex script is targeting the actual device you want (ECP5-Mini, `python3 project/ecp5_mini.py --build --load`, I assume you are using)?
<jeremyh_>
yep, I am using that command minus the --load
<jeremyh_>
i have not really used multipass before, so I'm trying to do as little as possible at first while i get something working ;)
<slagernate>
I think multipass isn't required if you have a fresh ubuntu install
<slagernate>
looking at stderr it seems the pin configuration is causing the packing error
<jeremyh_>
yep, I'm still trying to work out where the packing problem is though
<jeremyh_>
like which pins are the ones in the design that are causing the conflict
<slagernate>
hm, weird. Not sure what's going on. I guess worst case could possibly start from scratch and create your own board file, assuming there are no other existing examples for that board.
<slagernate>
sorry I can't help much
<jeremyh_>
no worries, thank you for the help anyway
<jeremyh_>
so i guess it is a problem with the usb core
<jeremyh_>
yep, indeed it seems that if I replace the usb-acm uart with a regular uart, the core builds and runs correctly
<jeremyh_>
so i guess the cdc-acm doesn't support the ECP5-12F ? I see a bunch of references to these IO buffers in the commit logs of the valentyusb litex repo
<tnt>
jeremyh_: seems like it's requesting something that's not possible for the IOBlocks.
<tnt>
Shouldn't be 12F specific, but it could be the exact pins on which USB is. Not all IO blocks are the same.
<tnt>
Could also be some recent change in either nextpnr (like it become more restrictive, or better at checking things) or the core...
<gatecat>
Yeah, it's got better at checking conflicts in the IO flipflops that would result in a silent miscompile, or, because of the bug, even memory corruption
<gatecat>
Quite possibly for USB 1.1 you could get away without them and just use regular flipflops. That may well be what Diamond actually does here anyway (nextpnr errors out where ECP5 IO FFs can't be used, Diamond usually just converts them back to regular ones...)
<gatecat>
For the ECP5 as far as IO flipflops are concerned there should be no differences between IO pins afaik