<boardrunner>
trying to get the usb3_pipe example running either on NeTV or Versa, but when I run ./versa_ecp5.py the .v file that is generated can't be synthesized because sys_rst is driven by multiple outputs: ERROR: Net 'bridge_count_TRELLIS_FF_Q_CE[0]' is multiply driven by cell ports FD1S3BX_1.Q and FD1S3BX_5.Q
<boardrunner>
any ideas what might be happening?
<boardrunner>
here are a few more lines when trying to run build_lattice_versa_ecp5.sh to synthesize the design: https://pastebin.com/XLPHzm0a
<tpb>
Title: 20.51. Executing CHECK pass (checking for obvious problems).Checking module la - Pastebin.com (at pastebin.com)
proteusguy has quit [Remote host closed the connection]
boardrunner has quit [Quit: Ping timeout (120 seconds)]
Bertl is now known as Bertl_zZ
boardrunner has joined #litex
boardrunner has quit [Client Quit]
chipdsgr has joined #litex
jon_ has quit [Ping timeout: 240 seconds]
jon_ has joined #litex
jon_ has quit [Ping timeout: 252 seconds]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
<_florent_>
but this project was an experiment and I would still recommend having a USB3 analyzer when testing it. The ECP5 port was not very stable but the Artix7/Kintex7 port was able to enumerate correctly and have the link stay up (but not with all computers).
<_florent_>
You can also look at Luna project that used this work as a basis for the USB3 support, there are probably been various improvements but I'm not well aware of them
<_florent_>
there are/there has
<chipdsgr>
did you use the ECP5-5G dev kit? (wondering if the lack of 5Gbps SERDES could have been the reason for the lack of stability)
RaivisR has joined #litex
<chipdsgr>
btw awesome fast fix :D I'm able to synthesize things now, thanks!
<RaivisR>
good time of day, I noticed interesting thing, every time I re-build simple design for ecp5, sys_clk max frequency reported is different. no changes to the design itself. is it a known thing?
rom16 has joined #litex
<rom16>
hi, I'm currently using Litex to generate SoC for testing on FPGA. I'm looking for a path to move the design from FPGA to ASIC (remove vendor IP, create blackbox, etc). Have anyone ever attempt this before?
<chipdsgr>
rom16: checkout OpenROAD/OpenLane and the skywater project for people experimenting going from RTL to ASIC
<rom16>
we have access to commercial tools so no need for the skywater project. We already have experience going from RTL to ASIC. The problem is the RTL generation from Litex
<rom16>
(thanks for the tips though)
<rom16>
I'm using Litex because Chipyard is a mess. Had one chip taped-out from it and it's just horrible to continue our work with it.
<chipdsgr>
oh wow, very cool! out of curiosity what tools did you use to do the layout of that design?
<Melkhior>
@rom16 Would be nice to have an ASIC version of Litex, no idea about seasibility. Assuming you're looking for a RISC-V SoC generator, maybe you can investigate https://www.esp.cs.columbia.edu/ as I think they're targeting ASIC as well
<tpb>
Title: ESP - open SoC platformESP | ESP - open SoC platform (at www.esp.cs.columbia.edu)
<Melkhior>
s/seasibility/feasibility/
<rom16>
chipdsgr I use the standard industry tools: DC for synthesis, ICC2 for PnR, PT for STA and Calibre for DFM
<rom16>
Melkhior I'm aiming to do it using Litex, probably going to take a month or 2 (it's just a master thesis, not my main job so it's going to take a bit of time)
<rom16>
planned to do the LiteDRAM for Altera parts (Cyclone IV) after the chip too
<Melkhior>
@rom16 a chip during a master thesis ? lucky you :-)
<rom16>
not during, before...
<rom16>
an IoT-oriented MCU with RISC-V core is my final thesis for M.S. (2.5 years from now)
<Melkhior>
@rom16 hehe kids today have all the luck:-) #oldfart ;-)
<rom16>
@Melkhior I'm not doing all the things alone:D I have a friend working on the analog portion of the chip for me
<Melkhior>
@rom16 ESP also has accelerators for AI in mind, which might be of interest fo you
<chipdsgr>
how's it going to talk to the outside world?
<chipdsgr>
any RF?
<rom16>
we don't have any people with experience in RF IC design, so sadly no
<rom16>
I guess we can use a SPI-based external IC
<rom16>
and if we need DRAM, we also don't have any IP for it... so FPGA will have to serve as a medium for it
<Melkhior>
@rom16 So you would have an ASIC with not much external connection except some 'custom' stuff to an FPGA, then the FPGA talks to the outside world?
<rom16>
@Melkhior: I would have an ASIC with some external connection, except for some special connection which need an FPGA to function (DRAM is a PITA to do IP for)
<rom16>
(and some people called RF "black magic")
<Melkhior>
@rom16 OK, nice, hopefully Litex will fit the bill :-)
<rom16>
well, considered that writing python is familiiar and less error-prone than scala (looking at you Chisel!), I think the feasibility is high
<rom16>
I'll come back to this IRC or push something to github when I make some progress
<rom16>
stay tuned!
<_florent_>
rom16: interesting, to create ASIC with LiteX, the path would probably be to create build backend, similar to what we have for the different FPGA vendor, expect that you'll be targeting your ASIC toolchain with its own primitives
<_florent_>
This would already allow building the designs with simple primitives, then you could create specialized wrapped for the PLL, specialized PHYs for LiteDRAM, LiteETH, etc...
<_florent_>
But for simple LiteDRAM PHYs (ex SDRAM), simple LiteETH PHYs (ex MII, RMII), just adding the build backend should be enough since LiteX will be lowering the primitives automatically
<_florent_>
rom16: feel free to ask it you need directions to get started and setup your ASIC flow with LiteX, that was not the primary aim of the project but we see more and more interest for this
<rom16>
_florent_: thanks for the direction. I'm more of a RTL design engineer, so my approach would be almost similar. I'd like to replace the vendor IP with blackbox (only contain input and nothing else) so I'd be integrating the ASIC IP later on if I can.
Bertl_zZ is now known as Bertl
<rom16>
and for the top chip IO, it would be similar to the board definition (I think, I haven't take a long look at it yet)
<rom16>
I don't really need the backend, since we already have a very solid backend at work. All I need for now is the synthesizable RTL.
<shoragan>
somlo, when trying to synthetize a rocket core with the code in https://github.com/litex-hub/pythondata-cpu-rocket, it complained that it couldn't find some port. are you using a different source?
<shoragan>
8.4.3. Analyzing design hierarchy..
<shoragan>
ERROR: Module `ExampleRocketSystem' referenced in module `lambdaconcept_ecpix5' in cell `ExampleRocketSystem' does not have a port named 'resetctrl_hartIsInReset_0'.
<somlo>
shoragan: assuming you have the latest of everything in litex, it might be about the yosys version -- mine is at git commit 26e01a6 (as of March 10 2021 or thereabouts)
<nickoe>
Is there a way to re-use the litex_server --jtag ... instance with the --load option?
<shoragan>
somlo, i've got yosys d061b0e41a2 and litex fb8f45be7330fd
<shoragan>
i'll try with your version
<nickoe>
What does this vivado critical warning really mean? I have an Artix7.
<nickoe>
CRITICAL WARNING: [Timing 38-472] The REFCLK pin of IDELAYCTRL IDELAYCTRL is not reached by any clock but IDELAYE2 IDELAYE2_10 has REFCLK_FREQUENCY of 200.000 Mhz (period 5.000 ns). The IDELAYCTRL REFCLK pin frequency must match the IDELAYE2 REFCLK_FREQUENCY property value.
<shoragan>
somlo, even with yosys 26e01a67db, i get the same error. is your litex newer than 116c2f15494?
acathla has quit [Remote host closed the connection]
<somlo>
shoragan: I keep my litex sync-ed up with enjoy-digital (and litex-hub) upstream, so it's the newest available
<shoragan>
somlo, hmm. did you regenerate your rocket core?
<nickoe>
Hmm, how does one buffer up a couple of words of serial data in a migen fsm?
<nickoe>
To be consumed at a lower rate.
<somlo>
shoragan: it's the rocket core currently in pythondata-cpu-rocket -- I should probably update it from chipsalliance/rocket-chip and see if any new breakage was introduced, but litex should work with the pythondata-cpu-rocket as is
<somlo>
shoragan: what board are you building for?
<shoragan>
somlo, ecpix-5 85k
<shoragan>
your prebuild bitstream works fine
<shoragan>
hmm, then i must be missing something else. i don't see how i'd get that 'resetctrl_hartIsInReset_0' error when using the same pythondata-cpu-rocket and litex
<somlo>
hmmm... I just started a build for ecpix5 and am currently at "8.24.*" in yosys
<somlo>
grasping at straws here, but maybe explicitly remove your build directory before restarting a build? Sometimes I get weird errors if I don't do that...
<shoragan>
somlo, i see "Warning: Max frequency for clock '$glbnet$sdrio_clk': 17.24 MHz (FAIL at 50.00 MHz)" in the log, but i heard that that is unlikely to be critical
<shoragan>
somlo, ok.
acathla has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<somlo>
is there an example of how to set up linux (probably on vexriscv) to directly utilize the liteuart? Right now, I'm using "console=hvc0" in bootargs (and grepping through linux-on-lite-vexriscv I find the same thing there), and that essentially traps into machine mode and has the m-mode emulator deal with the UART (BBL in my case)
<shoragan>
somlo, there is drivers/tty/serial/liteuart.c, which binds to the "litex,liteuart" dt compatible. from looking at the source it should register ttyLXU0
<shoragan>
(at least that's the way it would work on arm socs ;)
<somlo>
shoragan: tried "console=ttyLXU0" in bootargs (have the liteuart compiled in the kernel, and the DTS obviously correct (since BBL uses it too before passing it to linux)
<somlo>
but I get nothing after BBL :(
<shoragan>
if you can boot a different way, it should show up in /proc/tty/drivers
<shoragan>
you could test it with echo/cat/stty from there
<somlo>
I see "liteuart /dev/ttyLXU 253 0 serial"
<shoragan>
then you should also have a /dev/ttyLXU0
<somlo>
if I then "mknod /dev/ttyLXU c 253 0" I can echo things into it and see them show up on the console :)
<shoragan>
with mount -t devtmpfs none /dev it should already be there
<shoragan>
so the driver works :)
<shoragan>
you have CONFIG_SERIAL_LITEUART_CONSOLE=y?
<somlo>
yes
<somlo>
hm, I should mount devtmpfs in initrd, rather than have a few nodes manually created... Thanks for pointing that out :)
<somlo>
(still not sure why the booting kernel won't use the device if passed in on the kernel command line, but that's orthogonal :)
<shoragan>
check /proc/cmdline and /proc/console
<shoragan>
to be sure that you don't have any other console (primary) console
<somlo>
right now I have "console=hvc0" on the bootargs, and "hvc0 -W- (EC p ) 229:0" in /proc/consoles; but that's how I got it to output anything at all -- if I set "console=ttyLXU0" in bootargs instead, I get nothing at all
<shoragan>
you could try using earlycon via sbi, maybe you can see any error messages that way. i don't have any other ideas right now :/