| --- Log opened Sun Feb 09 00:00:31 2014 | ||
| -!- FreezingAlt is now known as FreezingCold | 01:02 | |
| -!- Netsplit *.net <-> *.split quits: O01eg, hno | 01:30 | |
| -!- Netsplit over, joins: O01eg | 01:37 | |
| flozn | Hello guys! I still have problems to use minsoc for my Digilent Atlys board. There is some kind of meta-stable behaviour. There were many minsoc-builds which worked fine (cpu test fails but rest is working) and negligible changes in HDL code lead to CPU and/or Bus failing. | 17:11 |
|---|---|---|
| flozn | In the last days I tried to port the settings of orpsocv2/Atlys port to minsoc. Now, or1200, ethmac, clkgen, constraints are copied. | 17:11 |
| flozn | The only difference beside the arbiter is that minsoc builds one .ngc file for each IP-core (multiple .xst calls). Orpsocv2 calls xst only once but with a xst constraint file (which is not used in minsoc)! Is it possible, this is the reason for orpsocv2 working (50MHz) and minsoc struggling (even with 25MHz)? | 17:11 |
| flozn | (Try to synth minsoc with 50MHz: par error -> some internal adress signals of or1200 could not be routed successfully) | 17:13 |
| flozn | (In the next days I will try to append xst constraint files for each IP-core) | 17:21 |
| flozn | noone time to talk? ;) | 18:57 |
| veprbl | flozn: why do you want to use minisoc? | 19:12 |
| flozn | well, at first it seemed to be the best out-of-the-box solution with complete software-example and nice testbenches. for my problem orpsocv2 seems kind of to much. now i have the software for minsoc working fine (with c++)... | 19:19 |
| veprbl | if you suspect some build process related problem then maybe you can try factor it out by building everything manually (use ISE for example) | 19:20 |
| flozn | that sounds like an option! | 19:21 |
| flozn | (sry for bad english - not my mothertongue ;) ) | 19:22 |
| veprbl | your english is great | 19:22 |
| flozn | do you think the separation of the ip-cores could be the reason? | 19:22 |
| flozn | (multiple xst calls) | 19:22 |
| veprbl | to be honest I have no idea. I'd like to think that xilinx has got their software to a decent state. | 19:24 |
| veprbl | if stay here longer someone might come up with better idea/insight | 19:27 |
| veprbl | s/if/if you/ | 19:27 |
| flozn | i think the same but afaik this is the only difference in my system. all syn/par parameter are transfered to minsoc. the only thing missing in minsoc is a xst constraint file. and this file doesn't fit to all ip-cores (different signal names). at orpsocv2 one xst constraint file is enough because of the "signal tracking". | 19:27 |
| veprbl | you mean .ucf constraint file? | 19:29 |
| flozn | no! there is another constraint file. | 19:29 |
| flozn | .xcf | 19:29 |
| flozn | (it contains only raw input clk period constraint and reset tig) | 19:30 |
| flozn | i thought that someone maybe know whether it is worth to insert the specific .xcf files in minsoc or merge all xst calls to one. | 19:34 |
| veprbl | I don't see how that would matter. Joining few existing netlists should be a pretty straightforward process. | 19:34 |
| flozn | you mean xst does not care about the constraints in .xcf and just forward them to the following stages (ngdbuild,...) ? | 19:36 |
| veprbl | where exactly xcf reside? there are some ucf's and no xcf in minsoc repo | 19:45 |
| flozn | yes. minsoc does not contain any xcf files. only orpsocv2 uses one with "-uc orpsoc.xcf" at the xst call. | 19:46 |
| flozn | (first line of orpsoc.xcf: "# Autogenerated XST .prj file") | 19:47 |
| veprbl | yes I saw it | 19:47 |
| flozn | well, i may try to change the xst calls in minsoc... | 19:48 |
| veprbl | so again your problem was that minsoc won't synthesize with 50mhz constraint? | 19:49 |
| flozn | yes. but even with 25mhz it fails the cpu test and does not build reliable (some .bit files work, others not, while neglible changes of the verilog code). | 19:50 |
| flozn | so i think the atlys board wants some more constraints in minsoc than other (supported) boards. | 19:50 |
| flozn | (the build problems also occur without my wishbone slave) | 19:53 |
| veprbl | it is not like you have to specify system clock constraints | 19:54 |
| veprbl | just synthesize something and look at fmax | 19:54 |
| flozn | ok! well, without constraints the or1200 cpu just reaches 42.5mhz in my configuration (with original minsoc/dev or1200 hdl-directory) | 19:56 |
| veprbl | and how does it work? | 19:58 |
| flozn | this is from the log of a 25mhz build, which works fine. | 19:58 |
| flozn | and as i saw, 40.6mhz with the or1200 files of orpsocv2. | 19:58 |
| flozn | the cpu/bus problems occur also if "all constraints met" is written by par. :/ | 19:59 |
| flozn | but if i understood it right, the xst log shows up to which frequency the generated netlists can be used. because there are no values below 25mhz, at least the 25mhz minsoc should work! | 20:03 |
| flozn | the clock/reset generation are the same and the ucf constraints are the same (signal names changed torwards to minsoc) as orpsocv2 | 20:07 |
| veprbl | and what exactly is your test that fails? | 20:07 |
| flozn | that differs between: cpu not stalled, crc error, and "no error" (without selftest) but than gdb stucks at 0x000 or 0x100 ... | 20:08 |
| veprbl | you mean your debugger doesn't work? | 20:09 |
| flozn | another thing differing between minsoc and orpsocv2 is the jtag tap: in minsoc i use the bscan module instead of a generic tap | 20:09 |
| veprbl | well, this is an important part | 20:10 |
| flozn | i may wrote not exact: the debugger shows me "sigint" or similar exception after loading content in, set $pc=0x100 and continuing | 20:10 |
| flozn | oh | 20:10 |
| flozn | you mean the jtag tap leads to the problems? | 20:10 |
| veprbl | of course! this is the first suspect | 20:11 |
| flozn | ... shame on me | 20:11 |
| flozn | hm ... | 20:11 |
| veprbl | do they both use dbg_if? | 20:13 |
| flozn | so i will make another debug wire and check the 25mhz minsoc with generic tap. if this works reliable i may try to insert the .xcf constraints to get netlists which allow over 40mhz | 20:13 |
| flozn | minsoc: advanced debug interface | 20:13 |
| veprbl | then what jtag adapter are you using with orpsocv2? | 20:13 |
| flozn | my desktop pc: advanced debug bridge and openocd (both fail. i reached just one case where only openocd works) | 20:14 |
| flozn | ft2232 | 20:14 |
| flozn | ah. stop. i didn't started orpsocv2 until now. i relied on the successful results of stekern | 20:15 |
| veprbl | the tap itself is not as important as debug module | 20:15 |
| flozn | ok. in another irc session someone told me advanced debug interface is reliable | 20:16 |
| flozn | but may this was wrong | 20:16 |
| veprbl | and it is, but if it never worked for you how do you know that you're doing it right? | 20:16 |
| flozn | i don't know! in the minsoc wiki is written, the cpu self test does not work 100% due to different or1200 versions. so i did not give much about the failing cpu test as long as the soc works. | 20:18 |
| veprbl | don't mind the cpu. try writing/reading memory | 20:20 |
| flozn | do you think i shall try the dbg_if module instead of adgb_top before changing the jtag tap? | 20:20 |
| flozn | memory reading and writing is ok in at least half of the bitfiles. but thats not the yield i expect ;) ... | 20:21 |
| veprbl | and when it works everything else is working? | 20:23 |
| flozn | yes. | 20:24 |
| flozn | but wait! | 20:24 |
| flozn | one time there was a strange error in proven c++ code. i examined every asm line and could not find any error. but the some hard-exception (sigint,busint,... ? dont know anymore, sry) occured. | 20:25 |
| flozn | but 99% yes. | 20:25 |
| veprbl | thats enough. so it is working | 20:26 |
| flozn | so now there is a problem of the debug interface or the tap?! | 20:26 |
| veprbl | for both orpsocv2 and minsoc you had one time when it loaded your program and execution worked well? if yes then both jtag-if and tap should be ok. | 20:29 |
| flozn | as mentioned above i did not load any program into orpsocv2. i relied on the experiences of stefan kristiansson. | 20:31 |
| flozn | maybe i shall append some constraints to the adgb interface which the dgb_if not needs? | 20:32 |
| veprbl | you don't need any time constraints for your generic minisoc design | 20:35 |
| veprbl | so there was that one time when you loaded a program into your minisoc system and it worked? | 20:37 |
| flozn | there are bitfiles which work fine | 20:37 |
| flozn | (but cpu test fails ...) | 20:37 |
| veprbl | work fine but cpu test fails? how is that fine? | 20:38 |
| flozn | ok, than i misunderstood you above. i though only the memory test is really necessary | 20:39 |
| flozn | i got one bitfile of minsoc where all self-tests work. but not with the i2c-core. | 20:40 |
| flozn | (i could not find an exakt cause. so i think there is problem in the build process / constraining. while appending some things in my own wishbone slave the bitfiles switch between ok/non-ok ) | 20:41 |
| veprbl | not with i2c core synthesized or not with i2c test? | 20:42 |
| flozn | not with i2c core synthesized | 20:43 |
| veprbl | if you don't need i2c turn it off now | 20:46 |
| flozn | you mean the system is only correctly synthesized if the cpu test passes? | 20:46 |
| flozn | i did. | 20:47 |
| veprbl | so you do these changes that break the system. what are they? | 20:48 |
| flozn | you condensed the problem right ;) . i have a lot of backup-versions. but i was searching for a way to get a reliable configuration. i started two times at the working example and added verilog code which can not be the reason (only some more fsm states). and such small changes lead to the broken bitfile. | 20:50 |
| flozn | of course there may be an error inserted by me in the last days of trying but i think this is a structural problem like syn/par or as you say dbg/tap. | 20:51 |
| veprbl | forget about dbg/tap for now | 20:52 |
| veprbl | you say that your changes can not be the reason. why do you think so? | 20:53 |
| flozn | well, these are small changes which are verified by icarus verilog simulator. and they e.g. do not lead to increased frequency. | 20:55 |
| flozn | ah | 20:55 |
| flozn | and the 64kb sram changed a working bitfile into a broken bitfile. | 20:55 |
| veprbl | was it a resize? | 20:56 |
| flozn | than i started to change the xilinx tools parameters torwards to orpsocv2. they are nearly default whereas minsoc has some specific options set. | 20:57 |
| flozn | resize: i changed in minsoc_defines the MEMORY_ADR_WIDTH to 14 | 20:57 |
| veprbl | sidenote: changing ALL variables at the same time is often a not very efficient debug practice | 20:58 |
| flozn | hehe, of course ;). i changed only one at a time. i build the minsoc hundred times ... | 20:59 |
| veprbl | and after that resize you couldn't anymore connect to jtag? | 21:01 |
| flozn | the behaviour varied quite arbitrary between cpu not stalled, crc error, sram error, ok | 21:02 |
| veprbl | you use OpenOCD? adv_jtag_bridge? | 21:04 |
| flozn | i tried both | 21:04 |
| veprbl | cpu not stalled, crc error, sram error, ok - those come from jtag software? | 21:05 |
| flozn | only *one* bitfile was accessable only by openocd. all others either by both or not at all | 21:05 |
| flozn | yes | 21:05 |
| veprbl | and one bitfile could produce all of the above errors? | 21:06 |
| flozn | no. each bitfile results in its specific error. but it seems to me the kind of the error varies quite arbitrary. "all constraints are met" is printed always! | 21:08 |
| veprbl | how do you load your bitfiles? | 21:10 |
| flozn | gdb: file [...] , tar rem :9999 , load , set $pc=0x100, c | 21:10 |
| flozn | , = enter | 21:10 |
| veprbl | I mean fpga bit files | 21:11 |
| flozn | sry! impact | 21:11 |
| veprbl | via jtag? | 21:11 |
| flozn | via another(!) usb cable | 21:11 |
| flozn | the atlys board contains a usb-jtag converter which is needed by impact and not supported by adgb_bridge/openocd | 21:12 |
| veprbl | and they share tap pins with ft2232? | 21:13 |
| flozn | and: very strange - i used a long, unshielded cable for programming bitfile at first. than the same bitfile sometimes worked, sometimes not. after changing to a short and shielded usb-cable each bitfile behaves always the same. | 21:13 |
| flozn | ft2232 directly accesses the jtag-lanes from spartan-6. the onboard usb-jtag converter accesses the same lanes. i connect and disconnect the usb-cables for bitfile programming respective gdb | 21:14 |
| flozn | so i have to use the bscan jtag tag with the jtag header on the board (which i use at the moment with ft2232). orpsocv2 uses the gpio pins of another header and route the jtag-signals of the generic tap to them | 21:16 |
| veprbl | how long is the cable to ft2232? | 21:17 |
| flozn | the jtag wires below 10cm, the usb cable 1.5m (but quite thick/shielded) | 21:18 |
| flozn | you mean this could be the problem? | 21:19 |
| veprbl | by the way. sram is in fpga crystal or there is some external chip? | 21:19 |
| flozn | in fpga. synthesized with blockram | 21:20 |
| veprbl | did you try to initialize it with image? | 21:20 |
| flozn | the ram? i did not tried until now. the blockrams i use in my own wb-slave are initialized with zero. the line "defparam blockram.INIT_00" is not supported (in icarus it works fine). | 21:22 |
| veprbl | try doing this. if you have uart then you will be able to confirm that cpu is alive | 21:23 |
| flozn | thats a great idea! | 21:23 |
| veprbl | do you know how to obtain hex from elf file? | 21:23 |
| flozn | so i can exclude the tap and dbg interface from being the cause of the problem | 21:23 |
| veprbl | yes! | 21:24 |
| flozn | i think with the objdump tool or not? | 21:24 |
| flozn | how do i initialize the ram without using the "defparam blockram.INIT_xx" command? the synthesis doesn't allow them | 21:25 |
| flozn | do i have to use rom and a small bootloader? this would also be a big effort (compare to trying other dgb/tap) ... | 21:27 |
| veprbl | I do this with or1k-elf-objcopy and then do "xxd -p -c 4 program.bin > program.hex". $readmemh will eat that | 21:27 |
| flozn | readmemh? | 21:28 |
| veprbl | no. whatever elf file you loaded via jtag will do | 21:28 |
| flozn | so initializing the ram is not an option? the bitfile should "simply" contain a .hex file . | 21:30 |
| veprbl | you need to somehow tell bitgen to initialize your onchip memory with the contents of that file | 21:33 |
| veprbl | in minsoc block ram resides somewhere in minsoc/rtl/verilog/minsoc_onchip_ram_top.v | 21:34 |
| flozn | yes, just studying it ;) | 21:34 |
| veprbl | you will need to put $readmemh statement somewhere | 21:34 |
| flozn | and i found some information at http://www.minsoc.com/minsoc_faq | 21:34 |
| flozn | and this is read by bitgen? | 21:34 |
| veprbl | use orpsocv2/rtl/verilog/ram_wb/ram_wb.v for reference | 21:34 |
| flozn | sounds like a simulation function?! | 21:34 |
| flozn | in \orpsocv2\rtl\verilog\ram_wb\ram_wb_b3.v the $readmemh seems to be only for simulation | 21:36 |
| flozn | there is a solution in "I want my design to automatically initialize my firmware on power-up, how do I do that?" of minsoc faq. | 21:37 |
| flozn | i will try this at first! hopefully the dbg interface/ jtag tap is the reason. i searched a long time and think it would be nice if minsoc would work now. | 21:38 |
| veprbl | yes it is and in ram_wb it is intended for simulation but if you ommit those "// synthesis translate_off" it will autmagically work | 21:38 |
| flozn | very nice feature :) | 21:39 |
| veprbl | if you use isim there is a way to check that everything initialized correctly. there is some kind of memory inspector. | 21:40 |
| flozn | you mean or1k-sim? | 21:40 |
| veprbl | xilinx isim | 21:40 |
| flozn | no, i just use the icarus verilog simulator | 21:41 |
| flozn | but the inspector sounds nice | 21:41 |
| flozn | ok. i think this is enough input for today :) | 21:44 |
| veprbl | xilinx has some tool to generate "proper" memory initialization files, but I didn't try it | 21:44 |
| flozn | if there is one, i will find it in the next days :) ! | 21:44 |
| veprbl | great! | 21:45 |
| flozn | thanks alot(!!) for your great patience!! | 21:45 |
| veprbl | you're welcome! | 21:45 |
| flozn | as you see, there are alot of things which could be the reason. some are more others are less likely ;) | 21:46 |
| flozn | did you have used minsoc in the past? if yes, above 25mhz? | 21:47 |
| veprbl | I've booted orpsocv2 last november, and it was a little bit above 25. Since then I've replaced or1200 with mor1kx and now it is somewhere around 80-90 i think. | 21:51 |
| flozn | wow! | 21:51 |
| flozn | thats an improvement. | 21:51 |
| flozn | altera or xilinx device? | 21:51 |
| veprbl | It's not like my merit) | 21:51 |
| flozn | ok ;) | 21:52 |
| veprbl | slx9 | 21:52 |
| veprbl | mor1kx is also a great help with saving some area | 21:53 |
| veprbl | as well as switching to adv_dbg_if | 21:54 |
| flozn | you switched to it? | 21:54 |
| veprbl | yep | 21:54 |
| flozn | well. than i want to thank you again! for all the input and critical questions which hopefully lead to solving my "everlasting minsoc problem" :) | 21:57 |
| veprbl | yeah. You shouldn't really think that this is something beyond your reach. | 21:58 |
| flozn | thanks for the supporting words! ;) | 21:59 |
| flozn | than i would say goodbye from germany :) | 22:00 |
| veprbl | goodbye!) | 22:02 |
| --- Log closed Mon Feb 10 00:00:32 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!