<mwk>
what's a reasonable way to cause an elaboration-time error for invalid parameter values? (I'm writing more simulation models for xilinx/cells_sim.v and would like to add some armor plating)
kuldeep has joined #yosys
citypw has joined #yosys
<ZipCPU>
An initial block with a $stop command in it
citypw has quit [Ping timeout: 265 seconds]
Jybz has joined #yosys
Jybz has quit [Quit: Konversation terminated!]
nrossi has joined #yosys
citypw has joined #yosys
emeb_mac has quit [Quit: Leaving.]
dys has joined #yosys
<pepijndevos>
I think I have lived with a confusion of what GENERIC_IOB considers an input or an output.
kraiskil has joined #yosys
<pepijndevos>
daveshah, soooo GENERIC_IOB O is the output of the input buffer, and I is the input to the output buffer. But is INPUT_USED supposed to indicate that the Input buffer is used, or that the input pin of the output buffer is used?
<pepijndevos>
Seems the latter
<daveshah>
INPUT_USED was supposed to mean it is used as an input
<daveshah>
ie the O pin is used
<daveshah>
Maybe I messed this up
<pepijndevos>
Yea, it seems the other way around. I was creating input pins for my blinky LEDs hehe
citypw has quit [Ping timeout: 276 seconds]
<pepijndevos>
parameter \OUTPUT_USED 1
<pepijndevos>
parameter \INPUT_USED 0
<pepijndevos>
connect \O \clk
<daveshah>
Right could you fix that in the packer and PR it?
<pepijndevos>
Sure... but... part of me feels it kinda makes sense the way it is.
<pepijndevos>
And... I'm confused how this actually happens
<pepijndevos>
Yea... remember you told me to do constraints you have to initialise the IOB yourself?
<pepijndevos>
Well...
<pepijndevos>
I uploaded my blinky, and... it doesn't blink, but it outputs *something* and accepts my bitstream, so that's a pretty good start of the day I'd say.
kraiskil has quit [Ping timeout: 246 seconds]
<daveshah>
Very good!
<daveshah>
Usually my first tests are output at constant 0 or 1
<daveshah>
Then input to output direct
<daveshah>
Then a NOT gate
<daveshah>
Then it might be worth trying blinky
<pepijndevos>
Yea, doing that now.
<pepijndevos>
It likes constants less than blinky it seems
<daveshah>
Good start, at least that means outputs work
<pepijndevos>
No I mean... if I do constants, nothing happens. If I do blinky, it at least lit some random LEDs
<pepijndevos>
Well, nothing: all LEDs are off
<pepijndevos>
It's doing something really fishy, routing them to a DFF
<pepijndevos>
I need to somehow tell Nextpnr about my VCC and VSS nets.
<daveshah>
If you don't tell it about them then it will use a LUT
<daveshah>
However, I think the LUT init value it uses might be wrong for Gowin
<daveshah>
ie just a single 1 for Vcc assuming unused LUT inputs are 0 rather than all 1s
<pepijndevos>
Ah, it might actually be an issue with my unpacker, which might not find a LUT with all 1's which are all 0s in the bitstream.
<pepijndevos>
But how would I express a constant net?
<pepijndevos>
I think I already create VCC and VSS nets for the pips, but they are just normal nets, and nothing outputs to them.
<daveshah>
You would need to create a bel with Vcc and Gnd pins that map to those wires
<daveshah>
And then get the packer to use that bel rather than creating constant driving LUTs
<daveshah>
For now I'd try and get the constant driving LUTs to work
<daveshah>
Less efficient, but in the spirit of generic - some FPGAs don't have omnipresent Vcc and Gnd (e.g. ICE40)
<pepijndevos>
But a bell that doesn't have a location on the fpga
<pepijndevos>
(I actually expand init values by repeating them so 01 would become 0101010101 and 1 becomse 11111111 so that should not be a problem)
<daveshah>
You give it an arbitrary one
<daveshah>
It's not a real bel
<sorear>
am I the only person bothered by using "vcc and gnd" as notation for logic 1 and 0? for all we actually know the ice40 fabric could be active-low internally
<daveshah>
It's just a way of accessing the gloval Vcc and Gnd wires
<pepijndevos>
Ohi I see
<daveshah>
Well, several fpga companies also use this notation...
<daveshah>
(and given the schematics in patents I'm pretty sure it isn't...
<pepijndevos>
Gowin even mixes VSS and GND
<whitequark>
yamaha has a chip with only vss and gnd
<whitequark>
no other power pins :)
<pepijndevos>
Wait, that's actually odd... their global names are VSS and VCC, mixing BJT and CMOS naming.
<daveshah>
Xilinx tends to use Vcc and Gnd
<daveshah>
Because their FPGAs are bjt based :p
<pepijndevos>
Their primitives are VCC and GND, but the wire name is not.
<daveshah>
For the ECP5 it was easy as you just send the bitstream as the payload to an SVF command after a few initial setup commands
<daveshah>
Not sure how Gowin works
<daveshah>
If the vendor tools can create an SVF file then you could work from that
<ZirconiumX>
I could probably look at how quartus does it for the CV
<daveshah>
I'm sure Quartus can create an SVF, I think I've even done it before
<ZirconiumX>
Yep
<daveshah>
No idea what that SVF looks like though
<pepijndevos>
So this SVF file tells openocd all it needs to program the things?
<ZirconiumX>
Basically, yeah; it's a command dump
<pepijndevos>
Hmmm, lemme see if the Gowin IDE has anything like that or I need to somehow capture it.
<daveshah>
A logic analyser on the JTAG would be the way forward otherwise
<daveshah>
Looks like sigrok even has a JTAG decoder
<daveshah>
Haven't tried it though
<ZirconiumX>
Not necessarily. It's going over USB, so you could Wireshark it
<whitequark>
that'd probably be more annoying tbh
<pepijndevos>
Yea, but I have wireshark, I misplaced my logic analyser :(((
<ZirconiumX>
It does annoy me that Wireshark don't let you build message streams over USB because USB packets are supposed to be independent
* pepijndevos
needs a glasgow
<ZirconiumX>
We all do
<whitequark>
:D
<pepijndevos>
Actually... JTAG is kind of a giant gap in my knowledge. It's like this magic thing that "other people" use to debug their chips or something. I also seem to be under the impression it's super hard to use, requires expensive hardware, and gives you super powers.
* pepijndevos
programms FPGAs using JTAG FTDI chips without thinking about it
<whitequark>
it doesn't require expensive hardware at all
<whitequark>
you need, what, five GPIOs?
<whitequark>
now, *very fast* JTAG does
<ZirconiumX>
Y'know, I'm suddenly very glad Altera changed their SKU naming scheme. I'm sure it wouldn't be confusing to have ecppack and ep5cpack.
<pepijndevos>
I don't see any SVF option in Gowin IDE or programmer.
<daveshah>
It might be called deployment or similar
<daveshah>
Such an option would be used for bulk testing/programming with industrial programmers, for example
<pepijndevos>
It's not helpful that the GUI tool doesn't work on my machine at all.
<mwk>
it's not about the init value, btw, that part is actually easy to fix
<FSM_Dude>
Hmm okay
<FSM_Dude>
I just face one 'big' problem at the moment
<FSM_Dude>
I'm trying to add states to the state machine, but that seems to be tricky in Yosys
FabM has quit [Ping timeout: 240 seconds]
<mwk>
well, you'd have to parse all the params into something sane, possibly enlarge the state encoding size, add whatever transitions you want, and reencode
FSM_Dude has quit [Ping timeout: 260 seconds]
FSM_Dude has joined #yosys
<FSM_Dude>
mwk So what I do now is: add an encoding type to the fsm_recode.cc; like Yosys already has "one-hot" or "binary", I added the functionality of "my_encoding". So now, you can run: fsm_recode -encoding my_encoding.
<FSM_Dude>
what my_encoding does, is encode the state signals from the fsm_data in a certain way, and add additional states to the fsm_data's state table. Also I add the necessary transitions.From there on, I continue the synthesis process, but somehow I end up with no logic and cells in the end
<mwk>
that's worrying
<mwk>
it sounds like it should work, fsm_map doesn't really do anything smart
<FSM_Dude>
I tried it my new encoding type on a small FSM
<FSM_Dude>
and after running fsm_recode -encoding my_encoding, I ran fsm_info and I printed the fsm to a png
<FSM_Dude>
which was the exact result I hoped for
<FSM_Dude>
but then continuing the synthesis process, something else seem to fail
<FSM_Dude>
on the other hand, I'm quite new to this all, so it might be my incompetence
<mwk>
could you show me fsm_info before and after?
FSM_Dude has quit [Ping timeout: 260 seconds]
qu1j0t3 is now known as OK_b00m3r
dys has quit [Ping timeout: 276 seconds]
<ZirconiumX>
daveshah: So, I copied synth_intel and modified it a bit to be called synth_intel_alm, but Yosys does not seem to be picking it up, so I've evidently missed a step.
<ZirconiumX>
This command runs synthesis for ALM-based Intel FPGAs.
<ZirconiumX>
Yay
<daveshah>
We've all been there
<ZirconiumX>
The next question is: can I actually compile anything with it?
<ZirconiumX>
Answer: yes, but it then crashes kind of oddly.
<ZirconiumX>
I'm probably being an idiot again
<ZirconiumX>
Yep.
<daveshah>
Oh BTW,the Yosys makefile strips binaries before installing them
<daveshah>
so for dev it's usually best not to use installed yosys
<ZirconiumX>
Yep, those commands get printed from the Makefile
<daveshah>
at least if you want decent debug info
Jybz has joined #yosys
Jybz has quit [Client Quit]
<cr1901_modern>
Modern gcc does something similar, except the Makefile command to install stripped binaries to --prefix is "install-strip" instead of "install". So they got it _half_ right.
<ZirconiumX>
Right, the test run seems to work. Now to adapt my script pass for this.
Jybz has joined #yosys
bobzoidting has joined #yosys
adjtm has joined #yosys
Jybz has quit [Quit: Konversation terminated!]
dys has joined #yosys
<ZirconiumX>
How much more efficient is cmp2lut compared to letting ABC figure it out? Has anybody tried to quantify that?
<daveshah>
the problem isn't abc per se, but yosys using carries
<daveshah>
that then limit abc's optimisation
<whitequark>
cmp2lut should not exist
<whitequark>
instead lut mapping should be able to use whiteboxes
<daveshah>
but this is more about optimisation than mapping
<daveshah>
whitebox aware fine grain optimisation would eliminate it
<ZipCPU>
daveshah: Have you ever used any of the DELAYF elements/
<ZipCPU>
?
<whitequark>
would it?
<daveshah>
or more, combined optimisation and mapping
<daveshah>
not so much cmp2lut, but the example I think of is (7-x) on a 8-input mux select input
<daveshah>
If you don't have hard blocks in the way, you can optimise and map the mux to LUTs with the data inputs reversed
<daveshah>
perhaps I'm not explaining this well
<ZipCPU>
Looks like I jumped in in the middle of a conversation
<daveshah>
but the core problem isn't just local mapping of the hard blocks to logic
<daveshah>
there's also the bigger decision where hard blocks prevent optimisation opportunities elsewhere
<daveshah>
it's certainly an interesting thing to think about and something that could well be done better than abc does it
<daveshah>
this uses one of the built in delay modes
<ZipCPU>
Is there any particular trick to it? I'm trying to adjust one and ... it doesn't seem to be adjusting. Do need to hold the MOVE pin high for any particular length of time for example?
* ZipCPU
opens the link
<daveshah>
I don't know, tbh
<daveshah>
I've only ever used fixed delays
<daveshah>
I believe it is edge triggered on move
<daveshah>
I presume you have LOADN high?
<ZipCPU>
Yes.
<daveshah>
worth noting the step size is pretty small - something like 60ps
<ZipCPU>
It doesn't ever seem to be setting the CFLAG high when I raise the delay
<daveshah>
It is possible there is a trellis bug here
<ZipCPU>
Any suggestions?
<daveshah>
Hang on, I'll have a look
<ZipCPU>
Thanks!
<daveshah>
Yes, I can see a missing database bit
<ZipCPU>
Also, should the parameter values show up in the json file? DEL_MODE and DEL_VALUE?
<janrinze>
daveshah: in nextpnr the posedge to posedge of the global clk is 9.9 ns yet nextpnr tells me the max frequency is 70.61 Mhz. how does that work? does it add the I/O async times?
emeb_mac has joined #yosys
<daveshah>
ZipCPU: no, not if they are not assigned values
<daveshah>
janrinze: hmm, might be a bug - can you post the path report?
<ZipCPU>
Ok
<ZipCPU>
The path report? You mean the log from running nextpnr-ecp5?
<daveshah>
That was for janrinze :)
<janrinze>
will do
<ZipCPU>
Oh, sorry, that was to janrinze ;)
<janrinze>
:D
<daveshah>
I've found what I think is the delay issue. I just need to patch trellis and nextpnr now...
<tpb>
Title: how to read the path report. · Issue #354 · YosysHQ/nextpnr · GitHub (at github.com)
<daveshah>
ZipCPU: can you try again with latest nextpnr and trellis (if it still fails, then I'll look further on hardware tomorrow)
<ZipCPU>
Absolutely! Thanks!
<janrinze>
daveshah: where do i send the json?
<janrinze>
daveshah: and the cpu runs at.. 96MHz without errors :D
<daveshah>
Either attach it to the issue, zipped, or email it to me at dave@ds0.me
<daveshah>
That's probably more to do with the margin at room temperature with a decent die than anything else...
stzsch has quit [Ping timeout: 252 seconds]
<janrinze>
daveshah: 35% faster is within 'normal' range? I have not been able to 'overclock' designs before with the HX8K but if ECP5 is more lenient then that's nice to know.
<daveshah>
It certainly seems doable
<daveshah>
Maybe iCE40 devices have less margin
<daveshah>
What speed grade is your ECP5 BTW? I have a suspicion that if Lattice have too many good -8 devices then they'll just sell them as -6 as artificial market segmentation
<janrinze>
daveshah: it's a -8
<daveshah>
That would get you at least 35% if that happened
<daveshah>
Oh, nevermind that idea then
<janrinze>
do they have a -10? ;D
<daveshah>
Well, they have the 5G parts
<janrinze>
it's a 5G
<daveshah>
Ah, they are like a -9 already because of the overvoltage
<daveshah>
but that is taken account of already in the numbers
<janrinze>
I use the lattice ecp5 board. (the one without the PCIe connector)
<janrinze>
uploaded the json file.
<janrinze>
i'm going to test 110 MHz too :-)
<janrinze>
ok. that's too much for the monitor.
nrossi has quit [Quit: Connection closed for inactivity]
<daveshah>
janrinze: Have pushed a fix to nextpnr master
<daveshah>
unfortunately the path was wrong, the 68MHz was correct...
<janrinze>
it will take a while to build. I will keep am eye out on the margins allowable for this ecp5. 68MHz vs 96MHz is nice to keep in mind. Of course just for fiddling, not for stable.
kraiskil has quit [Ping timeout: 240 seconds]
<ZipCPU>
daveshah: nextpnr is now crashing on an assertion_failure, in nextpnr.h:340
<daveshah>
ZipCPU: can you get a backtrace with gdb/coredumpctl/etc?
<daveshah>
It is possible this is from another recent change
<ZipCPU>
It says, "terminate called after throwing an instance of nextpnr_ecp5::assertion_failure what(): Assertion failure: is_string (/home/dan/work/rnd/opencores/tools/nextpnr/common/nextpnr.h:340)
<daveshah>
ZipCPU: can you run `gdb --args nextpnr-ecp5 --json .....`, `run` and then print the stack trace pointing to where the assertion failure is?