clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
pie__ has joined #yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
pie___ has quit [Remote host closed the connection]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
seldridge has quit [Ping timeout: 250 seconds]
seldridge has joined #yosys
pie__ has quit [Remote host closed the connection]
pie___ has joined #yosys
leviathanch has joined #yosys
rohitksingh_work has joined #yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
AlexDaniel has quit [Read error: Connection reset by peer]
AlexDaniel has joined #yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
pie__ has joined #yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
pie___ has quit [Remote host closed the connection]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
seldridge has quit [Ping timeout: 245 seconds]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
dys has quit [Ping timeout: 240 seconds]
wavedrom has joined #yosys
wavedrom has quit [Ping timeout: 240 seconds]
leviathanch has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
pie___ has joined #yosys
pie__ has quit [Remote host closed the connection]
seldridge has joined #yosys
seldridge has quit [Ping timeout: 250 seconds]
rohitksingh has joined #yosys
seldridge has joined #yosys
pie__ has joined #yosys
pie___ has quit [Remote host closed the connection]
m4ssi has quit [Remote host closed the connection]
seldridge has quit [Ping timeout: 250 seconds]
wavedrom has joined #yosys
seldridge has joined #yosys
key2 has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
dys has joined #yosys
<key2> hi
<key2> how can one generates verilog without comments ?
<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`
<daveshah> Are you sure you don't mean the attributes?
<key2> yeah i mean those attr (* src = "/x/x/x/" *)
<daveshah> Use `write_verilog -noattr`
<daveshah> or, alternately `write_verilog -attr2comment` if you want to turn them into real comments (/**/)
<key2> I see
<key2> thx
<key2> but then would I lose other usefull attribute ?
<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
<daveshah> out of curiosity, what tool are you feeding this verilog into?
<key2> vivado or verilator
<daveshah> I don't think either of those will have any problem with attributes
seldridge has quit [Ping timeout: 272 seconds]
<key2> thx
<key2> working wiht nMigen, generating rtlil and converting to verilog
<daveshah> Oh awesome! I'm really excited about nMigen
seldridge has joined #yosys
<key2> just generated my riscv with it
lutsabound has joined #yosys
key2 has quit [Quit: Page closed]
key2 has joined #yosys
janrinze has joined #yosys
<janrinze> next-pnr is a great addition to the icestorm/yosys environment. kudos to all involved.
<janrinze> as a small test has already shown me it can produce up to 20% faster stable clock for my SoC design. Nice!
wavedrom has quit [Ping timeout: 250 seconds]
seldridge has quit [Ping timeout: 240 seconds]
rohitksingh has joined #yosys
nurelin_ has joined #yosys
dxld has quit [Ping timeout: 260 seconds]
seldridge has joined #yosys
dxld has joined #yosys
<key2> Someonas has some experience about generating verilog code for verilator ?
<key2> I wonder if there are any kind of optimisation that are needed
seldridge has quit [Ping timeout: 240 seconds]
<ZipCPU> key2: I use Verilator all the time
<ZipCPU> I don't generate my Verilog code explicitly for verilator though--it's just my normal Verilog code but with one exception
<ZipCPU> First, I always use the -Wall option. It provides a basic lint capability, and *SO* many bugs right there
seldridge has joined #yosys
<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
<ZipCPU> For these, I surround them with comments such as // Verilator lint_off UNUSED
<ZipCPU> and again // Verilator lint_on UNUSED
<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.
<ZipCPU> An example of such would be a PLL. Verilator doesn't generate PLL's, so these would go in the toplevel
rohitksingh has quit [Remote host closed the connection]
<key2> ZipCPU: I know, currently I'm testing a generation of verilog from rtlil
<ZipCPU> Ok, cool, how's it working out for you?
<ZipCPU> I have a project, btw, that does just that ... generates verilog from a bit stream which is then run into Verilator
<key2> well the thing is, we are testing nMigen currently
<ZipCPU> Go on
<key2> which generates rtlil
<key2> I was wondering for example what you do with memrd and memwr privimives
<ZipCPU> Wow, all the way down to rtlil within migen? Is it using yosys internally at all?
<key2> ZipCPU: nMigen is the next migen
<key2> I sponsored whitequarks to write it
<ZipCPU> Nice, go on
<key2> yeah in fact it will generates rtlil
<key2> instead of writing the verilog alla migen
<key2> what kind of verilog do you use with verilator when using code generated from yosys ?
<ZipCPU> Your memrd and memwr primitives ... do they have Verilog equivalents? (They should, right?)
<ZipCPU> You are welcome to examine the project: https://github.com/ZipCPU/cputest-harness
<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)
<ZipCPU> The guts are found in the primary makefile
<ZipCPU> Basically, there's a cell simulator for the iCE40 that I was able to include to create a complete Verilator based project
<key2> always @(posedge clk_i) x <= (y)? 1'bz : m;
<key2> this kinda thing doesn't wokr with verilator in fact
<ZipCPU> It sort of does, but only at the top level.
<ZipCPU> I've used that with success before. I just don't know the limits of how far it can be made to work.
<ZipCPU> Or ... maybe I've only used: assign x = (y) ? 1'bz : m; /// not sure
<ZipCPU> I know I've used one of the two successfully, and it surprised me when I did
<key2> =
<key2> yes
<ZipCPU> You can generate the posedge clk_i one from the assign one
<ZipCPU> always @(posedge clk_i) begin r_i <= y; r_x <= x; end assign x = (r_y) ? 1'bz : r_x;
<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'
<ZipCPU> Which version of Verilator?
<key2> 4.0.0.devel
<ZipCPU> Is that the github version?
<ZipCPU> I mean, raw git version?
* ZipCPU is shooting in the dark
lutsabound has quit [Quit: Connection closed for inactivity]
<key2> probably yes
<ZipCPU> I know that there are times when it helps to create an always @(*) block to replace several assign statements
<ZipCPU> But, not sure if this helps either
* ZipCPU is still shooting in the dark
<tpb> Title: debian Pastezone (at paste.debian.net)
<ZipCPU> You only want one of those bits to be a 'z'?
<ZipCPU> If so, that's probably the problem
<ZipCPU> Verilator is word based, and doesn't handle bit level operations all that well. Try this:
<ZipCPU> always @(*) begin finst_pc94$next[30] = (rst) ? 1'bz : _144_[30]; finst_whatever[29:0] = 1 : _144_[29:0];
<ZipCPU> Oh, and don't forget the "end" on the "end" of that :)
<key2> ha i found smth
<key2> thx
<key2> works now
<ZipCPU> Cool! What was it?
<key2> well i was getting the z because i was converting from 30 to 31 bits
<key2> therefor, nMigen filled it with a z
<ZipCPU> z doesn't seem like the right value to fill something with
<key2> now I forced a concatenation
<ZipCPU> Wouldn't you rather fill it with x?
<daveshah> Yeah, x would make more sense
<daveshah> z is tristate and should really only be used for IO pins imo
<ZipCPU> ^ +1
<daveshah> x is undefined and any synthesis tool will optimise it as a don't care
<key2> could also x be used instead of z ?
<daveshah> It should be used instead of z
<key2> on top level
<key2> on io pins
<key2> tristates
<ZipCPU> No. 'z' is a tristate, 'x' is an undefined
<daveshah> No
<key2> i see
<key2> so thats a bug in nMigen
<key2> ;)
lutsabound has joined #yosys
<ZipCPU> Actually, let me be clearer: 'z' is high impedence, as used within a tristate. 'z' by itself isn't tristate
<key2> it's yosys that added it
<key2> as my rtlil didn't have this :)
<ZipCPU> I thought you said you weren't using yosys?
<key2> i am
<key2> nMigen -> rtlil -> yosys -> verilog -> verilator
<key2> :)
<ZipCPU> Just to convert RTLIL to Verilog after nMigen creates the RTLIL?
<key2> yes
<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
<ZipCPU> Oh, okay
<ZipCPU> daveshah: Do you know where yosys might be adding a 'z' to RTL?
<daveshah> Maybe if something is disconnected?
<ZipCPU> key2: This was a data range issue, right? Where you were going from a 30 bit register to a 31 bit register?
<key2> in this case, it's when you take a signal of 31 bits let say, and give it a 30 bit value
<key2> it filled it with a z
<key2> yeah
<key2> and verilator didnt like it
<ZipCPU> In Verilog, it should propagate the high order bit. Not sure of the semantics of RTLIL
<janrinze> in Verilog the top bit would be undefined and thus z.
seldridge0 has joined #yosys
<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
<ZipCPU> If it's a 1 or 0, and the value is unsigned, it propagates up as a zero
<ZipCPU> Nothing gets left on the floor as undefined--unless you make it so
<janrinze> sign extension is possible with signed values
seldridge has quit [Ping timeout: 250 seconds]
<key2> in fact the value is a negative value
<key2> that might explain
<ZipCPU> Converting a set value (the sign bit) to a z sounds like a bug
<janrinze> if there is no initial value for the destination this may very well happen.
<janrinze> wire [4:0] A ; reg [3:0] B=0; assign A=B; .. what is A[4] supposed to be?
<ZipCPU> I've been programming "C" too long that the answer is too obvious. A[4] is "supposed" to be a zero.
* ZipCPU 's mind will be blown if it isn't supposed to be a zero
<janrinze> in any case it's not C but Verilog and each bit is just a wire. A[4] is not connected to anything.
<key2> so should it be z or x ?
<ZipCPU> If it's internal, it should be an x
<key2> k
<ZipCPU> (or a zero ... I'm still looking that up)
<ZipCPU> I think I found the rule in the 2012 SV standard
* ZipCPU is taking a screenshot to share
<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].
<ZipCPU> Yes. That's special tho
<tpb> Title: Imgur: The magic of the Internet (at imgur.com)
<janrinze> SV != Verilog.. it's a bit of a headache to get to grasp that..
<ZipCPU> Sigh
<ZipCPU> Are you suggesting I should look for another standard?
<daveshah> I think Verilog is the same here
* ZipCPU switches to 1364-2005
<janrinze> So what would A=B&C; result into? sign extension?
<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
<ZipCPU> type" ... not quite it
<key2> what verilog version does yosys output ?
<ZipCPU> I think it's supposed to be 2005. daveshah, can you correct me on this?
<daveshah> Yes
* ZipCPU waits to be corrected
<daveshah> I think that's correct too
<daveshah> Yosys in general is Verilog 2005
<daveshah> Possibly with a few SV extensions like assert and assume, if those are written
<ZipCPU> Ok, I found the issue in the 2005 std. It's not nearly as clear, but I can share a snapshot
<ZipCPU> Here's all I can find in 2005 related to the issue: https://imgur.com/i6XZwiB
<tpb> Title: Imgur: The magic of the Internet (at imgur.com)
<daveshah> It's the line above that's relevant
<daveshah> If needed, extend the size of the right-hand side, performing sign extension if, and only if, the type
<daveshah> of the right-hand side is signed.
<ZipCPU> Well, sort of ... it doesn't say to use zero extension if the value isn't signed--which I think it should say
<daveshah> I think that's what it implies
<daveshah> I don't think SV and V differ on anything that fundamental
<ZipCPU> The later standard was clearer, which was why I liked it
<janrinze> oh, daveshah, thanks for the quick fixes.
<janrinze> it looks like next-npr is a lot better than arachnepnr.
<janrinze> opps next-pnr
<ZipCPU> Oh, dear ... and I thought NPR was bad. Are we now switching to discussing political topics?
<ZipCPU> Oh, ok
<janrinze> :D
<daveshah> no problem, thanks for the good quality issues :)
<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.
<janrinze> *ordered
<janrinze> ZipCPU: your SoC has libraries for reading SDcard FAT and such?
<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.
<janrinze> raw sectors is a good start, i guess.
<janrinze> I should give that a try soon.
<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
<tpb> Title: GitHub - ZipCPU/zbasic: A bare bones, basic, ZipCPU system designed for both testing and quick integration into new systems (at github.com)
<janrinze> yes, SPI mode seems sufficient for my initial goals
<ZipCPU> The https://github.com/ZipCPU/zbasic/blob/master/sw/board/sdtest.c file exercises it to prove that it works
<tpb> Title: zbasic/sdtest.c at master · ZipCPU/zbasic · GitHub (at github.com)
<ZipCPU> The documentation for the SDSPI core, though, is found with the core itself: https://github.com/ZipCPU/sdspi
<tpb> Title: GitHub - ZipCPU/sdspi: SD-Card controller, using a SPI interface that is (optionally) shared (at github.com)
<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
<ZipCPU> daveshah: Yosys seems to be optimizing nearly my whole design away. Any suggestions about the process to find and fix that?
<daveshah> Nothing beyond the usual trawling through logs, really
<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.
<daveshah> I would expect your lint process to catch most issues though
<ZipCPU> So would I. It hasn't
<ZipCPU> janrinze: I also have a similar QSPI flash core as well, that treats the flash memory as a bus peripheral
<ZipCPU> It's designed to be a "universal" core, but the first chip I tested it on needed some "special" modifications. :D
<tpb> Title: qspiflash/qflexpress.v at master · ZipCPU/qspiflash · GitHub (at github.com)
<janrinze> I read that people now want SPI accessed SRAM.. not sure if that's my cup-o-tea..
<ZipCPU> Have you read about HyperRAM yet?
<janrinze> I think it probably only matches sytems with cache well.
<janrinze> or graphics buffers..
<ZipCPU> You mean, the SPI accessed SRAM?
<janrinze> or any other HyperRam that can do burst blocks but not do random access that well..
<ZipCPU> It's faster than a DDR3 SDRAM at random access
<ZipCPU> daveshah: I think I found the problem. Initially, I was holding the system in reset. Then, I misinterpreted yosys' "Removing unused module" statements
<janrinze> ZipCPU: i have not seen any throughput numbers of random-access on HyperRam. DDR3 is quite slow with that indeed.
<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. ;)
<janrinze> ZipCPU: will do. I have limited time for my pet projects but hope to find some time during Christmas holidays.
<ZipCPU> Yeah, you and me both
<ZipCPU> I keep trying to blog about my I-cache implementation, and everytime it's just a bit beyond me
<ZipCPU> Perhaps I can get that done over the holidays as well
<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.
<ZipCPU> It's been trying to explain the performance aspect that's given me the biggest struggle so far
<janrinze> perhaps i can convert it to verilog some day. would be nice to test it. Also cache replacement strategies can be very complex
<ZipCPU> The good news is that the basic formal contract is easy to express--it only takes three properties.
<ZipCPU> The bad news is ... it can still be a pain to get it to pass.
seldridge0 has quit [Ping timeout: 245 seconds]
<janrinze> ZipCPU: what type of cache startegy is your i-cache?
* ZipCPU has 39 assertions within his cache, others within the WB property file
<ZipCPU> Direct-mapped
<ZipCPU> It was easiest
<janrinze> how many number of 'ways'?
<ZipCPU> 1-way (i.e. direct mapped). Going from direct-mapped to N-way shouldn't be that much extra work.
<janrinze> hmm.. direct mapped means only one block is in cache and a cache miss does stall a lot?
<ZipCPU> Direct mapped means that for any particular cache line, the line can be described with only one tag
<ZipCPU> Does it miss and stall a lot? According to H&P that depends upon the size of the cache
<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
<ZipCPU> daveshah: Is there a way to specify a clock speed in the pcf file?
<ZipCPU> Nvm ... found what I needed in the documentation
<janrinze> ZipCPU: does the cache use phys or virt address? or perhaps there is no MMU?
<ZipCPU> While I have an MMU, I haven't yet integrated it. So ... I suppose I might as well not have it
<janrinze> I found the old code and it handles the virt to phys translation as well.
<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
<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.
<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.
<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
<ZipCPU> Not remembering it now tho
<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.
<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.
tpb has quit [Remote host closed the connection]
tpb has joined #yosys