ZipCPU has quit [Remote host closed the connection]
promach has quit [Quit: WeeChat 2.3-dev]
promach has joined #yosys
leviathanch has joined #yosys
lutsabound has joined #yosys
citypw has joined #yosys
ZipCPU has joined #yosys
emeb has joined #yosys
rohitksingh_work has joined #yosys
rohitksingh has joined #yosys
pie__ has joined #yosys
pie___ has quit [Ping timeout: 255 seconds]
gsi__ is now known as gsi_
lutsabound has quit [Quit: Connection closed for inactivity]
kraiskil has joined #yosys
_whitelogger has joined #yosys
rohitksingh has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
<promach>
corecode : the problem with NoC compared to regular bus is that we might have some problem determining the starting packets nodes as well as finishing packets nodes
<promach>
in other words, for a task to be loaded into the computation units within the NoC, it is a bit difficult to determine the start nodes and finish nodes
<promach>
so, it is more about finding out where the data entrance and exit points
<promach>
corecode : have you done some coding on NoC previously ?
rohitksingh has joined #yosys
<promach>
it is really a headache to do the mapping of computation task to the computation units within a NoC
<promach>
I mean without the help of gcc compiler
citypw has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Ping timeout: 258 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 244 seconds]
citypw has joined #yosys
leviathanch has joined #yosys
<corecode>
hi promach
<corecode>
why is it hard?
<corecode>
what computation do you want to do?
cr1901_modern has quit [Ping timeout: 244 seconds]
cr1901_modern has joined #yosys
* sxpert
is having fun with logisim-evolution
<sxpert>
finds it more intuitive than bare verilog
<promach_>
this is sort of manipulating how the final result is obtained
<promach_>
corecode : from the c code, get a DFG (this is usually done by compiler tool, not human)
<promach_>
and the DFG is optimized by human for hardware
emeb_mac has joined #yosys
<corecode>
okay
<corecode>
well, good luck
<tnt>
MoeIcenowy: Import "P&R" file works fine here.
<tnt>
Placed and routed as well.
<daveshah>
fyi, just tried your design and noticed the critical path is posedge->negedge which icetime doesn't handle correctly
<daveshah>
nextpnr does, and gives 25MHz Fmax
<MoeIcenowy>
nextpnr can deliver timing info?
<MoeIcenowy>
tnt: maybe my iCECube2 is cursed?
<daveshah>
yeah, it has much better timing analysis than icetime
<daveshah>
also supports multiple clocks unlike icetime
<MoeIcenowy>
I used 2017.08
<tnt>
Me too
<tnt>
you might want to retry to create a project from scratch. I kno corecode (IIRC) also has issue witha corrupted project file / env throwing stuff off.
<MoeIcenowy>
I just created it...
<tnt>
oh.
<corecode>
yep, i don't know what i did, but it failed to place
shuggsy has joined #yosys
<MoeIcenowy>
I will try Radiant then
<MoeIcenowy>
tnt: did you import the PCF?
<tnt>
I did
<tnt>
Radiant is annoying because they changes the primitives, so you can't have same code with instanciated primites that works in icecube and in radiant.
<MoeIcenowy>
"/home/icenowy/git-repos/bfcpu/i_mem_icecream_v1.v":16:1:16:9|Cannot find data file instructions_icecream_v1.hex for task $readmemh
<MoeIcenowy>
WTF? Synplify Pro cannot find the hex file in the same directory with source file?
<MoeIcenowy>
CURSED.
<MoeIcenowy>
tnt: where's the Radient primitives library?
<MoeIcenowy>
BTW I recreated a proj, and still failed to PnR
<corecode>
no, it cannot
<corecode>
the synplify project is elsewhere
<MoeIcenowy>
maybe it's now the time for `rm -rf ~/fpga/lattice/iCEcube2.2017.08/`?
<MoeIcenowy>
remembered when attending our "Laboratory of Computer Organization" lesson, the teacher warned us that under Vivado only absolute path will work for $readmemh
<tnt>
Well to be fair yosys also looks for file in cwd and not in the same directory as the source file. I wish verilog had the same as C for include where using "" searches the same dir as the source.
<daveshah>
heh, looks like we actually beat icecube in this case
<daveshah>
icecube is reporting 22-24MHz across runs, nextpnr with the new criticality driven placer is getting 25-27MHz
<tnt>
daveshah: ? I get 36.98 MHz with icecube
<daveshah>
is it picking up the hex file?
<tnt>
Oh ...
<daveshah>
I was getting around that when it wasn't processing the readmemh and optimised half the core away
<MoeIcenowy>
seems that if hex is not picked
<MoeIcenowy>
the whole i_mem is optimized out
<MoeIcenowy>
too clever
<daveshah>
synthesis tools are too clever until they aren't clever enough :P
<MoeIcenowy>
daveshah: it's still not clever enough to optimize the whole core ;-)
<MoeIcenowy>
optimize it to fixed 000 output ;-)
<daveshah>
at some point you hit the halting problem
<MoeIcenowy>
daveshah: BTW how to let nextpnr generate timing report?
<daveshah>
it does it automatically
<daveshah>
just look towards the end of the output
<daveshah>
unless you run with -q, then it will only print failures
<MoeIcenowy>
daveshah: by proving it's not a turing machine halting problem can be solved
<daveshah>
yes, this is true
<tnt>
daveshah: indeed, now I get 23.5M
<MoeIcenowy>
I think maybe if we try to inject not-so-optimized yosys result to iCECube2 PnR
<MoeIcenowy>
it will be lower freq
<MoeIcenowy>
;-)
<daveshah>
yeah, Yosys does struggle a bit with some optimisations atm
<tnt>
Is there a way to feed synopsys output to nextpnr ?
<daveshah>
hmm
<daveshah>
not sure if it can export anything other than an edif
<MoeIcenowy>
daveshah: it says to export VQM
<daveshah>
that might work
<MoeIcenowy>
but I don't know whether Lattice ver of Synplify supports it
<MoeIcenowy>
oh maybe it's now the time for me to rebuilt nextpnr
<MoeIcenowy>
my nextpnr version here only produces 22MHz
<daveshah>
this both improves the current placer1 and adds a new placer
<daveshah>
I was actually using the improved placer1 to get the 27MHz result
<daveshah>
hoping this gets approved and merged this week
<MoeIcenowy>
so a rebuild is really useful?
<daveshah>
I don't think rebuilding master will make much difference
<MoeIcenowy>
BTW does rebuilding master require rebuild icestorm?
<daveshah>
yes, because the u4k device was added
<MoeIcenowy>
daveshah: how does --opt-timing work?
<daveshah>
that runs an extra post-placement pass that can improve timing a bit (at the expense of runtime, and not always improving)
<daveshah>
master with opt-timing gets me 27.9Mhz
<MoeIcenowy>
hears so good
<MoeIcenowy>
so maybe master will help
<MoeIcenowy>
currently mine is 19cffde
<tnt>
daveshah: synopsis can actually write out a mapped verilog netlist.
emeb has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
tnt: it's VQM
<MoeIcenowy>
oh that reminds me of the VQM generated by Yosys not recognized by Quartus Prime 18.1
<daveshah>
yeah, just found it
<MoeIcenowy>
VQM seems to be a quite strict Verilog subset
<MoeIcenowy>
BTW something interesting: AGM Supra, which uses Quartus II defaultly as its synthesis suite, can read Yosys VQM (because Yosys is also its choice)
<daveshah>
Looks like it needs a definition of SB_RAM512x8NR
<daveshah>
then Yosys should handle it
<tnt>
For some IPs the config seem to be attributes rather than params, that ight be anissue.
<MoeIcenowy>
now I start to believe iCE40 has really bad timing
<tnt>
The UP5K is optimized for ultra low power, not for speed.
<daveshah>
so looks like nextpnr gets 22MHz on the synplify netlist
<MoeIcenowy>
tnt: HX is for speed?
<tnt>
MoeIcenowy: yes.
<MoeIcenowy>
daveshah: the same branch with Yosys netlist?
<tnt>
although ... it's still a 'low power class' so don't go expects Xilinx 7 series level of perf.
<daveshah>
MoeIcenowy: 27MHz
<tnt>
daveshah: interesting.
rohitksingh has quit [Ping timeout: 250 seconds]
<MoeIcenowy>
really interesting
<MoeIcenowy>
how about LC usage?
<MoeIcenowy>
BTW is there anyone crazy enough to attach a SDRAM to iCE40UP?
<daveshah>
Synplify wins, about 455 LCs compared to 503
<MoeIcenowy>
tnt: I used to expect Cyclone IV E level of perf
<tnt>
I have 0 experience with altera so ... can't comment.
<MoeIcenowy>
my main experience is with altera
<MoeIcenowy>
then anlogic
<MoeIcenowy>
then xilinx
<MoeIcenowy>
silliconblue just started
<MoeIcenowy>
and never any experience with genuine lattice
<MoeIcenowy>
daveshah: I remember synplify always win on space to yosys
<MoeIcenowy>
it might be useful if you want to use LP384 ;-)
<daveshah>
yeah, seems to win on space but not timing (tried setting a timing constraint but didn't seem to change things)
<MoeIcenowy>
BTW for FPGA REing I now think the infomation given by vendor toolchain is very necessary ;-)
qu1j0t3 has left #yosys ["WeeChat 0.4.3"]
<MoeIcenowy>
I abandoned to RE AGM AG1280 because it can give out no useful info except a JTAG sequence used to burn the FPGA
<MoeIcenowy>
Lattice and SiliconBlue toolchain seem to deliver many useful internal info
rohitksingh has joined #yosys
<corecode>
you mean it doesn't produce a binary?
<MoeIcenowy>
corecode: it do produce, but a binary cannot be burned at all
<MoeIcenowy>
to burn the bitstream into SRAM the JTAG sequence is needed
<MoeIcenowy>
and binary cannot be furtherly converted
<MoeIcenowy>
the only chance of generating JTAG sequence is when PnR
<corecode>
so what is the holdup for RE?
<MoeIcenowy>
you cannot even judge whether the binary file is meaningful
<MoeIcenowy>
I remember at least one generation function of AGM Supra generates useless output, that is what the FAE says
<corecode>
you mean whether the vendor tool produced a correct bitstream?
<MoeIcenowy>
yes
<corecode>
well that is a requirement of course
<corecode>
or you would have to verify the behavior from the outside
<MoeIcenowy>
but the bitstream file is not used in any process at all
<MoeIcenowy>
only the programming command file is useful
<corecode>
jtag command sequence is the equivalent to a bitstream
<MoeIcenowy>
yes
<MoeIcenowy>
but I think extract info from it will be weird
<corecode>
not different from a bitstream
lutsabound has quit [Quit: Connection closed for inactivity]
maikmerten has joined #yosys
promach_ has quit [Ping timeout: 245 seconds]
<MoeIcenowy>
oh for the previous PnR failure on iCEcube2
<MoeIcenowy>
I just checked my dmesg
<tnt>
OOM ?
<MoeIcenowy>
it says "edifparser[15356]: segfault at 0 ip 00000000f7e9d5e2 sp 00000000ff905838 error 4 in liboaCommon.so[f7e92000+11000]"
<MoeIcenowy>
just segfault
<MoeIcenowy>
no OOM
<tnt>
ah well.
<MoeIcenowy>
not only edifparser can fail on Yosys EDIF, but it can also fail on Synplify Pro EDIF
<MoeIcenowy>
hahahaha
<MoeIcenowy>
nextpnr perfectly outperform iCEcube2 here by no segfault