<bvernoux>
as it is clearly discouraging for new users/developers which come on that repo and will be very disappointed by unmaintained obsolete stuff ...
<d1b2>
<dub_dub_11> Oh nMigen boards does have ECPIX-5
<bvernoux>
yes ;)
<bvernoux>
it is what I'm trying to test ;)
<bvernoux>
I have the 45F version
<bvernoux>
and soon 85F the big boy
FL4SHK has quit [Ping timeout: 260 seconds]
FL4SHK has joined #nmigen
<bvernoux>
ECP5-5G is clearly amazing ;)
<bvernoux>
I'm impatient to see final support for USB 3.0
<bvernoux>
kate is doing an amazing job on that
FL4SHK has quit [Ping timeout: 272 seconds]
FL4SHK has joined #nmigen
FL4SHK has quit [Ping timeout: 256 seconds]
FL4SHK has joined #nmigen
FL4SHK has quit [Ping timeout: 260 seconds]
<_whitenotifier>
[nmigen] hansfbaier opened issue #566: Python simulator hangs or throws when trying to drive reset from testbench - https://git.io/JL1XE
FL4SHK has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
FL4SHK has quit [Ping timeout: 256 seconds]
emeb has joined #nmigen
FL4SHK has joined #nmigen
FL4SHK has quit [Ping timeout: 265 seconds]
FL4SHK has joined #nmigen
FL4SHK has quit [Ping timeout: 264 seconds]
FL4SHK has joined #nmigen
<whitequark>
bvernoux: what? nmigen does *not* require python 3.8, where did you get that idea?
<whitequark>
bvernoux: well, that's incorrect, and I am going to complain to Robert about it
<bvernoux>
yes it is great to clarify that
<bvernoux>
especially it is a mess to install python 3.8x on Ubuntu 18.04 LTS or 20.04 LTS as by default it is Python 3.6.x or 3.7.x
<bvernoux>
he has added a mandatory check in fact in some script to check it is python 3.8 min
<bvernoux>
So I was thinking it comes from a requirements in latest nmigen code
<bvernoux>
...
emeb_mac has joined #nmigen
<_whitenotifier>
[nmigen] whitequark commented on issue #566: Python simulator hangs or throws when trying to drive reset from testbench - https://git.io/JL19g
<_whitenotifier>
[nmigen] whitequark commented on issue #566: Python simulator hangs or throws when trying to drive reset from testbench - https://git.io/JL19a
<whitequark>
bvernoux: okay, Robert has clarified the version requirement in his tutorial/repo
<bvernoux>
ha great
<bvernoux>
so he has removed the check of python 3.8 too ?
<whitequark>
yes
<bvernoux>
ok great ;)
<bvernoux>
that will simplify things ;)
<bvernoux>
I do not know if there is any major benefit to use Python 3.8 vs Python 3.6 so far
<bvernoux>
I doubt there is big improvements in performances ...
<vup>
the `:=` syntax can be quite handy, thats what I use from python 3.8 the most
<whitequark>
there is no benefit in performance at all AFAIK
<bvernoux>
cd ~/nmigen-boards/build/lib/nmigen_boards
<bvernoux>
python3 ecpix5.py
<bvernoux>
trig an error ;)
<bvernoux>
ImportError: attempted relative import with no known parent package
<bvernoux>
which is obscure for me
<bvernoux>
related to from .resources import *
<bvernoux>
I do not understand why python3 cannot do that from local dir
<bvernoux>
resources is a local dir with python stuff
<lkcl>
bvernoux: copy ecpix5.py out of the directory and then execute it
<bvernoux>
ha ok it does not like to do that in the same dir
<lkcl>
also you don't want to be executing code in the build directory
<bvernoux>
it was a test ;)
<lkcl>
:)
<lkcl>
sigh i understand why relative imports exist (to make moving of whole library directories easier, should you need to)
<lkcl>
understand that this is a personal choice on my part: i just.. for exactly the reason you just encountered, don't like them :)
<bvernoux>
I have done some python3 stuff before but I'm not aware of those special import
<bvernoux>
how does python3 know where are the import if I move the file ?
<bvernoux>
it shall know the path
<lkcl>
ok so python has something called sys.path (import sys first)
<lkcl>
and the search order for a given import is based on that list
<bvernoux>
here it is relative import with .
<bvernoux>
mainly resources
<bvernoux>
if i copy ecpix5.py outside the directory it still does not find relative import
<lkcl>
there's a few ways to solve this one. personally i use "python3 setup.py develop"
<lkcl>
that's because you haven't actually installed nmigen-boards yet: you've only built it
<bvernoux>
ha ok
<lkcl>
or if you prefer not to do that as root, you can do
<lkcl>
python3 setup.py develop --user
<bvernoux>
I tried both in fact ;)
<lkcl>
but you have to then add... err.. what is it... ~/.libsomething to an environment variable EXPORT $PYTHONPATH=xxx or some sort of voodoo incantations
<d1b2>
<dub_dub_11> You can install with pip
<lkcl>
yes, pip3 will cover much of the voodoo for you
<lkcl>
except *sigh* it often goes off "oh look you don't have this version of this library i will just automagically download it and install it without asking or warning you of the consequences"
<whitequark>
Sarayan: this is fixed with the new pip dependency resolver
<bvernoux>
it is a mess between pip which use python2 ...
<bvernoux>
so i use pip3
<lkcl>
"python3.7 /usr/bin/pip3 {arguments}"
<bvernoux>
pip3 is probably an alias ?
<bvernoux>
it was never clear for me how to use it correctly ;)
<whitequark>
if you want to use pip with a specific pythonX.Y binary, use `pythonX.Y -m pip`
<bvernoux>
ha ok ;)
<lkcl>
bvernoux: have a look at the contents of /usr/bin/pip3. it's... a 9-line script
<lkcl>
its job: Find The Right Version Of Pip Module To Import (tm)
<lkcl>
other people swear by using virtualenv to "solve" this.
<lkcl>
each virtualenv gets everything, downloads everything, cleanly isolates it from whatever-else-you-have (including, importantly, whatever version(s) of python3.N are *distro* installed)
<lkcl>
but, you have to remember to switch to correct virtualenvs :)
<bvernoux>
yes I need to read more how to use pip with python ;)
<Sarayan>
wq: they're fixing it? Nice
<Sarayan>
Arch is very python-3-is-the-default, so pip goes to python3 (and its package is called python-pip) which pip2 goes to python 2 (with package python2-pip)
<Sarayan>
tbh, I like that
<whitequark>
Sarayan: they've already fixed it
<whitequark>
I believe the new resolver should be enabled by default now, if you have latest pip
<Sarayan>
not sure when was my latest update, <1 month I think
<_whitenotifier>
[nmigen] RobertBaruch opened issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL17W
<bvernoux>
ok I have repaired my python3 stuff ;)
<bvernoux>
I have new error now
<bvernoux>
nmigen._toolchain.ToolNotFound: Could not find required tool yosys in PATH. Place it directly in PATH or specify path explicitly via the YOSYS environment variable
<bvernoux>
I have installed pip3 install yowasp-yosys
<bvernoux>
maybe I have missed something ?
<bvernoux>
ha ok
<bvernoux>
maybe
<bvernoux>
pip3 install yowasp-nextpnr-ecp5-all
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL17S
<whitequark>
bvernoux: you need to specify it via the environment variable
<_whitenotifier>
[nmigen] whitequark commented on issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL15f
<bvernoux>
nice it works ;)
<bvernoux>
ECPIX-5 blink leds ;)
<bvernoux>
next step is to check how to do that in flash to have persistent bitstream flashed ;)
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL158
<miek>
Greg Davill's ecpprog just works with it for me
<_whitenotifier>
[nmigen] whitequark commented on issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL15a
<whitequark>
yes, I think ecpprog is your best option atm
<bvernoux>
yes i need to check that
<bvernoux>
thanks for all
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL15V
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL15r
<_whitenotifier>
[nmigen] RobertBaruch closed issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL17W
<_whitenotifier>
[nmigen] RobertBaruch edited a comment on issue #567: Assigning clock domain to attribute results in failures, radically different RTLIL output - https://git.io/JL15r
<bvernoux>
it was exactly what I was searching to start something in different form verilog, nmigen ...
<bvernoux>
nice I have converted the nmigen example and modified it a bit to blink all 4 RGB LEDs ;)
<bvernoux>
so I have a full example now working fine
<bvernoux>
with interesting things in build
<bvernoux>
does it is possible to generate a clean verilog file too ?
<bvernoux>
I see the top.debug.v
<bvernoux>
I will prefer also a clean top.v
<bvernoux>
it is interesting how nmigen "python" code is generated in verilo
<bvernoux>
verliog
<bvernoux>
verilog ;)
<d1b2>
<dub_dub_11> It generates both
<bvernoux>
i do not see any other .v
<bvernoux>
in build
<bvernoux>
maybe there is hint ?
<whitequark>
bvernoux: when you use the FOSS tools, there is no Verilog involved in building a bitstream
<bvernoux>
ha ok
<bvernoux>
so only the debug.v
<whitequark>
the difference between top.v (when it exists) and top.debug.v is that from the former, some attributes that would confuse the proprietary toolchains are stripped
<whitequark>
for FOSS tools, there would be no difference
<whitequark>
you can just use .debug.v
<whitequark>
for your reference that is
<bvernoux>
yes the idea was to do review of the verilog code
<bvernoux>
and debug.v is not very clean for fast review
<bvernoux>
but it is ok
<whitequark>
what do you mean by "clean" here?
<bvernoux>
I was suspecting something without all those python comments
<whitequark>
(*src*)?
<bvernoux>
yes
<bvernoux>
it is not really a problem
<bvernoux>
i'm very impressed how it is fast to build things
<whitequark>
ok
<bvernoux>
compared to when I was doing some verilog blink led which took few minutes to do the synthesis with Altera FPGA proprietary tools
<bvernoux>
so it is a very good surprise as I was so disappointed by the Altera build tools so bloated big and slow to do very simple things
<whitequark>
yep the FOSS tools are quite fast
<bvernoux>
I compare ECP5-5G-45F vs Cyclone IV (DE2-115)
<bvernoux>
on the same PC of course ;)
<whitequark>
the speed of the tools is often not bottlenecked by chip size, but by things like DRM
<bvernoux>
such FOSS tools are a real game changer ;)
<d1b2>
<dub_dub_11> Oh the non debug top.v still has the src bits
<whitequark>
don't know about Altera, but Xilinx would probably be twice as fast without DRM
<whitequark>
dub_dub_11: the (*src*) attribute is always left if the PNR supports it
<whitequark>
because then you can see source corresponding to critical path
<bvernoux>
yes their build tools are so bloated and so huge ;)
<whitequark>
nextpnr should actually show you the python source line, i think?
<bvernoux>
I remember Altera tools take lot of GB ...
<d1b2>
<dub_dub_11> Oh neat
<daveshah>
I think we removed that from the PR in the end to avoid all the complexities of file IO in timing analysis
<whitequark>
ohh right
<daveshah>
but it does give you the line numbers
<whitequark>
daveshah: but... the option is still there?
<whitequark>
--no-print-critical-path-source disable printing of the source lines
<whitequark>
associated with each net in the critical
<whitequark>
path
<daveshah>
Huh, let me see
<daveshah>
I think that text should be fixed, it just disables printing of the line number now
<daveshah>
Not the line content
<whitequark>
do we even need an option for that?
<whitequark>
oh, it might be printing a lot of file:line lines, maybe?
<daveshah>
Yeah
<whitequark>
right, ok
<daveshah>
The Verilog frontend can be quite prone to that in some cases
<daveshah>
Carry chains are the main problem, because then the line numbers end up repeated N times
<bvernoux>
daveshah, do you remember what are the actual limitation for ECP5-5G with FOSS tools ? (or what is missing in FOSS tools)
<daveshah>
Advanced DSP features, routeability for very high utilisation designs, and overall SERDES support quality
<bvernoux>
ha ok
<daveshah>
plus weaker timing analysis overall
<bvernoux>
Do you think ECP5 can reach 500MHz on IO ?
<bvernoux>
without using serdes ?
<bvernoux>
IO+Core+CLK ;)
<daveshah>
wdym 500MHz? 500Mbps or 1000Mbps
<daveshah>
Officially, the limit is 400MHz/800Mbps per pin
<bvernoux>
in fact I want to design a Logic Analyzer pattern generator
<bvernoux>
to validate my Rigol MSO5000 LA or other LA which can go up to 1GSPS ;)
<bvernoux>
I will like to know what are the limit of ECP5-5G for that
<bvernoux>
idea is to generate signal with 3.3V so I cannot use SerDes ...
<daveshah>
You'd be pushing the IO a bit electrically, but in this case it should work even though technically out of spec
<bvernoux>
so in worst case 400MHz ?
<daveshah>
Yeah
<bvernoux>
but maybe 500MHz will be working ?
<daveshah>
I'd be surprised if it wasn't
<bvernoux>
ha great
<bvernoux>
anyway even just 400MHz is enough I think with test pattern on simple IO mode
<bvernoux>
Advanced DSP will be a must have for future ;)
<bvernoux>
I was not aware there was such features in ECP5
<bvernoux>
it is very nice to do some ultra fast filters ...
<bvernoux>
or some nice HW FFT ...
<daveshah>
I don't even understand all the various modes for efficient filters (like some ways of shifting coefficients into multipliers) let alone support them yet
<bvernoux>
anyway before I shall understand how to do things with nmigen ;)
<bvernoux>
or even mix nmigen stuff with verilog
<bvernoux>
...
<bvernoux>
next step is to have an ECP5-5G which cost less than 10USD/unit with low volume ;)
<bvernoux>
We can always dream ;)
<bvernoux>
with 85Kcells of course ;)
<bvernoux>
and with LQFP package < 100pins ;)
<daveshah>
Well, there might be a (non-SERDES) tqfp144 ECP5 in the works
<daveshah>
It was added in a datasheet revision this October, but hasn't appeared at any distributors yet nor has a pinout been published
<bvernoux>
it could be a good things if it is not a strange package ;)
<bvernoux>
hybride between QFN & LQFP ;)
<whitequark>
pretty common for low cost packages
<bvernoux>
tqfp144 will be nice anyway for 4 layers PCB which can be build at low cost ;)
<bvernoux>
does it is planned to have litex working with nmigen ?
<bvernoux>
so far it is still using the old migen
<bvernoux>
I will check with Florent
<whitequark>
it is up to Florent
<bvernoux>
yes
<daveshah>
I don't think it is in his plans for the short term, at least
<bvernoux>
it will be a very nice test for nmigen ;)
<bvernoux>
daveshah, Yes I imagine there is lot of work ...
<daveshah>
Yeah, and a lot of ways that things could subtly break
jeanthom has quit [Ping timeout: 246 seconds]
jeanthom has joined #nmigen
sorear has quit [Ping timeout: 260 seconds]
sorear has joined #nmigen
<lkcl>
daveshah: one of the employees of Lattice left, founded a chinese company and licensed the ECP5 core from Lattice. can't remember the name of the damn things. the success of that probably told Lattice, "hey maybe you should do a low-cost QFP version" :)
<daveshah>
Presumably Gowin or Anlogic
<daveshah>
But neither have 'licensed' the ECP5 core, afaik
<daveshah>
Just taken a certain amount of knowledge with them
<lkcl>
yes! Gowin Semi
<daveshah>
Yeah, of the devices I've seen they definitely aren't close enough to ECP5 to be 'licensed'
<daveshah>
The similarity is on a 'group of former employee' level
FL4SHK has quit [Ping timeout: 256 seconds]
bvernoux has quit [Read error: Connection reset by peer]
FL4SHK has joined #nmigen
<lsneff>
Y'all remember the talk about interface types?
<_whitenotifier>
[nmigen] hansfbaier commented on issue #566: Python simulator hangs or throws when trying to drive reset from testbench - https://git.io/JLMem
<_whitenotifier>
[nmigen] whitequark commented on issue #566: Python simulator hangs or throws when trying to drive reset from testbench - https://git.io/JLMeO
jeanthom has quit [Ping timeout: 264 seconds]
<_whitenotifier>
[nmigen] hansfbaier commented on issue #566: Python simulator hangs or throws when trying to drive reset from testbench - https://git.io/JLMe2
<_whitenotifier>
[nmigen] whitequark commented on issue #566: Python simulator hangs or throws when trying to drive reset from testbench - https://git.io/JLMeK