Friday, 2018-12-21

*** tpb has joined #yosys		00:00
*** xa0 has joined #yosys		00:00
*** xa0 has joined #yosys		00:05
*** xa0 has joined #yosys		00:07
*** xa0 has joined #yosys		00:08
*** xa0 has joined #yosys		00:09
*** xa0 has joined #yosys		00:10
*** xa0 has joined #yosys		00:11
*** xa0 has joined #yosys		00:12
*** xa0 has joined #yosys		00:12
*** xa0 has joined #yosys		00:13
*** xa0 has joined #yosys		00:21
*** xa0 has joined #yosys		00:22
*** xa0 has joined #yosys		00:23
*** xa0 has joined #yosys		00:24
*** pie__ has joined #yosys		00:24
*** xa0 has joined #yosys		00:24
*** pie___ has quit IRC		00:26
*** xa0 has joined #yosys		00:26
*** xa0 has joined #yosys		00:27
*** seldridge has quit IRC		00:32
*** seldridge has joined #yosys		02:08
*** pie__ has quit IRC		02:38
*** pie___ has joined #yosys		02:38
*** leviathanch has joined #yosys		03:50
*** rohitksingh_work has joined #yosys		04:03
*** xa0 has joined #yosys		04:14
*** xa0 has joined #yosys		04:14
*** xa0 has joined #yosys		04:18
*** xa0 has joined #yosys		04:19
*** xa0 has joined #yosys		04:20
*** xa0 has joined #yosys		04:22
*** xa0 has joined #yosys		04:23
*** xa0 has joined #yosys		04:28
*** AlexDaniel has quit IRC		04:28
*** AlexDaniel has joined #yosys		04:29
*** xa0 has joined #yosys		04:32
*** xa0 has joined #yosys		04:33
*** xa0 has joined #yosys		04:35
*** xa0 has joined #yosys		04:38
*** xa0 has joined #yosys		04:45
*** xa0 has joined #yosys		04:46
*** xa0 has joined #yosys		04:47
*** xa0 has joined #yosys		04:48
*** xa0 has joined #yosys		04:50
*** xa0 has joined #yosys		04:54
*** xa0 has joined #yosys		04:55
*** xa0 has joined #yosys		04:56
*** xa0 has joined #yosys		04:57
*** xa0 has joined #yosys		05:02
*** xa0 has joined #yosys		05:09
*** pie__ has joined #yosys		05:10
*** xa0 has joined #yosys		05:11
*** pie___ has quit IRC		05:12
*** xa0 has joined #yosys		05:13
*** xa0 has joined #yosys		05:15
*** xa0 has joined #yosys		05:17
*** xa0 has joined #yosys		05:21
*** xa0 has joined #yosys		05:22
*** xa0 has joined #yosys		05:24
*** xa0 has joined #yosys		05:28
*** xa0 has joined #yosys		05:30
*** xa0 has joined #yosys		05:32
*** xa0 has joined #yosys		05:35
*** xa0 has joined #yosys		05:36
*** xa0 has joined #yosys		05:37
*** xa0 has joined #yosys		05:38
*** xa0 has joined #yosys		05:38
*** xa0 has joined #yosys		05:41
*** xa0 has joined #yosys		05:42
*** xa0 has joined #yosys		05:44
*** xa0 has joined #yosys		05:46
*** xa0 has joined #yosys		05:48
*** xa0 has joined #yosys		05:48
*** xa0 has joined #yosys		05:49
*** xa0 has joined #yosys		05:50
*** seldridge has quit IRC		05:52
*** xa0 has joined #yosys		05:54
*** xa0 has joined #yosys		05:55
*** xa0 has joined #yosys		06:00
*** xa0 has joined #yosys		06:02
*** xa0 has joined #yosys		06:04
*** xa0 has joined #yosys		06:06
*** xa0 has joined #yosys		06:07
*** xa0 has joined #yosys		06:10
*** xa0 has joined #yosys		06:11
*** xa0 has joined #yosys		06:12
*** dys has quit IRC		07:16
*** wavedrom has joined #yosys		07:51
*** wavedrom has quit IRC		08:31
*** leviathanch has quit IRC		09:30
*** rohitksingh_work has quit IRC		11:54
*** pie___ has joined #yosys		13:35
*** pie__ has quit IRC		13:35
*** seldridge has joined #yosys		13:58
*** seldridge has quit IRC		15:12
*** rohitksingh has joined #yosys		15:16
*** seldridge has joined #yosys		16:09
*** pie__ has joined #yosys		16:39
*** pie___ has quit IRC		16:41
*** m4ssi has quit IRC		17:07
*** seldridge has quit IRC		17:10
*** wavedrom has joined #yosys		17:22
*** seldridge has joined #yosys		17:27
*** key2 has joined #yosys		18:02
*** rohitksingh has quit IRC		18:13
*** dys has joined #yosys		18:14
key2	hi	18:18
key2	how can one generates verilog without comments ?	18:18
daveshah	key2: I don't think there is an option for this. The only comment I see is the first "generated by" line, which you could strip out with `sed 1d`	18:24
daveshah	Are you sure you don't mean the attributes?	18:24
key2	yeah i mean those attr (* src = "/x/x/x/" *)	18:25
daveshah	Use `write_verilog -noattr`	18:25
daveshah	or, alternately `write_verilog -attr2comment` if you want to turn them into real comments (/**/)	18:25
key2	I see	18:26
key2	thx	18:26
key2	but then would I lose other usefull attribute ?	18:26
daveshah	It is fairly rare for attributes to affect how a design functions, normally they are just useful info like `src` or tool-internal hints. If you don't have any (* *)s in your Verilog input, chances are you don't need any in the output either	18:27
daveshah	out of curiosity, what tool are you feeding this verilog into?	18:27
key2	vivado or verilator	18:28
daveshah	I don't think either of those will have any problem with attributes	18:28
*** seldridge has quit IRC		18:28
key2	thx	18:29
key2	working wiht nMigen, generating rtlil and converting to verilog	18:29
daveshah	Oh awesome! I'm really excited about nMigen	18:30
*** seldridge has joined #yosys		18:32
key2	just generated my riscv with it	18:32
*** lutsabound has joined #yosys		18:33
*** key2 has quit IRC		18:35
*** key2 has joined #yosys		18:36
*** janrinze has joined #yosys		18:43
janrinze	next-pnr is a great addition to the icestorm/yosys environment. kudos to all involved.	18:54
janrinze	as a small test has already shown me it can produce up to 20% faster stable clock for my SoC design. Nice!	18:55
*** wavedrom has quit IRC		19:03
*** seldridge has quit IRC		19:11
*** rohitksingh has joined #yosys		19:13
*** nurelin_ has joined #yosys		19:24
*** dxld has quit IRC		19:24
*** seldridge has joined #yosys		19:24
*** dxld has joined #yosys		19:30
key2	Someonas has some experience about generating verilog code for verilator ?	19:50
key2	I wonder if there are any kind of optimisation that are needed	19:50
*** seldridge has quit IRC		20:11
ZipCPU	key2: I use Verilator all the time	20:24
ZipCPU	I don't generate my Verilog code explicitly for verilator though--it's just my normal Verilog code but with one exception	20:25
ZipCPU	First, I always use the -Wall option. It provides a basic lint capability, and SO many bugs right there	20:25
*** seldridge has joined #yosys		20:25
ZipCPU	The problem with -Wall is that it also finds wires that you might not be using within your design--things you want kept there, but that Verilator properly discovers you aren't using	20:25
ZipCPU	For these, I surround them with comments such as // Verilator lint_off UNUSED	20:26
ZipCPU	and again // Verilator lint_on UNUSED	20:26
ZipCPU	Third: I don't place any hardware specific code in my Verilator sections. To do this, I place all of the Verilator synthesizable code in a subset of my design I call main.v, which is a submodule of toplevel.v. Any thing that isn't Verilator compatible doesn't go in main.v but in toplevel.v or another submodule of it.	20:27
ZipCPU	An example of such would be a PLL. Verilator doesn't generate PLL's, so these would go in the toplevel	20:28
*** rohitksingh has quit IRC		20:53
key2	ZipCPU: I know, currently I'm testing a generation of verilog from rtlil	20:58
ZipCPU	Ok, cool, how's it working out for you?	20:58
ZipCPU	I have a project, btw, that does just that ... generates verilog from a bit stream which is then run into Verilator	20:59
key2	well the thing is, we are testing nMigen currently	20:59
ZipCPU	Go on	20:59
key2	which generates rtlil	20:59
key2	I was wondering for example what you do with memrd and memwr privimives	21:00
ZipCPU	Wow, all the way down to rtlil within migen? Is it using yosys internally at all?	21:00
key2	ZipCPU: nMigen is the next migen	21:00
key2	I sponsored whitequarks to write it	21:00
ZipCPU	Nice, go on	21:00
key2	yeah in fact it will generates rtlil	21:00
key2	instead of writing the verilog alla migen	21:00
key2	what kind of verilog do you use with verilator when using code generated from yosys ?	21:01
ZipCPU	Your memrd and memwr primitives ... do they have Verilog equivalents? (They should, right?)	21:01
ZipCPU	You are welcome to examine the project: https://github.com/ZipCPU/cputest-harness	21:02
tpb	Title: GitHub - ZipCPU/cputest-harness: A simulation test harness, containing serial port, QSPI flash, and an output done I/O--just provide the CPU (at github.com)	21:02
ZipCPU	The guts are found in the primary makefile	21:02
ZipCPU	Basically, there's a cell simulator for the iCE40 that I was able to include to create a complete Verilator based project	21:03
key2	always @(posedge clk_i) x <= (y)? 1'bz : m;	21:03
key2	this kinda thing doesn't wokr with verilator in fact	21:03
ZipCPU	It sort of does, but only at the top level.	21:03
ZipCPU	I've used that with success before. I just don't know the limits of how far it can be made to work.	21:03
ZipCPU	Or ... maybe I've only used: assign x = (y) ? 1'bz : m; /// not sure	21:04
ZipCPU	I know I've used one of the two successfully, and it surprised me when I did	21:04
key2	=	21:04
key2	yes	21:04
ZipCPU	You can generate the posedge clk_i one from the assign one	21:05
ZipCPU	always @(posedge clk_i) begin r_i <= y; r_x <= x; end assign x = (r_y) ? 1'bz : r_x;	21:05
key2	%Error: /home/xxx/src/litex/litex/soc/cores/cpu/minerva/verilog/minerva.v:4235: Unsupported tristate construct (not in propagation graph): VARREF 'finst_pc$94'	21:08
ZipCPU	Which version of Verilator?	21:11
key2	4.0.0.devel	21:11
ZipCPU	Is that the github version?	21:11
ZipCPU	I mean, raw git version?	21:11
* ZipCPU is shooting in the dark		21:12
*** lutsabound has quit IRC		21:12
key2	probably yes	21:13
ZipCPU	I know that there are times when it helps to create an always @(*) block to replace several assign statements	21:14
ZipCPU	But, not sure if this helps either	21:14
* ZipCPU is still shooting in the dark		21:14
key2	https://paste.debian.net/1057006/	21:15
tpb	Title: debian Pastezone (at paste.debian.net)	21:15
ZipCPU	You only want one of those bits to be a 'z'?	21:15
ZipCPU	If so, that's probably the problem	21:16
ZipCPU	Verilator is word based, and doesn't handle bit level operations all that well. Try this:	21:16
ZipCPU	always @(*) begin finst_pc94$next[30] = (rst) ? 1'bz : _144_[30]; finst_whatever[29:0] = 1 : _144_[29:0];	21:16
ZipCPU	Oh, and don't forget the "end" on the "end" of that :)	21:17
key2	ha i found smth	21:24
key2	thx	21:24
key2	works now	21:24
ZipCPU	Cool! What was it?	21:24
key2	well i was getting the z because i was converting from 30 to 31 bits	21:24
key2	therefor, nMigen filled it with a z	21:25
ZipCPU	z doesn't seem like the right value to fill something with	21:25
key2	now I forced a concatenation	21:25
ZipCPU	Wouldn't you rather fill it with x?	21:25
daveshah	Yeah, x would make more sense	21:25
daveshah	z is tristate and should really only be used for IO pins imo	21:25
ZipCPU	^ +1	21:25
daveshah	x is undefined and any synthesis tool will optimise it as a don't care	21:26
key2	could also x be used instead of z ?	21:26
daveshah	It should be used instead of z	21:26
key2	on top level	21:26
key2	on io pins	21:26
key2	tristates	21:26
ZipCPU	No. 'z' is a tristate, 'x' is an undefined	21:26
daveshah	No	21:26
key2	i see	21:26
key2	so thats a bug in nMigen	21:26
key2	;)	21:26
*** lutsabound has joined #yosys		21:27
ZipCPU	Actually, let me be clearer: 'z' is high impedence, as used within a tristate. 'z' by itself isn't tristate	21:27
key2	it's yosys that added it	21:32
key2	as my rtlil didn't have this :)	21:32
ZipCPU	I thought you said you weren't using yosys?	21:33
key2	i am	21:33
key2	nMigen -> rtlil -> yosys -> verilog -> verilator	21:33
key2	:)	21:33
ZipCPU	Just to convert RTLIL to Verilog after nMigen creates the RTLIL?	21:33
key2	yes	21:33
daveshah	This sounds a bit like a Yosys issue. I feel like a z in this context, even if strictly legal, is going to cause issues	21:33
ZipCPU	Oh, okay	21:33
ZipCPU	daveshah: Do you know where yosys might be adding a 'z' to RTL?	21:35
daveshah	Maybe if something is disconnected?	21:35
ZipCPU	key2: This was a data range issue, right? Where you were going from a 30 bit register to a 31 bit register?	21:35
key2	in this case, it's when you take a signal of 31 bits let say, and give it a 30 bit value	21:36
key2	it filled it with a z	21:36
key2	yeah	21:36
key2	and verilator didnt like it	21:36
ZipCPU	In Verilog, it should propagate the high order bit. Not sure of the semantics of RTLIL	21:36
janrinze	in Verilog the top bit would be undefined and thus z.	21:37
*** seldridge0 has joined #yosys		21:37
ZipCPU	I just looked this up the other day. If you are assigning an N bit literal to an N+1 bit value, if the Nth bit is a z or an x, it propagates into the N+1th bit	21:38
ZipCPU	If it's a 1 or 0, and the value is unsigned, it propagates up as a zero	21:38
ZipCPU	Nothing gets left on the floor as undefined--unless you make it so	21:38
janrinze	sign extension is possible with signed values	21:38
*** seldridge has quit IRC		21:39
key2	in fact the value is a negative value	21:41
key2	that might explain	21:41
ZipCPU	Converting a set value (the sign bit) to a z sounds like a bug	21:42
janrinze	if there is no initial value for the destination this may very well happen.	21:44
janrinze	wire [4:0] A ; reg [3:0] B=0; assign A=B; .. what is A[4] supposed to be?	21:45
ZipCPU	I've been programming "C" too long that the answer is too obvious. A[4] is "supposed" to be a zero.	21:46
* ZipCPU 's mind will be blown if it isn't supposed to be a zero		21:46
janrinze	in any case it's not C but Verilog and each bit is just a wire. A[4] is not connected to anything.	21:47
key2	so should it be z or x ?	21:49
ZipCPU	If it's internal, it should be an x	21:49
key2	k	21:49
ZipCPU	(or a zero ... I'm still looking that up)	21:50
ZipCPU	I think I found the rule in the 2012 SV standard	21:51
* ZipCPU is taking a screenshot to share		21:52
janrinze	when doing arithmetic it will be different and verilog assumes that for example reg [4:0] A; reg [3:0] B; reg [3:0] C; always @* begin A = B + C; end will get the overflow of the addition in A[4].	21:52
ZipCPU	Yes. That's special tho	21:52
ZipCPU	https://imgur.com/dILJLMX	21:53
tpb	Title: Imgur: The magic of the Internet (at imgur.com)	21:53
janrinze	SV != Verilog.. it's a bit of a headache to get to grasp that..	21:53
ZipCPU	Sigh	21:53
ZipCPU	Are you suggesting I should look for another standard?	21:54
daveshah	I think Verilog is the same here	21:54
* ZipCPU switches to 1364-2005		21:54
janrinze	So what would A=B&C; result into? sign extension?	21:55
ZipCPU	"If a signed operand is to be resized to a larger signed width and the value of the sign bit is 'x', the resulting value shall be bit-filled with xs. If the sign bit of the value is z, then the resulting value shall be bit-filled with zs. If any bit of a signed value is x or z, then any nonlogical operation involving the value shall result in the entire resultant value being an x and the type consistent with the expression's	21:56
ZipCPU	type" ... not quite it	21:56
key2	what verilog version does yosys output ?	21:57
ZipCPU	I think it's supposed to be 2005. daveshah, can you correct me on this?	21:57
daveshah	Yes	21:57
* ZipCPU waits to be corrected		21:58
daveshah	I think that's correct too	21:58
daveshah	Yosys in general is Verilog 2005	21:58
daveshah	Possibly with a few SV extensions like assert and assume, if those are written	21:58
ZipCPU	Ok, I found the issue in the 2005 std. It's not nearly as clear, but I can share a snapshot	21:59
ZipCPU	Here's all I can find in 2005 related to the issue: https://imgur.com/i6XZwiB	22:01
tpb	Title: Imgur: The magic of the Internet (at imgur.com)	22:01
daveshah	It's the line above that's relevant	22:02
daveshah	If needed, extend the size of the right-hand side, performing sign extension if, and only if, the type	22:03
daveshah	of the right-hand side is signed.	22:03
ZipCPU	Well, sort of ... it doesn't say to use zero extension if the value isn't signed--which I think it should say	22:03
daveshah	I think that's what it implies	22:04
daveshah	I don't think SV and V differ on anything that fundamental	22:04
ZipCPU	The later standard was clearer, which was why I liked it	22:04
janrinze	oh, daveshah, thanks for the quick fixes.	22:05
janrinze	it looks like next-npr is a lot better than arachnepnr.	22:06
janrinze	opps next-pnr	22:06
ZipCPU	Oh, dear ... and I thought NPR was bad. Are we now switching to discussing political topics?	22:07
ZipCPU	Oh, ok	22:07
janrinze	:D	22:07
daveshah	no problem, thanks for the good quality issues :)	22:08
janrinze	daveshah: I orered a up5k eval board so i can test that too. Been only using yosys with the hx8k boards like icoboard and such.	22:12
janrinze	*ordered	22:12
janrinze	ZipCPU: your SoC has libraries for reading SDcard FAT and such?	22:13
ZipCPU	No. I never got as far as processing the FAT of an SDcard. I got far enough along that I can read and write raw sectors though.	22:13
janrinze	raw sectors is a good start, i guess.	22:14
janrinze	I should give that a try soon.	22:14
ZipCPU	Also, I only did SPI mode. There is a full SD-SPI simulator, and you can try working with it at https://github.com/ZipCPU/zbasic	22:15
tpb	Title: GitHub - ZipCPU/zbasic: A bare bones, basic, ZipCPU system designed for both testing and quick integration into new systems (at github.com)	22:15
janrinze	yes, SPI mode seems sufficient for my initial goals	22:15
ZipCPU	The https://github.com/ZipCPU/zbasic/blob/master/sw/board/sdtest.c file exercises it to prove that it works	22:15
tpb	Title: zbasic/sdtest.c at master · ZipCPU/zbasic · GitHub (at github.com)	22:15
ZipCPU	The documentation for the SDSPI core, though, is found with the core itself: https://github.com/ZipCPU/sdspi	22:16
tpb	Title: GitHub - ZipCPU/sdspi: SD-Card controller, using a SPI interface that is (optionally) shared (at github.com)	22:16
ZipCPU	Also, there's an open source FAT library that (should) make working with the core as is really easy--I just haven't tried it yet	22:17
ZipCPU	daveshah: Yosys seems to be optimizing nearly my whole design away. Any suggestions about the process to find and fix that?	22:18
daveshah	Nothing beyond the usual trawling through logs, really	22:18
janrinze	i have SPI for the flash memory, so i probably could wrap a simple memory mapped I/O for that like you have done.	22:19
daveshah	I would expect your lint process to catch most issues though	22:19
ZipCPU	So would I. It hasn't	22:19
ZipCPU	janrinze: I also have a similar QSPI flash core as well, that treats the flash memory as a bus peripheral	22:20
ZipCPU	It's designed to be a "universal" core, but the first chip I tested it on needed some "special" modifications. :D	22:20
ZipCPU	https://github.com/ZipCPU/qspiflash/blob/master/rtl/qflexpress.v	22:20
tpb	Title: qspiflash/qflexpress.v at master · ZipCPU/qspiflash · GitHub (at github.com)	22:20
janrinze	I read that people now want SPI accessed SRAM.. not sure if that's my cup-o-tea..	22:22
ZipCPU	Have you read about HyperRAM yet?	22:22
janrinze	I think it probably only matches sytems with cache well.	22:22
janrinze	or graphics buffers..	22:23
ZipCPU	You mean, the SPI accessed SRAM?	22:24
janrinze	or any other HyperRam that can do burst blocks but not do random access that well..	22:25
ZipCPU	It's faster than a DDR3 SDRAM at random access	22:26
ZipCPU	daveshah: I think I found the problem. Initially, I was holding the system in reset. Then, I misinterpreted yosys' "Removing unused module" statements	22:27
janrinze	ZipCPU: i have not seen any throughput numbers of random-access on HyperRam. DDR3 is quite slow with that indeed.	22:31
ZipCPU	janrinze: If you get file access, vice sector access, running with SDSPI please let me know. I'd love to share in the excitement. ;)	22:32
janrinze	ZipCPU: will do. I have limited time for my pet projects but hope to find some time during Christmas holidays.	22:33
ZipCPU	Yeah, you and me both	22:33
ZipCPU	I keep trying to blog about my I-cache implementation, and everytime it's just a bit beyond me	22:34
ZipCPU	Perhaps I can get that done over the holidays as well	22:34
janrinze	i did a I-cache in software for an ARM emulator, helped me a lot with understanding the performance in respect to caching strategies and size.	22:40
ZipCPU	It's been trying to explain the performance aspect that's given me the biggest struggle so far	22:41
janrinze	perhaps i can convert it to verilog some day. would be nice to test it. Also cache replacement strategies can be very complex	22:41
ZipCPU	The good news is that the basic formal contract is easy to express--it only takes three properties.	22:42
ZipCPU	The bad news is ... it can still be a pain to get it to pass.	22:42
*** seldridge0 has quit IRC		22:42
janrinze	ZipCPU: what type of cache startegy is your i-cache?	22:43
* ZipCPU has 39 assertions within his cache, others within the WB property file		22:43
ZipCPU	Direct-mapped	22:43
ZipCPU	It was easiest	22:43
janrinze	how many number of 'ways'?	22:44
ZipCPU	1-way (i.e. direct mapped). Going from direct-mapped to N-way shouldn't be that much extra work.	22:44
janrinze	hmm.. direct mapped means only one block is in cache and a cache miss does stall a lot?	22:45
ZipCPU	Direct mapped means that for any particular cache line, the line can be described with only one tag	22:45
ZipCPU	Does it miss and stall a lot? According to H&P that depends upon the size of the cache	22:45
ZipCPU	H&P also recommends running with a line size of ~8 instructions or so. I was using ~64 before, so I'm expecting a speed up in the near future due to this change of configuration	22:46
ZipCPU	daveshah: Is there a way to specify a clock speed in the pcf file?	23:02
ZipCPU	Nvm ... found what I needed in the documentation	23:04
janrinze	ZipCPU: does the cache use phys or virt address? or perhaps there is no MMU?	23:09
ZipCPU	While I have an MMU, I haven't yet integrated it. So ... I suppose I might as well not have it	23:09
janrinze	I found the old code and it handles the virt to phys translation as well.	23:10
ZipCPU	I didn't want to "pollute" the CPU with the MMU, since the purpose of the CPU was to be "low-logic". This means that the default I-cache doesn't know about the MMU. I'm trying to figure out how to maintain that, but reality means I'll need to modify the I-cache somewhat to support the MMU	23:12
janrinze	ah, i see. was tinkering with MMU the other day but it also requires a lot of software to handle and keep track of that. the sw is mainly simplistic stuff without a real OS so the MMU was getting in the way. Only graphics memory has a simple mapping for triple buffering for now.	23:12
janrinze	if the I-cache lines can be invalidated from the MMU (when MMU gets new mappings) then it is possible to cache virtual addresses.	23:14
ZipCPU	There was another optimization you could make, having to do with the fact that the cache line size would always be smaller than the page size	23:15
ZipCPU	Not remembering it now tho	23:15
janrinze	depends a bit on the indexing scheme, if the index scheme spans a page then each page change invalidates all cache lines with the tag for that page.	23:18
janrinze	if the index scheme is bigger then only the lines that can map to that page will require tag test and appropriate invalidation if necessary.	23:20

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