<pepijndevos>
whitequark, hi, now you know 3 people who do Ada. I'd by no means consider myself an Ada programmer, but I have patches in GHDL. I have no opinion on gnat.
<pepijndevos>
It's more like I know VHDL and "funny VHDL"
<pepijndevos>
Counterpoint: All VHDL programmers already know Ada.
<pepijndevos>
But as someone who writes in Python for the contributors, I'm sure you have strong opinions on this.
<pepijndevos>
And... uhhh, I guess you have history on your side. GHDL is pretty much exclusively written by Tristan it seems.
<pepijndevos>
daveshah, depends which part of VHDL you like "better" haha The GHDL parser is *very* comprehensive, so it probably supports more *syntax*, but a translater probably has an easier time supporting operators and types that map well to verilog.
<pepijndevos>
I would not hold my breath for a translater to preserve casting/extension/metavalue semantics.
<pepijndevos>
For example, logic operations on signed/unsigned are only a recent addition in GHDL.
<pepijndevos>
But I've talked to some people who worked on translation, and it appears to be a dead end with unresolvable issues.
AndrevS has joined ##openfpga
freemint has joined ##openfpga
AndrevS has quit [Ping timeout: 250 seconds]
pie_ has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
mwk has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
Flux42 has quit [Quit: Lost terminal]
<whitequark>
pepijndevos: :D
pie_ has quit [Ping timeout: 252 seconds]
genii has joined ##openfpga
fibmod has quit [Ping timeout: 245 seconds]
fibmod has joined ##openfpga
<Sprite_tm>
Is Yosys/nextpnr still incapable of inferring a dual-port BRAM?
<ZirconiumX>
Sprite_tm: Yosys has been able to infer dual-port BRAMs just fine for as long as I've been using it (3 months?)
<Sprite_tm>
I seem to remember it had a problem with true dual-port BRAMs, clocked in different always@ blocks...
<Sprite_tm>
Lemme put it like this: it derps in a design where I do this. Merged the always@ blocks, see if that helps...
<ZirconiumX>
Are they clocked with the same clock?
<Sprite_tm>
Yes.
<Sprite_tm>
Merging the always@ blocks still does nothing :/
<whitequark>
Sprite_tm: what does the yosys log say?
<Sprite_tm>
whitequark: Lots and lots, as usual :P what am I looking for?
<whitequark>
memory_bram
<Sprite_tm>
Sec, gotta re-run the synth...
<Sprite_tm>
Well, it says nothing with that word in it for the memory I instantiated.
<daveshah>
Is there a `Replacing memory * with list of registers` warning from the frontend instead?
<tnt>
Sprite_tm: what does the code look like ?
<Sprite_tm>
Lemme take the RAM out of the rest of the design... it's not much other logic, but it may throw Yosys up.
<Sprite_tm>
daveshah: Nope, not for that memory.
<tnt>
Sprite_tm: you're often better off having the RAM in its separate module.
<Sprite_tm>
Yeah, guess so. Thought I could get away with adding a bit more logic into it... no good.
<Sprite_tm>
Aaaah, that did the trick. Reduced the full-ness of the FPGA from 70% to 42%.
<Sprite_tm>
Can put an extra CPU or 2 in there instead of the non-bram 3K of memory.
<tnt>
lol
<whitequark>
huh what?
<whitequark>
separate module worked?
<Sprite_tm>
So, LPT: by just smashing RAM into the designs, for the cost of only a few days of debugging you can save what would otherwise have been many minutes of doing it properly!
<whitequark>
no
<whitequark>
nonononono
<whitequark>
this is a yosys bug obviously
<whitequark>
putting a RAM in the middle of a module is very much "doing it properly" inasmuch as anything written in verilog is done properly
<Sprite_tm>
E_NOCLUE tbh. May be something where I derped.
<Sprite_tm>
Bot nothing obvious I could see.
<whitequark>
can you inline it back and recheck? and post the log maybe
<Sprite_tm>
Sure, it's only a commit back.
azonenberg_work has quit [Ping timeout: 250 seconds]
<whitequark>
Read port #0 is in clock domain !~async~.
<whitequark>
Bram port B1.1 has incompatible clock type.
<whitequark>
here's the answer
yuriks has joined ##openfpga
<whitequark>
that's... interesting
ormiret has joined ##openfpga
benreynwar has joined ##openfpga
diamondman has joined ##openfpga
sorear has joined ##openfpga
cblam has joined ##openfpga
lopsided98 has joined ##openfpga
m4gul0_ has quit [Ping timeout: 250 seconds]
elms has joined ##openfpga
azonenberg_work has joined ##openfpga
jhol has joined ##openfpga
<Sprite_tm>
Hm, afaik the tech should be able to do this... I've created bram like this manually.
<whitequark>
it's not an async read port
<Sprite_tm>
Tbh, in the separate module I refactored it as all-registered because it doesn't really matter here.
<whitequark>
yes. like I said. should have inlined it back manually.
<whitequark>
anyway
<Sprite_tm>
...you sure about that? The tag ram of my cache wouldn't work if the read port couldn't be async.
<Sprite_tm>
And it works, sooo...
<Sprite_tm>
That's manually instantiated, btw.
<whitequark>
no, I'm talking about prog_mem
m4gul0_ has joined ##openfpga
jhol has quit [Ping timeout: 250 seconds]
jhol has joined ##openfpga
jhol has quit [Ping timeout: 250 seconds]
jhol has joined ##openfpga
Ultrasauce has quit [Ping timeout: 250 seconds]
Ultrasauce has joined ##openfpga
X-Scale has joined ##openfpga
freemint has joined ##openfpga
emeb has joined ##openfpga
dh73 has joined ##openfpga
Flea86 has quit [Quit: Leaving]
constantin has joined ##openfpga
<GenTooMan>
whitequark <-- this bug in yosys perhaps? https://github.com/YosysHQ/yosys/issues/1087 BRAM does require clocks to function (hence why it will say incompatible clock).
<whitequark>
yes, possible
<GenTooMan>
whitequark I have yosys 0.8 which of course has that bug, and of course I am using block ram, and of course that causes my verilog output to ... die horribly.
mumptai has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
mumptai has quit [Ping timeout: 246 seconds]
mumptai has joined ##openfpga
mumptai has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
constantin_ has joined ##openfpga
constantin has quit [Ping timeout: 276 seconds]
pie_ has quit [Ping timeout: 250 seconds]
constantin__ has joined ##openfpga
mumptai has joined ##openfpga
constantin_ has quit [Ping timeout: 246 seconds]
Flux42 has joined ##openfpga
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined ##openfpga
freemint has joined ##openfpga
dh73 has quit [Ping timeout: 260 seconds]
<TD-Linux>
do asics ever have inner tristate buses? my feeling is "no" for the same reason as fpgas but I don't do asic design
<whitequark>
i think they do but i'm not sure
<whitequark>
i mean, some asics certainly do
<whitequark>
old devices, analog-ish devices
<davidc__>
TD-Linux: as I understand it, modern stuff doesn't
<whitequark>
interesting
<davidc__>
TD-Linux: devices usually aren't routing constrained. a tristate bus just trades routing for transistors
<Ultrasauce>
didn't some cpus in the 80s have internal bus contention as a design feature
<Ultrasauce>
like with different driver impedances
Jybz has joined ##openfpga
<sorear>
I know about 80s CPUs with internal tristating and wired-OR, different drive strengths would be new to me though
constantin_ has joined ##openfpga
constantin__ has quit [Ping timeout: 276 seconds]
constantin__ has joined ##openfpga
constantin_ has quit [Ping timeout: 245 seconds]
mumptai has quit [Quit: Verlassend]
constantin__ has quit [Quit: Leaving]
<emily>
whitequark: ZirconiumX: "megawizard"...
<emily>
what a name
<ZirconiumX>
Yeah we're having a great time in ##yamahasynths
<emily>
...which is where you talk about FPGAs, naturally
<whitequark>
lol
<cr1901_modern>
It's good for IRC rooms to be off-topic
<ZirconiumX>
At least they're being used for something
<cr1901_modern>
indeed
<emily>
so uh....... anyone here like yamaha synths
<TD-Linux>
I'm already using this as a backchannel for questions that came up reading that channel :^)
<ZirconiumX>
Either way this is mostly my/Sarayan's fault and I apologise whitequark :P
* cr1901_modern
looks at the YM2151 breadboard to his side
<cr1901_modern>
yea I think I might
Jybz has quit [Quit: Konversation terminated!]
<TD-Linux>
speaking of IOB FFs.... I've previously never explicitly used them... do they get inferred if you have a ff right after your input/output?
<TD-Linux>
also does nextpnr or any other tool verify timing out of an IOB? does it just use a clock cycle for setup/hold length?
<TD-Linux>
I've totally ignored this on all my designs so far but they worked mostly because they are pretty slow (16MHz)
<whitequark>
inferred: this varies enormously between toolchains
<whitequark>
nextpnr doesn't, vivado does with an attribute
<mwk>
xilinx does it if you specify some option
emeb_mac has joined ##openfpga
<whitequark>
diamond claims to do it with an attribute but doesn't actually respect it
<whitequark>
for reasons none of us were able to understand
<whitequark>
diamond with ecp5
<whitequark>
no idea about icecube but i doubt it
<mwk>
ISE has some attributes you can specify in UCF to describe clock-to-pin / setup requirements; something like this should exist in Vivado as well
<davidc__>
I've always used the device primitive, since inference is always so variable
pie_ has joined ##openfpga
Bike has joined ##openfpga
carl0s has quit [Remote host closed the connection]