Friday, 2019-12-27

*** tpb has joined #yosys		00:00
*** rohitksingh has joined #yosys		00:20
*** rohitksingh has quit IRC		00:54
*** rohitksingh has joined #yosys		01:00
*** shorne has joined #yosys		01:08
*** Stary has quit IRC		01:11
*** Stary has joined #yosys		01:19
*** emeb has quit IRC		01:50
*** kraiskil has joined #yosys		03:20
*** lukego has joined #yosys		04:06
*** dh73 has joined #yosys		04:36
*** rohitksingh has quit IRC		04:41
*** dh73 has quit IRC		05:35
*** rohitksingh has joined #yosys		06:05
*** emeb_mac has quit IRC		06:32
*** vidbina has joined #yosys		08:03
*** vidbina has quit IRC		08:20
*** vidbina has joined #yosys		08:21
*** kraiskil has quit IRC		08:21
*** vidbina has quit IRC		08:21
*** vidbina has joined #yosys		08:22
*** vidbina has quit IRC		08:40
*** vidbina has joined #yosys		08:40
*** _whitelogger has quit IRC		08:49
*** _whitelogger has joined #yosys		08:51
*** vidbina has quit IRC		09:00
*** vidbina has joined #yosys		09:01
*** fsasm has joined #yosys		09:02
*** _whitelogger has quit IRC		09:10
*** _whitelogger has joined #yosys		09:12
*** _whitelogger has quit IRC		09:16
*** _whitelogger has joined #yosys		09:18
*** vidbina has quit IRC		09:37
*** promach3 has quit IRC		11:33
*** fevv8[m] has quit IRC		11:33
*** pepijndevos[m] has quit IRC		11:33
*** nrossi has quit IRC		11:33
*** _whitelogger has quit IRC		11:49
*** _whitelogger has joined #yosys		11:51
*** vidbina has joined #yosys		12:23
*** dys has joined #yosys		12:23
*** rohitksingh has quit IRC		12:32
*** pepijndevos[m] has joined #yosys		12:50
*** nrossi has joined #yosys		12:50
*** fevv8[m] has joined #yosys		12:50
*** promach3 has joined #yosys		12:50
*** vidbina has quit IRC		12:54
*** vidbina has joined #yosys		12:56
*** vidbina has quit IRC		13:12
*** vidbina has joined #yosys		13:12
*** vidbina has quit IRC		13:17
*** vidbina has joined #yosys		13:18
*** kraiskil has joined #yosys		13:32
*** vidbina has quit IRC		13:40
*** vidbina has joined #yosys		13:41
*** X-Scale has quit IRC		13:50
*** vidbina has quit IRC		14:04
*** vidbina has joined #yosys		14:06
*** vidbina has quit IRC		14:20
*** kraiskil has quit IRC		14:26
*** kraiskil has joined #yosys		14:27
*** kraiskil has quit IRC		14:34
*** _whitelogger has quit IRC		14:40
*** _whitelogger has joined #yosys		14:42
*** fsasm has quit IRC		14:59
*** rombik_su has joined #yosys		15:46
*** klotz has joined #yosys		15:47
*** vidbina has joined #yosys		16:05
*** Jybz has joined #yosys		16:17
*** emeb has joined #yosys		16:24
*** vidbina has quit IRC		16:40
*** kraiskil has joined #yosys		16:41
*** kraiskil has quit IRC		16:57
*** dh73 has joined #yosys		17:03
*** meawoppl has joined #yosys		17:51
meawoppl	hey all!	17:51
meawoppl	can anyone in the channel help me with how DDR signals should be treated in ice40 packages?	17:52
ZipCPU	Sure	17:54
ZipCPU	What's up?	17:54
ZipCPU	Typically, I handle DDR signals by directliy instantiating an SB_IO primitive	17:54
meawoppl	that is already a helpful lead	17:55
whitequark	there's no other way to do this on iCE40 other than instantiating SB_IO	17:55
meawoppl	looking at that (macro?) is looks like you then get two output signals?	17:56
daveshah	No, those will be the outputs from the DDR input	17:56
daveshah	The output of the DDR output block is "PACKAGE_PIN"	17:56
daveshah	that must be driving a top level output (or inout)	17:56
meawoppl	oh, I think I am getting the language backward here	17:57
daveshah	You mean a DDR input primitive (i.e. the external pin is an input) ?	17:57
daveshah	or perhaps better said input DDR primitive	17:57
meawoppl	package pin (or two b/c of differential input here) -> SB_IO -> 2 inputs	17:58
meawoppl	I am implementing a MIPI receiver	17:58
daveshah	Yeah	17:58
daveshah	so you want to use D_IN_0 and D_IN_1 on the SB_IO to drive your logic	17:59
daveshah	the former is registered on the positive edge and the latter on the negative edge, iirc	17:59
meawoppl	ah, so those are set on the edges, then I can just look at 1 edge of the signal in my logic reading those?	18:00
daveshah	Yes, all your logic following would be on the posedge	18:02
meawoppl	posedge of the clock used to sync SB_IO	18:02
daveshah	yes	18:02
meawoppl	and I expect a delay of 2 cycles then?	18:02
daveshah	often you would have a posedge register as the next thing after the SB_IO at least on D_IN_1	18:02
daveshah	yeah	18:02
meawoppl	awesome, that makes so much more sense now	18:03
meawoppl	I tried some really hacky stuffs making an xor'ed signal based on posedge+negedge logic	18:03
meawoppl	and, the more I think about it, the more I am suprised it worked at all	18:04
daveshah	Yeah that's nasty	18:04
ZipCPU	meawoppl: Yeah, most FPGAs don't support that kind of logic. It's in the language, I think, because certain ASIC logic needs to do that kind of stuff	18:04
ZipCPU	(Not certain, though, since ... I've never done ASIC work)	18:05
meawoppl	it just seems really fraught to me now, thinking about the flip-flow state progression and I think the data would be underdetermined if the input clock was anything less than perfect	18:05
ZipCPU	meawoppl: Incidentally, some of the ugliest "yosys" bugs have been linked to not using the SB_IOs.	18:07
ZipCPU	The result is typically that yosys + (then) arachne-pnr would place the logic anywhere within the chip, leading to horrible I/O timings	18:07
meawoppl	interesting	18:08
ZipCPU	A Yosys update might adjust where the placement was made, since it was never controlled, and the design might go from working to not working. The student or other user then blames the "yosys" change for why the design no longer works	18:08
meawoppl	so SB_IO is basically 1:1 with some chip-edge special hardware?	18:08
ZipCPU	Absolutely!~	18:08
meawoppl	(new to this all)	18:09
ZipCPU	If you want timing to be controlled across multiple pins, you'll also want to make certain that the SB_IO uses the clock and registers all outputs as well.	18:09
ZipCPU	For a single pin it usually doesn't make a difference, but across several pins in some I/O interface or another--perhaps one is a clock, another data, then ... yeah, you want to use the SB_IO primitives	18:10
meawoppl	ZipCPU thanks	18:14
meawoppl	so here I am doing a differential clock and differential signal	18:14
ZipCPU	Are you creating the clock signal?	18:15
meawoppl	so I use 1 SB_IO for the clock, then a second using that input clock to clock the DDR data input	18:15
meawoppl	(two sub-lvds pairs)	18:16
ZipCPU	I mean ... Are you generating the clock signal and outputting it from your design, or is it coming into your design as an input?	18:16
meawoppl	thats coming in	18:16
ZipCPU	Are you using any global buffers? SB_GB() ?	18:17
meawoppl	I am for the clock (totally cargo-culted), I am honestly not sure what it buys me	18:18
whitequark	fun fact: some Altera FPGAs actually use regular flip-flops to implement DDR I/O. they do constrain placement to be right next to the I/O tile though	18:18
whitequark	regular fabric flip-flops, I mean	18:19
ZipCPU	whitequark: Wow ... is that how those design elements worked?	18:19
meawoppl	it looks like `SG_GB` does signal fanout to minimize latenccy?	18:20
ZipCPU	meawoppl: It buys you low clock skew across the chip, making it more likely that everything within your design uses the same clock with the same skew	18:20
ZipCPU	Yes, that's it	18:20
whitequark	ZipCPU: I'll tell you something worse. unless I misremember or misunderstood how it works, Altera actually implements clock muxes with LUTs on some FPGAs like Cyclone V	18:20
ZipCPU	That said, I think there is a certain latency by going through the global buffer network, but it would be more controlled than just routing the pin without using the clock network	18:21
whitequark	that seemed very very strange to me, so I dug into it, and again, unless I really misunderstood something in their toolchain, it seems that's what they do.	18:21
ZipCPU	whitequark: I'm not sure if I should be impressed and stand in awe, or if I should rather cringe at the sound of that	18:21
whitequark	I suspect the latter. I have seen reports on the web that their trick of using FFs for DDR IO has rather unfavorable results.	18:22
whitequark	which is exactly what you would expect.	18:22
whitequark	remember that you need a LUT to mux the output from the posedge and negedge FF... so the timings of that complete construct are not great	18:22
whitequark	bizarrely, the input DDR path on Cyclone V is actually hard logic in the IO tile. I'm wondering if they are working around a silicon bug or something.	18:22
ZipCPU	Yeah, I suppose that would make sense	18:23
ZipCPU	Makes you wonder if it gets fixed in a future silicon revision --- or even if so .. how would you know and tell?	18:24
whitequark	I think they've been dragging that design along for a rather long time, across many FPGA families	18:24
meawoppl	interesting, so when I plumb the clock signal (post `SB_IO`) should I route it directly into the data-SB_IO or should I use the post SB_GB signal?	18:25
whitequark	ZipCPU: take a look at this: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyc/cyc_c51010.pdf	18:27
ZipCPU	meawoppl: I'd use the SB_GB signal if possible	18:27
meawoppl	gotcha, but it will introduce some latency into the read, right?	18:28
ZipCPU	whitequark: "HTTP request sent, awaiting response... 403 Forbidden" ... well, maybe I'll look into it some other day	18:28
meawoppl	but consistent latency.... hermmm	18:29
ZipCPU	meawoppl: Yes, but that's not saying much. Everything will introduce some latency. The question is whether or not that latency is significant in your application. That I cannot answer.	18:29
ZipCPU	If it is a problem, you might be able to adjust the phase of the clock ... but I wouldn't be able to cite information on that off the top of my head	18:29
meawoppl	awesome, thanks for helping me understand all these tradeoffs	18:31
whitequark	note that SB_IO+SB_GB is not the same as SB_GB_IO!	18:34
whitequark	if you can, you really should use SB_GB_IO	18:34
whitequark	as this can change the phase of your clock quite significantly. I hit that bug some time ago.	18:34
ZipCPU	?? whitequark: Can you explain the difference?	18:35
whitequark	I think SB_IO+SB_GB actually routes your clock through fabric first	18:35
whitequark	https://github.com/GlasgowEmbedded/Glasgow/issues/89	18:35
tpb	Title: Use SB_GB_IO instead of SB_IO+SB_GB · Issue #89 · GlasgowEmbedded/glasgow · GitHub (at github.com)	18:35
whitequark	I didn't check the actual netlist, but all signs point to SB_IO+SB_GB routing the clock through fabric, and not even always the same way	18:36
* ZipCPU searches iCE40 doc's for SB_GB_IO information ...		18:37
* ZipCPU finds references in the family handbook		18:38
whitequark	unfortunately iCE40 does not have particularly great documentation	18:42
meawoppl	interesting, I can use that if I don't use the inputs, and just relay on the global buffer it produces...	18:42
whitequark	for example, have you seen the circuit diagram that describes the SB_IO behavior? it is profoundly wrong	18:42
whitequark	(quiz: where is it wrong?)	18:43
whitequark	meawoppl: yep, you should preferably do that	18:43
rombik_su	whitequark: That's interesting! I'm looking rn at my DDR3 Cyclone V. At least in the floorplan Quartus shows that both DDIO_IN and DDIO_OUT contained within IOB (as dedicated h/w) and enabled. Judging from post-route netlist, looks like it's dedicated.	18:48
rombik_su	*at my DDR3 Cyclone V project.	18:48
whitequark	hmmm	18:49
whitequark	then I might have misunderstood something	18:49
rombik_su	I will scramble simple project to inspect	18:49
whitequark	can you check for Cyclone III too/	18:49
*** svenn7 has joined #yosys		18:49
whitequark	I originally got a Cyclone III board by mistake and I might have first checked on it	18:50
whitequark	and then misremembered	18:50
rombik_su	whitequark: No problem, I'll check	18:50
meawoppl	one other question for the group here	18:51
meawoppl	what is the typical testing narrative/process for a `yosys` workflow	18:51
meawoppl	right now I am using an oscilloscope for everything, but there are a bunch of modules I have written that seem very testable	18:51
*** kraiskil has joined #yosys		18:53
whitequark	typically people write Verilog testbenches and use Icarus Verilog	18:53
meawoppl	`testbench` was the keyword I needed there	18:55
rombik_su	whitequark: From Cyclone III handbook: The DDR input registers are implemented with three internal logic element (LE) registers for every DQ pin. These LE registers are located in the logic array block (LAB) adjacent to the DDR input pin.	18:55
rombik_su	A dedicated write DDIO block is implemented in the DDR output and output enable paths. Figure 8–5 shows how Cyclone III device family dedicated write DDIO block is implemented in the I/O element (IOE) registers	18:55
whitequark	aha, right, that's what I was missing.	18:56
whitequark	ZipCPU: ^	18:56
whitequark	looks like Cyclone (original) implemented DDR input and output in fabric, Cyclone III moved output into IOB, and Cyclone V has input and output in IOB	18:56
*** dys has quit IRC		18:57
rombik_su	I'm pretty sure C4 have dedicated DDR h/w in IOBs	18:57
ZirconiumX	rombik_su: Ah, a fellow Cyclone V user	18:57
* rombik_su checking		18:57
rombik_su	ZirconiumX: \o/	18:58
ZirconiumX	I've actually been working a bit on the Cyclone V stuff today	18:58
ZirconiumX	We now have carry chain support :P	18:59
ZirconiumX	Unfortunately integrating into Quartus is hell on earth	18:59
rombik_su	whitequark: I'm wrong, Cyclone IV has the same story as Cyclone III wrt to DDR in IOB	18:59
ZipCPU	meawoppl: There's a "better" Yosys workflow that goes through a formal verification step before going into the simulator. Spares you some simulation cycles	19:02
meawoppl	is simulation really slow?	19:05
rombik_su	meawoppl: It depends on the simulator (iverilog vs commercial) and design size/complexity	19:06
ZipCPU	Definitely depends upon design size and complexity	19:07
sorear	formal verification (satisifiability) can also be very slow	19:12
*** pie_ has joined #yosys		19:13
ZipCPU	sorear: It can be, but in 90% of my example cases, it takes less than 2 minutes	19:13
ZipCPU	See for reference: https:zipcpu.com/formal/2019/08/03/proof-duration.html	19:14
dh73	It might be difficult to integrate into Quartus, because there are parameters still needed, and special inputs that you should be using. I can't remember if "shared_arith" is needed for carry chain, and also, sumout and cin inputs should be used for this instead of normal dataa..datag afaik	19:18
ZirconiumX	Yes, that's what I'm using dh73	19:19
ZirconiumX	data{a,b,c,d,f}	19:19
ZirconiumX	But that's not my point here	19:19
ZirconiumX	Quartus breaks on valid Verilog if you try to pass it as VQM	19:20
ZirconiumX	(Syntax error last time I checked)	19:20
ZirconiumX	If you pass it as Verilog, Quartus will instead ICE	19:20
ZirconiumX	And if you pass it as EDIF, Quartus complains that the ground net cannot be used more than once	19:21
dh73	Wait a second	19:22
dh73	What I said is, carry chain needs cin and datad as inputs, cout and sumout as outpus, not the normal dataa..datag, but anyway in any case Quartus clearbox will merge the logic in that fashion if you don't, is kind of a carry computation, just mentioning. I didn't know Quartus supports edif now, but I will not expect that thing working fine at all. Can I use one of your examples to see what errors the tools is giving?, just for curiosity	19:26
ZirconiumX	dh73: https://github.com/YosysHQ/yosys/pull/1554 has a `-edif` option	19:27
tpb	Title: synth_intel_alm: replacement flow for ALM-based Intel FPGAs. by ZirconiumX · Pull Request #1554 · YosysHQ/yosys · GitHub (at github.com)	19:28
dh73	thanks!	19:30
ZirconiumX	I have timing tables for C10GX, but I don't want to overload the patch reviewers just yet :P	19:31
ZirconiumX	A10GX would need new tables I think because it uses a different process	19:32
*** quigonjinn has joined #yosys		19:34
rombik_su	Arria 10 is 20 nm, Cyclone V is 28 nm	19:35
ZirconiumX	C10 is also 20nm	19:36
ZirconiumX	AIUI	19:36
rombik_su	Cyclone 10 GX is 20 nm, Cyclone 10 LP is 60 nm	19:38
ZirconiumX	...I'd noticed that the 10LP seemed to be slower than the IV	19:40
quigonjinn	I know arachne-pnr is not maintained, just a question in case someone here can answer. Running the tests of the latest commit fails with yosys-0.9 and 0.8, but is successful with 0.7. The relevant part is in the folowing paste: https://paste.debian.net/1122888/ It keeps allocating memory until the system run out of memory. Is this some bug with the latest versions of yosys, or just arachne-pnr is not compatible with	19:41
quigonjinn	them?	19:41
tpb	Title: debian Pastezone (at paste.debian.net)	19:41
ZirconiumX	...If arachne-pnr is not maintained, isn't it a bit counterproductive to ask a question that involves arachne-pnr maintenance?	19:41
whitequark	you really just shouldn't use arachne-pnr	19:48
whitequark	it has no value beyond being a proof of concept. the quality of routing is very poor	19:48
whitequark	even if I knew the answer, I'd just tell you to not use it.	19:48
*** vidbina has joined #yosys		20:11
quigonjinn	just wondering if this may be a yosys bug, becauses it occurs with yosys being run	20:13
*** vidbina has quit IRC		20:19
*** vidbina has joined #yosys		20:20
*** X-Scale has joined #yosys		20:23
*** Jybz has quit IRC		20:28
*** vidbina has quit IRC		20:35
*** vidbina has joined #yosys		20:36
*** emeb_mac has joined #yosys		20:45
*** fsasm has joined #yosys		20:58
meawoppl	Another question re: Global buffers and the ice40 package	21:00
meawoppl	I am getting this error:	21:00
meawoppl	```	21:00
meawoppl	`ERROR: BEL 'X9/Y0/io0' has no global buffer connection available`	21:00
meawoppl	and I am not sure what to make of it	21:00
meawoppl	I think this is confusing because I am mixing global-buffer with LVDS here	21:02
meawoppl	If I use SB_GB_IO with lvds, does the + pin have to be one with the global buffer tap?	21:04
*** vidbina has quit IRC		21:06
*** vidbina has joined #yosys		21:08
daveshah	Yes, it does	21:16
meawoppl	daveshah will it not let me use the COMP pin, or will it just be inverted?	21:25
daveshah	You will get an error if you use the COMP pin	21:25
meawoppl	makes sense, I am going to see if I can getaway without using it, because this boxes me into an annoying position, I have to use bank3 (subLVDS), and the GB wiring is on the comp line :/	21:29
*** emeb_mac has quit IRC		21:33
daveshah	Which chip is this?	21:34
meawoppl	the sg48 package	21:35
meawoppl	weird, I may have misread this	21:45
meawoppl	what is `the sysIO buffer`?	21:45
daveshah	This is a up5k	21:45
daveshah	?	21:45
meawoppl	yessir	21:45
daveshah	the sysIO buffer is just the IO buffer	21:45
daveshah	which pins are you trying to use	21:45
daveshah	I think at least one Lattice doc is wrong in terms of the up5k	21:49
daveshah	You don't have to use bank 3 for LVDS, definitely, and afaik the positive side is A not B	21:49
*** dh73 has quit IRC		21:53
*** dh73 has joined #yosys		21:53
meawoppl	the page I was looking at was here: https://www.latticesemi.com/view_document?document_id=51971	22:03
meawoppl	specifically that `IOB_3b_G6` seems to be the negative differential pair	22:06
daveshah	Yes, that looks to be a problem	22:06
meawoppl	confusingly numbered bank2 here	22:06
daveshah	That is the correct document	22:06
daveshah	The bank thing only applies to earlier iCE40 devices	22:06
daveshah	All of the UP5K pairs can be used as differential inputs regardless of bank	22:06
meawoppl	bah, so I was just looking at an old doc somewhere?	22:11
meawoppl	heh, I resister swapped this bank down to subLVDS voltages, now I suspect I have to do the swap....again to get to a differential with global input	22:12
meawoppl	bah	22:12
meawoppl	I am going to see if I can get away with this configuration for a bit, I am only using the clock as DDR input to the SB_IO, and a demuxing layer, so might be ok	22:35
*** fsasm has quit IRC		22:53
*** rombik_su has quit IRC		23:04
meawoppl	so, somewhat confusing question	23:04
meawoppl	is partial bit-range assignment allowed in yosys	23:04
meawoppl	like	23:04
meawoppl	reg[3:0] foo;	23:05
meawoppl	always @whatever	23:05
meawoppl	reg[2] <= 1;	23:05
meawoppl	?	23:05
daveshah	Yeah that should be fine	23:05
ZirconiumX	That's standard verilog	23:23
*** emeb has quit IRC		23:33
*** emeb_mac has joined #yosys		23:37

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!