<daveshah>
BRAM initialisation might be worth checking
<daveshah>
there is a test for that
jayaura has joined #yosys
<jayaura>
Hi, I tried synth for a riscv verilog file generated by SpinalHDL, but getting errors which I do not understand: https://pastebin.com/P94CzGiT
<tpb>
Title: Fix WREDUCE on FF not fixing ARST_VALUE parameter. by litghost · Pull Request #824 · YosysHQ/yosys · GitHub (at github.com)
<jayaura>
daveshah: thanks for the quick response. I'll try rebuilding
<jayaura>
oh wait, was that for me?
<jayaura>
daveshah: thanks that patch fixes the error!
<daveshah>
:)
<daveshah>
it was a recent regression
<jayaura>
I see!
proteusguy has joined #yosys
emeb has joined #yosys
voxadam_ has quit [Read error: Connection reset by peer]
voxadam_ has joined #yosys
citypw has quit [Ping timeout: 244 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]
develonepi3 has quit [Remote host closed the connection]
rohitksingh has joined #yosys
ouznext has joined #yosys
<ouznext>
hi. my project passed building (synthesizing) last week just file (https://travis-ci.org/adumont/hrm-cpu/builds/494525894), it was using yosys at commit e45f62b0c56717a23099425f078d1e56212aa632. Today my same code is failing to synthesize with error: "hrmcpu.v:146: ERROR: Identifier `\program0.PROGRAM' is implicitly declared and `default_nettype is set to none.". Today it's at Yosys commit c521f4632f1c82b48a5538c832980668044e8fd9 .
<tpb>
Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org)
<ouznext>
Is it possible there is some regression between commit e45f62b0c56717a23099425f078d1e56212aa632 and c521f4632f1c82b48a5538c832980668044e8fd9 of yosys, regarding parameters? Offending line in my code according to yosys is: https://github.com/adumont/hrm-cpu/blob/master/verilog/hrmcpu.v#L146, defparam program0.PROGRAM = PROGRAM;
<corecode>
you should explicitly declare all your nets
<daveshah>
But this is a parameter not a net
<daveshah>
bisecting now
rohitksingh has quit [Ping timeout: 245 seconds]
<ouznext>
I am using `default_nettype none , but code hasn't changed since Feb 10. Was sinthesizing fine 7 days ago with that.
<corecode>
oh parameter
<daveshah>
Offending commit seems to be 23148ffae14318bb34cb311eb13494e25ebf4593
<corecode>
do you already have a testing setup
<corecode>
i guess yosys compiles faster than nextprn
<corecode>
pnr*
<ouznext>
@daveshah I can try to build yosys at the previous commit, run my tests, then build yosys at that commit and test again. I 'll come back and tell you results. Thanks
<daveshah>
The problem commit is definitely 23148ffae14318bb34cb311eb13494e25ebf4593
proteusguy has quit [Remote host closed the connection]
<tnt>
your SCK seems a bit fast compared to the clock btw.
<tnt>
The result from ip_comb is undefined, so some of the inputs must be missing resets.
<corecode>
yes that was deliberate
<corecode>
yea, my is ip_comb undefined
<corecode>
why*
<corecode>
because it can run on the fpga
<tnt>
Well 'x' don't exit on the fpga :p
<corecode>
must be something about what is fetched from ram
<tnt>
It's doesn't even fetch anything from RAM.
<corecode>
how do you know?
<tnt>
Well, I looked at the simulation trace ... address is always underfined.
<corecode>
yes
<corecode>
i think it's a cycle
<corecode>
it fetches data using an undefined address
<corecode>
and then dispatches the next instruction pointer generation based on the undefined result
<corecode>
a fix point, basically :)
<tnt>
instruction pointer is always undefined ...
<corecode>
no, IP is defined while in reset
<tnt>
but not iaddr
<corecode>
yes
<corecode>
because that's the address to fetch in this cycle to execute next
<corecode>
so it is IP+1
<corecode>
i did not really know how to implement this elegantly
<tnt>
some of the control signals to actually make it ip+1 are obviously not reset properly.
<corecode>
i have the feeling i should add some pipelining - the core is a bit too slow for my liking
<corecode>
tnt: yea, they come from RAM
<corecode>
i guess the question is, what do i execute in the first cycle after reset, when there is no instruction word fetched yet
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined #yosys
lutsabound has joined #yosys
<tnt>
corecode: well, the RAM wouldn't be in reset so it should fetch the first instruction if your logic ensured that iaddr == IP if reset is asserted.
<corecode>
yes
<corecode>
the problem is that i am fetching from ip_result
<tnt>
you could combinatorially force iaddr to 0 during reset.
<corecode>
in ip_comb?
<tnt>
for instance
<corecode>
so why don't i get this problem when i simulate the design, not the synthesis result
<tnt>
not sure ... but the 'x' won't behave the same in the original verilog and in the synth result just because the order of operation isn't preserved.
<corecode>
i tried to avoid another LUT in the imem fetch path
<corecode>
but okay
<corecode>
let's keep this for now
<corecode>
yep
<corecode>
that fixed it
<corecode>
thanks!
<tnt>
The reset process and initial pipeline fill is tricky ... I also had trouble with it when I first made my cpu.
<corecode>
how did you solve it?
<tnt>
By adding resets on every FF that influence the fetch address.
<tnt>
but I don't have any direct combinatorial dependency between the RAM output and the next address because I have a pipeline.
<tnt>
The downside of the pipeline is the added jump latency of course.
<corecode>
yes
<tnt>
What's the fmax on the U4k btw ?
<corecode>
unless you have a pre-decode, maybe?
<corecode>
on this design?
<tnt>
No idea how the fabric is compared to the up5k.
<tnt>
yeah.
<corecode>
same timing as the up5k
<corecode>
says 29MHz
<corecode>
however, synopsys estimated >40MHz
kuldeep has quit [Quit: Its never too late!]
<corecode>
but the icecube2 placer is buggy
<corecode>
and can't place my design
<tnt>
Oh ok. Yeah, I built it here with up5k target at 31 MHz.
<tnt>
The synopsys 'estimates' are meaningless ... I had variation up to +- 50% of synth estimate vs actual placed timing with icecube depending on the design.
<corecode>
okay
<tnt>
What's the issue with the placer ?
kuldeep has joined #yosys
<corecode>
RAM cpu_top.iram_iram_0_0 Illegally placed at (0,21)
<corecode>
RAM cpu_top.cpu.cpu_execute.rstack.stack_mem_stack_mem_0_0 Illegally placed at (0,1)
<corecode>
used logic cells: 622
<corecode>
Packing failed due to placement violation!
<tnt>
That's huh .. weird.
<tnt>
Did you try another target ? (like up5k or hx),
<corecode>
so yosys can deal with localparams that are declared after they are being referenced
<corecode>
synopsys cannot
<corecode>
so i guess i need to make it a parameter
<corecode>
icarus can deal with it as well
cr1901_modern has quit [Read error: Connection reset by peer]
* sxpert
is having issues with synch between modules. this thing is probably more complicated than it should
* sxpert
is about to throw it all out and start over
<corecode>
what's the problem
cr1901_modern has joined #yosys
<sxpert>
corecode: well, the thing is becoming a big mess of inter-acting stall flags...
<sxpert>
it's no good, period
<corecode>
ok
<sxpert>
when it starts looking like spaghetti and timing horror, it's because it's coded the wrong way ;-)
<corecode>
any idea why this is?
<sxpert>
started with the wrong bit, I guess ;)
m4ssi has joined #yosys
<sxpert>
no problem, I'm doing this to learn, so I can start over as many times as it will take ;-)
<tnt>
sxpert: heh, I feel you. Always takes me a while to figure things out ... paper helps in my case (drawing block diagram / logic diagram / timing waveforms ...)
<corecode>
oh now synplify shits its pants
<corecode>
conflicting driver!
<sxpert>
hah !
<sxpert>
seen that before ;-)
<corecode>
but not during compile
<corecode>
but during map
<corecode>
that sounds to me like some optimization side effect
<tnt>
... or you have two drivers :p (which is valid in verilog ... and you can produce that with yosys too ... but nextpnr would complain later on)
<sxpert>
yeah
<sxpert>
maybe synplify checks that at compile time
<corecode>
@E:MF529 : | Tristates on constant net GND (in view: work.top_u4k(verilog)) triggering multiple-drivers failure:
<corecode>
i think what happens is that it can't deal with mismatched port sizes
<corecode>
and somehow decided to connect the unused net to gnd
<corecode>
and now complains that gnd is being driven
<sxpert>
there, moved everything to the attic
<sxpert>
time to start over ;)
<corecode>
are you using CVS still? :)
<tnt>
sxpert: is that your first experience with fpga btw ?
<sxpert>
tnt: yeah, apart from your basic blink
<sxpert>
corecode: god no
<corecode>
sxpert: i'm a beginner too; i noticed that heavy factoring into modules is useful
<corecode>
you can test them separately, you can synthesize them separately and see what the tool produces
<tnt>
sxpert: you sure didn't pick something trivial :p CPU are always a bit tricky with the control logic, and the Saturn is especially twisted architecture.
<sxpert>
yeah
<sxpert>
that's where the fun is ;-)
<sxpert>
tnt: but I learned from my mistakes, will start from the ground up...
<sxpert>
tnt: I did start by the instruction decoder, which was the wrong move
<corecode>
yea
<corecode>
first start with the functional units
<tnt>
yeah you probably want to start with the datapath ... see what needs to move where. Then figure out how to generate all the control signal to pilot that DP.
<sxpert>
also, maybe I need to use systemverilog and not classic verilog
<corecode>
then you can't use yosys tho
<tnt>
yosys doesn't do SV though.
<corecode>
or icarus
<sxpert>
ah
Laksen has quit [Quit: Leaving]
<sxpert>
hah !
<sxpert>
ok
<sxpert>
never mind ;-)
<corecode>
why did synplify change my reset counter to 4 bits and replaced the top 4 bits with 1s?
<corecode>
haha what is this
<sxpert>
because it tried to synplify your thing and tripped on it's own socks
m4ssi has quit [Remote host closed the connection]
<corecode>
tnt: the icecube2 placer estimates 47MHz
<corecode>
but then of course it also fails to place
<corecode>
so it might not be correct at all
<tnt>
:/ I'm wondering wtf is causing it to fail placement. Could you pastebin the complete logs ?
<corecode>
yes
<corecode>
but you can just try yourself
<tnt>
(but yeah, icecube often still beats yosys+nextpnr in fmax ATM)
<corecode>
hm, when i add the pcf, it says E2792: Instance pins_obuft_0 incorrectly constrained at SB_IO_OD location
<daveshah>
In icecube you need to use an SB_IO_OD primitive to use these pins
<corecode>
yea
<corecode>
but, how?
<corecode>
in my top design then?
<corecode>
meh
<daveshah>
Yeah
<tnt>
" unknown variable npins."
<corecode>
that means i either would have to route the enable, in, out signals all the way to the top
<daveshah>
Also beware that the ports of an SB_IO_OD primitive have no underscores unlike the normal SB_IO
<corecode>
ah yea, i had to convert this localparam to a parameter
<corecode>
or i have to put the SB_IO_OD deep into my design
<corecode>
tnt: updated
<tnt>
corecode: huh. Placed just fine here.
<sxpert>
have been getting those, am puzzled
<sxpert>
saturn_bus.v:27: warning: Port declaration of i_clk inherits dimensions from var/net.
<corecode>
tnt: !!! WHAT
<corecode>
what icecube version?
<tnt>
2017.08.27940
<tnt>
I didn't put any constraint files for the pins or anything though.
<corecode>
on what part
<tnt>
ice5lp sg48
<tnt>
4k
<corecode>
hm
<corecode>
so something in my project settings failed
<corecode>
now i made a new project and it works
<corecode>
...
<corecode>
wow, 51MHz vs 29MHz
<corecode>
that's a huge difference
<corecode>
well i guess pebkac lead to u4k support in icestorm and nextpnr
<corecode>
what could make such a significant difference?
<daveshah>
Two biggest differences are likely carry chain optimisations and placer quality
<corecode>
i guess to decide we'd have to have nextpnr place the synplify output
<corecode>
and the lattice tool place yosys output
<sxpert>
the lattice tool looks like something escaped from the early 2000
<corecode>
daveshah: is there a way to test yosys vs nextpnr? do the edifs work across?
<daveshah>
corecode: no, Yosys doesn't parse EDIF and the icecube EDIF parser segfaults on Yosys EDIFs
<corecode>
yey :/
<daveshah>
You can export Verilog from Yosys and import to icecube, although I had some trouble with that too
maikmerten has quit [Remote host closed the connection]
<corecode>
hm, what's the easiest way to selectively use SB_IO_OD...
<daveshah>
Sounds like a case of an if/generate
<emeb>
corecode: how's your u4k addition to icestorm going?
<sxpert>
tnt: ok, put down the basics, time to go to bed ;-)
<tnt>
corecode: why the ul4k btw ?
<tnt>
sxpert: o/
<emeb>
tnt: as you suggested a few days ago, I tried to build the TinyFPGA BX bootloader in icecube2 - managed to get it done but it didn't meet timing @ 48MHz.
<emeb>
best I got was ~39MHz
<emeb>
was wondering if that's what you saw too?
<emeb>
(targeting a up5k device)
dys has quit [Ping timeout: 246 seconds]
<tnt>
I'm pretty sure it met timing. I might have cheated a little by using 'typical' settings instead of 'worst case' :p
<emeb>
heh
<MoeIcenowy>
emeb: how about nextpnr?
dys has joined #yosys
chaseemory has joined #yosys
<corecode>
tnt: it's the chip i have on my board
<emeb>
MoeIcenowy: what about nextpnr?
<emeb>
tnt: Yep - changing the timing condition to Typ makes it pass
<emeb>
60MHz instead of 39
<corecode>
oh wow
<emeb>
good enough for hobby work. probably not something I'd want to ship in volume.
<corecode>
wow what on best with icecube2 it shows 83MHz for my design
<emeb>
zippy!
<emeb>
looks like the long paths in the TinyFPGA bootloader are some of the adder carry chains in the ROM address generator.
<emeb>
IIRC that's all stuff that can be made to run @ 12MHz.
<emeb>
I looked over the pull request where they split the design into 48MHz and 12MHz sections and it didn't look too bad. That hasn't been accepted yet though.
<corecode>
doesn't most of the design only have to run at much lower speeds?
<emeb>
that's my understanding
<emeb>
I haven't studied the design closely though.
<emeb>
I'm going to knock out a PCB with the USB circuit & oscillator for a UP5k / u4k SG48 package so I can try fiddling with it.
<corecode>
i still am baffled by the difference in timing between icecube and nextpnr
<emeb>
Is it due to differences in routing, or differences in the way timing is computed?
<corecode>
i don't know
<corecode>
critical path is a different one
<emeb>
do the icestorm and icecube timing estimates agree for the same design?
<corecode>
it has RAM out, 4 LUTs, carry chain, 3 more LUTs
<emeb>
all in one async path?
<corecode>
oh that is a good question - how do i get a timing report from a .asc or vlog output?
<corecode>
from clock to clock
<daveshah>
corecode: use icetime
<corecode>
thanks
<daveshah>
The timing differences are for lots of reasons
<corecode>
so there are 7 luts and routing between them
<daveshah>
one issue is how Yosys is quite poor at optimising certain things like carries
<corecode>
i don't quite understand why some luts are 1.2 and some are 1.3
<daveshah>
Another is nextpnr not being very well tuned
<daveshah>
corecode: different LUT inputs have different delays
<corecode>
out of 35ns, carry is 5.8
<corecode>
so not really much
<daveshah>
The problem is optimising around the carry chain
<corecode>
aha
tpb has quit [Remote host closed the connection]
<corecode>
icetime estimates 35MHz for the icecube output
tpb has joined #yosys
<emeb>
how well does that compare to what icecube estimates?
<corecode>
icecube says 51MHz
<emeb>
hmm... that's a fair difference for the same design.
<corecode>
yes
<emeb>
timing analysis has always seemed like it involves a lot of "art" and some luck though.