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 > >>> cha...@steinkuehler.net > >>> > >> > > > > > -- > Charles Steinkuehler > cha...@steinkuehler.net <javascript:> > -- 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/3fd50c91-a1d6-4637-9e27-6fa821746099%40googlegroups.com.
