Note: It did really help to have your full quartus project online to play with, that was probaly what immediately triggered my internal analyzer/debugger.... :-)
On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote: > > Valid Files Here: > > On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote: >> >> Ups Sorry sorry sorry ... my BAD .... (Suddently my biain kicked in :-) ) >> I should have spotted it immediately. >> Culprit is due to my single experimental (verilog) added capasitive >> depth/touch sensor core. >> This is not a part of the "original mesa hm2 vhdl config system, and the >> pins are hardwired to: >> GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in >> config file) >> --- >> Solution is very simple: >> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/ >> atlas_st_fpga_soc_dc1f_ss.sv >> --> parameter Capsense = 0; >> >> I have tested with: >> (StepGenTag, x"02", ClockLowTag, x"06", >> StepGenRateAddr&PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >> >> and all >> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 >> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 >> entities show up populated. >> :-) >> once again excuse for my temporary brain paralysys.. >> ... >> >> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote: >>> >>> Dig through the synthesis log (*.map.rpt) a bit and look for warnings >>> that indicate undriven nets. Sadly, most tool chains consider >>> undriven signals a warning vs. an error, so they'll happily optimize >>> away huge chunks of your design. A typical warning would look >>> something like: >>> >>> Warning (10541): VHDL Signal Declaration warning at >>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for >>> signal "clk250_out" because signal was never assigned a value or an >>> explicit default value. Use of implicit default value may introduce >>> unintended design optimizations. >>> >>> In vim, I use the regex: ^Warning.*$ which highlights the whole line >>> (if you're in GUI mode). >>> >>> Note you will see lots of other warnings, most of which are probably >>> OK. In particular, the ever present: >>> >>> Warning (10036): Verilog HDL or VHDL warning at >>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but >>> never read >>> >>> ...is (usually) perfectly OK, it's similar to an unused variable in >>> "C". This _might_ be an actual error (if the signal was supposed to >>> go somewhere) but is typically OK. >>> >>> On 8/20/2019 9:09 AM, justin White wrote: >>> > Thanks for the advice Charles. Actually I use this project: >>> > >>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps >>> >>> > >>> > Michael explained it has more functionallity than the DB25 project, so >>> I've >>> > never tried the DB25. >>> > >>> > Not really up on my git stuff, I forked master and slapped my config >>> files >>> > in, like I said these are modifications of the "3x24_cap_enc" config. >>> > https://github.com/blazini36/mksocfpga >>> > >>> > The pin assignments are so different from anything else I can't >>> imagine >>> > it's looking at another pinfile, it's likely I just didn't modify >>> something >>> > I probably should have. I'll try to look into your suggestions a bit >>> later. >>> > >>> > >>> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler >>> wrote: >>> >> >>> >> It sounds like the synthesis tools are optimizing away the stepgen >>> >> logic, almost certainly because of an issue with signal connectivity >>> >> to the top level I/O pins. The actual step accumulator is still >>> >> generated because it's value gets read back via the register >>> >> interface, but the steptables are only needed to generate the output >>> >> signals so they're getting optimized away. >>> >> >>> >> Is your project checked into github somewhere I can grab it? I can >>> >> try building in the desktop Quartus tools and see what's wrong. >>> >> >>> >> Otherwise, double-check the pin assignments the top-level I/O port >>> >> definitions, and make sure the physical I/O pins are properly >>> >> connected to the hm2 instance. >>> >> >>> >> I took a quick look at the project I think you're using: >>> >> >>> >> >>> >> >>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/ >>> >>> >> >>> >> ...and the top-level stuff looks OK at first glance. The important >>> >> part is the use of the correct PIN_<config> library, which gets >>> called >>> >> out here: >>> >> >>> >> >>> >> >>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74 >>> >>> >> >>> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting >>> >> generated with the correct name in the "use" line, and make sure the >>> >> pin file you're including in the project has proper values for >>> IOWidth >>> >> and IOPorts. >>> >> >>> >> You can dig through the first part of the compile log messages to >>> >> verify the correct PIN file is _really_ getting analyzed and not some >>> >> other file. >>> >> >>> >> I'm also not sure how mixing the system verilog config files with >>> VHDL >>> >> packages works (I know just enough Verilog to generally be able to >>> >> transcode it to VHDL). If there's any problems with that, Michael B. >>> >> will have to comment. >>> >> >>> >> On 8/20/2019 8:04 AM, justin White wrote: >>> >>> I deleted my mksocfpga directory and re-pulled it and I get the same >>> >>> results after building the .rbf. >>> >>> >>> >>> Still not quite sure what's going on, though I did catch something >>> in >>> >>> Quartus. Using "0A" for stepgens in the pinfile creates 10 >>> stepgens, >>> >> but >>> >>> only the first 4 seem to be complete. #4 (the 5th stepgen) when >>> expanded >>> >>> shows blank resources for "SRL16E:\steptable:0:asr16e", but does >>> show >>> >>> resources for "SRL16E:\steptable:1:asr16e". On every stepgen after >>> they >>> >> are >>> >>> both blank which looks like it mimics exactly the problem I'm >>> having. If >>> >> "steptable:1" >>> >>> relates to the dir pin and "steptable:0" relates to the step pin, it >>> >>> explains why I have a working direction pin on #4 but no step pin, >>> and >>> >> #5 >>> >>> doesn't work at all. In this case I'd assume no later stepgens would >>> >> work. >>> >>> >>> >>> I'm not really sure how Quartus works with the configs. I'm just >>> >> dropping >>> >>> the pinfile I made into the >>> >>> '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and >>> renaming >>> >>> the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I do >>> >> with >>> >>> the mksocfpga docker build. I don't specify a pinfile or anything >>> when >>> >>> running the analysis in Quartus, yet it does seem to catch the >>> changes >>> >> I've >>> >>> made to that specific pinfile even though I don't specify anything >>> in >>> >>> Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file. >>> >>> >>> >>> Pics, QP1 shows all 10 stepgens, QP2 shows the difference between >>> the >>> >>> working #3 stepgen (0-3 all look the same) and #4 and #5 where the >>> >> problem >>> >>> starts. "combinational ALUTS" and every feild after is blank. >>> >>> >>> >>> [image: QP1.png] >>> >>> >>> >>> [image: QP2.png] >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown wrote: >>> >>>> >>> >>>> Thanx for the clairifying Charles, I doublechecked tha line and it >>> >> reads: >>> >>>> (StepGenTag, x"02", ClockLowTag, x"06", >>> >>>> StepGenRateAddr&PadT, StepGenNumRegs, x"00", >>> >> StepGenMPBitMask), >>> >>>> >>> >>>> So that should be ok... >>> >>>> >>> >>>> On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler >>> wrote: >>> >>>>> >>> >>>>> Actually, the NumInstances field of the ModuleRecord is defined as >>> an >>> >>>>> 8 bit std_logic_vector: >>> >>>>> >>> >>>>> >>> >>>>> >>> >> >>> https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L839 >>> >>> >>>>> >>> >>>>> In VHDL, it should throw an error if you use 06 for this value >>> (VHDL >>> >>>>> won't convert an integer value into a std_logic_vector without >>> some >>> >>>>> sort of type conversion). >>> >>>>> >>> >>>>> If you meant that you are using x"06" (an 8-bit hexadecimal >>> value), >>> >>>>> that should work fine, but you will only get 6 stepgens instead of >>> the >>> >>>>> 10 you'd get with x"0A". >>> >>>>> >>> >>>>> On 8/19/2019 3:19 PM, Michael Brown wrote: >>> >>>>>> No changing numinst should work just fine >>> >>>>>> >>> >>>>>> On Monday, 19 August 2019 18:05:28 UTC+2, justin White wrote: >>> >>>>>>> >>> >>>>>>> One thing I noticed, I recall seeing this the first time I >>> started >>> >>>>> messing >>> >>>>>>> with the .vhd's. All of the pinfiles in the DExx_Nano_xxx_Cramps >>> >>>>> config use >>> >>>>>>> this line for stepgens >>> >>>>>>> >>> >>>>>>> (StepGenTag, x"02", ClockLowTag, x"0A", >>> >>>>> StepGenRateAddr& >>> >>>>>>> PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >>> >>>>>>> >>> >>>>>>> The NumInst being "0A" looked a little strange to me so I >>> changed it >>> >>>>> to >>> >>>>>>> the actual number (06) for every pinfile I've been working with. >>> >> Could >>> >>>>> that >>> >>>>>>> be causing an issue? >>> >>>>>>> >>> >>>>>>> On Monday, August 19, 2019 at 11:33:29 AM UTC-4, justin White >>> wrote: >>> >>>>>>>> >>> >>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >>> >>>>>>>>>> hm2_soc_ol config line here: >>> >>>>>>>>>> < >>> >>>>> >>> >> >>> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >>> >>> >>> >> >>> >>>>> >>> >>>>>>>>>> Have you tried with: >>> >>>>>>>>>> num_stepgens=6 in the hm2_soc_ol config line ? >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>> Yes, my config line is: >>> >>>>>>>> [HOSTMOT2] >>> >>>>>>>> DRIVER=hm2_soc_ol >>> >>>>>>>> BOARD=5i25 >>> >>>>>>>> CONFIG="num_encoders=6 num_stepgens=6" "enable_adc=1" >>> >>>>>>>> DEVNAME=hm2-socfpga0 already_programmed=1 >>> >>>>>>>> >>> >>>>>>>> If the stepgens=6 wasn't there hm2 wouldn't instantiate them in >>> >> HAL. >>> >>>>> They >>> >>>>>>>> are actually completely visible and HAL seems to think they're >>> >>>>> working. I >>> >>>>>>>> dug up one of my first test hal files and #4 did in fact work >>> with >>> >>>>> that but >>> >>>>>>>> I had much less else going on. >>> >>>>>>>> >>> >>>>>>>> I'm not terribly familiar with Quartus. I usually just do as in >>> the >>> >>>>>>>> readme https://github.com/the-snowwhite/mksocfpga to build the >>> >>>>> firmware. >>> >>>>>>>> I did have an issue before where it was building firmware that >>> >>>>> wouldn't >>> >>>>>>>> boot, deleting mksocfpga and pulling it again fixed that. That >>> may >>> >>>>> even >>> >>>>>>>> have had something to do with trying to open the project >>> >> previously. >>> >>>>> Ill >>> >>>>>>>> try re-pulling it and see what happens. >>> >>>>>>>> >>> >>>>>>>> I ran the analysis in in QP and this is what I'm seeing with >>> the >>> >>>>>>>> stepgens: >>> >>>>>>>> >>> >>>>>>>> [image: QP.png] >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown >>> >> wrote: >>> >>>>>>>>> >>> >>>>>>>>> Quartus Update: >>> >>>>>>>>> After compiling (the default DE10_Nano_FB_Cramps project) >>> Notice >>> >>>>> that >>> >>>>>>>>> all 9 (0-8) stepgens instansiated in the pin file have a (not >>> >> null) >>> >>>>> sized >>> >>>>>>>>> SRL16E:\steptable:0:asr16e instance: >>> >>>>>>>>> >>> >>>>>>>>> [image: >>> Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png] >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >>> >>>>>>>>>> hm2_soc_ol config line here: >>> >>>>>>>>>> < >>> >>>>> >>> >> >>> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >>> >>> >>> >> >>> >>>>> >>> >>>>>>>>>> Have you tried with: >>> >>>>>>>>>> num_stepgens=6 in the hm2_soc_ol config line ? >>> >>>>>>>>>> >>> >>>>>>>>>> Also You can look in the Compiled (Or after analysis & >>> >> elaboration) >>> >>>>>>>>>> Quartus project and see how many stepgens are elaborated like >>> in >>> >>>>> below pic: >>> >>>>>>>>>> >>> >>>>>>>>>> [image: Quartus_Num_Stepgens.png] >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> On Monday, 19 August 2019 00:31:53 UTC+2, justin White wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> The hal component did work fine then my friend "cleaned it >>> up" >>> >> and >>> >>>>> it >>> >>>>>>>>>>> acts weird when you enable the filter. Could just remove the >>> >>>>> filter pin and >>> >>>>>>>>>>> post it but it is rather handy. >>> >>>>>>>>>>> >>> >>>>>>>>>>> I've been tracking down an issue with the stepgens and >>> depending >>> >>>>> on >>> >>>>>>>>>>> what the issue is it may be part of the smart serial issue. >>> I >>> >> have >>> >>>>> 4 out of >>> >>>>>>>>>>> 6 stepgens that work, on my 5th stepgen only the direction >>> pin >>> >>>>> works, not >>> >>>>>>>>>>> the step pin. Neither work on the 6th stepgen. I disabled >>> SS >>> >> for >>> >>>>> the time >>> >>>>>>>>>>> being but it was using consecutive pins with the 5th and 6th >>> >>>>> stepgens. It >>> >>>>>>>>>>> was difficult to see what was going on until I got my GUI >>> setup. >>> >>>>> Now I can >>> >>>>>>>>>>> see that in hal it is actually working and I'm getting >>> feedback >>> >> to >>> >>>>> the PID >>> >>>>>>>>>>> loop but the pins of the Nano itself do not electrically do >>> >>>>> anything, I can >>> >>>>>>>>>>> verify that with my scope. Thinking maybe I damaged the GPIO >>> >> pins >>> >>>>> from all >>> >>>>>>>>>>> the hardware swapping I've been doing, I picked up another >>> DE10 >>> >>>>> Nano and >>> >>>>>>>>>>> the same thing happens. I tried swapping stepgen instance >>> 0,1 >>> >> for >>> >>>>> 4,5 in >>> >>>>>>>>>>> the .vhd and rebuilt the firmware without changing any hal >>> >>>>> configuration >>> >>>>>>>>>>> and stepgens 4 and 5 work fine if they are controlling >>> different >>> >>>>> GPIO pins >>> >>>>>>>>>>> without making any hal changes. I jumped the GPIO pins for a >>> >>>>> working >>> >>>>>>>>>>> stepgen to the PCB pins I use for 4 and 5 and the interface >>> >>>>> hardware works >>> >>>>>>>>>>> fine that way. >>> >>>>>>>>>>> >>> >>>>>>>>>>> So the conclusion I'm drawing is that there's an issue with >>> the >>> >>>>>>>>>>> firmware that's getting built. hm2 thinks all 6 stepgens are >>> >> there >>> >>>>> but >>> >>>>>>>>>>> there is only 4 1/2 stepgens actually working. I seem to >>> recall >>> >>>>> there is a >>> >>>>>>>>>>> parameter that has to change to add a certain amount of >>> certain >>> >>>>> pin types, >>> >>>>>>>>>>> but I didn't think it applied in this case and I'm not sure >>> what >>> >>>>> it is. >>> >>>>>>>>>>> >>> >>>>>>>>>>> My current VHD with SS disabled attached >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, Michael >>> Brown >>> >>>>> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> OK back to being able to be online with my workstation: >>> >>>>>>>>>>>> I have allways had a fight setting up proper display >>> >> resolutions >>> >>>>> on >>> >>>>>>>>>>>> the altera soc's however I can give you some key notes: >>> >>>>>>>>>>>> In qsys there are 3 cores to consider: >>> >>>>>>>>>>>> For display timing settings: >>> >>>>>>>>>>>> alt_vip_vfr_hdmi (framereader) >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> alt_vip_itc_0 (Clocked video output) >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> The display core clock itself: >>> >>>>>>>>>>>> pll_lcd --> lcd_clk >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> 1600x900 would allow me to test it out on my mill and I >>> might >>> >>>>> have a >>> >>>>>>>>>>>>> use for 800x480. I didn't realize the resolution was >>> fixed, my >>> >>>>> 1080P >>> >>>>>>>>>>>>> monitors don't have a problem displaying 1024x768, all my >>> >> other >>> >>>>> monitors >>> >>>>>>>>>>>>> do. I suppose in a real usage scenario I'd have to look >>> >> further >>> >>>>> into your >>> >>>>>>>>>>>>> previous reply and try to figure out how to set a >>> resolution >>> >> for >>> >>>>> whatever >>> >>>>>>>>>>>>> monitor I intended to use. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Sadly there are currently no presets for these 2 >>> resolutions >>> >> for >>> >>>>> the >>> >>>>>>>>>>>> framebuffer related cores (presets are found in qsys view >>> >> menu), >>> >>>>> as I >>> >>>>>>>>>>>> havent had use of these resolutions myself (in newer time). >>> >>>>>>>>>>>> And I also have no (qsys) formula other than intuitive >>> guess >>> >>>>> work..... >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Last there is the Devicetree entry this is the current one: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>> >>> >> >>> https://github.com/the-snowwhite/soc-image-buildscripts/blob/master/SD-Image-Gen/patches/4.9.76-ltsi-rt/current/0012-Added-DE-10-Nano-with-uio-with-without-framebuffer-1.patch#L291 >>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> This entry: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> vip@0x100031000 { >>> >>>>>>>>>>>> compatible = "altr,vip-frame-reader-1.0", >>> >>>>> "ALTR,vip-frame-reader-9.1"; >>> >>>>>>>>>>>> reg = <0x00000001 0x00031000 0x00000080>; >>> >>>>>>>>>>>> max-width = <1024>; >>> >>>>>>>>>>>> max-height = <768>; >>> >>>>>>>>>>>> bits-per-color = <0x8>; >>> >>>>>>>>>>>> colors-per-beat = <0x4>; >>> >>>>>>>>>>>> beats-per-pixel = <0x1>; >>> >>>>>>>>>>>> mem-word-width = <0x80>; >>> >>>>>>>>>>>> }; >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> On Friday, 9 August 2019 03:55:13 UTC+2, justin White >>> wrote: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> On Tuesday, August 6, 2019 at 1:07:38 PM UTC-4, Michael >>> Brown >>> >>>>> wrote: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Not very easy from my cell phone here however: >>> >>>>>>>>>>>>>> In qsys there are 2 instances where you set up the >>> timings >>> >> for >>> >>>>> the >>> >>>>>>>>>>>>>> screen monitor. There should be some saved setups HD etc. >>> >>>>> Lastly you need >>> >>>>>>>>>>>>>> to place the correct screen settings in the device tree >>> there >>> >>>>> is a HD >>> >>>>>>>>>>>>>> example there too. 1920 x1080. Sorry for not being online >>> >>>>> atm... >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Gonna Give this a try soon as I get a chance. Waiting for >>> my >>> >>>>> friend >>> >>>>>>>>>>>>> to correct a minor issue with the time based filter in the >>> RT >>> >>>>> hal component >>> >>>>>>>>>>>>> he whipped up for me for the ADC then I'll post it up >>> here. >>> >>>>> Maybe you can >>> >>>>>>>>>>>>> include it in your project if you think it's useful. It >>> >>>>> certainly is for >>> >>>>>>>>>>>>> someone like me who only works with hal. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Well It would be nice with a hal rt component for >>> calculating >>> >>>>>>>>>>>> temperature readings based on ntc probes instead of the >>> python >>> >>>>> user >>> >>>>>>>>>>>> component hal_temp_atlas I derived from the hal_temp_bbb >>> .... >>> >> :-) >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Charles Steinkuehler >>> >>>>> [email protected] >>> >>>>> >>> >>>> >>> >>> >>> >> >>> >> >>> >> -- >>> >> Charles Steinkuehler >>> >> [email protected] <javascript:> >>> >> >>> > >>> >>> >>> -- >>> Charles Steinkuehler >>> [email protected] >>> >> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/4046265c-316f-4488-81dd-04f86e55d4f5%40googlegroups.com.
