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] <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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/6b1d9777-c0f9-4abb-bdd0-34513685e8cb%40googlegroups.com.
