proteusguy has quit [Remote host closed the connection]
rohitksingh has joined #yosys
_whitelogger has joined #yosys
<pepijndevos>
ZirconiumX, currently the muxes are defined in both the library and as a techmap. Can one of them go?
<pepijndevos>
../74_models.v:12: Module 74AC151_1x1MUX8 was already declared here: 74series.v:141
emeb_mac has quit [Ping timeout: 272 seconds]
dys has quit [Ping timeout: 248 seconds]
<pepijndevos>
Awesome, I got my synthesized 74xx counter to simulate
<pepijndevos>
Now trying to hunt down where ZirconiumX got these benchmark files and see if they have easy to add testbenches.
dys has joined #yosys
<ZirconiumX>
pepijndevos: no; techmap needs them to map large muxes, and ABC can synthesise functions out of muxes, too
<ZirconiumX>
Oh, you generated a model from the liberty file
<pepijndevos>
Exactly, so the generated model is conflicting with the techmap
<ZirconiumX>
So remove the generated model :P
<pepijndevos>
But I need all the other ones.
<ZirconiumX>
Do you?
<pepijndevos>
What I think is more sane is to load the liberty file in the script and remove them from models.
<ZirconiumX>
One question is whether the liberty models are black boxes or not
<pepijndevos>
depends how you load them. read_liberty -lib makes black boxes
<pepijndevos>
So these can then be omited from 74_models.v
<ZirconiumX>
Okay, I'll try to make a model for things like the 74283
<pepijndevos>
Huh?
<pepijndevos>
Hold on... I'll try if this works and send a pr so you can see what I'm doing
<pepijndevos>
no need to rewrite all the things just yet.
<pepijndevos>
Huh, I just plainly deleted the models from 74_models.v and it does not even complain.
<pepijndevos>
I don't think it's using those muxes
<ZirconiumX>
It is, as far as I can tell
<ZirconiumX>
But presumably it's synthesising the model from the liberty file
<pepijndevos>
Yea, but I think the mux techmap is not generating any. If I completely omit the models.v it complains it's missing the adder, but if I removet the verilog mux def it's still happy.
<pepijndevos>
Anyway, pushing changes
mms has joined #yosys
<pepijndevos>
ZirconiumX, do you want my simulation stuff too? (possibly in a new branch/pr)
<tpb>
Title: Remove duplicate models by loading the liberty ones by pepijndevos · Pull Request #2 · ZirconiumX/74xx-liberty · GitHub (at github.com)
<pepijndevos>
I only have a very simple simulation now, trying to find something more interesting and elaborate.
_whitelogger has joined #yosys
proteusguy has joined #yosys
<pepijndevos>
Hrm, the bram doesn't have a verilog model either obviously...
<pepijndevos>
Commenting out that pass, I can run the picorv32 testbench, but it's not working correctly.
<pepijndevos>
ZirconiumX, I've been staring at gtkwave to find the difference between the original simulation and the synthesized one and... I have no clue what is going on. Things seem to be not initialised and spread XXXXX like wildfire.
<ZirconiumX>
Esh
<ZirconiumX>
I've just been trying to synthesize things, but apparently I didn't test it properly too.
<ZirconiumX>
Hmm.
fsasm has joined #yosys
<pepijndevos>
This seems a reasonable observation ;)
<pepijndevos>
Glad this came to light before you order PCB's for your 1k chips riscv CPU ;)
<pepijndevos>
Honestly, it might be a better idea to write some tests than try to debug picorv32.
<pepijndevos>
IIRC there are various types of DFF with reset and initial values and stuff. Maybe one of those is broken.
<pepijndevos>
I'm going to add more stuff from yosys-bench that has verilog testbenches, which are a whole 4 tests.
gsi__ is now known as gsi_
<pepijndevos>
ZirconiumX, I've added a bunch more simple benchmarks, which should help pin down the problem.
nengel has quit [Ping timeout: 246 seconds]
<pepijndevos>
In particular cic5 is pretty simple and also turns into XXXX pretty quickly.
attie has joined #yosys
<pepijndevos>
dspmac also produces xxxx
<ZirconiumX>
Hmm...
<ZirconiumX>
pepijndevos: file an issue, please
<pepijndevos>
Sure. I'll spend a bit more time trying to figure out what is going on, and make a nice issue. So far I've just been piling commits onto the PR.
<ZirconiumX>
I'll review them when I get back from the shop
<pepijndevos>
yay
<pepijndevos>
At this point I'd be really happy if Icarus could treat an X value as an error and tell me where it happened.
<ZirconiumX>
The most boring approach is to go through the Yosys script one command at a time and write_verilog
<pepijndevos>
This might be a very good idea, because the end result is... not okay.
<pepijndevos>
Basicallly there is nothing left except the output DFF.
<pepijndevos>
Such optimize, many efficient, wow
<pepijndevos>
The final opt pass deletes everything :/
<pepijndevos>
Ahhh... I think I know... it is totally my own fault... maybe
<pepijndevos>
YAY it works... at least I'm getting *something"
<pepijndevos>
Yea, it's definitely not correct yet. But... it does stuff, so that's an improvement.
fsasm_ has joined #yosys
fsasm_ has quit [Remote host closed the connection]
fsasm has quit [Ping timeout: 245 seconds]
<pepijndevos>
welp... I'm not convinced I got the order of the mux pors right...
<pepijndevos>
yea... my muxes are still broken.
rohitksingh has quit [Ping timeout: 272 seconds]
<pepijndevos>
Basically $_MUX4_ has a different idea of what things mean than 74AC153, and I know neither...
cr1901_modern has quit [Read error: Connection reset by peer]
voxadam has quit [Ping timeout: 252 seconds]
<pepijndevos>
ZirconiumX, unless I'm being thick, your S0-S2 seem reversed from the datasheet?
voxadam has joined #yosys
<ZirconiumX>
Ah, possibly?
<pepijndevos>
Ok, dspmac works now
<pepijndevos>
But that's not using mux8
<pepijndevos>
YESSSSSSS!!!
<pepijndevos>
PicoRV32 works!!!
<ZirconiumX>
Woo
<ZirconiumX>
How many chips?
<pepijndevos>
Oh, not sure. Will check.
<pepijndevos>
Didn't change that part though.
cr1901_modern has joined #yosys
<pepijndevos>
Oh, I disabled bram though, because it doesn't have a verilog model, so that's going to be lots of extra memory chips I guess
<pepijndevos>
859??
<pepijndevos>
If I reenable the pass it makes IDT7132: 8
<ZirconiumX>
Yep
<ZirconiumX>
BRAM is a pretty major optimisation
mms has quit [Ping timeout: 246 seconds]
<pepijndevos>
As in... to-be-optimised? Pretty minor difference in chip count at least in the picorv32
proteusguy has quit [Remote host closed the connection]
emeb has joined #yosys
<pepijndevos>
huh... I'm confused
<pepijndevos>
it seems to add the IDT chips, but does not remove and others
<pepijndevos>
Like... if I comment out "memory_bram -rules ../bram.rules" I get 8 *less* chips.
<pepijndevos>
That seems broken...
proteusguy has joined #yosys
pie_ has quit [Ping timeout: 258 seconds]
cr1901_modern has quit [Ping timeout: 258 seconds]
trmm has joined #yosys
<trmm>
Is there a way to enable pullups on a ECP5 bidirectional pin with the TRELLIS_IO?
<trmm>
ecp5/cells_sim.v doesn't have a pullup parameter, and I'm not sure where else to look.
<daveshah>
Use the PULLMODE attribute either on the TRELLIS_IO or in the LPF
<daveshah>
`(* PULLMODE="UP" *)` or `(* PULLMODE="DOWN" *)` as an attribute
rohitksingh has joined #yosys
<trmm>
Ah, I had seen that used in non-LPF programs to assign pins. Is that a long-term feature or a transitional one?
<daveshah>
Everything should really be LPF now
<daveshah>
the attributes were a hack before I got round to writing a LPF parser
pie_ has joined #yosys
<trmm>
It would be nice to have pullups selectable in the verilog so that the LPF can be shared between projects that might have different pullup requirements.
cr1901_modern has joined #yosys
indy has quit [Ping timeout: 272 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined #yosys
<pepijndevos>
ZirconiumX, any prefs what I write the KiCad stuff in? Since it's s-expr based, I'm thinking about Clojure(Script), but if you prefer Python(already used) or something else, no problem.
<ZirconiumX>
I can't speak s-expr, sadly
<ZirconiumX>
Not for lack of trying
<ZirconiumX>
I'd prefer Python
<pepijndevos>
Alright
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #yosys
indy has joined #yosys
dys has quit [Ping timeout: 258 seconds]
dys has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
cr1901_modern has quit [Ping timeout: 246 seconds]
<ZirconiumX>
I'm having issues getting Yosys to infer a (6-port) block RAM
<ZirconiumX>
It handles 3-port just fine
<ZirconiumX>
But I need 6
<mwk>
what... what kind of hardware actually has a 6-port block RAM?
<ZirconiumX>
Well, I need two pairs of two read/one write ports
<azonenberg>
Did someone say multiport register file?
<ZirconiumX>
azonenberg: I'm the one sorear summoned you for
<ZirconiumX>
(hello!)
<ZirconiumX>
I've been commissioned to make a SuperH SH4a core for emulation purposes
<ZirconiumX>
However, the SH4a is two-way superscalar
<ZirconiumX>
Which means I need multiple write ports
<azonenberg>
So, multiple read ports is obviously an easy problem
<azonenberg>
just replicate the array
<ZirconiumX>
sorear linked an interesting paper, and said you could help
<ZirconiumX>
Yosys can do that already
<azonenberg>
Yeah so as far as multiple write ports, the method i've preferred most is probably the paper sorear linked
<azonenberg>
laforest's paper on XOR based multiport memory?
<ZirconiumX>
Yep
<azonenberg>
if not, that's the method i suggest
<azonenberg>
Area scaling is O(W(W+R))
<azonenberg>
or O(W^2 + WR)
<azonenberg>
So write ports are expensive and read ports comparatively cheap
<ZirconiumX>
I hopefully only need two of them right now
<daveshah>
Given this is only 32 deep, I do wonder if LVT would be more efficient here
<azonenberg>
Possible
<azonenberg>
in my case i was going with a multithreaded design
<azonenberg>
so i had 32 regs * 32 threads
<ZirconiumX>
There are more registers in SH4, but I haven't figured out where I wanted to put them
<azonenberg>
i used a full block ram for each bank of reigsters
<daveshah>
At 32x32 it's marginal whether DRAM or BRAM would be the better choice
<azonenberg>
Yeah
<azonenberg>
I have not done a superscalar processor that was not also multithreaded so i can't suggest much there
trmm has quit [Ping timeout: 272 seconds]
<sorear>
ZirconiumX: so how complete is this supposed to be, does it target cycle accuracy, will it be public, and language of choice?
<ZirconiumX>
Yes, yes (license yet to be determined, but open source), Verilog
<ZirconiumX>
Not very for the completeness at the moment
<sorear>
ZirconiumX: I’m wondering if you just bit off a project larger than the multi person multi year j-core.org (architecturally sh2 compatible but slower, single issue)
<ZirconiumX>
I'm not being paid to finish this, I'm being paid to start it :P
<ZirconiumX>
And yes, I'm aware of the J2
<ZirconiumX>
But byuu managed to perfectly emulate the SNES
<ZirconiumX>
A CPU is a bit less complicated than a game console, even if it is more recent
<ZirconiumX>
I'm reading LaForest's paper and slides, but I still don't think I quite get how the LVT itself is made
<sorear>
haha. good luck with that, honestly
<daveshah>
aiui, the LVT is small enough that a bit blasted dual write port RAM would be fine
<daveshah>
It is only 32 entries
<daveshah>
1 bit each
<ZirconiumX>
Ah, I think I just grokked it
<ZirconiumX>
Though I'm not smart enough to figure out how to synthesise a PLL or whatever for the double clocking
<ZirconiumX>
I think I can figure out how to divide a clock through a counter, but not multiply it
<sorear>
maybe you’ll have a MMU public before them
<ZirconiumX>
Well, the j-core website appears to be down, so I'm in no rush