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/582ffbc2-31cd-4cf6-af8d-f5778a890a97%40googlegroups.com.
atlas_st_fpga_soc_dc1f_ss.sv
Description: Binary data
PIN_st_fpga_soc_dc1f_ss.vhd
Description: Binary data
