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 >>> cha...@steinkuehler.net >>> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/9e173dc9-7bb5-a3d8-3ab5-ea1a8e1f8912%40steinkuehler.net.
