<tpb>
Title: [Eda-dev] 1st time silicon success on qflow! (at opencircuitdesign.com)
citypw has joined #yosys
rohitksingh has joined #yosys
SpaceCoaster has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Remote host closed the connection]
lutsabound has quit [Quit: Connection closed for inactivity]
danieljabailey has joined #yosys
rohitksingh_work has joined #yosys
<emeb_mac>
so that opencores osdvu UART I used in my icestick 6502 demo has some very weird stuff going on in it.
<emeb_mac>
in particular, the guts is all one synchronous process - blech.
<emeb_mac>
and to top it off, they used blocking assignments for everything.
<emeb_mac>
yosys mostly handled it OK, but there was one glitch where it crashed when I tried to use one of the outputs. I had to add some extra logic on the outside to make it work.
<emeb_mac>
during ABC step I'd get this: ABC: Warning: The network is combinational (run "fraig" or "fraig_sweep").
<emeb_mac>
and then within a few more lines of the output log it would throw an exception and crash
danieljabailey has quit [Ping timeout: 245 seconds]
<emeb_mac>
tnt: god help me - studying the cc65 docs to figure out how to make a custom target for this configuration. :P
<tnt>
emeb_mac: I guess you just need driver for the serial ?
<emeb_mac>
tnt: that, plus the linker scripts and startup code.
<emeb_mac>
but I've already written most of the serial I/O routines needed so it should go together pretty well.
<emeb_mac>
there's a tutorial in the cc65 docs that pretty much lays out what's needed for an FPGA-based 6502 that's similar to what I did.
<tnt>
that's nice of them :)
<emeb_mac>
tnt: the makefile you linked has all kinds of cruft in it for existing 6502 systems (Commodore/Apple/Atari/etc) that's completely useless for this application. Would end up stripping 90% of that out.
<emeb_mac>
using the icestick limits the amount of ROM/RAM to just 8kB total and the system as-is uses about 80% of the fabric so this is nearing the limits.
<emeb_mac>
moving to a u4k or up5k will significantly increase the memory and periphs possible. SPRAM on the up5k opens things up significantly.
<emeb_mac>
but that'll wait until morning.
emeb_mac has quit [Ping timeout: 245 seconds]
leviathanch has joined #yosys
danieljabailey has joined #yosys
citypw has quit [Ping timeout: 244 seconds]
m4ssi has joined #yosys
danieljabailey has quit [Ping timeout: 244 seconds]
leviathanch has quit [Remote host closed the connection]
<corecode>
woh these ecp devboards are expensive
rohitksingh_work has quit [Read error: Connection reset by peer]
<daveshah>
The LFE5UM5G-85F-EVN isn't bad
<daveshah>
$99 for the biggest ECP5 and a year's diamond license
<ylamarre>
Define expensive?
<corecode>
oh you need a diamond license to use the ecp5?
<corecode>
that's a downer
<daveshah>
Yes, you need one to use any of the with SERDES variants
<daveshah>
The non SERDES ECP5s don't need a license
<corecode>
ok
<corecode>
crazy that this is a business model they can do
<daveshah>
I think it's so they can give them for free to their big customers, to make those customers feel special
<corecode>
lol
<srk>
the rest of us needs to wait for RE efforts and opensource toolchain :D
m4ssi has quit [Ping timeout: 244 seconds]
m4ssi has joined #yosys
leviathanch has joined #yosys
rohitksingh has joined #yosys
develonepi3 has joined #yosys
citypw has joined #yosys
emeb has joined #yosys
leviathanch has quit [Read error: Connection reset by peer]
proteusguy has joined #yosys
gsi_ has joined #yosys
gsi__ has quit [Ping timeout: 268 seconds]
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #yosys
citypw has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 245 seconds]
m4ssi has quit [Remote host closed the connection]
<daveshah>
placer_heap_ddrn was a rebase of placer_heap onto the ddr3 changes
<daveshah>
The latter are now merged into master
<daveshah>
And placer_heap/#219 are on top of that (and should be used(
<keesj>
is the physical constraint file format documented somewhere?
<daveshah>
No, it's a vaguely extended variant of the icecube format
<keesj>
ok
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Remote host closed the connection]
<somlo>
daveshah: I've been using #219 for a few weeks now, as it's awesomely fast compared to *not* using it -- works great for my use case (rocket-chip on ecp5), will try using it on the ddr3 litedram SoC today...
maikmerten has joined #yosys
<daveshah>
Awesome, I'm hoping to have it upstreamed fairly soon
proteusguy has quit [Ping timeout: 250 seconds]
<keesj>
can I add verilog files while in the yosys shell ? e.g. something like add but for verilog files
<corecode>
hm, so now my simulation works, but doesn't seem to work on the fpga?
<tnt>
corecode: what are you trying to run ?
<corecode>
my forth cpu
<tnt>
on what board ?
<corecode>
my own, u4k
<corecode>
must be my mistake
<corecode>
pre-synthesis simulates right, post-synthesis does not
<corecode>
my write strobe gets lost
<ylamarre>
sim/synth mismatches are my favorites <3
<ZipCPU>
ylamarre: I wrote about that once some time ago ...
<ylamarre>
Most of the time they are uninitialized signals getting compared to 0.
<ZipCPU>
I tried to categorize as many sim/synth mismatches as I could get ahold of--thanks to the reddit folks
<ZipCPU>
Uninitialized stuffs ... formal usually finds that for me, so that much is fairly simple
<ylamarre>
ZipCPU: Hi, haven't had time to go through all your stuff, but from what i've looked there were some very good articles,
<ZipCPU>
Thanks!
<tnt>
post-synthesis simulation is something I almost never do. Actally I rarely have something working in simulation and not in real hw.
<corecode>
wel this one doesn't :/
<ZipCPU>
There's an icebox_vlog program that makes post-synthesis simulation very possible, even with Verilator. Not sure it works with the u4k or not.
<tnt>
do you have an explicit reset line ? (rather than relying on reg x = 1'b1) ?
<corecode>
ZipCPU: it does
<corecode>
i have a reset counter
<corecode>
haha
<corecode>
oh man, what a dumb mistake
<corecode>
always @(posedge clk) if (reset) sig <= 0; else if (clk) sig <= somethingelse;
<corecode>
not attentive, added a if(clk)
<corecode>
unclear why this made it not synthesize "properly"
<corecode>
and now it works!
<tnt>
if rising_edge(clk) ... VHDL FTW !
<corecode>
not sure how that would have helped
<tnt>
corecode: congrats :)
<tnt>
That's the 'gotcha' with verilog ... if you deviate from the best practice / templates ... you get crap synthesis results
<ylamarre>
Where as with VHDL you'd get none?
<tnt>
exactly. with vhdl it would throw an error :)
<tnt>
(or you just can't ... like there is no blocking / non-blocking stuff in vhdl so you can't get it wrong)
<ylamarre>
Well, there is variables vs signals, but, I guess those are not exactly the same...
<corecode>
but shouldn't synthesis and simulation always agree?
<tnt>
yeah, variables are local to the process.
<ylamarre>
corecode: LOL
<corecode>
well, if not, there must be a bug in the implementations
<ylamarre>
Well the uninitialized compare to 0 is a good example of both implementation being rigth, but still mismatching.
<tnt>
corecode: no ... verilog allows you to describe non-deterministic logic.