14:50 <desowin> Can I view (if yes, then how) the RTL after building migen based project for Xilinx xc6slx9-3tqg144 (ov3_ftdi in particular)?

18:15 <kittennbfive> desowin: Yosys has a command to build some graphs using graphviz, but i tried it and either it the graphs where so huge that i couldn't even open them or they where not really clear/helpful. Anyway, if you want to try: http://bygone.clairexen.net/yosys/cmd_show.html

18:18 <kittennbfive> Other question: Is there any good (english) book or similar about writing fast code? The Verilog *syntax* is really simple if you know C, but i am *really* struggling with the speed. Sometimes changing a single digit in the code makes 20MHz of difference and i don't understand the logic... I would need something like "Do X, don't do Y" or similar.

18:18 <kittennbfive> (feel free to answer even if i am offline, reading the archives)

21:12 <knielsen> kittennbfive: The key to synthesizing fast logic is to think in terms of the circuits you want to have, and then use the Verilog code to express that circuit. Not to think too much in terms of the concrete syntax written. Think in terms of dependencies (and use pipelining to split long dependency chains). Routing starts to matter a lot for larger curcuits, something that's not even visible on the

21:12 <knielsen> verilog level

21:17 <kittennbfive> Thanks for your reply. Thats exactly the problem, thinking in terms of circuits. I have a software background, i know some stuff like basic logic gates, i know what pipelining means in theory and so on but this does not help me. There must be some book or sth to learn this?? Or - to join desowin - is there a better way to visualize the output of Yosys to see what the tool actually made out of the Verilog input?

21:17 <kittennbfive> (I am having a really hard time parsing the timing informations from nextpnr too.)

21:18 <desowin> I don't think pipelining is what matters here, but more like doing as much as possible in single clock cycle

21:19 <knielsen> Hm, the only book I've read is "CMOS VLSI design", I think it's quite good but it has mostly focus on the CMOS technology, there are probably better books for circuit design

21:20 <jn> there's a balance to be struck between (the extremes of) doing a lot in a single clock cycle and thus potentially having a long propagation delay and low fmax, versus heavy pipelining that might result in many cycles per operation

21:21 <jn> sometimes high clock frequency is more important, sometimes performance per cycle is more important, sometimes performance per time, or other factors like area usage

21:35 <kittennbfive> Maybe i should tell more about my problem: I have https://github.com/q3k/chubby75/blob/master/5a-75b/hardware_V7.0.md and after blinking an LED, making a simple UART and all this stuff (that is not critical in terms of fmax) i - once again - try to make a SDRAM controller for this board. I had an almost working design at some point with fmax 190MHz (PLL output 175MHz, the RAM can go up to 200MHz in theory) but i made a small

21:35 <kittennbfive> mistake and after correcting it (width of a reg+1) the fmax dropped to like 150MHz or so. I want to understand what is going on, learn more about how my code is synthesized and all this to be able to write fast code.

21:37 <jn> how stable is that 150MHz number across multiple PnR runs?

21:38 <jn> i'd suspect some random variation (unless the RNG seed is fixed to one value)

21:39 <kittennbfive> The fmax are quite stable (+-1 or 2 MHz max) between runs of nextpnr (compiled like 10 days ago from git master)

21:40 <kittennbfive> However the slighest(?) change in the code can make a huge difference and that's my problem, i don't understand the logic... Software kitten messing with hardware i guess...