*** tpb has joined #yosys | 00:00 | |
*** kuldeep has quit IRC | 00:10 | |
*** kuldeep has joined #yosys | 00:11 | |
*** dys has quit IRC | 00:26 | |
*** xerpi has quit IRC | 00:34 | |
*** seldridge has joined #yosys | 00:38 | |
*** pie_ has quit IRC | 00:44 | |
*** pie_ has joined #yosys | 00:45 | |
*** pie__ has joined #yosys | 00:46 | |
*** pie_ has quit IRC | 00:47 | |
*** pie__ has quit IRC | 00:53 | |
*** emeb has quit IRC | 01:02 | |
*** emeb_mac has joined #yosys | 01:05 | |
*** kuldeep has quit IRC | 01:33 | |
*** kuldeep has joined #yosys | 01:37 | |
*** pie_ has joined #yosys | 01:58 | |
*** promach_ has joined #yosys | 02:02 | |
*** gyroninja has quit IRC | 02:04 | |
*** pie_ has quit IRC | 02:51 | |
*** pie_ has joined #yosys | 02:52 | |
*** leviathan has joined #yosys | 03:31 | |
*** leviathan has joined #yosys | 03:32 | |
*** digshadow has quit IRC | 03:45 | |
*** seldridge has quit IRC | 04:06 | |
*** digshadow has joined #yosys | 04:31 | |
*** gyroninja has joined #yosys | 04:55 | |
*** leviathan has quit IRC | 05:06 | |
*** dys has joined #yosys | 05:53 | |
*** _whitelogger has quit IRC | 06:22 | |
*** _whitelogger has joined #yosys | 06:24 | |
*** xerpi has joined #yosys | 06:25 | |
*** seldridge has joined #yosys | 06:47 | |
*** gyroninja has quit IRC | 06:53 | |
*** pie_ has quit IRC | 07:04 | |
*** emeb_mac has quit IRC | 07:05 | |
*** sklv has joined #yosys | 09:14 | |
*** _whitelogger has quit IRC | 09:37 | |
*** _whitelogger has joined #yosys | 09:39 | |
*** xerpi has quit IRC | 10:36 | |
*** _whitelogger has quit IRC | 10:49 | |
*** _whitelogger has joined #yosys | 10:51 | |
*** GuzTech has joined #yosys | 11:40 | |
*** dys has quit IRC | 12:26 | |
*** promach_ has quit IRC | 12:35 | |
*** ZipCPU|ztop has quit IRC | 12:40 | |
*** worldchat has joined #yosys | 12:41 | |
*** dys has joined #yosys | 12:48 | |
*** promach_ has joined #yosys | 14:11 | |
*** GuzTech has quit IRC | 14:34 | |
*** emeb_mac has joined #yosys | 14:42 | |
*** clifford has joined #yosys | 14:47 | |
*** ChanServ sets mode: +o clifford | 14:47 | |
*** clifford has quit IRC | 14:49 | |
*** leviathan has joined #yosys | 14:55 | |
*** leviathan has quit IRC | 15:03 | |
*** clifford has joined #yosys | 15:03 | |
*** ChanServ sets mode: +o clifford | 15:03 | |
*** leviathan has joined #yosys | 15:03 | |
*** clifford has quit IRC | 15:03 | |
promach_ | in smtbmc, what actually drives the always clocked block ? | 15:08 |
---|---|---|
*** worldchat has quit IRC | 15:23 | |
*** X-Scale has quit IRC | 16:49 | |
*** lutsabound has joined #yosys | 17:35 | |
*** seldridge has quit IRC | 17:41 | |
*** dys has quit IRC | 18:11 | |
*** leviathan has quit IRC | 18:15 | |
*** promach_ has quit IRC | 18:36 | |
*** dys has joined #yosys | 18:37 | |
*** dxld has quit IRC | 18:49 | |
*** dxld has joined #yosys | 18:49 | |
*** eduardo__ has quit IRC | 18:53 | |
*** janrinze has joined #yosys | 18:58 | |
janrinze | having a strange problem. when I run yosys and arachne-pnr it seems that often i need to re run to get a working binary. are there tools to find out what happened and why some give failing binaries? | 19:00 |
daveshah | janrinze: are you running icetime? Sounds like a design that is failing timing, or possibly suffering from metastability | 19:06 |
janrinze | icetime reports that the result is properly within timing requirements. | 19:12 |
janrinze | any trick to track metastability? | 19:12 |
lutsabound | Metastability shouldn't keep the design from building | 19:14 |
lutsabound | Are you getting a binary both ways? | 19:15 |
janrinze | no of course not. but usually is caused by using different clock domains. | 19:15 |
janrinze | only using one clock domain here. | 19:15 |
janrinze | and it is only 30 MHz. | 19:16 |
lutsabound | Metastability can also be caused by asynchronous inputs | 19:16 |
lutsabound | How Are you generatinf your 30mhz clock? Did you use icepll? | 19:18 |
janrinze | I use as many register latching as necessary. doing things in 'always@(posedge clk)' | 19:18 |
janrinze | icepll for 120 Mhz and then divide by 4 | 19:19 |
daveshah | It's possibly the divide by four that's causing problems | 19:20 |
daveshah | What board are you using BTW? | 19:20 |
janrinze | icoboard | 19:21 |
daveshah | Great, that doesn't have any known issues (some boards have dodgy PLL supplies causing these kind of issues) | 19:21 |
janrinze | hx8k + 1MB SRAM board | 19:21 |
daveshah | Roughly, what is your design? | 19:22 |
janrinze | often re running arachne-pnr with -r fixes the issue | 19:22 |
daveshah | Yeah. That normally happens in cases where timing is a bit marginal | 19:23 |
janrinze | design is a 16 bit CPU plus I/O (vga and keyboard.) | 19:23 |
daveshah | Are you doing anything like negative edge clocks, etc, internally? | 19:24 |
janrinze | Yes, as a matter of fact I do. | 19:24 |
daveshah | icetime won't analyse them well | 19:25 |
daveshah | I suspect the timing is marginal | 19:25 |
daveshah | Best to try and run at a reduced clock frequency, and see if every design works | 19:25 |
daveshah | Ideally using a clock straight from the PLL, without a divider | 19:25 |
janrinze | This already is the reduce frequency .. used to be able to run at 36 MHz easily. | 19:26 |
daveshah | Personally I'd try and get everything running on the same clock edge | 19:26 |
lutsabound | Might need a timing optimiEd placer ... | 19:27 |
daveshah | My guess is it is the negative edge clocks causing the problems | 19:27 |
janrinze | yes, i understand. I will try to find an alternate solution. | 19:28 |
janrinze | Would it be smarter to clock everything with the pll at 120 MHz and add a 4 phase coding? | 19:31 |
janrinze | the code would be one hot. | 19:31 |
daveshah | 120MHz is really pushing the ice40 | 19:31 |
daveshah | Personally I'd clock everything at 30MHz, positive edge | 19:31 |
daveshah | That's going to be by far the easiest approach | 19:32 |
janrinze | I had a design working very well at 65 MHz | 19:32 |
janrinze | other type of system though | 19:32 |
janrinze | hx8k breakout board | 19:32 |
daveshah | Yeah, for a CPU I think that's really the upper limit | 19:33 |
janrinze | i hear about 100MHz cpu designs on hx8k.. bogus, you think? | 19:34 |
janrinze | could very well be.. unless heavily pipelined system maybe? | 19:34 |
janrinze | After placement: | 19:35 |
janrinze | PIOs 67 / 206 | 19:35 |
janrinze | PLBs 739 / 960 | 19:35 |
janrinze | BRAMs 0 / 32 | 19:35 |
daveshah | Maybe, if you're really careful with design. VexRiscv goes up to about 80MHz, but in a small config with low instructions per clock | 19:35 |
janrinze | i can do 1 instruction/clock mostly. | 19:36 |
janrinze | exceptions are the 2 word instructions , jumps, branches and of course multiply and divide. | 19:37 |
daveshah | Do you have any pipelining? | 19:38 |
janrinze | if prefetching the instruction counts then yes ;-) | 19:38 |
daveshah | Otherwise, sounds like 30-40MHz is probably a realistic target | 19:39 |
janrinze | load/store and jumps all will be a second stage. | 19:39 |
janrinze | and it runs of the external SRAM. | 19:39 |
janrinze | VexRiscv smallest (RV32I, 0.52 DMIPS/Mhz) that's what you mean, right? | 19:48 |
janrinze | it has a 32 bit bus to the block ram, i guess.. | 19:48 |
daveshah | Yeap that's the config I was looking at | 19:55 |
daveshah | Not having external ram makes things a lot faster and easier | 19:55 |
janrinze | at first I worried that the 16 x 16bit registers were the culprit but that seems to be hardly a problem | 19:57 |
janrinze | time sharing the bus with vga is no big issue either, it only needs to fetch a word once every 16 clock cycles. | 19:58 |
janrinze | So i lose only 6.25 % of the bandwidth to the vga at 512x384@60Hz. | 19:59 |
daveshah | Yeah, although the resulting multiplexers will increase the critical path delay | 20:00 |
janrinze | 10 ns SRAM.. that has a bit of leeway. | 20:01 |
janrinze | when using 30 MHz the memory cycle is 33.3 ns | 20:01 |
daveshah | Yeah, but you have logic around that, bus turnaround time, etc | 20:02 |
janrinze | pin delay is about 5 ns, right? so that still is more than 20 ns for the SRAM | 20:02 |
daveshah | There's logic delay too of course | 20:02 |
janrinze | yes but that is a lot less, at least according to icetime. | 20:03 |
daveshah | But remember that icetime does not take into account the SRAM delay, nor does it consider negative edge clocks properly | 20:04 |
janrinze | true. I only use the negative edge for the write enable signal because it requires the address to settle first. | 20:05 |
janrinze | i know that some FPGA have multi phase clock outputs. That could be a lot more stable. | 20:06 |
lutsabound | https://www.irccloud.com/pastebin/mjBSnKIv | 20:11 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 20:11 |
* lutsabound is not sure he likes his new phone | 20:11 | |
janrinze | lutsabound: the nwr signal is supposed to be low during the last half of the memory cycle. So only on negative edge would stretch it into the second half of the next memory cycle. | 20:16 |
janrinze | daveshah: it seems that icepll choses not to use global output but pllcore. would that affect the system adversely too? | 20:27 |
daveshah | Possibly, but the core signal will be routed straight onto a global anyway | 20:28 |
daveshah | So the difference shouldn't be massive | 20:28 |
janrinze | https://github.com/mystorm-org/BlackIce-II/wiki/PLLs-Improved this is about the blackice but it does have some info | 20:32 |
tpb | Title: PLLs Improved · mystorm-org/BlackIce-II Wiki · GitHub (at github.com) | 20:32 |
janrinze | https://github.com/mystorm-org/BlackIce-II/wiki/PLLs-Advanced seems to be a bit more complicated but has a dual clock option. | 20:35 |
tpb | Title: PLLs Advanced · mystorm-org/BlackIce-II Wiki · GitHub (at github.com) | 20:35 |
janrinze | found this link too. there is a work-around mentioned here for the global clock buffers: https://www.mjoldfield.com/atelier/2018/02/ice40-blinky-hx8k-breakout.html | 21:36 |
*** X-Scale has joined #yosys | 22:24 | |
*** lutsabound has quit IRC | 23:33 | |
*** emeb_mac has quit IRC | 23:49 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!